Condividi tramite

Prerequisiti per la sincronizzazione cloud di Microsoft Entra

  • Articolo

Questo articolo fornisce indicazioni sull'uso della sincronizzazione cloud di Microsoft Entra come soluzione di gestione delle identità.

Requisiti dell'agente di provisioning cloud

Per usare la sincronizzazione cloud di Microsoft Entra, è necessario quanto segue:

  • Credenziali di amministratore di dominio o amministratore aziendale per creare l'account del servizio gestito di gruppo (gMSA) della 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 di Active Directory. Non è supportata l'installazione dell'agente in un controller di dominio. Per altre informazioni, vedere Implementare la protezione avanzata del server dell'agente di provisioning di Microsoft Entra.
    • Necessario per l'attributo dello schema di Active Directory: msDS-ExternalDirectoryObjectId
  • La disponibilità elevata si riferisce alla capacità della sincronizzazione cloud di Microsoft Entra di operare in modo continuo senza errori per molto tempo. Se sono installati ed eseguiti più agenti attivi, la sincronizzazione cloud di Microsoft Entra può continuare a funzionare anche se un agente non riesce. Microsoft consiglia di installare 3 agenti attivi per la disponibilità elevata.
  • Configurazione del firewall locale.

Implementare la protezione avanzata del server dell'agente di provisioning di Microsoft Entra

È consigliabile implementare la protezione avanzata per il server dell'agente di provisioning Microsoft Entra per ridurre le possibilità di attacco a questo componente critico dell'ambiente IT. Seguendo queste raccomandazioni, è possibile attenuare alcuni rischi per la sicurezza dell'organizzazione.

  • È consigliabile implementare la protezione avanzata per il server dell'agente di provisioning di Microsoft Entra come asset del Piano di controllo (precedentemente Livello 0) seguendo le indicazioni fornite in Accesso sicuro con privilegi e Modello a livelli dell'amministrazione di Active Directory.
  • Limitare l'accesso amministrativo al server dell'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 con privilegi. Gli amministratori non devono esplorare il Web, controllare la posta elettronica personale e svolgere attività di produttività quotidiane con account con privilegi elevati.
  • Seguire le indicazioni in Protezione dell'accesso con privilegi.
  • Negare l'uso dell'autenticazione NTLM con il server dell'agente di provisioning di Microsoft Entra. Ecco alcuni modi per eseguire questa operazione: Limitare NTLM sul server dell'agente di provisioning di Microsoft Entra e Limitare NTLM su un dominio
  • Assicurarsi che a ogni computer sia assegnata una password di amministratore locale univoca. Per altre informazioni, vedere Soluzione password dell'amministratore locale (Windows LAPS), che può configurare password casuali univoche in ogni workstation e server e archiviarle in Active Directory protette da un elenco di controllo di accesso. Solo gli utenti autorizzati idonei possono leggere o richiedere la reimpostazione di queste password di account amministratore locale. Per altre indicazioni sull'utilizzo di un ambiente con Windows LAPS e workstation dotate di accesso con privilegi (PAW), vedere Standard operativi basati sul principio dell'origine pulita.
  • Implementare workstation dotate di accesso con privilegi dedicate per tutto il personale con accesso con privilegi ai sistemi informativi dell'organizzazione.
  • Seguire queste linee guida aggiuntive per ridurre la superficie di attacco dell'ambiente Active Directory.
  • Seguire la procedura Monitorare le modifiche alla configurazione della federazione per configurare gli avvisi per monitorare le modifiche apportate al trust stabilito tra il proprio provider di identità 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 Active Directory. Quando si usa l'agente di provisioning Microsoft Entra, può verificarsi un problema di sicurezza se un utente malintenzionato acquisisce il controllo del server dell'agente di provisioning di Microsoft Entra e può manipolare gli utenti in Microsoft Entra ID. Per impedire a un utente malintenzionato di usare queste funzionalità per acquisire il controllo degli account di Microsoft Entra, l'autenticazione a più fattori offre sistemi di protezione tali che, anche se un utente malintenzionato riuscisse, ad esempio, a reimpostare la password di un utente tramite l'agente di provisioning Microsoft Entra, non potrebbe comunque eludere il secondo fattore.

Account del servizio gestito di gruppo

Un account del servizio gestito di gruppo è un account di dominio gestito che fornisce la gestione automatica delle password, la gestione semplificata del nome dell'entità servizio (SPN), la possibilità di delegare la gestione ad altri amministratori e di estendere questa funzionalità su più server. La sincronizzazione cloud di Microsoft Entra supporta e usa un account dei servizi gestiti del gruppo (gMSA) per l'esecuzione dell'agente. Durante la configurazione, verranno richieste le credenziali amministrative per creare account. L'account viene visualizzato come domain\provAgentgMSA$. Per altre informazioni su un gMSA, vedere: Account del servizio gestiti del gruppo

