Condividi tramite

Confrontare i servizi di dominio Active Directory auto-gestiti, Microsoft Entra ID e i servizi di dominio gestiti Microsoft Entra

  • Articolo

Per fornire alle applicazioni, ai servizi o ai dispositivi l'accesso a un'identità centrale, esistono tre modi comuni per usare i servizi basati su Active Directory in Azure. Questa scelta nelle soluzioni di gestione delle identità offre la flessibilità necessaria per usare la directory più appropriata per le esigenze dell'organizzazione. Ad esempio, se si gestiscono principalmente utenti solo cloud che eseguono dispositivi mobili, potrebbe non essere opportuno compilare ed eseguire la propria soluzione di gestione delle identità di Active Directory Domain Services (AD DS). È invece possibile usare solo l'ID Entra di Microsoft.

Anche se le tre soluzioni di identità basate su Active Directory condividono un nome e una tecnologia comuni, sono progettate per fornire servizi che soddisfano esigenze diverse dei clienti. A livello generale, queste soluzioni di identità e set di funzionalità sono:

  • Active Directory Domain Services (AD DS) - Un server LDAP (Lightweight Directory Access Protocol) adatto alle esigenze aziendali che fornisce funzionalità chiave come identità e autenticazione, gestione degli oggetti computer, criteri di gruppo e relazioni di trust.
  • 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 funzionano in modo nativo nel cloud.
    • Per altre informazioni sull'ID Microsoft Entra, vedere Che cos'è Microsoft Entra ID?
  • microsoft Entra Domain Services : 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.
    • I servizi di dominio si integrano con Microsoft Entra ID, che a sua volta può essere sincronizzato con un ambiente locale di Active Directory Domain Services. Questa funzionalità estende i casi d'uso delle identità centrali alle applicazioni web tradizionali eseguite in Azure come parte di una strategia lift-and-shift.
    • Per ulteriori informazioni sulla sincronizzazione con Microsoft Entra ID e in sede, vedere Come oggetti e credenziali vengono sincronizzati in un dominio gestito.

Questo articolo di panoramica confronta e contrasta il modo in cui queste soluzioni di gestione delle identità possono interagire o verranno usate in modo indipendente, a seconda delle esigenze dell'organizzazione.

Per iniziare, crea un dominio gestito dei Servizi di dominio usando l'interfaccia di amministrazione di Microsoft Entra

Servizi di dominio e Servizi di dominio di Active Directory autogestiti

Se si dispone di applicazioni e servizi che richiedono l'accesso a meccanismi di autenticazione tradizionali, ad esempio Kerberos o NTLM, esistono due modi per fornire Servizi di dominio Active Directory nel cloud:

  • Un dominio gestito che crei con Microsoft Entra Domain Services. Microsoft crea e gestisce le risorse necessarie.
  • Un dominio autogestito creato e configurato utilizzando risorse tradizionali, come macchine virtuali (VM), guest OS di Windows Server e Servizi di dominio Active Directory. Quindi continui ad amministrare queste risorse.

Con Servizi di dominio, i componenti principali del servizio vengono distribuiti e gestiti da Microsoft come un'esperienza di dominio gestita. Non ti occupi di implementare, gestire, effettuare patch e proteggere l'infrastruttura di Active Directory Domain Services per componenti come le macchine virtuali, il sistema operativo Windows Server o i controller di dominio.

Domain Services offre un sottoinsieme più ridotto di funzionalità rispetto all'ambiente tradizionale di Active Directory Domain Services autogestiti, riducendo alcune delle complessità di progettazione e gestione. Ad esempio, in Active Directory non sono presenti foreste, domini, siti e collegamenti di replica da progettare e gestire. È comunque possibile creare trust di foresta tra Servizi di dominio Active Directory 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 ulteriori informazioni, vedere i concetti di gestione per account utente, password e amministrazione in Servizi di dominio .

Quando si distribuisce ed esegue un ambiente Active Directory Domain Services autogestito, è necessario gestire tutti i componenti di infrastruttura e directory associati. È previsto un onere di manutenzione aggiuntivo con un ambiente di Active Directory Domain Services autogestito, ma è possibile eseguire attività ulteriori, come estendere lo schema o creare trust tra foreste.

