Più foreste con Active Directory Domain Services e Microsoft Entra ID

Molte organizzazioni vogliono sfruttare Desktop virtuale Azure per creare ambienti con più foreste Active Directory locale.

Questo articolo illustra l'architettura descritta nell'articolo Desktop virtuale Azure su scala aziendale. È progettato per comprendere come integrare più domini e Desktop virtuale Azure usando Microsoft Entra Connessione per sincronizzare gli utenti da servizi di Dominio di Active Directory locali (AD DS) a Microsoft Entra ID.

Architettura

Scaricare un file di Visio di questa architettura.

Flusso di dati

In questa architettura il flusso di identità funziona come segue:

1. Microsoft Entra Connessione sincronizza gli utenti sia da CompanyA.com che da CompanyB.com a un tenant di Microsoft Entra (NewCompanyAB.onmicrosoft.com).
2. I pool di host, le aree di lavoro e i gruppi di app vengono creati in sottoscrizioni e reti virtuali spoke separate.
3. Gli utenti vengono assegnati ai gruppi di app.
4. Gli host di sessione di Desktop virtuale Azure nei pool di host aggiungono i domini CompanyA.com e CompanyB.com usando i controller di dominio in Azure.
5. Gli utenti accedono usando l'applicazione Desktop virtuale Azure o il client Web con un nome dell'entità utente (UPN) nel formato seguente: user@NewCompanyA.com, user@CompanyB.como user@NewCompanyAB.com, a seconda del suffisso UPN configurato.
6. Gli utenti vengono presentati con i rispettivi desktop virtuali o applicazioni. Ad esempio, gli utenti di CompanyA vengono presentati con un desktop virtuale o un'applicazione nell'area di lavoro A, nel pool di host 1 o 2.
7. Vengono creati profili utente FSLogix in condivisioni di File di Azure negli account di archiviazione corrispondenti.
8. Gli oggetti Criteri di gruppo (GPO) sincronizzati dall'ambiente locale vengono applicati agli utenti e agli host sessione di Desktop virtuale Azure.

Componenti

Questa architettura usa gli stessi componenti elencati in Desktop virtuale Azure su scala aziendale.

Inoltre, questa architettura usa i componenti seguenti:

• Microsoft Entra Connessione in modalità di gestione temporanea: il server di gestione temporanea per le topologie di Microsoft Entra Connessione offre ridondanza aggiuntiva per l'istanza di Microsoft Entra Connessione.

• Sottoscrizioni di Azure, aree di lavoro di Desktop virtuale Azure e pool di host: è possibile usare più sottoscrizioni, aree di lavoro di Desktop virtuale Azure e pool di host per i limiti di amministrazione e i requisiti aziendali.

Dettagli dello scenario

Questo diagramma dell'architettura rappresenta uno scenario tipico che contiene gli elementi seguenti:

• Il tenant di Microsoft Entra è disponibile per una nuova società denominata NewCompanyAB.onmicrosoft.com.
• Microsoft Entra Connessione sincronizza gli utenti da Active Directory Domain Services locale all'ID Microsoft Entra.
• La società A e la società B hanno sottoscrizioni di Azure separate. Hanno anche una sottoscrizione di servizi condivisi, denominata Sottoscrizione 1 nel diagramma.
• Un'architettura hub-spoke di Azure viene implementata con una rete virtuale dell'hub dei servizi condivisi.
• Gli ambienti ibridi Active Directory locale complessi sono presenti con due o più foreste di Active Directory. I domini sono presenti in foreste separate, ognuna con un suffisso UPN diverso, Ad esempio, CompanyA.local con il suffisso UPN CompanyA.com, CompanyB.local con il suffisso UPN CompanyB.com e un suffisso UPN aggiuntivo, NewCompanyAB.com.
• I controller di dominio per entrambe le foreste si trovano in locale e in Azure.
• I domini verificati sono presenti in Azure per CompanyA.com, CompanyB.com e NewCompanyAB.com.
• Vengono usati oggetti Criteri di gruppo e autenticazione legacy, ad esempio Kerberos, NTLM (Windows New Technology LAN Manager) e LDAP (Lightweight Directory Access Protocol).
• Per gli ambienti di Azure che hanno ancora una dipendenza dall'infrastruttura locale, la connettività privata (VPN da sito a sito o Azure ExpressRoute) è configurata tra l'ambiente locale e Azure.
• L'ambiente Desktop virtuale Azure è costituito da un'area di lavoro di Desktop virtuale Azure per ogni business unit e due pool di host per area di lavoro.
• Gli host di sessione di Desktop virtuale Azure vengono aggiunti ai controller di dominio in Azure. Ovvero, gli host di sessione CompanyA vengono aggiunti al dominio CompanyA.local e gli host di sessione CompanyB vengono aggiunti al dominio CompanyB.local.
• Gli account di archiviazione di Azure possono usare File di Azure per i profili FSLogix. Viene creato un account per dominio aziendale, ovvero CompanyA.local e CompanyB.local, e l'account viene aggiunto al dominio corrispondente.