Prerequisiti per gMSA

  1. Lo schema di Active Directory nell'insieme di strutture del dominio gMSA deve essere aggiornato a Windows Server 2012 o versione successiva.
  2. Moduli RSAT di PowerShell su un controller di dominio.
  3. Almeno un controller di dominio nel dominio deve eseguire Windows Server 2012 o versione successiva.
  4. Il server aggiunto al dominio in cui viene installato l'agente deve eseguire Windows Server 2016 o versione successiva.

Account gMSA personalizzato

Se viene creato un account gMSA personalizzato, è necessario assicurarsi che l'account disponga delle seguenti autorizzazioni.

Tipo Nome Accesso Si applica a
Consentire Account gMSA Leggere tutte le proprietà Oggetti dispositivo discendenti
Consentire Account gMSA Leggere tutte le proprietà Oggetti InetOrgPerson discendenti
Consentire Account gMSA Leggere tutte le proprietà Oggetti Computer discendenti
Consentire Account gMSA Leggere tutte le proprietà Oggetti foreignSecurityPrincipal discendenti
Consentire Account gMSA Controllo completo Oggetti Gruppo discendenti
Consentire Account gMSA Leggere tutte le proprietà Oggetti User discendenti
Consentire Account gMSA Leggere tutte le proprietà Oggetti Contact discendenti
Consentire Account gMSA Creare/eliminare oggetti Utenti Questo oggetto e tutti i discendenti

Per informazioni su come aggiornare un agente esistente per l'uso di un account gMSA, vedere Account del servizio gestito di gruppo.

Per altre informazioni su come preparare Active Directory per l'account del servizio gestito del gruppo, vedere la Panoramica sugli account del servizio gestito di gruppo e Gli account del servizio gestito di gruppo con la sincronizzazione cloud.

Nell'interfaccia di amministrazione di Microsoft Entra

  1. Creare un account amministratore delle identità ibride di tipo solo cloud nel tenant di Microsoft Entra. In questo modo è possibile gestire la configurazione del tenant in caso di errore o mancata disponibilità dei servizi locali. Altre informazioni su come aggiungere un account amministratore delle identità ibride di tipo solo cloud. Il completamento di questo passaggio è fondamentale ed evita di rimanere bloccati fuori dal tenant.
  2. Aggiungere uno o più nomi di dominio personalizzati al tenant di Microsoft Entra. Gli utenti possono accedere usando uno di questi nomi di dominio.

Nella directory personale di Active Directory

Eseguire lo strumento IdFix per preparare gli attributi di directory per la sincronizzazione.

Nell'ambiente locale

  1. Identificare un server host aggiunto a un dominio che esegue Windows Server 2016 o versione successiva con almeno 4 GB di RAM e il runtime di .NET 4.7.1.
  2. I criteri di esecuzione di PowerShell nel server locale devono essere impostati su Undefined o RemoteSigned.
  3. Se è presente un firewall tra i server e Microsoft Entra ID, consultare Requisiti del firewall e del proxy.

Nota

L'installazione dell'agente di provisioning cloud in Windows Server Core non è supportata.

Effettuare il provisioning di Microsoft Entra ID 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 le licenze di Microsoft Entra ID P1. Per trovare la licenza corretta per le proprie esigenze, vedere il confronto delle funzionalità di Microsoft Entra ID disponibili a livello generale.

Requisiti generali

  • Account Microsoft Entra con almeno un ruolo di amministratore delle identità ibride.
  • Ambiente Active Directory Domain Services locale con sistema operativo Windows Server 2016 o versioni successive.
    • Necessario per l'attributo dello schema di Active Directory: msDS-ExternalDirectoryObjectId
  • Agente di provisioning con versione build 1.1.1370.0 o versioni successive.

Nota

Le autorizzazioni per l'account del servizio vengono assegnate solo durante l'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 lettura, scrittura, creazione ed eliminazione di tutte le proprietà per tutti i gruppi e gli oggetti utente discendenti.

Queste autorizzazioni non vengono applicate agli oggetti AdminSDHolder per impostazione predefinita cmdlet di PowerShell gMSA 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).
    • Necessario per la ricerca nel catalogo globale per filtrare riferimenti ad appartenenze non valide
  • Microsoft Entra Connect Sync con la 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à

