Confrontare Active Directory Domain Services autogestito, Microsoft Entra ID e Microsoft Entra Domain Services gestito
Per offrire ad applicazioni, servizi o dispositivi l'accesso a un'identità centrale usando servizi basati su Active Directory in Azure, esistono tre modi comuni. Questa possibilità di scelta tra soluzioni di gestione delle identità consente di usare in modo flessibile la directory più appropriata per le esigenze dell'organizzazione. Se si gestiscono prevalentemente utenti solo cloud che eseguono dispositivi mobili, ad esempio, potrebbe non essere opportuno creare ed eseguire una propria soluzione di gestione delle identità Active Directory Domain Services. Si potrebbe invece usare solo Microsoft Entra ID.
Nonostante condividano nome e tecnologia, le tre soluzioni di gestione delle identità basate su Active Directory sono progettate per offrire servizi che soddisfano esigenze diverse dei clienti. A livello generale, queste soluzioni di gestione delle identità offrono i set di funzionalità seguenti.
- Active Directory Domain Services: server LDAP (Lightweight Directory Access Protocol) di livello aziendale che offre funzionalità chiave come identità e autenticazione, gestione di oggetti computer, Criteri di gruppo e trust.
- Active Directory Domain Services è un componente centrale in molte organizzazioni con un ambiente IT locale e offre funzionalità di base per l'autenticazione degli account utente e la gestione dei computer.
- Per altre informazioni, vedere la panoramica di Active Directory Domain Services nella documentazione di Windows Server.
- Microsoft Entra ID : gestione di dispositivi mobili e identità basata sul cloud che fornisce servizi di autenticazione e account utente per risorse come Microsoft 365, l'interfaccia di amministrazione di Microsoft Entra o applicazioni SaaS.
- Microsoft Entra ID può essere sincronizzato con un ambiente di Active Directory Domain Services locale per fornire un'unica identità agli utenti che lavorano in modo nativo nel cloud.
- Per altre informazioni sull'ID Microsoft Entra, vedere Che cos'è Microsoft Entra ID?
- Servizi di dominio Microsoft Entra: fornisce servizi di dominio gestiti con un subset di funzionalità di Active Directory Domain Services completamente compatibili, ad esempio l'aggiunta a un dominio, criteri di gruppo, LDAP e l'autenticazione Kerberos/NTLM.
- Domain Services si integra con Microsoft Entra ID, che può essere sincronizzato con un ambiente di Active Directory Domain Services locale. Questa capacità estende i casi d'uso delle identità centrali alle applicazioni Web tradizionali eseguite in Azure come parte di una strategia lift-and-shift.
- Per altre informazioni sulla sincronizzazione con Microsoft Entra ID e locale, vedere Modalità di sincronizzazione di oggetti e credenziali in un dominio gestito.
Questo articolo di panoramica mette a confronto il modo in cui queste soluzioni di gestione delle identità possono interagire o essere usate in modo indipendente, a seconda delle esigenze dell'organizzazione.
Servizi di dominio e Servizi di dominio Active Directory autogestito
Se si usano applicazioni e servizi che devono accedere a meccanismi di autenticazione tradizionali come Kerberos o NTLM, è possibile offrire Active Directory Domain Services nel cloud in due modi:
- Dominio gestito creato con Microsoft Entra Domain Services. Microsoft crea e gestisce le risorse necessarie.
- Dominio autogestito creato e configurato usando risorse tradizionali come le macchine virtuali, il sistema operativo guest Windows Server e Active Directory Domain Services. Si continuerà quindi ad amministrare queste risorse.
Con Servizi di dominio, i componenti principali del servizio vengono distribuiti e gestiti da Microsoft come esperienza di dominio gestito . Non si devono eseguire la distribuzione, la gestione, l'applicazione di patch e la protezione dell'infrastruttura di Active Directory Domain Services per componenti come le VM, il sistema operativo Windows Server o i controller di dominio.
Domain Services offre un sottoinsieme di funzionalità all'ambiente di Active Directory Domain Services autogestito tradizionale, riducendo alcune delle complessità di progettazione e gestione. Non è ad esempio necessario progettare e gestire foreste, domini, siti e collegamenti di replica di Active Directory. È comunque possibile creare trust tra foreste tra Servizi di dominio e ambienti locali.
Per le applicazioni e i servizi eseguiti nel cloud e devono accedere a meccanismi di autenticazione tradizionali, ad esempio Kerberos o NTLM, Servizi di dominio offre un'esperienza di dominio gestito con la quantità minima di sovraccarico amministrativo. Per altre informazioni, vedere Concetti relativi alla gestione per account utente, password e amministrazione in Servizi di dominio.
Quando si distribuisce e si esegue un ambiente Active Directory Domain Services autogestito, è necessario gestire tutti i componenti associati dell'infrastruttura e delle directory. Un ambiente Active Directory Domain Services autogestito comporta un carico di manutenzione aggiuntivo, ma consente di eseguire attività supplementari come estendere lo schema o creare trust tra foreste.
Di seguito sono illustrati i modelli di distribuzione comuni per un ambiente Active Directory Domain Services autogestito che fornisce identità ad applicazioni e servizi nel cloud.
- Ambiente AD DS solo cloud autonomo: le VM di Azure sono configurate come controller di dominio e viene creato un ambiente di AD DS solo cloud separato, non integrato con un ambiente Active Directory Domain Services locale. Per accedere alle VM nel cloud e amministrarle viene usato un diverso set di credenziali.
- Estensione del dominio locale in Azure: una rete virtuale di Azure si connette alla rete locale con una connessione VPN/ExpressRoute. Le VM di Azure si connettono alla rete virtuale di Azure e tramite questa possono essere aggiunte a un dominio nell'ambiente Active Directory Domain Services locale.
- In alternativa, è possibile creare le VM di Azure e alzarle di livello al ruolo di controller di dominio di replica dal dominio di Active Directory Domain Services locale. Questi controller di dominio eseguono la replica tramite una connessione VPN/ExpressRoute all'ambiente Active Directory Domain Services locale. Il dominio di Active Directory Domain Services locale viene di fatto esteso in Azure.
La tabella seguente illustra alcune delle funzionalità necessarie per l'organizzazione e le differenze tra un dominio gestito o un dominio di Active Directory Domain Services autogestito:
| Funzionalità | Dominio gestito | Active Directory Domain Services autogestito |
|---|---|---|
| Servizio gestito | ✓ | ✕ |
| Distribuzioni sicure | ✓ | L'amministratore protegge la distribuzione |
| Server DNS | ✓ (servizio gestito) | ✓ |
| Privilegi di amministratore di dominio o dell'organizzazione | ✕ | ✓ |
| Aggiunta a un dominio | ✓ | ✓ |
| Autenticazione di dominio con NTLM e Kerberos | ✓ | ✓ |
| Delega vincolata Kerberos | Basata sulle risorse | Basata sulle risorse e basata sull'account |
| Struttura personalizzata per le unità organizzative | ✓ | ✓ |
| Criteri di gruppo | ✓ | ✓ |
| Estensioni dello schema | ✕ | ✓ |
| Trust tra foreste/domini di AD | ✓ (solo trust tra foreste in uscita unidirezionale) | ✓ |
| LDAP sicuro (LDAPS) | ✓ | ✓ |
| Lettura LDAP | ✓ | ✓ |
| Scrittura LDAP | ✓ (all'interno del dominio gestito) | ✓ |
| Distribuzioni geograficamente distribuite | ✓ | ✓ |
Domain Services e Microsoft Entra ID
Microsoft Entra ID consente di gestire l'identità dei dispositivi utilizzati dall'organizzazione e di controllare l'accesso alle risorse aziendali da tali dispositivi. Inoltre, gli utenti possono registrare il proprio dispositivo personale (un dispositivo BYO) con Microsoft Entra ID, che fornisce un'identità al dispositivo. Microsoft Entra ID autentica quindi il dispositivo quando un utente accede a Microsoft Entra ID e utilizza il dispositivo per accedere alle risorse protette. Il dispositivo può essere gestito con software MDM (Mobile Device Management) come Microsoft Intune. Questa possibilità di gestione consente di limitare l'accesso a risorse sensibili ai dispositivi gestiti e conformi ai criteri.
I computer e i portatili tradizionali possono anche essere aggiunti a Microsoft Entra ID. Questo meccanismo offre gli stessi vantaggi della registrazione di un dispositivo personale con Microsoft Entra ID, ad esempio per consentire agli utenti di accedere al dispositivo usando le proprie credenziali aziendali.
I dispositivi aggiunti a Microsoft Entra offrono i vantaggi seguenti:
- Accesso Single Sign-On (SSO) alle applicazioni protette da Microsoft Entra ID.
- Roaming conforme ai criteri dell'organizzazione per le impostazioni utente su più dispositivi.
- Accesso a Windows Store per le aziende con le credenziali aziendali.
- Windows Hello for Business.
- Accesso alle app e alle risorse solo tramite dispositivi conformi ai criteri aziendali.
I dispositivi possono essere aggiunti a Microsoft Entra ID con o senza una distribuzione ibrida che include un ambiente di Active Directory Domain Services locale. La tabella seguente illustra i modelli comuni di proprietà dei dispositivi e come vengono in genere aggiunti a un dominio:
| Tipo di dispositivo | Piattaforme | Meccanismo |
|---|---|---|
| Dispositivi personali | Windows 10, iOS, Android, macOS | Microsoft Entra registrato |
| Dispositivo di proprietà dell'organizzazione non aggiunto a un'istanza locale di AD DS | Windows 10 | Microsoft Entra aggiunto |
| Dispositivo di proprietà dell'organizzazione aggiunto a un'istanza locale di AD DS | Windows 10 | Microsoft Entra aggiunto ibrido |
In un dispositivo registrato o aggiunto a Microsoft Entra, l'autenticazione utente avviene usando protocolli moderni basati su OAuth/OpenID Connessione. Questi protocolli, progettati per funzionare via Internet, sono ideali in scenari per dispositivi mobili in cui gli utenti accedono ovunque alle risorse aziendali.
Con i dispositivi aggiunti a Servizi di dominio, le applicazioni possono usare i protocolli Kerberos e NTLM per l'autenticazione, in modo da supportare le applicazioni legacy migrate per l'esecuzione in macchine virtuali di Azure come parte di una strategia lift-and-shift. La tabella seguente illustra le differenze nel modo in cui i dispositivi vengono rappresentati e possono eseguire l'autenticazione nella directory:
| Aspetto | Aggiunto a Microsoft Entra | Aggiunto a Domain Services |
|---|---|---|
| Dispositivo controllato da | Microsoft Entra ID | Dominio gestito di Servizi di dominio |
| Rappresentazione nella directory | Oggetti dispositivo nella directory Microsoft Entra | Oggetti computer nel dominio gestito di Servizi di dominio |
| Autenticazione | Protocolli basati su OAuth/OpenID Connect | Protocolli Kerberos e NTLM |
| Gestione | Software di gestione di dispositivi mobili (MDM), ad esempio Intune | Criteri di gruppo |
| Rete | Funziona attraverso Internet | Deve essere connesso o associato alla rete virtuale in cui è distribuito il dominio gestito |
| Ideale per... | Dispositivi mobili o desktop degli utenti finali | VM server distribuite in Azure |
Se Active Directory Domain Services locale e l'ID Microsoft Entra sono configurati per l'autenticazione federata tramite AD FS, non è disponibile alcun hash delle password (corrente/valido) in Azure DS. Gli account utente di Microsoft Entra creati prima dell'implementazione dell'autenticazione fed potrebbero avere un hash della password precedente, ma questo probabilmente non corrisponde a un hash della password locale. Di conseguenza, Domain Services non sarà in grado di convalidare le credenziali degli utenti
Passaggi successivi
Per iniziare a usare Servizi di dominio, creare un dominio gestito di Servizi di dominio usando l'interfaccia di amministrazione di Microsoft Entra.
È anche possibile ottenere altre informazioni sui concetti di gestione per account utente, password e amministrazione in Servizi di dominio e sul modo in cui gli oggetti e le credenziali vengono sincronizzati in un dominio gestito.