I modelli di distribuzione comuni per un ambiente di Active Directory Domain Services autogestito che fornisce l'identità alle applicazioni e ai servizi nel cloud includono quanto segue:

  • Servizi di dominio Active Directory (AD DS) autonomo solo cloud - le macchine virtuali di Azure vengono configurate come controller di dominio e viene creato un ambiente AD DS separato e solo cloud. Questo ambiente di Active Directory Domain Services non si integra con un ambiente di Active Directory Domain Services locale. Viene usato un set diverso di credenziali per accedere e amministrare le macchine virtuali nel cloud.
  • Estendere il dominio locale ad Azure: una rete virtuale di Azure si connette a una rete locale usando una connessione VPN/ExpressRoute. Le macchine virtuali di Azure si connettono a questa rete virtuale di Azure, che consente di aggiungere un dominio all'ambiente di Active Directory Domain Services locale.
    • Un'alternativa consiste nel creare macchine virtuali di Azure e alzarle di livello come controller di dominio di replica dal dominio di Active Directory Domain Services locale. Questi controller di dominio replicano tramite una connessione VPN/ExpressRoute verso l'ambiente locale di Active Directory Domain Services. Il dominio di Active Directory Domain Services locale viene esteso in modo efficace 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 (AD DS) autogestito
servizio gestito ✓ ✕
distribuzioni sicure ✓ L'amministratore protegge la distribuzione
server DNS ✓ (servizio gestito) ✓
privilegi di amministratore del dominio o di azienda × ✓
aggiunta a un dominio ✓ ✓
autenticazione del dominio tramite NTLM e Kerberos ✓ ✓
delega vincolata Kerberos Basato sulle risorse Basato su risorse & basato su account
Struttura personalizzata dell'unità organizzativa ✓ ✓
criteri di gruppo ✓ ✓
estensioni dello schema ✕ ✓
dominio e trust forestale di AD ✓ (L'anteprima richiede lo SKU Enterprise) ✓
LDAP (LDAPS) sicuro ✓ ✓
di lettura LDAP ✓ ✓
di scrittura LDAP ✓ (all'interno del dominio gestito) ✓
Distribuzioni geografiche ✓ ✓

Domain Services e Microsoft Entra ID

Microsoft Entra ID consente di gestire l'identità dei dispositivi usati dall'organizzazione e di controllare l'accesso alle risorse aziendali da tali dispositivi. Gli utenti possono anche registrare il proprio dispositivo personale (un modello BYO) con Microsoft Entra ID, che fornisce al dispositivo un'identità. Microsoft Entra ID autentica quindi il dispositivo quando un utente accede all'ID Microsoft Entra e usa il dispositivo per accedere alle risorse protette. Il dispositivo può essere gestito usando software mdm (Mobile Device Management) come Microsoft Intune. Questa capacità di gestione consente di limitare l'accesso alle 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 delle impostazioni utente conforme ai criteri aziendali tra i dispositivi.
  • Accesso a Windows Store per le aziende usando le credenziali aziendali.
  • Windows Hello for Business.
  • Accesso limitato alle app e alle risorse dai 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 il modo in cui in genere verrebbero aggiunti a un dominio:

Tipo di dispositivo Piattaforme di dispositivi meccanismo
Dispositivi personali Windows 10, iOS, Android, macOS Microsoft Entra è registrato
Dispositivo di proprietà dell'organizzazione non aggiunto ai servizi di dominio di Active Directory locali Windows 10 Microsoft Entra si è unito
Dispositivo di proprietà dell'organizzazione connesso a Active Directory Domain Services locale Windows 10 Microsoft Entra ibrido aggiunto

In un dispositivo registrato o aggiunto a Microsoft Entra, l'autenticazione utente avviene usando protocolli moderni basati su OAuth/OpenID Connect. Questi protocolli sono progettati per funzionare su Internet, quindi sono ideali per gli scenari per dispositivi mobili in cui gli utenti accedono alle risorse aziendali da qualsiasi posizione.

Con i dispositivi uniti ai 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 di lift-and-shift. La tabella seguente illustra le differenze tra il modo in cui i dispositivi sono rappresentati e possono autenticarsi nella directory:

aspetto Microsoft Entra si è unito a è stato unito a Domain Services
Dispositivo controllato da Microsoft Entra ID Dominio gestito da Domain Services
Rappresentazione nella rubrica Oggetti di 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 dei dispositivi mobili (MDM) come Intune Criteri di gruppo
Rete Funziona su Internet Deve essere connesso o sottoposto a peering con la rete virtuale in cui viene distribuito il dominio gestito
Ottimo per... Dispositivi mobili o desktop degli utenti finali Macchine virtuali server distribuite in Azure

Se AD DS locale e l'ID Microsoft Entra sono configurati per l'autenticazione federata tramite AD FS, non c'è alcun hash delle password (corrente/valido) disponibile 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 utilizzare i Servizi di dominio, crea un dominio gestito utilizzando 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 la sincronizzazione di oggetti e credenziali in un dominio gestito.