Vanliga användningsfall och scenarier för Microsoft Entra Domain Services

Microsoft Entra Domain Services tillhandahåller hanterade domäntjänster som domänanslutning, grupprincip, LDAP (Lightweight Directory Access Protocol) och Kerberos/NTLM-autentisering. Microsoft Entra Domain Services integreras med din befintliga Microsoft Entra-klientorganisation, vilket gör det möjligt för användare att logga in med sina befintliga autentiseringsuppgifter. Du använder dessa domäntjänster utan att behöva distribuera, hantera och korrigera domänkontrollanter i molnet, vilket ger en smidigare lift-and-shift av lokala resurser till Azure.

Den här artikeln beskriver några vanliga affärsscenarier där Microsoft Entra Domain Services ger värde och uppfyller dessa behov.

Vanliga sätt att tillhandahålla identitetslösningar i molnet

När du migrerar befintliga arbetsbelastningar till molnet kan katalogmedvetna program använda LDAP för läs- eller skrivåtkomst till en lokal AD DS-katalog. Program som körs på Windows Server distribueras vanligtvis på domänanslutna virtuella datorer (VM) så att de kan hanteras på ett säkert sätt med grupprincip. För att autentisera slutanvändare kan programmen också förlita sig på Windows-integrerad autentisering, till exempel Kerberos- eller NTLM-autentisering.

IT-administratörer använder ofta någon av följande lösningar för att tillhandahålla en identitetstjänst till program som körs i Azure:

• Konfigurera en plats-till-plats-VPN-anslutning mellan arbetsbelastningar som körs i Azure och en lokal AD DS-miljö.
  • De lokala domänkontrollanterna tillhandahåller sedan autentisering via VPN-anslutningen.
• Skapa replikdomänkontrollanter med hjälp av virtuella Azure-datorer (VM) för att utöka AD DS-domänen/skogen från en lokal plats.
  • Domänkontrollanterna som körs på virtuella Azure-datorer tillhandahåller autentisering och replikerar kataloginformation mellan den lokala AD DS-miljön.
• Distribuera en fristående AD DS-miljö i Azure med hjälp av domänkontrollanter som körs på virtuella Azure-datorer.
  • Domänkontrollanterna som körs på virtuella Azure-datorer tillhandahåller autentisering, men det finns ingen kataloginformation som replikeras från en lokal AD DS-miljö.

Med dessa metoder gör VPN-anslutningar till den lokala katalogen program sårbara för tillfälliga nätverksfel eller avbrott. Om du distribuerar domänkontrollanter med hjälp av virtuella datorer i Azure måste IT-teamet hantera de virtuella datorerna och sedan skydda, korrigera, övervaka, säkerhetskopiera och felsöka dem.

Microsoft Entra Domain Services erbjuder alternativ till behovet av att skapa VPN-anslutningar tillbaka till en lokal AD DS-miljö eller köra och hantera virtuella datorer i Azure för att tillhandahålla identitetstjänster. Som en hanterad tjänst minskar Microsoft Entra Domain Services komplexiteten att skapa en integrerad identitetslösning för både hybridmiljöer och molnbaserade miljöer.

Microsoft Entra Domain Services för hybridorganisationer

Många organisationer kör en hybridinfrastruktur som innehåller både molnbaserade och lokala programarbetsbelastningar. Äldre program som migreras till Azure som en del av en lift and shift-strategi kan använda traditionella LDAP-anslutningar för att tillhandahålla identitetsinformation. För att stödja den här hybridinfrastrukturen kan identitetsinformation från en lokal AD DS-miljö synkroniseras till en Microsoft Entra-klientorganisation. Microsoft Entra Domain Services tillhandahåller sedan dessa äldre program i Azure med en identitetskälla, utan att behöva konfigurera och hantera programanslutningar tillbaka till lokala katalogtjänster.

Nu ska vi titta på ett exempel för Litware Corporation, en hybridorganisation som kör både lokala resurser och Azure-resurser:

