Casi d'uso e scenari comuni per Servizi di dominio Microsoft Entra

Microsoft Entra Domain Services fornisce servizi di dominio gestiti, ad esempio l'aggiunta a un dominio, criteri di gruppo, LDAP (Lightweight Directory Access Protocol) 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, che offrono 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 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 le macchine virtuali in Azure per fornire servizi di 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.

Servizi di dominio Microsoft Entra 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à di un ambiente di Active Directory Domain Services locale con un tenant di Microsoft Entra. Microsoft Entra Domain Services fornisce quindi queste applicazioni legacy in Azure con un'origine di identità, senza la necessità di configurare e gestire nuovamente la connettività delle applicazioni ai servizi directory locali.

Di seguito è riportato un esempio di Litware Corporation, un'organizzazione ibrida che esegue risorse in locale e in Azure:

Microsoft Entra Domain Services for a hybrid organization that includes on-premises synchronization

  • 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 Connessione.
    • 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 questo o una rete virtuale con peering.
  • Le applicazioni e le macchine virtuali distribuite nella rete virtuale di Azure possono quindi usare le funzionalità di Servizi di dominio Microsoft Entra, ad esempio l'aggiunta a un dominio, la lettura LDAP, l'associazione LDAP, l'autenticazione NTLM e Kerberos e Criteri di gruppo.

Importante

Microsoft Entra Connessione deve essere installato e configurato solo per la sincronizzazione con gli ambienti di Active Directory Domain Services locali. Non è supportato installare Microsoft Entra Connessione in un dominio gestito per sincronizzare gli oggetti con Microsoft Entra ID.

Servizi di dominio Microsoft Entra 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 l'identità. Tutte le identità utente, le relative credenziali e le appartenenze ai gruppi vengono create e gestite in Microsoft Entra ID. Non è disponibile alcuna configurazione aggiuntiva di Microsoft Entra Connessione per sincronizzare le informazioni sull'identità da una directory locale.

Microsoft Entra Domain Services for a cloud-only organization with no on-premises synchronization

  • 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 nella rete virtuale di Azure possono quindi usare le funzionalità di Servizi di dominio Microsoft Entra, ad esempio l'aggiunta a un dominio, la lettura LDAP, l'associazione LDAP, l'autenticazione NTLM e Kerberos e Criteri di gruppo.

Proteggere l'amministrazione 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 usare le funzionalità di gestione di Criteri di gruppo per limitare i tipi di applicazioni che possono essere avviate nella macchina virtuale.

Streamlined administration of Azure virtual machines

Di seguito viene illustrato uno scenario di esempio comune. Man mano che i server e altre infrastrutture raggiungono la fine della vita, Contoso vuole spostare le applicazioni attualmente ospitate in locale nel cloud. Lo standard IT corrente impone che i server che ospitano applicazioni aziendali debbano essere aggiunti a un dominio e gestiti tramite 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 quindi 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 caso d'uso 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 personalizzati e destinarli a unità organizzative personalizzate.
  • Microsoft Entra Domain Services supporta lo schema dell'oggetto computer ad di base. Non è possibile estendere lo schema dell'oggetto computer.

Applicazioni locali lift-and-shift che usano l'autenticazione di associazione LDAP

Come scenario di esempio, Contoso ha un'applicazione locale acquistata da un ISV molti anni fa. L'applicazione è attualmente in modalità di manutenzione dall'ISV e richiede modifiche all'applicazione è eccessivamente costoso. Questa applicazione dispone di un front-end basato sul Web che raccoglie le credenziali utente usando un web form e quindi autentica gli utenti eseguendo un'associazione LDAP all'ambiente Active Directory Domain Services locale.

LDAP bind

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 caso d'uso 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 la password usando il meccanismo di modifica della password self-service di Microsoft Entra o rispetto alla directory locale. Queste modifiche vengono quindi sincronizzate automaticamente e disponibili nel dominio gestito.

Applicazioni 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 o scrive in altro modo nella directory.

Contoso vuole eseguire la migrazione di questa applicazione ad Azure e ritirare l'hardware locale obsoleto che attualmente ospita questa applicazione. Non è possibile riscrivere l'applicazione per usare API di directory moderne, ad esempio l'API Microsoft Graph basata su REST. Si desidera un'opzione lift-and-shift in cui è 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 caso d'uso 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 richieda uno schema di Active Directory personalizzato/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 all'ID Microsoft Entra 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.

Service account using WIA

In questo scenario di esempio, Contoso ha un'applicazione di insieme di credenziali software personalizzata che include un front-end Web, un server SQL e un server FTP back-end. L'autenticazione integrata di Windows tramite 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 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 del servizio nella directory locale per scopi di autenticazione dell'app, sincronizzati tramite Microsoft Entra ID usando Microsoft Entra Connessione.

Note sulla distribuzione

Le considerazioni sulla distribuzione seguenti si applicano a questo caso d'uso di esempio:

  • Assicurarsi che le applicazioni usino un nome utente e una password per l'autenticazione. L'autenticazione basata su certificato o smart card non è supportata da Microsoft Entra Domain Services.
  • Non è possibile modificare le password direttamente in un dominio gestito. Gli utenti finali possono modificare la password usando il meccanismo di modifica della password self-service di Microsoft Entra o rispetto alla directory locale. Queste modifiche vengono quindi sincronizzate automaticamente e disponibili nel dominio gestito.

Distribuzioni di servizi Desktop remoto windows Server in Azure

È possibile usare Servizi di dominio Microsoft Entra per fornire servizi di dominio gestiti ai server desktop remoti 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 configurare 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 data scientist, di connettersi a Hive usando strumenti basati su ODBC come Excel o Tableau. Continuiamo a lavorare per aggiungere altri carichi di lavoro, ad esempio HBase, Spark e Storm a HDInsight aggiunto al dominio.

Per altre informazioni su questo scenario di distribuzione, vedere come configurare i cluster HDInsight aggiunti al dominio

Passaggi successivi

Per iniziare, creare e configurare un dominio gestito di Microsoft Entra Domain Services.