Potenziali casi d'uso

Ecco alcuni casi d'uso rilevanti per questa architettura:

• Fusioni e acquisizioni, ridenominazione dell'organizzazione e più identità locali
• Ambienti active directory locali complessi (multi-foresta, multidomini, criteri di gruppo o criteri di gruppo) e autenticazione legacy
• Infrastruttura dell'oggetto Criteri di gruppo locale con Desktop virtuale Azure

Considerazioni

Quando si progetta il carico di lavoro in base a questa architettura, tenere presenti le idee seguenti.

Oggetti Criteri di gruppo

• Per estendere l'infrastruttura oggetti Criteri di gruppo per Desktop virtuale Azure, i controller di dominio locali devono eseguire la sincronizzazione con i controller di dominio IaaS (Infrastructure as a Service) di Azure.

• L'estensione dell'infrastruttura degli oggetti Criteri di gruppo ai controller di dominio IaaS di Azure richiede la connettività privata.

Rete e connettività

• I controller di dominio sono componenti condivisi, quindi devono essere distribuiti in una rete virtuale dell'hub servizi condivisi in questa architettura hub-spoke.

• Gli host di sessione di Desktop virtuale Azure si aggiungono al controller di dominio in Azure tramite il rispettivo peering di rete virtuale hub-spoke.

Archiviazione di Azure

Le considerazioni seguenti sulla progettazione si applicano ai contenitori di profili utente, ai contenitori di cache cloud e ai pacchetti MSIX:

• In questo scenario è possibile usare sia File di Azure che Azure NetApp Files. Scegliere la soluzione corretta in base a fattori quali prestazioni previste, costi e così via.

• Sia gli account di archiviazione di Azure che Azure NetApp Files sono limitati all'aggiunta a un solo ad Active Directory Domain Services alla volta. In questi casi sono necessari più account di archiviazione di Azure o istanze di Azure NetApp Files.

Microsoft Entra ID

Negli scenari con utenti in più foreste Active Directory locale, al tenant microsoft Entra Connessione Sync è connesso un solo server Di sincronizzazione di Microsoft Entra. Un'eccezione a questo è un server Connessione Microsoft Entra usato in modalità di gestione temporanea.

Sono supportate le topologie di identità seguenti:

• Più foreste Active Directory locali.
• Una o più foreste di risorse considera attendibili tutte le foreste account.
• Una topologia mesh completa consente la presenza di utenti e risorse in qualsiasi foresta. In genere esistono trust bidirezionali tra le foreste.

Per altri dettagli, vedere la sezione Server di gestione temporanea delle topologie di Microsoft Entra Connessione.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

• Tom Maher | Senior Security and Identity Engineer

Passaggi successivi

Per altre informazioni, vedere gli articoli seguenti:

• Topologia di Microsoft Entra Connessione
• Confrontare diverse opzioni di identità: Servizi di Dominio di Active Directory autogestito (AD DS), Microsoft Entra ID e Microsoft Entra Domain Services (Microsoft Entra Domain Services)
• Documentazione di Desktop virtuale Azure

Risorse correlate

• Desktop virtuale Azure per le aziende
• Idea di soluzione: più foreste con Microsoft Entra Domain Services