Veelvoorkomende use cases en scenario's voor Microsoft Entra Domain Services
Microsoft Entra Domain Services biedt beheerde domeinservices zoals domeindeelname, groepsbeleid, LIGHTWEIGHT Directory Access Protocol (LDAP) en Kerberos/NTLM-verificatie. Microsoft Entra Domain Services kan worden geïntegreerd met uw bestaande Microsoft Entra-tenant, waardoor gebruikers zich kunnen aanmelden met hun bestaande referenties. U gebruikt deze domeinservices zonder dat u domeincontrollers in de cloud hoeft te implementeren, beheren en patchen. Dit biedt een soepelere lift-and-shift van on-premises resources naar Azure.
In dit artikel worden enkele veelvoorkomende bedrijfsscenario's beschreven waarin Microsoft Entra Domain Services waarde biedt en aan deze behoeften voldoet.
Algemene manieren om identiteitsoplossingen in de cloud te bieden
Wanneer u bestaande workloads naar de cloud migreert, wordt voor toepassingen met een mappenstructuur mogelijk LDAP gebruikt voor lees- of schrijftoegang tot een on-premises AD DS-map. Toepassingen die op Windows Server worden uitgevoerd, worden doorgaans geïmplementeerd op met een domein samengevoegde virtuele machines (VM's) zodat ze veilig kunnen worden beheerd met behulp van groepsbeleid. Voor het verifiëren van eindgebruikers kunnen de toepassingen ook afhankelijk zijn van met Windows geïntegreerde verificatie, zoals Kerberos of NTLM-verificatie.
IT-beheerders gebruiken vaak een van de volgende oplossingen om een identiteitsservice te bieden voor toepassingen die worden uitgevoerd in Azure:
- Configureer een site-naar-site VPN-verbinding tussen workloads die worden uitgevoerd in Azure en een on-premises AD DS-omgeving.
- De on-premises domeincontrollers bieden vervolgens verificatie via de VPN-verbinding.
- Maak replica's van domeincontrollers met behulp van virtuele Azure-machines (VM's) om het AD DS-domein/forest uit te breiden van on-premises.
- De domeincontrollers die worden uitgevoerd op virtuele Azure-machines bieden verificatie en repliceren mapgegevens tussen de on-premises AD DS-omgeving.
- Implementeer een zelfstandige AD DS-omgeving in Azure met behulp van domeincontrollers die worden uitgevoerd op virtuele Azure-machines.
- De domeincontrollers die worden uitgevoerd op virtuele Azure-machines bieden verificatie, maar er worden geen mapgegevens gerepliceerd vanuit een on-premises AD DS-omgeving.
Met deze methoden maken VPN-verbindingen met de on-premises map toepassingen kwetsbaar voor tijdelijke netwerkstoringen of uitval. Als u domeincontrollers implementeert met behulp van virtuele machines in Azure, moet het IT-team de virtuele machines beheren en deze vervolgens beveiligen, patchen en bewaken, er een back-up van maken en problemen oplossen.
Microsoft Entra Domain Services biedt alternatieven voor het maken van VPN-verbindingen naar een on-premises AD DS-omgeving of het uitvoeren en beheren van VM's in Azure om identiteitsservices te bieden. Als beheerde service vermindert Microsoft Entra Domain Services de complexiteit om een geïntegreerde identiteitsoplossing te maken voor zowel hybride als cloudomgevingen.
Microsoft Entra Domain Services voor hybride organisaties
Veel organisaties voeren een hybride infrastructuur uit met toepassingsworkloads in zowel de cloud als on-premises. Voor verouderde toepassingen die naar Azure zijn gemigreerd als onderdeel van een lift-and-shift-strategie worden mogelijk traditionele LDAP-verbindingen gebruikt om identiteitsgegevens te bieden. Ter ondersteuning van deze hybride infrastructuur kunnen identiteitsgegevens uit een on-premises AD DS-omgeving worden gesynchroniseerd met een Microsoft Entra-tenant. Microsoft Entra Domain Services biedt deze verouderde toepassingen in Azure vervolgens een identiteitsbron, zonder dat u de toepassingsconnectiviteit met on-premises adreslijstservices hoeft te configureren en beheren.
Laten we eens kijken naar een voorbeeld voor Litware Corporation, een hybride organisatie die zowel on-premises resources als Azure-resources uitvoert:
- Toepassingen en serverworkloads waarvoor domeinservices moeten worden geïmplementeerd in een virtueel netwerk in Azure.
- Dit kunnen verouderde toepassingen zijn die naar Azure zijn gemigreerd als onderdeel van een lift-and-shift-strategie.
- Litware Corporation implementeert Microsoft Entra Verbinding maken om identiteitsgegevens uit hun on-premises directory te synchroniseren met hun Microsoft Entra-tenant.
- Identiteitsgegevens die worden gesynchroniseerd, zijn onder andere gebruikersaccounts en groepslidmaatschappen.
- Het IT-team van Litware stelt Microsoft Entra Domain Services in staat voor hun Microsoft Entra-tenant in dit of een gekoppeld virtueel netwerk.
- Toepassingen en VM's die zijn geïmplementeerd in het virtuele Azure-netwerk, kunnen vervolgens gebruikmaken van Functies van Microsoft Entra Domain Services, zoals domeindeelname, LDAP-leesbewerking, LDAP-binding, NTLM- en Kerberos-verificatie en Groepsbeleid.
Belangrijk
Microsoft Entra Verbinding maken mag alleen worden geïnstalleerd en geconfigureerd voor synchronisatie met on-premises AD DS-omgevingen. Het wordt niet ondersteund om Microsoft Entra Verbinding maken te installeren in een beheerd domein om objecten terug te synchroniseren naar Microsoft Entra-id.
Microsoft Entra Domain Services voor organisaties in de cloud
Een Microsoft Entra-tenant in de cloud heeft geen on-premises identiteitsbron. Gebruikersaccounts en groepslidmaatschappen worden bijvoorbeeld rechtstreeks in Microsoft Entra-id gemaakt en beheerd.
Laten we nu eens kijken naar een voorbeeld voor Contoso, een cloudorganisatie die gebruikmaakt van Microsoft Entra ID voor identiteit. Alle gebruikersidentiteiten, hun referenties en groepslidmaatschappen worden gemaakt en beheerd in Microsoft Entra-id. Er is geen aanvullende configuratie van Microsoft Entra Verbinding maken om identiteitsgegevens uit een on-premises directory te synchroniseren.
- Toepassingen en serverworkloads waarvoor domeinservices moeten worden geïmplementeerd in een virtueel netwerk in Azure.
- Het IT-team van Contoso stelt Microsoft Entra Domain Services in staat voor hun Microsoft Entra-tenant in dit of een gekoppeld virtueel netwerk.
- Toepassingen en VM's die zijn geïmplementeerd in het virtuele Azure-netwerk, kunnen vervolgens gebruikmaken van Functies van Microsoft Entra Domain Services, zoals domeindeelname, LDAP-leesbewerking, LDAP-binding, NTLM- en Kerberos-verificatie en Groepsbeleid.
Beveiligd beheer van virtuele Azure-machines
Als u één set AD-referenties wilt gebruiken, kunnen virtuele Azure-machines (VM's) worden toegevoegd aan een door Microsoft Entra Domain Services beheerd domein. Deze aanpak vermindert problemen met referentiebeheer, zoals het onderhouden van lokale beheerdersaccounts op elke VIRTUELE machine of afzonderlijke accounts en wachtwoorden tussen omgevingen.
VM's die zijn gekoppeld aan een beheerd domein, kunnen ook worden beheerd en beveiligd met behulp van groepsbeleid. Vereiste beveiligingsbasislijnen kunnen worden toegepast op VM's om ze te vergrendelen in overeenstemming met de beveiligingsrichtlijnen van het bedrijf. U kunt bijvoorbeeld mogelijkheden voor groepsbeleidsbeheer gebruiken om de typen toepassingen te beperken die kunnen worden gestart op de virtuele machine.
Laten we eens kijken naar een veelvoorkomend voorbeeldscenario. Naarmate servers en andere infrastructuur het einde van de levensduur bereiken, wil Contoso toepassingen die momenteel on-premises worden gehost, verplaatsen naar de cloud. De huidige IT-standaard vereist dat servers die bedrijfstoepassingen hosten, lid zijn van een domein en moeten worden beheerd met behulp van groepsbeleid.
De IT-beheerder van Contoso wil liever lid worden van VM's die zijn geïmplementeerd in Azure om beheer eenvoudiger te maken, omdat gebruikers zich vervolgens kunnen aanmelden met hun bedrijfsreferenties. Wanneer lid is van een domein, kunnen VM's ook worden geconfigureerd om te voldoen aan de vereiste beveiligingsbasislijnen met behulp van groepsbeleidsobjecten (GPO's). Contoso wil liever niet hun eigen domeincontrollers implementeren, bewaken en beheren in Azure.
Microsoft Entra Domain Services is geschikt voor deze use-case. Met een beheerd domein kunt u VM's toevoegen aan een domein, één set referenties gebruiken en groepsbeleid toepassen. En omdat het een beheerd domein is, hoeft u de domeincontrollers niet zelf te configureren en te onderhouden.
Opmerkingen bij de implementatie
De volgende implementatieoverwegingen zijn van toepassing op dit voorbeeldgebruik:
- Beheerde domeinen maken standaard gebruik van één organisatie-eenheidsstructuur (OE). Alle aan een domein gekoppelde VM's bevinden zich in één organisatie-eenheid. Desgewenst kunt u aangepaste organisatie-eenheden maken.
- Microsoft Entra Domain Services maakt gebruik van een ingebouwd groepsbeleidsobject voor de containers voor gebruikers en computers. Voor extra controle kunt u aangepaste GPO's maken en deze richten op aangepaste organisatie-eenheden.
- Microsoft Entra Domain Services ondersteunt het basis-AD-computerobjectschema. U kunt het schema van het computerobject niet uitbreiden.
Lift-and-shift on-premises toepassingen die gebruikmaken van LDAP-bindingsverificatie
Als voorbeeldscenario heeft Contoso een on-premises toepassing die vele jaren geleden is gekocht bij een ISV. De toepassing bevindt zich momenteel in de onderhoudsmodus door de ISV en het aanvragen van wijzigingen in de toepassing is niet duur. Deze toepassing heeft een webfront-end die gebruikersreferenties verzamelt met behulp van een webformulier en vervolgens gebruikers verifieert door een LDAP-binding uit te voeren met de on-premises AD DS-omgeving.
Contoso wil deze toepassing migreren naar Azure. De toepassing moet gewoon blijven werken, zonder dat er wijzigingen nodig zijn. Daarnaast moeten gebruikers zich kunnen verifiëren met hun bestaande bedrijfsreferenties en zonder extra training. Het moet transparant zijn voor eindgebruikers waarop de toepassing wordt uitgevoerd.
In dit scenario kunnen toepassingen met Microsoft Entra Domain Services LDAP-bindingen uitvoeren als onderdeel van het verificatieproces. Verouderde on-premises toepassingen kunnen lift-and-shiften naar Azure en blijven gebruikers naadloos verifiëren zonder enige wijziging in de configuratie of gebruikerservaring.
Opmerkingen bij de implementatie
De volgende implementatieoverwegingen zijn van toepassing op dit voorbeeldgebruik:
- Zorg ervoor dat de toepassing niet hoeft te wijzigen/schrijven naar de map. LDAP-schrijftoegang tot een beheerd domein wordt niet ondersteund.
- U kunt wachtwoorden niet rechtstreeks wijzigen voor een beheerd domein. Eindgebruikers kunnen hun wachtwoord wijzigen met behulp van het selfservicemechanisme voor wachtwoordwijziging van Microsoft Entra of met de on-premises directory. Deze wijzigingen worden vervolgens automatisch gesynchroniseerd en beschikbaar in het beheerde domein.
Lift-and-shift on-premises toepassingen die GEBRUIKMAKEN van LDAP-leesbewerkingen voor toegang tot de directory
Net als in het vorige voorbeeldscenario gaan we ervan uit dat Contoso een on-premises LOB-toepassing (Line-Of-Business) heeft die bijna tien jaar geleden is ontwikkeld. Deze toepassing is directorybewust en is ontworpen om LDAP te gebruiken voor het lezen van informatie/kenmerken over gebruikers van AD DS. De toepassing wijzigt geen kenmerken of schrijft op een andere manier naar de map.
Contoso wil deze toepassing migreren naar Azure en de verouderde on-premises hardware buiten gebruik stellen die momenteel als host fungeert voor deze toepassing. De toepassing kan niet opnieuw worden geschreven voor het gebruik van moderne map-API's, zoals de Microsoft Graph API op basis van REST. Een lift-and-shift-optie is gewenst waar de toepassing kan worden gemigreerd om te worden uitgevoerd in de cloud, zonder code te wijzigen of de toepassing te herschrijven.
Om dit scenario te helpen, kunnen toepassingen met Microsoft Entra Domain Services LDAP-leesbewerkingen uitvoeren op het beheerde domein om de benodigde kenmerkgegevens op te halen. De toepassing hoeft niet opnieuw te worden geschreven, dus met een lift-and-shift in Azure kunnen gebruikers de app blijven gebruiken zonder te beseffen dat er een wijziging is in waar deze wordt uitgevoerd.
Opmerkingen bij de implementatie
De volgende implementatieoverwegingen zijn van toepassing op dit voorbeeldgebruik:
- Zorg ervoor dat de toepassing niet hoeft te wijzigen/schrijven naar de map. LDAP-schrijftoegang tot een beheerd domein wordt niet ondersteund.
- Zorg ervoor dat de toepassing geen aangepast/uitgebreid Active Directory-schema nodig heeft. Schema-extensies worden niet ondersteund in Microsoft Entra Domain Services.
Een on-premises service of daemon-toepassing migreren naar Azure
Sommige toepassingen bevatten meerdere lagen, waarbij een van de lagen geverifieerde aanroepen moet uitvoeren naar een back-endlaag, zoals een database. AD-serviceaccounts worden vaak gebruikt in deze scenario's. Wanneer u toepassingen opheft en verschuift naar Azure, kunt u met Microsoft Entra Domain Services op dezelfde manier serviceaccounts blijven gebruiken. U kunt ervoor kiezen om hetzelfde serviceaccount te gebruiken dat vanuit uw on-premises adreslijst wordt gesynchroniseerd met Microsoft Entra-id of om een aangepaste organisatie-eenheid te maken en vervolgens een afzonderlijk serviceaccount in die organisatie-eenheid te maken. Met beide benaderingen blijven toepassingen op dezelfde manier werken om geverifieerde aanroepen naar andere lagen en services uit te voeren.
In dit voorbeeldscenario heeft Contoso een aangepaste softwarekluistoepassing die een webfront-end, een SQL-server en een back-end FTP-server bevat. Met Windows geïntegreerde verificatie met behulp van serviceaccounts wordt de webfront-end geverifieerd bij de FTP-server. De webfront-end is ingesteld voor uitvoering als een serviceaccount. De back-endserver is geconfigureerd voor het autoriseren van toegang vanuit het serviceaccount voor de webfront-end. Contoso wil hun eigen domeincontroller-VM's in de cloud niet implementeren en beheren om deze toepassing naar Azure te verplaatsen.
Voor dit scenario kunnen de servers die als host fungeren voor de webfront-end, SQL-server en de FTP-server worden gemigreerd naar Virtuele Azure-machines en worden gekoppeld aan een beheerd domein. De VM's kunnen vervolgens hetzelfde serviceaccount gebruiken in hun on-premises adreslijst voor de verificatiedoeleinden van de app, die wordt gesynchroniseerd via Microsoft Entra-id met behulp van Microsoft Entra Verbinding maken.
Opmerkingen bij de implementatie
De volgende implementatieoverwegingen zijn van toepassing op dit voorbeeldgebruik:
- Zorg ervoor dat de toepassingen een gebruikersnaam en wachtwoord gebruiken voor verificatie. Verificatie op basis van certificaten of smartcards wordt niet ondersteund door Microsoft Entra Domain Services.
- U kunt wachtwoorden niet rechtstreeks wijzigen voor een beheerd domein. Eindgebruikers kunnen hun wachtwoord wijzigen met behulp van het selfservicemechanisme voor wachtwoordwijziging van Microsoft Entra of met de on-premises directory. Deze wijzigingen worden vervolgens automatisch gesynchroniseerd en beschikbaar in het beheerde domein.
Implementaties van Extern bureaublad-services van Windows Server in Azure
U kunt Microsoft Entra Domain Services gebruiken om beheerde domeinservices te bieden aan extern-bureaubladservers die zijn geïmplementeerd in Azure.
Zie voor meer informatie over dit implementatiescenario hoe u Microsoft Entra Domain Services integreert met uw RDS-implementatie.
AAN een domein gekoppelde HDInsight-clusters
U kunt een Azure HDInsight-cluster instellen dat is gekoppeld aan een beheerd domein waarvoor Apache Ranger is ingeschakeld. U kunt Hive-beleid maken en toepassen via Apache Ranger en gebruikers, zoals gegevenswetenschappers, toestaan verbinding te maken met Hive met behulp van ODBC-hulpprogramma's zoals Excel of Tableau. We blijven werken om andere workloads, zoals HBase, Spark en Storm, toe te voegen aan HDInsight die lid zijn van een domein.
Zie voor meer informatie over dit implementatiescenario hoe u HDInsight-clusters configureert die lid zijn van een domein
Volgende stappen
Maak en configureer een door Microsoft Entra Domain Services beheerd domein om aan de slag te gaan.