• Program och serverarbetsbelastningar som kräver domäntjänster distribueras i ett virtuellt nätverk i Azure.
  • Detta kan omfatta äldre program som migrerats till Azure som en del av en lift and shift-strategi.
• Om du vill synkronisera identitetsinformation från deras lokala katalog till deras Microsoft Entra-klientorganisation distribuerar Litware Corporation Microsoft Entra Anslut.
  • Identitetsinformation som synkroniseras omfattar användarkonton och gruppmedlemskap.
• Litwares IT-team aktiverar Microsoft Entra Domain Services för sin Microsoft Entra-klientorganisation i det här, eller ett peer-kopplat, virtuellt nätverk.
• Program och virtuella datorer som distribueras i det virtuella Azure-nätverket kan sedan använda Microsoft Entra Domain Services-funktioner som domänanslutning, LDAP-läsning, LDAP-bindning, NTLM- och Kerberos-autentisering och grupprincip.

Microsoft Entra Domain Services för organisationer som endast är molnbaserade

En Microsoft Entra-klientorganisation som endast är molnbaserad har ingen lokal identitetskälla. Användarkonton och gruppmedlemskap skapas och hanteras till exempel direkt i Microsoft Entra-ID.

Nu ska vi titta på ett exempel för Contoso, en molnbaserad organisation som använder Microsoft Entra-ID för identitet. Alla användaridentiteter, deras autentiseringsuppgifter och gruppmedlemskap skapas och hanteras i Microsoft Entra-ID. Det finns ingen ytterligare konfiguration av Microsoft Entra Anslut för att synkronisera identitetsinformation från en lokal katalog.

• Program och serverarbetsbelastningar som kräver domäntjänster distribueras i ett virtuellt nätverk i Azure.
• Contosos IT-team aktiverar Microsoft Entra Domain Services för sin Microsoft Entra-klientorganisation i det här, eller ett peer-kopplat, virtuellt nätverk.
• Program och virtuella datorer som distribueras i det virtuella Azure-nätverket kan sedan använda Microsoft Entra Domain Services-funktioner som domänanslutning, LDAP-läsning, LDAP-bindning, NTLM- och Kerberos-autentisering och grupprincip.

Säker administration av virtuella Azure-datorer

För att du ska kunna använda en enda uppsättning AD-autentiseringsuppgifter kan virtuella Azure-datorer anslutas till en hanterad domän i Microsoft Entra Domain Services. Den här metoden minskar problem med hantering av autentiseringsuppgifter, till exempel att underhålla lokala administratörskonton på varje virtuell dator eller separata konton och lösenord mellan miljöer.

Virtuella datorer som är anslutna till en hanterad domän kan också administreras och skyddas med hjälp av en grupprincip. Nödvändiga säkerhetsbaslinjer kan tillämpas på virtuella datorer för att låsa dem i enlighet med företagets säkerhetsriktlinjer. Du kan till exempel använda funktioner för grupprinciphantering för att begränsa vilka typer av program som kan startas på den virtuella datorn.

Nu ska vi titta på ett vanligt exempelscenario. När servrar och annan infrastruktur når slutet av livscykeln vill Contoso flytta program som för närvarande finns lokalt till molnet. Deras nuvarande IT-standard kräver att servrar som är värdar för företagsprogram måste vara domänanslutna och hanterade med hjälp av en grupprincip.

Contosos IT-administratör föredrar att domänansluta virtuella datorer som distribueras i Azure för att underlätta administrationen eftersom användarna sedan kan logga in med sina företagsautentiseringsuppgifter. När de är domänanslutna kan virtuella datorer också konfigureras för att uppfylla nödvändiga säkerhetsbaslinjer med hjälp av grupprincipobjekt (GPO). Contoso föredrar att inte distribuera, övervaka och hantera sina egna domänkontrollanter i Azure.

