Questo articolo confronta le opzioni per l'integrazione dell'ambiente di Active Directory locale con una rete di Azure. Per ogni opzione è disponibile un'architettura di riferimento più dettagliata.
Molte organizzazioni usano Active Directory Domain Services per autenticare le identità associate a utenti, computer, applicazioni o ad altre risorse incluse in un limite di sicurezza. I servizi di gestione delle identità e delle directory vengono in genere ospitati in locale, ma se l'applicazione è ospitata in parte in locale e in parte in Azure, potrebbe esserci latenza nell'invio delle richieste di autenticazione da Azure a locale. L'implementazione dei servizi di gestione delle identità e delle directory in Azure può ridurre la latenza.
Azure offre due soluzioni per l'implementazione dei servizi di gestione delle identità e delle directory in Azure:
Usare Microsoft Entra ID per creare un dominio di Active Directory nel cloud e connetterlo al dominio Active Directory locale. Microsoft Entra Connessione integra le directory locali con Microsoft Entra ID.
Estendere l'infrastruttura locale esistente di Active Directory in Azure, distribuendo una macchina virtuale in Azure che esegue Active Directory Domain Services come controller di dominio. Questa architettura è più comune quando la rete locale e la rete virtuale di Azure sono connesse tramite una connessione VPN o ExpressRoute. Sono possibili diverse varianti di questa architettura:
- Creare un dominio in Azure e aggiungerlo alla foresta di Active Directory locale.
- Creare una foresta separata in Azure considerata attendibile dai domini nella foresta locale.
- Replicare una distribuzione di Active Directory Federation Services in Azure.
Le sezioni successive descrivono tutte queste opzioni in modo più dettagliato.
Integrare i domini locali con Microsoft Entra ID
Usare Microsoft Entra ID per creare un dominio in Azure e collegarlo a un dominio AD locale.
La directory Microsoft Entra non è un'estensione di una directory locale. Si tratta piuttosto di una copia che contiene gli stessi oggetti e le stesse identità. Le modifiche apportate a questi elementi in locale vengono copiate in Microsoft Entra ID, ma le modifiche apportate in Microsoft Entra ID non vengono replicate nel dominio locale.
È anche possibile usare Microsoft Entra ID senza usare una directory locale. In questo caso, Microsoft Entra ID funge da origine primaria di tutte le informazioni sull'identità, anziché contenere i dati replicati da una directory locale.
Vantaggi
- Non è necessario gestire un'infrastruttura di Active Directory nel cloud. Microsoft Entra ID è completamente gestito e gestito da Microsoft.
- Microsoft Entra ID fornisce le stesse informazioni sull'identità disponibili in locale.
- L'autenticazione può essere eseguita in Azure, riducendo la necessità di applicazioni esterne e utenti per contattare il dominio locale.
Problematiche
- È necessario configurare la connettività con il dominio locale per mantenere sincronizzata la directory Microsoft Entra.
- Potrebbe essere necessario riscrivere le applicazioni per abilitare l'autenticazione tramite Microsoft Entra ID.
- Se si desidera autenticare gli account del servizio e del computer, sarà necessario distribuire anche Microsoft Entra Domain Services.
Architettura di riferimento
Active Directory Domain Services in Azure unito a una foresta locale
Distribuire i server di Active Directory Domain Services in Azure. Creare un dominio in Azure e aggiungerlo alla foresta di Active Directory locale.
Prendere in considerazione questa opzione se è necessario usare le funzionalità di Active Directory Domain Services non attualmente implementate da Microsoft Entra ID.
Vantaggi
- Offre accesso alle stesse informazioni di identità disponibili in locale.
- È possibile eseguire l'autenticazione di utenti, servizi e account del computer locale e in Azure.
- Non è necessario gestire una foresta di Active Directory separata. Il dominio in Azure può appartenere alla foresta locale.
- È possibile applicare i criteri del gruppo definiti dagli oggetti Criteri di gruppo locali nel dominio in Azure.
Problematiche
- È necessario distribuire e gestire i propri server e il dominio di Active Directory Domain Services nel cloud.
- Potrebbe verificarsi una certa latenza di sincronizzazione tra i server del dominio nel cloud e i server in esecuzione in locale.
Architettura di riferimento
Active Directory Domain Services in Azure con una foresta separata
Distribuire i server di Active Directory Domain Services in Azure, ma creare un'altra foresta di Active Directory separata dalla foresta locale. Questa foresta è considerata attendibile dai domini nella foresta locale.
Gli usi tipici di questa architettura includono mantenere la separazione della sicurezza per le identità e gli oggetti contenuti nel cloud ed eseguire la migrazione di singoli domini da un ambiente locale al cloud.
Vantaggi
- È possibile implementare le identità locali e separare solo le identità di Azure.
- Non è necessario eseguire la replica dalla foresta locale di Active Directory in Azure.
Problematiche
- L'autenticazione in Azure per le identità locali richiede hop di rete aggiuntivi per i server di Active Directory locali.
- È necessario distribuire i propri server e la foresta di Active Directory Domain Services nel cloud e stabilire le relazioni di trust appropriate tra le foreste.
Architettura di riferimento
Estendere AD FS in Azure
Replicare una distribuzione di Active Directory Federation Services in Azure, per eseguire l'autenticazione federata e l'autorizzazione per i componenti in esecuzione in Azure.
Usi tipici di questa architettura:
- Le organizzazioni partner possono autenticare e autorizzare gli utenti.
- Gli utenti possono eseguire l'autenticazione da Web browser in esecuzione all'esterno del firewall aziendale.
- Gli utenti possono connettersi da dispositivi esterni autorizzati, ad esempio dispositivi mobili.
Vantaggi
- È possibile sfruttare le applicazioni in grado di riconoscere attestazioni.
- Offre la possibilità di considerare attendibili i partner esterni per l'autenticazione.
- Compatibilità con grandi set di protocolli di autenticazione.
Problematiche
- È necessario distribuire i server di Active Directory Domain Services, Active Directory Federation Services e del proxy applicazione Web di Active Directory Federation Services in Azure.
- Questa architettura può essere complessa da configurare.
Architettura di riferimento