Stai installando un secondo Microsoft Entra Connect in staging mode e l’installazione si interrompe con “Creation of connector … – AAD failed”? Nella quasi totalità dei casi il colpevole è l’assenza di TLS 1.2 lato server. In questa guida trovi diagnosi, verifiche e una procedura di fix solida.
Scenario e sintomi
Un amministratore tenta di predisporre un secondo server Entra (Azure AD) Connect v2.3.x in staging mode per avere un nodo di standby pronto al fail‑over. Durante il setup, il wizard fallisce quando prova a creare il connettore verso il tenant Microsoft Entra e restituisce messaggi del tipo:
Creation of connector <tenant>.onmicrosoft.com - AAD failed. This may be due to replication delay
System.Management.Automation.CmdletInvocationException …
Microsoft.IdentityManagement.PowerShell.ObjectModel.SynchronizationConfigurationValidationException …
Nell’Event Viewer e con gli strumenti classici per Active Directory (repadmin
) non compaiono errori di replica tra i DC on‑premises: questo porta spesso fuori strada, perché il testo del messaggio lascia intendere un problema AD quando, in realtà, la causa è esterna alla replica.
Che cosa succede davvero
Analizzando i log di installazione e i trace di Entra Connect compaiono ricorrentemente messaggi MSAL con codice di errore AADSTS50173 (“grant expired”) e tentativi falliti di creazione dell’account di servizio dedicato alla sincronizzazione in cloud (l’On‑Premises Directory Synchronization Service Account, tipicamente xxxx_sync@<tenant>.onmicrosoft.com
).
Amministratori diversi (ad esempio con utenti come “Bryan Thomas2”, “Mathias JWD” e altri casi d’uso simili) hanno isolato un pattern comune: il server candidato allo staging non aveva TLS 1.2 abilitato nello stack Schannel. Poiché Entra Connect ≥ 2.0 supporta solamente TLS 1.2, tutti i tentativi su TLS 1.0/1.1 vengono respinti a monte. L’errore risultante è fuorviante (“replication delay”) perché la fase che fallisce è l’apertura della sessione sicura verso i servizi Entra, non la replica tra DC.
Perché gli indizi ingannano
- Messaggi MSAL e “grant expired”: quando la TLS handshake non arriva a buon fine o si interrompe, i layer superiori (MSAL/OAuth) possono generare eccezioni generiche o apparire come problemi di autorizzazione, pur non essendo il vero punto di rottura.
- Event Viewer pulito lato AD: il percorso di errore non tocca la replica del dominio; per questo gli strumenti AD reportano tutto regolare.
- Connettore AAD non creato: il wizard prova a definire il connettore cloud, ma fallisce al momento di stabilire la connessione remota per la creazione dell’account di servizio e della relativa configurazione.
Implicazioni di sicurezza e prerequisiti
Entra Connect 2.x, rilasciato nel 2021, impone TLS 1.2 per tutti i canali verso Microsoft Entra. Il supporto a TLS 1.0/1.1 è stato dismesso e, in molti ambienti, attivamente disabilitato per motivi di sicurezza. I sistemi Windows Server 2016/2019/2022 generalmente hanno TLS 1.2 abilitato di default, ma possono verificarsi eccezioni:
- immagini RTM o installazioni molto datate non aggiornate;
- server appena preparati con hardening incompleto o baseline personalizzate;
- GPO o tool di sicurezza che hanno modificato i valori di Schannel.
Come verificare rapidamente lo stato di TLS
Prima di applicare modifiche, conviene misurare. Ecco tre controlli pratici.
Verifica del registro per Schannel
Controlla la presenza e il valore delle chiavi TLS 1.2 per client e server:
HKEYLOCALMACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client
HKEYLOCALMACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server
Valori attesi:
Enabled
=1
DisabledByDefault
=0
Verifica del registro per .NET Framework
Per le app .NET, Entra Connect incluso, è raccomandato forzare l’uso delle versioni TLS di sistema e la crittografia forte:
HKEYLOCALMACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
HKEYLOCALMACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319
Valori attesi in entrambe (quando presenti):
SystemDefaultTlsVersions
=1
SchUseStrongCrypto
=1
Test con PowerShell
Esegui dal server candidato allo staging:
# Verifica rapida dei registry keys TLS 1.2
$base = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2'
$client = Get-ItemProperty -Path "$base\Client" -Name Enabled,DisabledByDefault -ErrorAction SilentlyContinue
$server = Get-ItemProperty -Path "$base\Server" -Name Enabled,DisabledByDefault -ErrorAction SilentlyContinue
$net64 = Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -Name SystemDefaultTlsVersions,SchUseStrongCrypto -ErrorAction SilentlyContinue
$net32 = Get-ItemProperty -Path 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319' -Name SystemDefaultTlsVersions,SchUseStrongCrypto -ErrorAction SilentlyContinue
[pscustomobject]@{
TLS12ClientEnabled = $client.Enabled
TLS12ClientDisabledByDefault = $client.DisabledByDefault
TLS12ServerEnabled = $server.Enabled
TLS12ServerDisabledByDefault = $server.DisabledByDefault
Net64_SystemDefaultTlsVersions = $net64.SystemDefaultTlsVersions
Net64_SchUseStrongCrypto = $net64.SchUseStrongCrypto
Net32_SystemDefaultTlsVersions = $net32.SystemDefaultTlsVersions
Net32_SchUseStrongCrypto = $net32.SchUseStrongCrypto
} | Format-List
Procedura di correzione
Se le verifiche confermano che TLS 1.2 non è abilitato, applica i passaggi seguenti. Esegui le operazioni con privilegi amministrativi.
Abilitare TLS 1.2 nello stack Schannel
Imposta le chiavi di registro come segue. Puoi farlo con l’Editor del Registro o con script. Esempio tramite file .reg
:
; Lato client
[HKEYLOCALMACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"Enabled"=dword:00000001
"DisabledByDefault"=dword:00000000
; Lato server
[HKEYLOCALMACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"Enabled"=dword:00000001
"DisabledByDefault"=dword:00000000
Garantire che .NET Framework usi TLS 1.2
Assicurati che .NET utilizzi le versioni TLS predefinite del sistema e la crittografia forte:
[HKEYLOCALMACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto" =dword:00000001
[HKEYLOCALMACHINE\SOFTWARE\WOW6432Node\Microsoft.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto" =dword:00000001
Alternativa con PowerShell
Se preferisci scriptare la remediation:
# Abilitazione TLS 1.2 lato Client e Server
$schBase = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2'
New-Item -Path "$schBase\Client" -Force | Out-Null
New-Item -Path "$schBase\Server" -Force | Out-Null
New-ItemProperty -Path "$schBase\Client" -Name 'Enabled' -Value 1 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path "$schBase\Client" -Name 'DisabledByDefault' -Value 0 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path "$schBase\Server" -Name 'Enabled' -Value 1 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path "$schBase\Server" -Name 'DisabledByDefault' -Value 0 -PropertyType DWord -Force | Out-Null
.NET Framework: forzare TLS di sistema e strong crypto
$netPaths = @(
'HKLM:\SOFTWARE\Microsoft.NETFramework\v4.0.30319',
'HKLM:\SOFTWARE\WOW6432Node\Microsoft.NETFramework\v4.0.30319'
)
foreach($p in $netPaths){
if(-not (Test-Path $p)){ New-Item -Path $p -Force | Out-Null }
New-ItemProperty -Path $p -Name 'SystemDefaultTlsVersions' -Value 1 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $p -Name 'SchUseStrongCrypto' -Value 1 -PropertyType DWord -Force | Out-Null
}
Write-Host 'Modifiche applicate. Eseguire un riavvio del server.'
Riavvio obbligatorio
Riavvia il server per applicare le modifiche a tutti i processi e ai servizi di sistema.
Ripetere l’installazione in staging mode
Una volta eseguito il reboot, rilancia il wizard di Entra Connect, seleziona staging mode e completa la configurazione. Con TLS 1.2 attivo la creazione del connettore AAD e dell’account di servizio procede senza ulteriori errori.
Convalida post‑fix
- Wizard completato: il connettore verso
<tenant>.onmicrosoft.com
appare nella lista e non ricompaiono gli errori MSAL. - Synchronization Service Manager: il server in staging mostra le regole di sincronizzazione uguali al primario, ma con esportazioni inibite.
- Event Viewer: assenza di nuovi eventi critici da sorgenti ADSync o Directory Synchronization; presenza di eventi informativi di inizializzazione completata.
Checklist rapida
Controllo | Valore atteso | Dove verificare |
---|---|---|
TLS 1.2 lato client | Enabled=1 , DisabledByDefault=0 | Registro Schannel |
TLS 1.2 lato server | Enabled=1 , DisabledByDefault=0 | Registro Schannel |
.NET usa TLS di sistema | SystemDefaultTlsVersions=1 , SchUseStrongCrypto=1 | Registro .NET x86/x64 |
Firewall in uscita | Porta 443 aperta verso i servizi Microsoft Entra | Firewall/Proxy |
Ora e time‑sync | Skew <= 5 minuti tra server, DC e internet | NTP/Kerberos |
Certificati macchina | Store Local Machine integro, chain valida | MMC Certificati |
Account di servizio cloud | Consentita la creazione dell’On‑Premises Directory Synchronization Service Account | Portale Entra e policy del tenant |
Domande ricorrenti
Perché un Windows Server recente può avere TLS 1.2 disabilitato?
In rari casi, immagini RTM o template datati non includono gli ultimi default; hardening manuale o tool di terze parti possono avere disattivato alcune versioni TLS; talvolta GPO personalizzate sovrascrivono i valori Schannel. Per questo la verifica dei registry keys è il primo passo utile.
È sufficiente abilitare solo il lato client o anche il lato server?
Entra Connect agisce come client TLS verso i servizi cloud, ma abilitare anche la parte server è consigliabile per coprire eventuali dipendenze interne (componenti che fanno callback o interazioni locali). La prassi di hardening raccomanda di allineare entrambi.
Serve aggiornare .NET o il sistema operativo?
In genere no: impostare le chiavi SystemDefaultTlsVersions
e SchUseStrongCrypto
basta per istruire .NET a negoziare TLS 1.2. Mantenere comunque il sistema aggiornato resta una best practice.
Il messaggio “replication delay” indica davvero un problema AD?
No. È un messaggio fuorviante che si manifesta quando la connessione sicura verso Microsoft Entra non si stabilisce. Se repadmin
e i log AD non segnalano anomalie, indirizza la diagnosi verso TLS/HTTPs, proxy e MSAL.
Come posso prevenire che ricapiti?
- Inserisci nella build checklist dei server AAD Connect il controllo (e, se necessario, l’applicazione) delle chiavi Schannel e .NET.
- Applica baseline di sicurezza aggiornate che impongano TLS 1.2 e disabilitino le versioni deboli.
- Automatizza con PowerShell la verifica a ogni patching o golden image refresh.
Approfondimento tecnico
Entra Connect usa librerie MSAL per l’autenticazione‑autorizzazione verso Microsoft Entra. La catena di connessione include TLS handshake, negoziazione cifrature e scambio dei token. Se lo stack TLS del sistema non offre almeno TLS 1.2, la sessione fallisce prima ancora della richiesta MSAL. In questi casi vengono propagate eccezioni generiche (grant expired) o errori correlati alla creazione del connettore AAD, perché il componente di configurazione interpreta il fallimento come indisponibilità temporanea o ritardo.
Roadmap consigliata per lo staging
- Installare sistema operativo supportato e patch corrente.
- Verificare e abilitare TLS 1.2 (Schannel + .NET) come da sezioni precedenti.
- Preparare connettività uscente su 443 verso i servizi Microsoft Entra e, se esiste, configurare il proxy di sistema.
- Installare Entra Connect in staging mode, con le stesse opzioni del server primario (inclusi filtri OU, regole di join, attributi estesi).
- Convalidare con una full import e full sync senza esportare verso il cloud.
- Documentare la procedura di switch‑over per promuovere il server di staging a primario in caso di emergenza.
Vantaggi pratici dello staging
- Alta disponibilità: un secondo server pronto elimina punti singoli di guasto durante patching o manutenzioni.
- Zero impatto sugli oggetti cloud: in staging non vengono eseguite esportazioni, quindi è una copia “a caldo” della configurazione.
- Riduzione del tempo di ripristino: in caso di fault del primario, basta disattivare lo staging sul secondario e avviare il ciclo di esportazione.
Best practice operative
- Allineare versioni: mantieni i due server su release Entra Connect equivalenti.
- Replica della configurazione: documenta filtri OU, regole di sincronizzazione personalizzate, mappature attributi; usa script di export/import quando disponibili.
- Monitoraggio: controlla eventi ADSync, code di sincronizzazione e stato dei connector in modo continuativo anche sul nodo in staging.
- Sicurezza: applica hardening standard del sistema e verifica periodicamente TLS 1.2 e cipher suite abilitate.
Se il problema persiste dopo il fix TLS
In rari casi, dopo aver abilitato TLS 1.2, possono rimanere altri blocchi:
- Proxy aziendale: richiede autenticazione o ispezione TLS che interrompe la sessione; configura eccezioni per i domini di Microsoft Entra o imposta correttamente il proxy di sistema.
- Firewall: traffico in uscita su 443 limitato o DPI aggressivo; verifica log e regole esplicite.
- Certificati: store Local Machine incompleto o catene radici non aggiornate; aggiorna le radici attendibili.
- Skew dell’orario: sincronizzazione NTP assente o difettosa; riallinea l’ora per evitare rifiuti di token.
- Policy del tenant: restrizioni sulla creazione dell’account di servizio di sincronizzazione; verifica le impostazioni di sicurezza nel tenant.
Riepilogo dei punti da ricordare
Punto da ricordare | Dettagli |
---|---|
Requisito di sicurezza | Entra Connect 2.x impone TLS 1.2; TLS 1.0/1.1 non sono supportati. |
Windows Server “supportati” | Le build RTM di 2016/2019/2022 solitamente hanno TLS 1.2 abilitato; ambienti appena configurati o immagini personalizzate possono averlo disattivato. |
Verifiche preliminari | Oltre a TLS: firewall outbound 443, certificati macchina, ora/NTLM/Kerberos, autorizzazione alla creazione dell’On‑Premises Directory Synchronization Service Account. |
Vantaggi dello staging | Secondo server pronto al fail‑over, senza esportazioni finché lo staging resta attivo. |
Avvertenze e sicurezza dei cambi
- Backup del registro: prima di modificare le chiavi, esporta i rami interessati.
- Change management: registra il cambio e il motivo; annota il ticket per future verifiche.
- Rollback: i valori predefiniti possono essere ripristinati riportando
Enabled
a1
o rimuovendo le chiavi personalizzate, in base alla baseline aziendale.
Conclusione
L’errore “Creation of connector … – AAD failed” durante l’installazione di un secondo server Entra Connect in staging mode non è quasi mai un problema di replica AD, bensì una negoziazione TLS fallita perché TLS 1.2 non è abilitato. Abilitando TLS 1.2 nello stack Schannel e forzandone l’uso in .NET, seguito da un riavvio, l’installazione procede correttamente: il connettore AAD viene creato, i messaggi MSAL scompaiono e il server entra in staging senza anomalie.
TL;DR
Se stai vedendo “Creation of connector … – AAD failed” su Entra Connect 2.x, abilita TLS 1.2 su Schannel e .NET, riavvia, quindi ripeti il setup in staging: nella stragrande maggioranza dei casi il problema si risolve al primo colpo.
Nota operativa: se gestisci più ambienti, automatizza la verifica/abilitazione di TLS 1.2 con uno script PowerShell e includila nella pipeline di server provisioning per prevenire regressioni future.