Confrontare le opzioni di integrazione per Active Directory locale con una rete di Azure

Microsoft Entra ID

Questo articolo confronta le opzioni per l'integrazione dell'ambiente Active Directory (AD) locale con una rete di Azure. Per ogni opzione è disponibile un'architettura di riferimento più dettagliata.

Molte organizzazioni usano Active Directory Domain Services (AD DS) per autenticare le identità associate a utenti, computer, applicazioni o altre risorse incluse in un limite di sicurezza. I servizi di directory e identità sono in genere ospitati in locale, ma se l'applicazione è ospitata in parte in locale e in parte in Azure, potrebbe verificarsi una latenza che invia richieste di autenticazione da Azure in locale. L'implementazione di servizi di directory e identità in Azure può ridurre questa latenza.

Azure offre due soluzioni per l'implementazione di servizi di directory e identità in Azure:

  • Usare microsoft Entra ID per creare un dominio di Active Directory nel cloud e connetterlo al dominio di Active Directory locale. Microsoft Entra Connect integra le directory locali con Microsoft Entra ID.

  • Estendere l'infrastruttura di Active Directory locale esistente ad 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 AD locale.
    • Creare una foresta separata in Azure considerata attendibile dai domini nella foresta locale.
    • Replicare una distribuzione di Active Directory Federation Services (AD FS) in Azure.

Le sezioni successive descrivono ognuna di 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 invece di una copia che contiene gli stessi oggetti e 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ò verificarsi in Azure, riducendo la necessità di applicazioni esterne e utenti per contattare il dominio locale.

sfide

  • È 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 aggiunto a una foresta locale

Distribuire i server di Servizi di dominio Active Directory in Azure. Creare un dominio in Azure e aggiungerlo alla foresta AD locale.

Prendere in considerazione questa opzione se è necessario usare le funzionalità di Active Directory Domain Services non attualmente implementate da Microsoft Entra ID.

Vantaggi

  • Fornisce l'accesso alle stesse informazioni sull'identità disponibili in locale.
  • È possibile autenticare gli account utente, del servizio e del computer in locale e in Azure.
  • Non è necessario gestire una foresta di Active Directory separata. Il dominio in Azure può appartenere alla foresta locale.
  • È possibile applicare criteri di gruppo definiti dagli oggetti Criteri di gruppo locali al dominio in Azure.

sfide

  • È necessario distribuire e gestire i propri server e dominio di Active Directory Domain Services nel cloud.
  • Potrebbe verificarsi una certa latenza di sincronizzazione tra i server di 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 (AD DS) in Azure, ma creare una foresta di Active Directory separata separata dalla foresta locale. Questa foresta è considerata attendibile dai domini nella foresta locale.

Gli usi tipici di questa architettura includono la gestione della separazione della sicurezza per oggetti e identità contenuti nel cloud e la migrazione di singoli domini dall'ambiente locale al cloud.

Vantaggi

  • È possibile implementare identità locali e identità di sola Azure separate.
  • Non è necessario eseguire la replica dalla foresta AD locale ad Azure.

sfide

  • L'autenticazione all'interno di Azure per le identità locali richiede hop di rete aggiuntivi per i server AD locali.
  • È necessario distribuire server e foreste di Active Directory Domain Services nel cloud e stabilire le relazioni di trust appropriate tra foreste.

architettura di riferimento

Estendere AD FS ad Azure

Replicare una distribuzione di Active Directory Federation Services (AD FS) in Azure per eseguire l'autenticazione federata e l'autorizzazione per i componenti in esecuzione in Azure.

Usi tipici per questa architettura:

  • Autenticare e autorizzare gli utenti delle organizzazioni partner.
  • Consentire agli utenti di eseguire l'autenticazione da Web browser che eseguono all'esterno del firewall aziendale.
  • Consentire agli utenti di connettersi da dispositivi esterni autorizzati, ad esempio i 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 un set elevato di protocolli di autenticazione.

sfide

  • È necessario distribuire i propri server Ad DS, AD FS e Proxy applicazione Web AD FS in Azure.
  • Questa architettura può essere complessa da configurare.

architettura di riferimento