Microsoft Entra Domain Services passar bra för det här användningsfallet. Med en hanterad domän kan du domänansluta virtuella datorer, använda en enda uppsättning autentiseringsuppgifter och tillämpa en grupprincip. Och eftersom det är en hanterad domän behöver du inte konfigurera och underhålla domänkontrollanterna själv.

Distributionsanteckningar

Följande distributionsöverväganden gäller för det här exempelanvändningsfallet:

• Hanterade domäner använder en enda, platt organisationsenhetsstruktur (OU) som standard. Alla domänanslutna virtuella datorer finns i en enda organisationsenhet. Om du vill kan du skapa anpassade organisationsenheter.
• Microsoft Entra Domain Services använder ett inbyggt grupprincipobjekt för användare och datorcontainrar. Om du vill ha ytterligare kontroll kan du skapa anpassade grupprincipobjekt och rikta dem mot anpassade organisationsenheter.
• Microsoft Entra Domain Services stöder det grundläggande AD-datorobjektschemat. Du kan inte utöka datorobjektets schema.

Lift-and-shift-lokala program som använder LDAP-bindningsautentisering

Som ett exempelscenario har Contoso ett lokalt program som köptes från en ISV för många år sedan. Programmet är för närvarande i underhållsläge av ISV och det är oöverkomligt dyrt att begära ändringar i programmet. Det här programmet har en webbaserad klientdel som samlar in användarautentiseringsuppgifter med hjälp av ett webbformulär och sedan autentiserar användare genom att utföra en LDAP-bindning till den lokala AD DS-miljön.

Contoso vill migrera det här programmet till Azure. Programmet bör fortsätta att fungera som det är, utan att det behövs några ändringar. Dessutom bör användarna kunna autentisera med sina befintliga företagsautentiseringsuppgifter och utan ytterligare utbildning. Det bör vara transparent för slutanvändare där programmet körs.

I det här scenariot låter Microsoft Entra Domain Services program utföra LDAP-bindningar som en del av autentiseringsprocessen. Äldre lokala program kan lyfta och flytta till Azure och fortsätta att smidigt autentisera användare utan någon ändring i konfigurationen eller användarupplevelsen.

Distributionsanteckningar

Följande distributionsöverväganden gäller för det här exempelanvändningsfallet:

• Kontrollera att programmet inte behöver ändra/skriva till katalogen. LDAP-skrivåtkomst till en hanterad domän stöds inte.
• Du kan inte ändra lösenord direkt mot en hanterad domän. Slutanvändare kan ändra sitt lösenord antingen med hjälp av microsoft Entra-mekanismen för lösenordsändring via självbetjäning eller mot den lokala katalogen. Dessa ändringar synkroniseras sedan automatiskt och är tillgängliga i den hanterade domänen.

Lift-and-shift-lokala program som använder LDAP-läsning för att få åtkomst till katalogen

Precis som i föregående exempelscenario antar vi att Contoso har ett lokalt verksamhetsspecifikt program (LOB) som utvecklades för nästan ett decennium sedan. Det här programmet är katalogmedveten och har utformats för att använda LDAP för att läsa information/attribut om användare från AD DS. Programmet ändrar inte attribut eller skriver på annat sätt till katalogen.

Contoso vill migrera det här programmet till Azure och dra tillbaka den åldrande lokala maskinvaran som för närvarande är värd för det här programmet. Programmet kan inte skrivas om för att använda moderna katalog-API:er, till exempel REST-baserade Microsoft Graph API. Ett lift-and-shift-alternativ önskas där programmet kan migreras för att köras i molnet, utan att ändra kod eller skriva om programmet.

För att hjälpa till med det här scenariot låter Microsoft Entra Domain Services program utföra LDAP-läsningar mot den hanterade domänen för att få den attributinformation som behövs. Programmet behöver inte skrivas om, så en lift-and-shift till Azure gör att användarna kan fortsätta att använda appen utan att inse att det finns en ändring i var den körs.

