Come aggiungere un dispositivo Windows 10 ad Azure AD

Un dispositivo Windows 10 si aggiunge ad Azure AD quando vuoi portare identità, accesso e policy dentro il perimetro cloud di Microsoft senza dipendere da un dominio Active Directory on-premises. La differenza operativa rispetto a un join classico a dominio è che l’account utente e il device vengono registrati nel tenant Azure AD, così puoi applicare Single Sign-On, Conditional Access, MFA e controllo dello stato del dispositivo prima di concedere accesso alle risorse.

La procedura è semplice solo in apparenza. Nella pratica i problemi arrivano quasi sempre da prerequisiti mancanti: edizione di Windows non adatta, licenza non assegnata, device già registrato in un altro tenant, rete che blocca gli endpoint Microsoft o un utente che non ha diritto al join. Conviene quindi distinguere subito tra Azure AD registered, Azure AD joined e Hybrid Azure AD joined, perché la procedura cambia e cambia anche il risultato atteso.

Che cosa ottieni davvero con Azure AD join

Con un device Azure AD joined il computer diventa un dispositivo gestito dall’identità cloud del tenant. L’utente può accedere con un account organizzativo e ricevere un token di accesso integrato con Microsoft 365, Intune e applicazioni SaaS compatibili con Azure AD. Il join non sostituisce necessariamente una soluzione MDM, ma apre la strada a policy centralizzate e a un controllo molto più pulito rispetto a profili locali sparsi.

Un dispositivo registered è invece solo associato all’account per scenari BYOD e accessi meno invasivi. L’utente continua a usare il proprio Windows locale e il device viene visto dal tenant come dispositivo “conosciuto”. Per un notebook aziendale nuovo o riconfigurato, di solito il target corretto è il join completo.

Se il PC è già in dominio Active Directory e vuoi mantenerlo tale, la strada è il Hybrid Azure AD join, che richiede sincronizzazione con Azure AD Connect e una configurazione diversa. Qui parliamo invece del caso più lineare: un dispositivo Windows 10 che deve entrare direttamente in Azure AD.

Prerequisiti da verificare prima di iniziare

Prima di toccare il PC, controlla questi punti. Ti evitano gran parte dei falsi problemi.

• Edizione di Windows 10: servono edizioni supportate per Azure AD join, tipicamente Pro, Enterprise o Education. Su Home il join non è il percorso giusto.
• Connettività verso i servizi Microsoft: il device deve raggiungere gli endpoint di autenticazione e registrazione, senza proxy o firewall che spezzino l’handshake.
• Permessi lato tenant: nel portale Microsoft Entra ID l’utente deve poter fare join del dispositivo, oppure il numero massimo di dispositivi assegnati non deve essere stato superato.
• Licenza e policy: se il device dovrà essere gestito da Intune o soggetto a Conditional Access, verifica che gli utenti abbiano le licenze necessarie e che le policy siano coerenti con il nuovo stato del device.
• Stato del computer: se il PC è già registrato in un tenant diverso, o è ancora legato a un dominio non rimosso correttamente, il join può fallire o produrre comportamenti ambigui.

Un controllo rapido utile è verificare la versione del sistema e il tipo di edizione. Da prompt o PowerShell:

winver

Se vuoi verificare da shell l’edizione installata:

systeminfo | findstr /B /C:"OS Name" /C:"OS Version"

Verifiche lato tenant prima del join

Prima di partire dal PC, conviene controllare il tenant. In Microsoft Entra ID verifica che il join dei dispositivi sia consentito e che il limite per utente non sia stato raggiunto. Se la policy è restrittiva, il client Windows spesso mostra un errore poco esplicito e il problema sembra locale quando invece nasce dal portale.

Dal portale Microsoft Entra, il percorso tipico è Microsoft Entra ID > Devices > Device settings. Qui controlla almeno questi campi:

• Users may join devices to Microsoft Entra ID: deve includere l’utente o il gruppo corretto.
• Maximum number of devices per user: se è troppo basso, il join viene rifiutato quando l’utente ha già saturato il limite.
• Require Multifactor Authentication to register or join devices: se attivo, l’utente deve completare MFA durante il processo.

Se usi Intune, verifica anche che l’enrollment automatico sia coerente con il tipo di join che vuoi ottenere. Un device può essere Azure AD joined ma non ancora gestito da MDM se la configurazione lato tenant non è completa.

Procedura di aggiunta da Windows 10

Il percorso più pulito è dal pannello delle impostazioni di Windows, non da scorciatoie “creative”. Su un PC non ancora associato, apri Impostazioni > Account > Accesso a lavoro o scuola e scegli l’opzione per connetterti o eseguire il join a Microsoft Entra ID. In alcune build l’etichetta può comparire ancora come Azure AD, ma il comportamento è lo stesso.

1. Apri Impostazioni e vai su Account.
2. Seleziona Accesso a lavoro o scuola.
3. Clicca Connetti oppure Unisci questo dispositivo a Microsoft Entra ID, in base alla versione di Windows.
4. Inserisci l’account organizzativo autorizzato al join.
5. Completa eventuale MFA o verifica aggiuntiva richiesta dal tenant.
6. Conferma il nome del dispositivo e termina la procedura.

Durante il join, Windows crea il legame tra il device e il tenant e registra un set di informazioni utili per l’autenticazione e l’amministrazione. Se la procedura va a buon fine, il PC risulta visibile nel tenant come dispositivo unito, con stato coerente e utente principale associato.

Se preferisci la via più rapida per capire lo stato del dispositivo prima e dopo il join, usa questo comando:

dsregcmd /status

Le righe più utili da controllare sono quelle relative a AzureAdJoined, DomainJoined e DeviceId. Prima del join, AzureAdJoined deve risultare NO; dopo il join deve diventare YES. Se il PC è anche in dominio locale, DomainJoined sarà YES e stai guardando uno scenario diverso dal join diretto.

