Mehrere Gesamtstrukturen mit Active Directory Domain Services (AD DS) und Microsoft Entra ID

Viele Organisationen möchten Azure Virtual Desktop nutzen, um Umgebungen mit mehreren lokalen Active Directory-Gesamtstrukturen zu erstellen.

In diesem Artikel wird die Architektur erweitert, die im Artikel Azure Virtual Desktop im Unternehmensmaßstab beschrieben wird. Es soll Ihnen helfen, zu verstehen, wie Sie mehrere Domänen und Azure Virtual Desktop mithilfe von Microsoft Entra Connect integrieren, um Benutzer von lokalen Active Directory Domain Services (AD DS) in Microsoft Entra ID zu synchronisieren.

Aufbau

Laden Sie eine Visio-Datei dieser Architektur herunter.

Datenfluss

In dieser Architektur funktioniert der Identitätsfluss wie folgt:

1. Microsoft Entra Connect synchronisiert Benutzer von CompanyA.com und CompanyB.com mit einem Microsoft Entra-Mandanten (NewCompanyAB.onmicrosoft.com).
2. Hostpools, Arbeitsbereiche und App-Gruppen werden in separaten Abonnements und virtuellen Spoke-Netzwerken erstellt.
3. Die Benutzer werden App-Gruppen zugewiesen.
4. Azure Virtual Desktop-Sitzungshosts in den Hostpools treten den Domänen CompanyA.com und CompanyB.com bei, indem sie die Domänencontroller in Azure verwenden.
5. Benutzer melden sich mit der Azure Virtual Desktop-Anwendung oder dem Webclient mit einem Benutzerprinzipalnamen (UPN) im folgenden Format an: user@NewCompanyA.com, user@CompanyB.com, oder user@NewCompanyAB.com, je nach konfiguriertem UPN-Suffix.
6. Den Benutzern werden die entsprechenden virtuellen Desktops oder Apps angezeigt. Beispielsweise sehen Benutzer in CompanyA virtuelle Desktops oder Apps in Arbeitsbereich A, Hostpool 1 oder 2.
7. In Azure Files-Freigaben zu den zugehörigen Storage-Konten werden FSLogix-Benutzerprofile erstellt.
8. Gruppenrichtlinie Objekte (GPOs), die lokal synchronisiert werden, werden auf Benutzer und Azure Virtual Desktop-Sitzungshosts angewendet.

Komponenten

Diese Architektur verwendet die gleichen Komponenten wie die in Azure Virtual Desktop aufgeführten Komponenten in der Unternehmensarchitektur.

Diese Architektur verwendet die folgenden Komponenten:

• Microsoft Entra Connect im Staging-Modus: Der Staging-Server für Microsoft Entra Connect-Topologien bietet zusätzliche Redundanz für die Microsoft Entra Connect-Instanz.

• Azure-Abonnements, Azure Virtual Desktop-Arbeitsbereiche und Hostpools: Sie können mehrere Abonnements, Azure Virtual Desktop-Arbeitsbereiche und Hostpools für Verwaltungsgrenzen und Geschäftsanforderungen verwenden.

Szenariodetails

Dieses Architekturdiagramm zeigt ein typisches Szenario, das Folgendes umfasst:

• Der Microsoft Entra-Mandant ist für ein neues Unternehmen mit dem Namen NewCompanyAB.onmicrosoft.com verfügbar.
• Microsoft Entra Connect synchronisiert Benutzer von lokalem AD DS in Microsoft Entra ID.
• Unternehmen A und Firma B verfügen über separate Azure-Abonnements. Darüber hinaus verfügen sie über ein Abonnement für gemeinsam genutzte Dienste, das im obigen Diagramm als Abonnement 1 bezeichnet wird.
• Eine Azure-Hub-Spoke-Architektur wird zusammen mit einem gemeinsam genutzten virtuellen Hubnetzwerk implementiert.
• Es gibt komplexe lokale AD-Hybridumgebungen mit mindestens zwei AD-Gesamtstrukturen. Domänen werden unter separaten Gesamtstrukturen gespeichert, die alle über eigene UPN-Suffixe verfügen. Z.B., CompanyA.local mit dem UPN-SuffixCompanyA.com, CompanyB.local mit dem UPN-Suffix CompanyB.com, und ein zusätzliches UPN-Suffix, NewCompanyAB.com.
• Domänencontroller für beide Gesamtstrukturen werden sowohl lokal als auch in Azure gespeichert.
• Es gibt verifizierte Domänen in Azure für CompanyA.com, CompanyB.com und NewCompanyAB.com.
• GPO- und Legacyauthentifizierung wie Kerberos, NTLM (Windows New Technology LAN Manager) und LDAP (Lightweight Directory Access Protocol) werden verwendet.
• Azure-Umgebungen, die noch über eine lokale Abhängigkeitsinfrastruktur oder private Verbindungen (Site-to-Site-VPN oder Azure ExpressRoute) verfügen, werden zwischen lokalem Standort und Azure eingerichtet.
• Die Azure Virtual Desktop-Umgebung besteht aus einem Azure Virtual Desktop-Arbeitsbereich für jede Geschäftseinheit und zwei Hostpools pro Arbeitsbereich.
• Die Azure Virtual Desktop-Sitzungshosts werden mit Domänencontrollern in Azure verbunden. Das heißt, Die CompanyA-Sitzungshosts nehmen an der Domäne "CompanyA.local" teil, und die CompanyB-Sitzungshosts nehmen an der Domäne "CompanyB.local" teil.
• Azure Storage-Konten können Azure Files für FSLogix-Profile nutzen. Pro Unternehmensdomäne wird ein Konto erstellt (d. h. Unternehmen A.local und Unternehmen.local), und das Konto wird mit der entsprechenden Domäne verknüpft.