Distributionsanteckningar

Följande distributionsöverväganden gäller för det här exempelanvändningsfallet:

• Kontrollera att programmet inte behöver ändra/skriva till katalogen. LDAP-skrivåtkomst till en hanterad domän stöds inte.
• Kontrollera att programmet inte behöver ett anpassat/utökat Active Directory-schema. Schematillägg stöds inte i Microsoft Entra Domain Services.

Migrera en lokal tjänst eller ett daemonprogram till Azure

Vissa program innehåller flera nivåer, där en av nivåerna måste utföra autentiserade anrop till en serverdelsnivå, till exempel en databas. AD-tjänstkonton används ofta i dessa scenarier. När du lyfter och flyttar program till Azure kan du med Microsoft Entra Domain Services fortsätta att använda tjänstkonton på samma sätt. Du kan välja att använda samma tjänstkonto som synkroniseras från din lokala katalog till Microsoft Entra-ID eller skapa en anpassad organisationsenhet och sedan skapa ett separat tjänstkonto i organisationsenheten. Med endera metoden fortsätter programmen att fungera på samma sätt för att göra autentiserade anrop till andra nivåer och tjänster.

I det här exempelscenariot har Contoso ett anpassat program för programvaruvalv som innehåller en webbklientdel, en SQL-server och en FTP-server i serverdelen. Windows-integrerad autentisering med tjänstkonton autentiserar webbklientdelen till FTP-servern. Webbklientdelen är konfigurerad för att köras som ett tjänstkonto. Serverdelsservern är konfigurerad för att auktorisera åtkomst från tjänstkontot för webbklientdelen. Contoso vill inte distribuera och hantera sina egna virtuella domänkontrollantdatorer i molnet för att flytta programmet till Azure.

I det här scenariot kan servrar som är värdar för webbklientdelen, SQL Server och FTP-servern migreras till virtuella Azure-datorer och anslutas till en hanterad domän. De virtuella datorerna kan sedan använda samma tjänstkonto i sin lokala katalog för appens autentiseringsändamål, som synkroniseras via Microsoft Entra-ID med hjälp av Microsoft Entra Anslut.

Distributionsanteckningar

Följande distributionsöverväganden gäller för det här exempelanvändningsfallet:

• Kontrollera att programmen använder ett användarnamn och lösenord för autentisering. Certifikat- eller smartkortsbaserad autentisering stöds inte av Microsoft Entra Domain Services.
• Du kan inte ändra lösenord direkt mot en hanterad domän. Slutanvändare kan ändra sitt lösenord antingen med hjälp av microsoft Entra-mekanismen för lösenordsändring via självbetjäning eller mot den lokala katalogen. Dessa ändringar synkroniseras sedan automatiskt och är tillgängliga i den hanterade domänen.

Distributioner av Fjärrskrivbordstjänster i Windows Server i Azure

Du kan använda Microsoft Entra Domain Services för att tillhandahålla hanterade domäntjänster till fjärrskrivbordsservrar som distribuerats i Azure.

Mer information om det här distributionsscenariot finns i integrera Microsoft Entra Domain Services med din RDS-distribution.

Domänanslutna HDInsight-kluster

Du kan konfigurera ett Azure HDInsight-kluster som är anslutet till en hanterad domän med Apache Ranger aktiverat. Du kan skapa och tillämpa Hive-principer via Apache Ranger och tillåta användare, till exempel dataforskare, att ansluta till Hive med hjälp av ODBC-baserade verktyg som Excel eller Tableau. Vi fortsätter att arbeta med att lägga till andra arbetsbelastningar, till exempel HBase, Spark och Storm i domänanslutna HDInsight.

Mer information om det här distributionsscenariot finns i konfigurera domänanslutna HDInsight-kluster

Nästa steg

Kom igång genom att skapa och konfigurera en hanterad Domän för Microsoft Entra Domain Services.