Prerequisiti per Microsoft Entra Cloud Sync
Questo articolo fornisce indicazioni sull'uso di Microsoft Entra Cloud Sync come soluzione di gestione delle identità.
Requisiti dell'agente di cloud provisioning
Per usare Microsoft Entra Cloud Sync, è necessario quanto segue:
- Credenziali di amministratore di dominio o amministratore dell'organizzazione per creare l'account del servizio gestito di gruppo (gMSA) per la sincronizzazione cloud di Microsoft Entra Connect, per eseguire il servizio agente.
- Un account di amministratore delle identità ibride per il tenant di Microsoft Entra che non è un utente guest.
- Un server locale per l'agente di provisioning con Windows 2016 o versione successiva. Questo server deve essere un server di livello 0 basato sul modello di livello amministrativo Active Directory. L'installazione dell'agente in un controller di dominio è supportata. Per ulteriori informazioni, vedere Irrobustisci il server dell'agente di provisioning di Microsoft Entra
- Obbligatorio per l'attributo dello schema di Active Directory - msDS-ExternalDirectoryObjectId
- La disponibilità elevata si riferisce alla capacità di Microsoft Entra Cloud Sync di operare in modo continuo senza errori per molto tempo. Se sono installati ed eseguiti più agenti attivi, Microsoft Entra Cloud Sync può continuare a funzionare anche se un agente non riesce. Microsoft consiglia di installare 3 agenti attivi per la disponibilità elevata.
- Configurazioni del firewall locale.
Rafforzare il server dell'agente di provisioning di Microsoft Entra
È consigliabile rafforzare il server dell'agente di provisioning di Microsoft Entra per ridurre la superficie di attacco di sicurezza per questo componente critico dell'ambiente IT. Seguendo queste raccomandazioni è possibile attenuare alcuni rischi per la sicurezza per l'organizzazione.
- È consigliabile rafforzare la protezione del server agente di provisioning di Microsoft Entra come risorsa del Piano di Controllo (precedentemente Livello 0) seguendo le indicazioni fornite in Secure Privileged Access e modello di livello amministrativo di Active Directory.
- Limitare l'accesso amministrativo al server agente di provisioning di Microsoft Entra solo agli amministratori di dominio o ad altri gruppi di sicurezza strettamente controllati.
- Creare un account dedicato per tutto il personale con accesso privilegiato. Gli amministratori non devono esplorare il Web, controllare la posta elettronica e svolgere attività di produttività quotidiane con account con privilegi elevati.
- Seguire le indicazioni fornite in Protezione dell'accesso privilegiato.
- Impedire l'uso dell'autenticazione NTLM con l'agente di provisioning del server di Microsoft Entra. Ecco alcuni modi per eseguire questa operazione: Limitare NTLM sul Server degli agenti di provisioning di Microsoft Entra e Limitare NTLM su un dominio
- Verificare che ogni computer disponga di una password di amministratore locale univoca. Per ulteriori informazioni, vedere Soluzione password amministratore locale (Windows LAPS), che può configurare password casuali univoche su ciascuna workstation e server, archiviarle in Active Directory e proteggerle tramite una lista di controllo degli accessi (ACL). Solo gli utenti autorizzati idonei possono leggere o richiedere la reimpostazione di queste password dell'account amministratore locale. Altre indicazioni per l'uso di un ambiente con Windows LAPS e workstation con accesso privilegiato (workstation PAWs) sono disponibili in standard operativi basati sul principio dell'origine pulita.
- Implementare workstation di accesso con privilegi dedicate per tutto il personale con accesso con privilegi ai sistemi informativi dell'organizzazione.
- Segui queste linee guida aggiuntive per ridurre la superficie di attacco dell'ambiente Active Directory.
- Seguire il Monitorare le modifiche apportate alla configurazione della federazione per configurare gli avvisi per monitorare le modifiche apportate all'attendibilità stabilita tra Idp e Microsoft Entra ID.
- Abilitare l'autenticazione a più fattori (MFA) per tutti gli utenti con accesso con privilegi in Microsoft Entra ID o in AD. Un problema di sicurezza relativo all'uso dell'agente di provisioning di Microsoft Entra è che se un attaccante può ottenere il controllo sul server dell'agente di provisioning di Microsoft Entra, può manipolare gli utenti in Microsoft Entra ID. Per impedire a un utente malintenzionato di usare queste funzionalità per assumere gli account Microsoft Entra, MFA offre protezioni. Ad esempio, anche se un utente malintenzionato riesce a reimpostare la password di un utente usando l'agente di provisioning di Microsoft Entra, non può comunque ignorare il secondo fattore.
Account del servizio gestito di gruppo
Un account di servizio gestito di gruppo è un account di dominio gestito che offre la gestione automatica delle password e una gestione semplificata del nome principale del servizio (SPN). Offre anche la possibilità di delegare la gestione ad altri amministratori ed estende questa funzionalità su più server. Microsoft Entra Cloud Sync supporta e utilizza un gMSA per l'esecuzione dell'agente. Durante l'installazione verranno richieste credenziali amministrative per creare l'account. L'account viene visualizzato come domain\provAgentgMSA$
. Per ulteriori informazioni su un gMSA, vedere account del servizio gestito del gruppo.
Prerequisiti per gli account del servizio gestito di gruppo (gMSA)
- Lo schema di Active Directory nella foresta del dominio gMSA deve essere aggiornato per Windows Server 2012 o versione successiva.
- moduli RSAT di PowerShell su un controller di dominio.
- Almeno un controller di dominio nel dominio deve eseguire Windows Server 2012 o versione successiva.
- Un server aggiunto a un dominio in cui è installato l'agente deve essere Windows Server 2016 o versione successiva.
Account gMSA personalizzato
Se stai creando un account gMSA personalizzato, devi assicurarti che l'account abbia le seguenti autorizzazioni.
Digitare | Nome | Accesso | Si applica a |
---|---|---|---|
Consenti | Account di Servizio Gestito di Gruppo | Leggere tutte le proprietà | Oggetti discendenti del dispositivo |
Permettere | Account gMSA (Account del servizio gestito del gruppo) | Leggere tutte le proprietà | Oggetti InetOrgPerson discendenti |
Consenti | Account del Servizio Gestito di Gruppo | Leggere tutte le proprietà | Oggetti di Computer discendenti |
Consenti | Account gMSA (Group Managed Service Account) | Leggere tutte le proprietà | Oggetti discendenti "foreignSecurityPrincipal" |
Permettere | Account gMSA del gruppo | Controllo completo | Oggetti del Gruppo discendenti |
Consenti | Account gMSA (Account del Servizio Gestito di Gruppo) | Leggere tutte le proprietà | Oggetti utenti discendenti |
Consentire | Account del servizio gestito del gruppo | Leggere tutte le proprietà | Oggetti discendenti di contatto |
Consenti | Account del servizio gestito del gruppo | Creare/eliminare oggetti utente | Questo oggetto e tutti gli oggetti discendenti |
Per informazioni su come aggiornare un agente esistente per l'uso di un account del servizio gestito del gruppo, vedere account di servizio gestito del gruppo.
Per altre informazioni su come preparare Active Directory per gli account di servizio gestiti di gruppo, vedere la Panoramica degli account di servizio gestiti di gruppo e Account di servizio gestiti di gruppo con sincronizzazione cloud.
Nel centro di amministrazione di Microsoft Entra
- Creare un account Amministratore delle Identità Ibride solo cloud nel tenant di Microsoft Entra. In questo modo, è possibile gestire la configurazione del tenant se i servizi locali hanno esito negativo o diventano non disponibili. Informazioni su come aggiungere un account amministratore delle identità ibride solo cloud. Completare questo passaggio è fondamentale per evitare di essere escluso dal tenant.
- Aggiungi uno o più nomi di dominio personalizzati al tenant di Microsoft Entra. Gli utenti possono accedere con uno di questi nomi di dominio.
Nella tua directory in Active Directory
Eseguire lo strumento IdFix per preparare gli attributi della directory per la sincronizzazione.
Nell'ambiente locale
- Identificare un server host aggiunto a un dominio che esegue Windows Server 2016 o versione successiva con almeno 4 GB di RAM e runtime .NET 4.7.1+.
- I criteri di esecuzione di PowerShell nel server locale devono essere impostati su Undefined o RemoteSigned.
- Se è presente un firewall tra i server e l'ID di Microsoft Entra, vedere Requisiti del firewall e del proxy.
Nota
L'installazione dell'agente di provisioning cloud in Windows Server Core non è supportata.
Effettuare il provisioning dell'ID Microsoft Entra in Active Directory - Prerequisiti
Per implementare i gruppi di provisioning in Active Directory, sono necessari i prerequisiti seguenti.
Requisiti di licenza
L'uso di questa funzionalità richiede licenze microsoft Entra ID P1. Per trovare la licenza appropriata per i tuoi requisiti, vedere Confronta le funzionalità generalmente disponibili di Microsoft Entra ID.
Requisiti generali
- Account Microsoft Entra con almeno un ruolo di Amministratore di Identità Ibride.
- Ambiente Active Directory Domain Services locale con sistema operativo Windows Server 2016 o versione successiva.
- Obbligatorio per l'attributo dello schema di Active Directory - msDS-ExternalDirectoryObjectId
- Agente di provisioning con versione build 1.1.1370.0 o versione successiva.
Nota
Le autorizzazioni per l'account del servizio vengono assegnate esclusivamente durante un'installazione pulita. Se si esegue l'aggiornamento dalla versione precedente, è necessario assegnare manualmente le autorizzazioni usando il cmdlet di PowerShell:
$credential = Get-Credential
Set-AADCloudSyncPermissions -PermissionType UserGroupCreateDelete -TargetDomain "FQDN of domain" -EACredential $credential
Se le autorizzazioni vengono impostate manualmente, è necessario assicurarsi che la lettura, la scrittura, la creazione e l'eliminazione di tutte le proprietà siano garantite per tutti i gruppi e per tutti gli oggetti utente discendenti.
Queste autorizzazioni non vengono applicate agli oggetti AdminSDHolder per impostazione predefinita cmdlet PowerShell dell'agente di provisioning Microsoft Entra
- L'agente di provisioning deve essere in grado di comunicare con uno o più controller di dominio sulle porte TCP/389 (LDAP) e TCP/3268 (Catalogo globale).
- Obbligatorio per la ricerca del catalogo globale per escludere riferimenti di appartenenza non validi
- Sincronizzazione Microsoft Entra Connect con versione build 2.2.8.0 o versioni successive
- Obbligatorio per supportare l'appartenenza utente locale sincronizzata con Microsoft Entra Connect Sync
- Obbligatorio per sincronizzare AD:user:objectGUID con AAD:user:onPremisesObjectIdentifier
Gruppi supportati e limiti di scalabilità
Sono supportati i seguenti elementi:
- Sono supportati solo i gruppi di sicurezza creati nel cloud.
- Questi gruppi possono avere gruppi di appartenenza assegnati o dinamici.
- Questi gruppi possono contenere solo utenti sincronizzati locali e/o altri gruppi di sicurezza creati dal cloud.
- Gli account utente locali sincronizzati, che sono membri di questo gruppo di sicurezza creato nel cloud, possono appartenere allo stesso dominio o a domini diversi, ma tutti devono appartenere alla stessa foresta.
- Questi gruppi vengono riscritti con l'ambito universale dei gruppi di Active Directory di . L'ambiente locale deve supportare l'ambito del gruppo universale.
- I gruppi con dimensioni superiori a 50.000 membri non sono supportati.
- I tenant con più di 150.000 oggetti non sono supportati. Se un tenant ha una combinazione di utenti e gruppi che superano 150.000 oggetti, il tenant non è supportato.
- Ogni gruppo nido diretto viene conteggiato come un membro nel gruppo di riferimento
- La riconciliazione dei gruppi tra Microsoft Entra ID e Active Directory non è supportata se il gruppo viene aggiornato manualmente in Active Directory.
Informazioni aggiuntive
Di seguito sono riportate informazioni aggiuntive sui gruppi di provisioning in Active Directory.
- I gruppi di cui è stato effettuato il provisioning in ACTIVE Directory tramite la sincronizzazione cloud possono contenere solo utenti sincronizzati locali e/o altri gruppi di sicurezza creati dal cloud.
- Questi utenti devono avere l'attributo onPremisesObjectIdentifier impostato sul proprio account.
- L'onPremisesObjectIdentifier deve corrispondere a un objectGUID nell'ambiente AD di destinazione.
- L'attributo objectGUID degli utenti locali può essere sincronizzato con l'attributo onPremisesObjectIdentifier degli utenti cloud utilizzando Microsoft Entra Cloud Sync (1.1.1370.0) o Microsoft Entra Connect Sync (2.2.8.0)
- Se stai utilizzando Microsoft Entra Connect Sync (2.2.8.0) per sincronizzare gli utenti, invece di Microsoft Entra Cloud Sync, e desideri utilizzare il provisioning in AD, la versione deve essere 2.2.8.0 o successiva.
- Per il provisioning da Microsoft Entra ID ad Active Directory sono supportati solo i normali tenant di Microsoft Entra ID. I tenant, come ad esempio B2C, non sono supportati.
- Il processo di provisioning del gruppo è pianificato per essere eseguito ogni 20 minuti.
Altri requisiti
- Requisito minimo Microsoft .NET Framework 4.7.1
Requisiti TLS
Nota
Transport Layer Security (TLS) è un protocollo che fornisce comunicazioni sicure. La modifica delle impostazioni TLS influisce sull'intera foresta. Per altre informazioni, vedere Update per abilitare TLS 1.1 e TLS 1.2 come protocolli sicuri predefiniti in WinHTTP in Windows.
Il server Windows che ospita l'agente di provisioning cloud Microsoft Entra Connect deve avere TLS 1.2 abilitato prima di installarlo.
Per abilitare TLS 1.2, seguire questa procedura.
Impostare le chiavi del Registro di sistema seguenti copiando il contenuto in un file .reg e quindi eseguendo il file (selezionare con il pulsante destro del mouse sul file e scegliere Unisci):
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319] "SchUseStrongCrypto"=dword:00000001
Riavviare il server.
Requisiti del firewall e del proxy
Se è presente un firewall tra i server e Microsoft Entra ID, configurare gli elementi seguenti:
Assicurarsi che gli agenti possano effettuare richieste di in uscita a Microsoft Entra ID attraverso le porte seguenti:
Numero di porta Descrizione 80 Scarica gli elenchi di revoche di certificati (CRL) durante la convalida del certificato TLS/SSL. 443 Gestisce tutte le comunicazioni in uscita con il servizio. 8080 (facoltativo) Gli agenti segnalano lo stato ogni 10 minuti sulla porta 8080, se la porta 443 non è disponibile. Questo stato viene visualizzato nell'interfaccia di amministrazione di Microsoft Entra. Se il firewall applica regole in base agli utenti di provenienza, aprire queste porte per il traffico dai servizi Windows eseguiti come servizio di rete.
Assicurarsi che il proxy supporti almeno il protocollo HTTP 1.1 e che la codifica in blocchi sia abilitata.
Se il firewall o il proxy consente di specificare suffissi sicuri, aggiungere connessioni:
URL | Descrizione |
---|---|
*.msappproxy.net *.servicebus.windows.net |
L'agente usa questi URL per comunicare con il servizio cloud Microsoft Entra. |
*.microsoftonline.com *.microsoft.com *.msappproxy.com *.windowsazure.com |
L'agente usa questi URL per comunicare con il servizio cloud Microsoft Entra. |
mscrl.microsoft.com:80
crl.microsoft.com:80
ocsp.msocsp.com:80
www.microsoft.com:80
|
L'agente usa questi URL per verificare i certificati. |
login.windows.net |
L'agente usa questi URL durante il processo di registrazione. |
Requisito NTLM
Non è consigliabile abilitare NTLM sul Windows Server che esegue l'agente di provisioning di Microsoft Entra e, se è abilitato, assicurarsi di disabilitarlo.
Limitazioni note
Di seguito sono riportate le limitazioni note:
Sincronizzazione differenziale
- Il filtro dell'ambito del gruppo per la sincronizzazione differenziale non supporta più di 50.000 membri.
- Quando si elimina un gruppo utilizzato come filtro di ambito per un altro gruppo, gli utenti che sono membri del gruppo non vengono eliminati.
- Quando si rinomina l'unità organizzativa o il gruppo incluso nell'ambito, la sincronizzazione differenziale non rimuove gli utenti.
Log di provisioning
- I log di provisioning non distinguono chiaramente le operazioni di creazione e aggiornamento. È possibile visualizzare un'operazione di creazione per un aggiornamento e un'operazione di aggiornamento per una creazione.
Ridenominazione dei gruppi o ridenominazione dell'unità organizzativa
- Se si rinomina un gruppo o un'unità organizzativa in Active Directory nell'ambito di una determinata configurazione, il processo di sincronizzazione cloud non è in grado di riconoscere la modifica del nome in ACTIVE Directory. Il lavoro non va in quarantena e rimane sano.
Filtro di ambito
Quando si usa il filtro di ambito dell'unità organizzativa
La configurazione dell'ambito ha una limitazione di lunghezza di 4 MB in termini di caratteri. In un ambiente testato standard, questo si traduce in circa 50 unità organizzative separate (UNITÀ organizzative) o gruppi di sicurezza, inclusi i metadati necessari, per una determinata configurazione.
Sono supportate unità organizzative nidificate, ovvero è possibile sincronizzare un'unità organizzativa con 130 unità organizzative nidificate, ma non è possibile sincronizzare 60 unità organizzative separate nella stessa configurazione.
Sincronizzazione dell'hash delle password
- L'uso della sincronizzazione dell'hash delle password con InetOrgPerson non è supportato.