Casi d'uso e scenari comuni per Microsoft Entra Domain Services
Microsoft Entra Domain Services offre servizi di dominio gestiti, come l'aggiunta a un dominio, criteri di gruppo, Lightweight Directory Access Protocol (LDAP) e l'autenticazione Kerberos/NTLM. Microsoft Entra Domain Services si integra con il tenant di Microsoft Entra esistente, che consente agli utenti di accedere usando le credenziali esistenti. Questi servizi di dominio vengono usati senza la necessità di distribuire, gestire e applicare patch ai controller di dominio nel cloud, il che consente un trasferimento in modalità lift-and-shift più semplice delle risorse locali in Azure.
Questo articolo illustra alcuni scenari aziendali comuni in cui Microsoft Entra Domain Services fornisce un valore e soddisfa tali esigenze.
Modi comuni per fornire soluzioni di gestione delle identità nel cloud
Quando si esegue la migrazione dei carichi di lavoro esistenti nel cloud, le applicazioni compatibili con directory possono usare LDAP per l'accesso in lettura o scrittura a una directory di Active Directory Domain Services locale. Le applicazioni in esecuzione in Windows Server vengono in genere distribuite in macchine virtuali (VM) aggiunte a un dominio e possono quindi essere gestite in modo sicuro tramite Criteri di gruppo. Per autenticare gli utenti finali, le applicazioni possono anche basarsi sull'autenticazione integrata di Windows, ad esempio l'autenticazione Kerberos o NTLM.
Gli amministratori IT usano spesso una delle soluzioni seguenti per fornire un servizio di gestione delle identità alle applicazioni che vengono eseguite in Azure:
- Configurare una connessione VPN da sito a sito tra i carichi di lavoro in esecuzione in Azure e un ambiente di AD DS locale.
- I controller di dominio locali forniscono quindi l'autenticazione tramite la connessione VPN.
- Creare controller di dominio di replica usando macchine virtuali di Azure per estendere il dominio o la foresta di AD DS dall'ambiente locale.
- I controller di dominio eseguiti nelle macchine virtuali di Azure forniscono l'autenticazione e replicano le informazioni della directory tra l'ambiente di AD DS locale.
- Distribuire un ambiente di Active Directory Domain Services autonomo in Azure usando controller di dominio in esecuzione in macchine virtuali di Azure.
- I controller di dominio eseguiti nelle macchine virtuali di Azure forniscono l'autenticazione, ma non vengono replicate informazioni della directory da un ambiente di AD DS locale.
Con queste soluzioni, le connessioni VPN alla directory locale rendono le applicazioni vulnerabili a errori o interruzioni di rete temporanee. Se si distribuiscono controller di dominio usando macchine virtuali in Azure, il team IT deve gestire le VM, quindi eseguire le attività di protezione, applicazione di patch, monitoraggio, backup e risoluzione dei problemi.
Microsoft Entra Domain Services offre alternative alla necessità di creare connessioni VPN a un ambiente di Active Directory Domain Services locale o di eseguire e gestire macchine virtuali in Azure per fornire servizi di gestione delle identità. Come servizio gestito, Microsoft Entra Domain Services riduce la complessità di creare una soluzione di gestione delle identità integrata per ambienti ibridi e solo cloud.
Microsoft Entra Domain Services per organizzazioni ibride
Molte organizzazioni eseguono un'infrastruttura ibrida che include i carichi di lavoro di applicazioni cloud e locali. Le applicazioni legacy di cui è stata eseguita la migrazione in Azure nell'ambito di una strategia di trasferimento in modalità lift-and-shift possono usare le connessioni LDAP tradizionali per fornire informazioni sulle identità. Per supportare questa infrastruttura ibrida, è possibile sincronizzare le informazioni sulle identità da un ambiente di Active Directory Domain Services locale a un tenant di Microsoft Entra. Microsoft Entra Domain Services fornisce quindi a queste applicazioni legacy in Azure un'origine di identità, senza che sia necessario configurare e gestire la connettività delle applicazioni in servizi di directory locali.
Di seguito è riportato un esempio di Litware Corporation, un'organizzazione ibrida che esegue risorse in locale e in Azure:
- I carichi di lavoro di server e applicazioni che richiedono servizi di dominio sono distribuiti in una rete virtuale in Azure.
- Tra queste applicazioni possono essere incluse le applicazioni legacy di cui è stata eseguita la migrazione in Azure come parte di una strategia di trasferimento in modalità lift-and-shift.
- Per sincronizzare le informazioni sull'identità dalla directory locale al tenant di Microsoft Entra, Litware Corporation distribuisce Microsoft Entra Connect.
- Le informazioni sulle identità che vengono sincronizzate includono gli account utente e le appartenenze ai gruppi.
- Il team IT di Litware abilita Microsoft Entra Domain Services per il tenant di Microsoft Entra in questa rete virtuale o in una con peering.
- Le applicazioni e le macchine virtuali distribuite all'interno della rete virtuale di Azure possono quindi usare le funzionalità di Microsoft Entra Domain Services come l'aggiunta a un dominio, la lettura e l'associazione LDAP, l'autenticazione NTLM e Kerberos e Criteri di gruppo.
Importante
Microsoft Entra Connect deve essere installato e configurato solo per la sincronizzazione con gli ambienti di Active Directory Domain Services locali. L'installazione di Microsoft Entra Connect in un dominio gestito per sincronizzare nuovamente gli oggetti con Microsoft Entra ID non è supportata.
Microsoft Entra Domain Services per organizzazioni solo cloud
Un tenant Microsoft Entra solo cloud non ha un'origine di identità locale. Gli account utente e le appartenenze ai gruppi, ad esempio, vengono creati e gestiti direttamente in Microsoft Entra ID.
Si esaminerà ora un esempio per Contoso, un'organizzazione solo cloud che usa Microsoft Entra ID per la gestione delle identità. Tutte le identità degli utenti, le relative credenziali e le appartenenze ai gruppi vengono create e gestite in Microsoft Entra ID. Non esiste alcuna configurazione aggiuntiva di Microsoft Entra Connect per sincronizzare le informazioni sulle identità da una directory locale.
- I carichi di lavoro di server e applicazioni che richiedono servizi di dominio sono distribuiti in una rete virtuale in Azure.
- Il team IT di Contoso abilita Microsoft Entra Domain Services per il tenant di Microsoft Entra in questo o una rete virtuale con peering.
- Le applicazioni e le macchine virtuali distribuite all'interno della rete virtuale di Azure possono quindi usare le funzionalità di Microsoft Entra Domain Services come l'aggiunta a un dominio, la lettura e l'associazione LDAP, l'autenticazione NTLM e Kerberos e Criteri di gruppo.
Gestione sicura delle macchine virtuali di Azure
Per consentire l'uso di un singolo set di credenziali di Active Directory, le macchine virtuali di Azure possono essere aggiunte a un dominio gestito di Microsoft Entra Domain Services. Questo approccio riduce i problemi di gestione delle credenziali, come la necessità di mantenere account amministratore locali in ogni VM o di separare account e password tra gli ambienti.
Le macchine virtuali aggiunte a un dominio gestito possono anche essere amministrate e protette tramite Criteri di gruppo. Le baseline di sicurezza necessarie possono essere applicate alle macchine virtuali per bloccarle in conformità alle linee guida per la sicurezza aziendale. Ad esempio è possibile utilizzare le funzionalità di gestione dei criteri di gruppo per limitare i tipi di applicazioni che possono essere avviate su tali macchine virtuali.
Di seguito viene illustrato uno scenario di esempio comune. Man mano che i server e altri elementi dell'infrastruttura raggiungono la fine del ciclo di vita, Contoso intende spostare molte delle applicazioni attualmente ospitate in locale nel cloud. Lo standard IT corrente prevede che i server che ospitano applicazioni aziendali sia aggiunto a un dominio e gestito tramite i criteri di gruppo.
L'amministratore IT di Contoso preferisce aggiungere un dominio alle macchine virtuali distribuite in Azure per semplificare l'amministrazione, in quanto gli utenti possono così accedere usando le credenziali aziendali. Quando sono aggiunte a un dominio, le macchine virtuali possono anche essere configurate per essere conformi alle baseline di sicurezza necessarie usando oggetti Criteri di gruppo. Contoso preferisce non distribuire, monitorare e gestire i propri controller di dominio in Azure.
Microsoft Entra Domain Services è un'ottima soluzione per questo caso d'uso. Un dominio gestito consente di aggiungere macchine virtuali a un dominio, usare un singolo set di credenziali e applicare criteri di gruppo. Poiché si tratta di un dominio gestito, non è necessario configurare e gestire manualmente i controller di dominio.
Note sulla distribuzione
Le considerazioni sulla distribuzione seguenti si applicano a questo Use Case di esempio:
- Per impostazione predefinita, i domini gestiti usano una singola struttura unità organizzativa (OU). Tutte le VM aggiunte a un dominio sono contenute in una singola unità organizzativa. Se lo si desidera, è possibile creare unità organizzative personalizzate.
- Microsoft Entra Domain Services usa un oggetto Criteri di gruppo predefinito per gli utenti e i contenitori di computer. Per un controllo aggiuntivo, è possibile creare oggetti criteri di gruppo personalizzato e destinarli a unità organizzative personalizzate.
- Microsoft Entra Domain Services supporta lo schema dell'account computer di Active Directory di base. Non è possibile estendere lo schema dell'account computer.
Applicazioni locali con trasferimento in modalità lift-and-shift che usano l'autenticazione di associazione LDAP
Come scenario di esempio, Contoso dispone di un'applicazione locale acquistata da un fornitore di software indipendente molti anni fa. L'applicazione è attualmente in modalità manutenzione presso il fornitore di software indipendente e le modifiche apportate all'applicazione sono estremamente costose. L'applicazione ha un front-end basato sul Web che raccoglie le credenziali degli utenti tramite un modulo Web e che autentica gli utenti tramite un'associazione LDAP con l'ambiente Active Directory Domain Services locale.
Contoso vuole eseguire la migrazione di questa applicazione ad Azure. L'applicazione deve continuare a funzionare così come è, senza alcuna modifica necessaria. Inoltre, gli utenti devono essere in grado di eseguire l'autenticazione usando le credenziali aziendali esistenti e senza formazione aggiuntiva. Deve essere trasparente per gli utenti finali in cui è in esecuzione l'applicazione.
Per questo scenario Microsoft Entra Domain Services consente alle applicazioni di eseguire associazioni LDAP come parte del processo di autenticazione. Le applicazioni locali legacy possono essere trasferite in modalità lift-and-shift in Azure e continuare senza interruzioni ad autenticare gli utenti senza alcuna variazione nella configurazione o nell'esperienza utente.
Note sulla distribuzione
Le considerazioni sulla distribuzione seguenti si applicano a questo Use Case di esempio:
- Assicurarsi che l'applicazione non debba modificare/scrivere nella directory. L'accesso in scrittura LDAP a un dominio gestito non è supportato.
- Non è possibile modificare le password direttamente in un dominio gestito. Gli utenti finali possono modificare le password tramite il meccanismo di reimpostazione della password self-service di Microsoft Entra o nella directory locale. Successivamente queste modifiche vengono automaticamente sincronizzate e rese disponibili nel dominio gestito.
Applicazioni con trasferimento in modalità locali lift-and-shift che usano la lettura LDAP per accedere alla directory
Come nello scenario di esempio precedente, si supponga che Contoso abbia un'applicazione line-of-business (LOB) locale sviluppata quasi dieci anni fa. Questa applicazione è compatibile con la directory ed è stata progettata per l'uso di LDAP per leggere informazioni/attributi sugli utenti di Active Directory Domain Services. L'applicazione non modifica gli attributi né esegue operazioni di scrittura nella directory.
Contoso vuole eseguire la migrazione di questa applicazione ad Azure e ritirare l'hardware locale obsoleto che attualmente ospita questa applicazione. L'applicazione non può essere riscritta per l'uso di API di directory moderne, l'API REST di Microsoft Graph. Un'opzione di spostamento è opportuna quando è possibile eseguire la migrazione dell'applicazione per l'esecuzione nel cloud senza modificare il codice o riscrivere l'applicazione.
Per semplificare questo scenario, Microsoft Entra Domain Services consente alle applicazioni di eseguire letture LDAP sul dominio gestito per ottenere le informazioni sull'attributo necessarie. Non è necessario riscrivere l'applicazione, quindi tramite un trasferimento in modalità lift-and-shift in Azure gli utenti possono continuare a usare l'app senza nemmeno rendersi che la posizione di esecuzione è cambiata.
Note sulla distribuzione
Le considerazioni sulla distribuzione seguenti si applicano a questo Use Case di esempio:
- Assicurarsi che l'applicazione non debba modificare/scrivere nella directory. L'accesso in scrittura LDAP a un dominio gestito non è supportato.
- Assicurarsi che l'applicazione non necessiti di uno schema Active Directory personalizzato o esteso. Le estensioni dello schema non sono supportate in Microsoft Entra Domain Services.
Eseguire la migrazione di un servizio o di un'applicazione daemon locale ad Azure
Alcune applicazioni includono più livelli, uno dei quali deve eseguire chiamate autenticate a un livello back-end, ad esempio un database. Gli account del servizio Active Directory vengono comunemente usati in questi scenari. Quando si esegue il trasferimento in modalità lift-and-shift delle applicazioni in Azure, Microsoft Entra Domain Services consente di continuare a usare gli account del servizio nello stesso modo. È possibile scegliere di usare lo stesso account del servizio sincronizzato dalla directory locale a Microsoft Entra ID o creare un'unità organizzativa personalizzata e quindi creare un account di servizio separato in tale unità organizzativa. Con entrambi gli approcci le applicazioni continuano a funzionare allo stesso modo per eseguire chiamate autenticate ad altri livelli e servizi.
In questo scenario di esempio Contoso dispone di un'applicazione di insieme di credenziali appositamente sviluppata e personalizzata che include un front-end Web, un server SQL e un server FTP back-end. L'autenticazione integrata di Windows tramite gli account del servizio autentica il front-end Web nel server FTP. Il front-end Web è configurato per l'esecuzione come account del servizio. Il server back-end è configurato per autorizzare l'accesso dall'account del servizio per il front-end Web. Contoso non vuole distribuire e gestire le proprie macchine virtuali con controller di dominio nel cloud per spostare questa applicazione in Azure.
Per questo scenario i server che ospitano il front-end Web, SQL Server e il server FTP, possono essere migrati in macchine virtuali di Azure e aggiunti a un dominio gestito. Le macchine virtuali possono quindi usare lo stesso account di servizio nella directory locale per scopi di autenticazione dell'app, sincronizzata tramite Microsoft Entra ID usando Microsoft Entra Connect.
Note sulla distribuzione
Le considerazioni sulla distribuzione seguenti si applicano a questo Use Case di esempio:
- Assicurarsi che le applicazioni usino un nome utente e una password per l'autenticazione. L'autenticazione basata su certificato o smartcard non è supportata da Microsoft Entra Domain Services.
- Non è possibile modificare le password direttamente in un dominio gestito. Gli utenti finali possono modificare le password tramite il meccanismo di reimpostazione della password self-service di Microsoft Entra o nella directory locale. Successivamente queste modifiche vengono automaticamente sincronizzate e rese disponibili nel dominio gestito.
Distribuzioni di servizi desktop remoto di Windows Server in Azure
È possibile usare Microsoft Entra Domain Services per fornire servizi di dominio gestito ai server di desktop remoto distribuiti in Azure.
Per altre informazioni su questo scenario di distribuzione, vedere come integrare Microsoft Entra Domain Services con la distribuzione di Servizi Desktop remoto.
Cluster HDInsight aggiunti al dominio
È possibile impostare un cluster Azure HDInsight aggiunto a un dominio gestito con Apache Ranger abilitato. È possibile creare e applicare criteri Hive tramite Apache Ranger e consentire agli utenti, ad esempio gli scienziati dei dati, di connettersi a Hive usando strumenti basati su ODBC, come Excel o Tableau. Ci impegniamo ad aggiungere altri carichi di lavoro, ad esempio HBase, Spark e Storm a HDInsight aggiunto a un dominio.
Per altre informazioni su questo scenario di distribuzione, vedere come configurare i cluster HDInsight aggiunti al dominio
Passaggi successivi
Per le attività iniziali creare e configurare un dominio gestito di Microsoft Entra Domain Services.