Come verificare che il join sia riuscito

Dopo il completamento, non fermarti alla schermata di conferma. Controlla sia lato client sia lato tenant. Sul PC, esegui di nuovo dsregcmd /status e verifica almeno questi campi:

• AzureAdJoined : YES
• DeviceAuthStatus : SUCCESS o stato equivalente coerente con il tenant
• TenantName valorizzato correttamente
• SSO State attivo dove previsto

Lato portale, apri Microsoft Entra ID > Devices e cerca il nome del PC. Il device deve comparire con stato recente e con il tipo corretto, cioè Microsoft Entra joined. Se hai Intune attivo, verifica anche che il dispositivo sia comparso nell’elenco dei device gestiti, se l’enrollment automatico era previsto.

Se vuoi un controllo più “meccanico” del registro eventi, puoi usare il Visualizzatore eventi e cercare i log relativi a User Device Registration e DeviceManagement-Enterprise-Diagnostics-Provider. Sono i primi posti dove emergono errori di autenticazione, enrollment o policy.

Troubleshooting essenziale quando il join fallisce

Quando il join si interrompe, la prima domanda non è “come forzo il join”, ma “a quale layer si rompe”. In ordine pratico: identità, rete, tenant, stato del device.

1. Errore di autenticazione o MFA: controlla che l’utente sia autorizzato al join e che la policy MFA non stia bloccando il flusso. Se il tenant richiede MFA, il prompt deve completarsi senza timeout.
2. Errore di rete: verifica che il PC raggiunga gli endpoint Microsoft senza proxy ispezionati male o firewall troppo aggressivi. Un test rapido è aprire il browser e controllare che l’accesso ai servizi Microsoft non venga intercettato da captive portal o filtri TLS.
3. Device già registrato altrove: se il computer è già associato a un altro tenant o a un vecchio profilo di join, il nuovo tentativo può fallire. In questo caso va pulito lo stato precedente prima di riprovare.

Per capire se il problema è di configurazione locale o di tenant, guarda l’output di:

dsregcmd /status

Se trovi AzureAdJoined : YES ma il tenant non è quello atteso, hai un device registrato nel posto sbagliato. Se invece trovi stato non coerente e errori di join nel log, il problema è più probabilmente nel flusso di autenticazione o nei permessi lato tenant.

Un altro controllo utile è il log operativo della registrazione dispositivo. Dal Visualizzatore eventi, cerca sotto:

Applications and Services Logs\\Microsoft\\Windows\\User Device Registration\\Admin

Qui trovi spesso il codice errore reale, molto più utile del messaggio sintetico mostrato dalla GUI.

Problemi tipici e correzioni pratiche

Se il PC è già stato usato in precedenza in un altro tenant, la soluzione corretta non è ripetere il join all’infinito. Prima va rimosso il vecchio legame. Dal client, in Accesso a lavoro o scuola, scollega eventuali account o connessioni residue. Se necessario, rimuovi il device anche dal tenant precedente, perché alcuni stati rimangono memorizzati lato cloud e continuano a bloccare il nuovo enrollment.

Se il problema è il numero massimo di dispositivi per utente, la correzione è lato tenant: aumenti il limite oppure elimini i device obsoleti che occupano ancora una quota. Se invece il blocco deriva da policy di accesso condizionale troppo aggressive, conviene creare una finestra di enrollment o un gruppo di esclusione temporaneo per i dispositivi in onboarding.

Quando il join fallisce per rete, non partire dall’idea che “Internet c’è quindi è tutto a posto”. Molti ambienti aziendali consentono solo traffico web generico ma bloccano endpoint di autenticazione, device registration o servizi di gestione. In quel caso il dispositivo vede la rete, ma non riesce a completare il handshake con Microsoft.

Post-join: cosa fare subito dopo

Una volta completato il join, esegui le verifiche minime per evitare sorprese al primo login utente. Accedi con l’account aziendale, conferma che il profilo venga creato correttamente e che il dispositivo riceva le policy previste. Se usi Intune, verifica la sincronizzazione iniziale e l’eventuale applicazione di compliance policy.

Se il device deve essere usato in produzione, controlla anche questi aspetti:

• BitLocker: se previsto dalla policy, verifica che la cifratura si attivi e che la chiave di ripristino sia salvata correttamente nel tenant.
• Conditional Access: prova l’accesso a una risorsa protetta per verificare che il device venga riconosciuto come conforme o almeno come joined.
• Sincronizzazione oraria: un orologio fuori tolleranza può rompere autenticazione e token, soprattutto in ambienti con policy strette.

Se qualcosa non torna, è meglio fermarsi subito e leggere il log invece di forzare nuovi tentativi. Un device con stato ibrido o incompleto può generare sintomi diversi a seconda dell’utente che accede e della policy che scatta.

Quando conviene ripartire da zero

Conviene azzerare e rifare la procedura quando il PC ha uno stato sporco, ad esempio dopo tentativi ripetuti, vecchi account di lavoro ancora presenti o un passaggio improprio da dominio locale a cloud. In questi casi il tempo perso a inseguire errori residui è spesso maggiore del tempo necessario per ripulire il device e rifare il join in modo corretto.

La regola pratica è questa: se dsregcmd /status mostra uno stato incoerente, il tenant non vede il device come ti aspetti e i log parlano di registrazione fallita o conflitti di identità, non insistere. Prima rimuovi il vecchio legame, verifica i prerequisiti e poi ripeti il join.

Assunzione: il lettore dispone di un tenant Microsoft Entra ID attivo, di un PC Windows 10 supportato e delle autorizzazioni necessarie per registrare il dispositivo.