Meerdere forests met AD DS en Microsoft Entra-id

Veel organisaties willen profiteren van Azure Virtual Desktop om omgevingen te maken met meerdere on-premises Active Directory-forests.

Dit artikel breidt de architectuur uit die wordt beschreven in het artikel over Azure Virtual Desktop op ondernemingsniveau . Het is bedoeld om te begrijpen hoe u meerdere domeinen en Azure Virtual Desktop integreert met behulp van Microsoft Entra Verbinding maken om gebruikers van on-premises Active Directory-domein Services (AD DS) te synchroniseren met Microsoft Entra ID.

Architectuur

Een Visio-bestand van deze architectuur downloaden.

Gegevensstroom

In deze architectuur werkt de identiteitsstroom als volgt:

1. Microsoft Entra Verbinding maken synchroniseert gebruikers van zowel CompanyA.com als CompanyB.com naar een Microsoft Entra-tenant (NewCompanyAB.onmicrosoft.com).
2. Hostgroepen, werkruimten en app-groepen worden gemaakt in afzonderlijke abonnementen en virtuele spoke-netwerken.
3. Gebruikers worden toegewezen aan de app-groepen.
4. Azure Virtual Desktop-sessiehosts in de hostgroepen voegen zich toe aan de domeinen CompanyA.com en CompanyB.com met behulp van de domeincontrollers in Azure.
5. Gebruikers melden zich aan met behulp van de Azure Virtual Desktop-toepassing of de webclient met een User Principal Name (UPN) in de volgende indeling: user@NewCompanyA.com, , user@CompanyB.comof user@NewCompanyAB.com, afhankelijk van hun geconfigureerde UPN-achtervoegsel.
6. Gebruikers krijgen hun respectieve virtuele bureaubladen of toepassingen te zien. Gebruikers in CompanyA krijgen bijvoorbeeld een virtueel bureaublad of een toepassing te zien in werkruimte A, hostgroep 1 of 2.
7. FSLogix-gebruikersprofielen worden gemaakt in Azure Files-shares op de bijbehorende opslagaccounts.
8. Groepsbeleidsobjecten (GPO's) die vanuit on-premises worden gesynchroniseerd, worden toegepast op gebruikers en Azure Virtual Desktop-sessiehosts.

Onderdelen

Deze architectuur maakt gebruik van dezelfde onderdelen als die worden vermeld in Azure Virtual Desktop op enterprise-schaalarchitectuur.

Daarnaast maakt deze architectuur gebruik van de volgende onderdelen:

• Microsoft Entra Verbinding maken in faseringsmodus: de staging-server voor Microsoft Entra Verbinding maken topologieën biedt extra redundantie voor het Microsoft Entra Verbinding maken-exemplaar.

• Azure-abonnementen, Azure Virtual Desktop-werkruimten en hostgroepen: u kunt meerdere abonnementen, Azure Virtual Desktop-werkruimten en hostgroepen gebruiken voor beheergrenzen en zakelijke vereisten.

Scenariodetails

Dit architectuurdiagram vertegenwoordigt een typisch scenario dat de volgende elementen bevat:

• De Microsoft Entra-tenant is beschikbaar voor een nieuw bedrijf met de naam NewCompanyAB.onmicrosoft.com.
• Microsoft Entra Verbinding maken synchroniseert gebruikers van on-premises AD DS naar Microsoft Entra ID.
• Bedrijf A en Bedrijf B hebben afzonderlijke Azure-abonnementen. Ze hebben ook een abonnement op gedeelde services, aangeduid als abonnement 1 in het diagram.
• Een Azure hub-spoke-architectuur wordt geïmplementeerd met een virtueel netwerk van een gedeelde services-hub.
• Complexe hybride on-premises Active Directory-omgevingen zijn aanwezig met twee of meer Active Directory-forests. Domeinen leven in afzonderlijke forests, elk met een ander UPN-achtervoegsel. Bijvoorbeeld CompanyA.local met het UPN-achtervoegsel CompanyA.com, CompanyB.local met het UPN-achtervoegsel CompanyB.com en een extra UPN-achtervoegsel, NewCompanyAB.com.
• Domeincontrollers voor beide forests bevinden zich on-premises en in Azure.
• Geverifieerde domeinen zijn aanwezig in Azure voor CompanyA.com, CompanyB.com en NewCompanyAB.com.
• GPO en verouderde verificatie, zoals Kerberos, NTLM (Windows New Technology LAN Manager) en LDAP (Lightweight Directory Access Protocol) worden gebruikt.
• Voor Azure-omgevingen die nog steeds afhankelijk zijn van een on-premises infrastructuur, wordt privéconnectiviteit (site-naar-site-VPN of Azure ExpressRoute) ingesteld tussen on-premises en Azure.
• De Azure Virtual Desktop-omgeving bestaat uit een Azure Virtual Desktop-werkruimte voor elke bedrijfseenheid en twee hostgroepen per werkruimte.
• De Azure Virtual Desktop-sessiehosts worden toegevoegd aan domeincontrollers in Azure. Dat wil gezegd, companyA-sessiehosts worden lid van het domein CompanyA.local en de hosts van de CompanyB.local-sessie worden lid van het domein CompanyB.local.
• Azure-opslagaccounts kunnen Azure Files gebruiken voor FSLogix-profielen. Er wordt één account gemaakt per bedrijfsdomein (bijvoorbeeld CompanyA.local en CompanyB.local) en het account wordt toegevoegd aan het bijbehorende domein.

Potentiële gebruikscases

Hier volgen enkele relevante use cases voor deze architectuur:

• Fusies en overnames, organisatieherbranding en meerdere on-premises identiteiten
• Complexe on-premises Active Directory-omgevingen (vereisten voor meerdere forests, meerdere domeinen, groepsbeleid (of GPO) en verouderde verificatie)
• On-premises GPO-infrastructuur met Azure Virtual Desktop

Overwegingen

Houd bij het ontwerpen van uw workload op basis van deze architectuur rekening met de volgende ideeën.

Groepsbeleidsobjecten

• Als u de GPO-infrastructuur voor Azure Virtual Desktop wilt uitbreiden, moeten de on-premises domeincontrollers worden gesynchroniseerd met de IaaS-domeincontrollers (Infrastructure as a Service).

• Voor het uitbreiden van de GPO-infrastructuur naar Azure IaaS-domeincontrollers is privéconnectiviteit vereist.

Netwerk en connectiviteit

• De domeincontrollers zijn gedeelde onderdelen, dus ze moeten worden geïmplementeerd in een virtueel netwerk van een gedeelde services-hub in deze hub-spoke-architectuur.

• Azure Virtual Desktop-sessiehosts nemen deel aan de domeincontroller in Azure via hun respectieve hub-spoke-peering voor virtuele netwerken.

Azure Storage

De volgende ontwerpoverwegingen zijn van toepassing op containers met gebruikersprofielen, cloudcachecontainers en MSIX-pakketten :

• In dit scenario kunt u zowel Azure Files als Azure NetApp Files gebruiken. U kiest de juiste oplossing op basis van factoren zoals verwachte prestaties, kosten, enzovoort.

• Zowel Azure-opslagaccounts als Azure NetApp Files zijn beperkt tot deelname aan één AD DS tegelijk. In deze gevallen zijn meerdere Azure-opslagaccounts of Azure NetApp Files-exemplaren vereist.

Microsoft Entra ID

In scenario's met gebruikers in meerdere on-premises Active Directory-forests is slechts één Microsoft Entra-Verbinding maken Synchronisatieserver verbonden met de Microsoft Entra-tenant. Een uitzondering hierop is een Microsoft Entra-Verbinding maken-server die wordt gebruikt in de faseringsmodus.

De volgende identiteitstopologieën worden ondersteund:

• Meerdere on-premises Active Directory-forests.
• Een of meer resourceforests vertrouwen alle accountforests.
• Met een volledige mesh-topologie kunnen gebruikers en resources zich in elk forest bevinden. Meestal zijn er tweerichtingsvertrouwensrelaties tussen de bossen.

Zie de sectie Faseringsserver van Microsoft Entra Verbinding maken topologieën voor meer informatie.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

• Tom Maher | Senior Beveiligings- en identiteitstechnicus

Volgende stappen

Raadpleeg voor meer informatie de volgende artikelen:

• Microsoft Entra Verbinding maken topologie
• Verschillende identiteitsopties vergelijken: Zelfbeheerde Active Directory-domein Services (AD DS), Microsoft Entra ID en Microsoft Entra Domain Services (Microsoft Entra Domain Services)
• Documentatie voor Azure Virtual Desktop

Verwante resources

• Azure Virtual Desktop voor de onderneming
• Oplossingsidee: Meerdere forests met Microsoft Entra Domain Services