Mögliche Anwendungsfälle

Hier sind einige relevante Anwendungsfälle für diese Architektur:

• Fusionen und Übernahmen, Rebrandings von Unternehmen und mehrere lokale Identitäten
• Komplexe lokale Active Directory-Umgebungen (mehrere Gesamtstrukturen, mehrere Domänen, Gruppenrichtlinien (oder GPO) und Legacyauthentifizierung)
• Lokale GPO-Infrastruktur mit Azure Virtual Desktop

Überlegungen

Wenn Sie Ihre Workload basierend auf dieser Architektur entwerfen, beachten Sie die folgenden Ideen.

Gruppenrichtlinienobjekte

• Um die GPO-Infrastruktur für Azure Virtual Desktop zu erweitern, sollten die lokalen Domänencontroller mit den Azure Infrastructure as a Service (IaaS)-Domänencontrollern synchronisiert werden.

• Das Erweitern der GPO-Infrastruktur auf Azure IaaS-Domänencontroller erfordert eine private Konnektivität.

Netzwerk und Konnektivität

• Die Domänencontroller sind gemeinsam genutzte Komponenten, daher müssen sie in dieser Hub-Spoke-Architektur in einem virtuellen Hubnetzwerk für gemeinsam genutzte Dienste bereitgestellt werden.

• Azure Virtual Desktop-Sitzungshosts treten dem Domänencontroller in Azure über ihr jeweiliges virtuelles Hub-Spoke-Netzwerk-Peering bei.

Azure Storage

Die folgenden Entwurfsaspekte gelten für Benutzerprofilcontainer, Cloudcachecontainer und MSIX-Pakete:

• In diesem Szenario können sowohl Azure Files als auch Azure NetApp Files verwendet werden. Wählen Sie basierend auf Faktoren wie der erwarteten Leistung und den Kosten die richtige Lösung aus.

• Sowohl Azure-Speicherkonten als auch Azure NetApp Files sind darauf beschränkt, jeweils einem einzigen AD DS beizutreten. In diesen Fällen sind mehrere Azure-Speicherkonten oder Azure NetApp Files-Instanzen erforderlich.

Microsoft Entra ID

In Szenarien mit Benutzern in mehreren lokalen Active Directory-Gesamtstrukturen ist nur ein Microsoft Entra Connect-Synchronisierungsserver mit dem Microsoft Entra-Mandanten verbunden. Eine Ausnahme ist ein Microsoft Entra Connect-Server, der im Staging-Modus verwendet wird.

Die folgenden Identitätstopologien werden unterstützt:

• Mehrere lokale AD-Gesamtstrukturen
• Mindestens eine Ressourcengesamtstruktur gilt für alle Kontogesamtstrukturen als vertrauenswürdig.
• Mit einer vollständigen Meshtopologie können sich Benutzer und Ressourcen in jeder beliebigen Gesamtstruktur befinden. Häufig bestehen bidirektionale Vertrauensstellungen zwischen den Gesamtstrukturen.

Weitere Einzelheiten finden Sie im Abschnitt Staging-Server von Azure AD Connect-Topologien.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

• Tom Maher | Senior Security and Identity Engineer

Nächste Schritte

Weitere Informationen finden Sie in den folgenden Artikeln:

• Microsoft Entra Connect-Topologie
• Vergleichen verschiedener Identitätsoptionen: Self-managed Active Directory Domain Services (AD DS), Microsoft Entra ID und Microsoft Entra Domain Services (Microsoft Entra Domain Services)
• Dokumentation zu Azure Virtual Desktop

Zugehörige Ressourcen

• Azure Virtual Desktop für Unternehmen
• Idee zur Lösung: Mehrere Gesamtstrukturen mit Microsoft Entra Domain Services