Quanto segue è supportato:

  • Sono supportati solo i gruppi di sicurezza creati nel cloud
  • Questi gruppi possono avere gruppi di appartenenza dinamica o assegnata.
  • Questi gruppi possono contenere solo utenti sincronizzati locali e/o altri gruppi di sicurezza creati nel cloud.
  • Gli account utente locali sincronizzati e membri di questo gruppo di sicurezza creato dal cloud possono appartenere allo stesso dominio o tra domini, ma tutti devono appartenere alla stessa foresta.
  • Questi gruppi vengono sottoposti a writeback con l'ambito dei gruppi universale di Active Directory. 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. Ciò significa che se un tenant ha una combinazione di utenti e gruppi che supera i 150.000 oggetti, il tenant non è supportato.
  • Ogni gruppo annidato figlio 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 nel cloud.
  • Tutti questi utenti devono avere l'attributo onPremisesObjectIdentifier impostato sul relativo account.
  • L'attributo onPremisesObjectIdentifier deve corrispondere a un objectGUID corrispondente nell'ambiente di Active Directory di destinazione.
  • Un attributo objectGUID degli utenti locali può essere sincronizzato con un attributo onPremisesObjectIdentifier degli utenti cloud con la sincronizzazione cloud di Microsoft Entra (1.1.1370.0) o la sincronizzazione cloud di Microsoft Entra (2.2.8.0)
  • Se si usa la sincronizzazione cloud di Microsoft Entra (2.2.8.0) per sincronizzare gli utenti, invece della sincronizzazione cloud di Microsoft Entra, e si vuole usare il provisioning in Active Directory, deve essere 2.2.8.0 o versione successiva.
  • Per il provisioning da Microsoft Entra ID ad Active Directory sono supportati solo i normali tenant di Microsoft Entra ID. I tenant, ad esempio B2C, non sono supportati.
  • Il processo di provisioning del gruppo è pianificato per l'esecuzione ogni 20 minuti.

Altri requisiti

Requisiti TLS

Nota

Transport Layer Security (TLS) è un protocollo che garantisce comunicazioni sicure. Eventuali modifiche alle impostazioni TLS influiscono sull'intera foresta. Per ulteriori informazioni, vedere Aggiornamento per abilitare TLS 1.1 e TLS 1.2 come protocollo di protezione predefinito in WinHTTP in Windows.

Nel server Windows che ospita l'agente di cloud provisioning di Microsoft Entra Connect deve essere abilitato il protocollo TLS 1.2 per poter eseguire l'installazione.

Per abilitare il protocollo TLS 1.2, seguire questa procedura.

  1. Impostare le chiavi del Registro di sistema seguenti copiando il contenuto in un file .reg e quindi eseguendolo (fare clic con il pulsante destro del mouse 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

  2. Riavviare il server.

Requisiti di firewall e proxy

Se è presente un firewall tra i server e Microsoft Entra ID, configurare gli elementi seguenti:

  • Assicurarsi che gli agenti possano effettuare richieste in uscita in Microsoft Entra ID sulle 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) Se la porta 443 non è disponibile, gli agenti di autenticazione segnalano il proprio stato ogni dieci minuti attraverso la porta 8080. Questo stato viene visualizzato nell'interfaccia di amministrazione di Microsoft Entra.

  • Se il firewall applica regole in base agli utenti di origine, aprire queste porte per il traffico proveniente da servizi di Windows in esecuzione come servizi di rete.

  • Assicurarsi che il proxy supporti come minimo 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 di Microsoft Entra.
*.microsoftonline.com
*.microsoft.com
*.msappproxy.com
*.windowsazure.com		 L'agente usa questi URL per comunicare con il servizio cloud di Microsoft Entra.
mscrl.microsoft.com:80
crl.microsoft.com:80
ocsp.msocsp.com:80
www.microsoft.com:80		 L'operatore usa questi URL per verificare i certificati.
login.windows.net L'operatore 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 delta

  • Il filtro dell'ambito del gruppo per la sincronizzazione delta non supporta più di 50.000 membri.
  • All'eliminazione di un gruppo usato come parte di un filtro di ambito del gruppo, non vengono eliminati gli utenti membri del gruppo.
  • Quando si rinomina l'unità organizzativa o il gruppo incluso nell'ambito, con la sincronizzazione delta non verranno rimossi gli utenti.

Log di provisioning

  • I log di provisioning non distinguono chiaramente le operazioni di creazione e aggiornamento. È possibile che venga visualizzata 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 sarà in grado di riconoscere la modifica del nome in AD. Il processo non entra in quarantena e rimane integro.

Filtro per la definizione dell'ambito

Quando si usa il filtro di ambito dell'unità organizzativa

  • La configurazione dell'ambito ha una limitazione di 4 MB di lunghezza del carattere. In un ambiente testato standard, questo si traduce in circa 50 unità organizzative separate (OU) o gruppi di sicurezza, inclusi i metadati necessari per una determinata configurazione.

  • Sono supportate unità organizzative annidate, ovvero è possibile sincronizzare un'unità organizzativa con 130 unità organizzative annidate, ma non è possibilesincronizzare 60 unità organizzative separate nella stessa configurazione.

Sincronizzazione dell'hash delle password

  • L'uso della sincronizzazione dell'hash delle password con InetOrgPerson non è supportato.

Passaggi successivi