Jämför självhanterade Active Directory-domän Services, Microsoft Entra-ID och hanterade Microsoft Entra Domain Services
För att tillhandahålla program, tjänster eller enheter åtkomst till en central identitet finns det tre vanliga sätt att använda Active Directory-baserade tjänster i Azure. Det här valet i identitetslösningar ger dig flexibiliteten att använda den lämpligaste katalogen för organisationens behov. Om du till exempel främst hanterar molnbaserade användare som kör mobila enheter kanske det inte är meningsfullt att skapa och köra en egen identitetslösning för Active Directory-domän Services (AD DS). I stället kan du bara använda Microsoft Entra-ID.
De tre Active Directory-baserade identitetslösningarna har ett gemensamt namn och en gemensam teknik, men de är utformade för att tillhandahålla tjänster som uppfyller olika kundkrav. På hög nivå är följande identitetslösningar och funktionsuppsättningar:
- Active Directory-domän Services (AD DS) – Företagsklar LDAP-server (Lightweight Directory Access Protocol) som innehåller viktiga funktioner som identitet och autentisering, hantering av datorobjekt, grupprincip och förtroenden.
- AD DS är en central komponent i många organisationer med en lokal IT-miljö och tillhandahåller grundläggande funktioner för autentisering av användarkonton och datorhantering.
- Mer information finns i översikten över Active Directory-domän Services i Windows Server-dokumentationen.
- Microsoft Entra-ID – Molnbaserad identitets- och mobilenhetshantering som tillhandahåller användarkonto- och autentiseringstjänster för resurser som Microsoft 365, administrationscentret för Microsoft Entra eller SaaS-program.
- Microsoft Entra-ID kan synkroniseras med en lokal AD DS-miljö för att tillhandahålla en enda identitet till användare som arbetar internt i molnet.
- Mer information om Microsoft Entra-ID finns i Vad är Microsoft Entra-ID?
- Microsoft Entra Domain Services – Tillhandahåller hanterade domäntjänster med en delmängd av fullständigt kompatibla traditionella AD DS-funktioner som domänanslutning, grupprincip, LDAP och Kerberos/NTLM-autentisering.
- Domain Services integreras med Microsoft Entra ID, som i sig kan synkroniseras med en lokal AD DS-miljö. Den här möjligheten utökar centrala användningsfall för identiteter till traditionella webbprogram som körs i Azure som en del av en lift and shift-strategi.
- Mer information om synkronisering med Microsoft Entra-ID och lokalt finns i Hur objekt och autentiseringsuppgifter synkroniseras i en hanterad domän.
Den här översiktsartikeln jämför och kontrasterar hur dessa identitetslösningar kan fungera tillsammans eller användas oberoende av organisationens behov.
Domäntjänster och självhanterad AD DS
Om du har program och tjänster som behöver åtkomst till traditionella autentiseringsmekanismer som Kerberos eller NTLM finns det två sätt att tillhandahålla Active Directory-domän Services i molnet:
- En hanterad domän som du skapar med Hjälp av Microsoft Entra Domain Services. Microsoft skapar och hanterar de resurser som krävs.
- En självhanterad domän som du skapar och konfigurerar med traditionella resurser, till exempel virtuella datorer, Windows Server-gästoperativsystem och Active Directory-domän Services (AD DS). Sedan fortsätter du att administrera dessa resurser.
Med Domain Services distribueras och underhålls kärntjänstkomponenterna åt dig av Microsoft som en hanterad domänupplevelse. Du distribuerar, hanterar, korrigerar och skyddar inte AD DS-infrastrukturen för komponenter som de virtuella datorerna, Windows Server OS eller domänkontrollanter (DCs).
Domain Services tillhandahåller en mindre delmängd av funktioner till en traditionell självhanterad AD DS-miljö, vilket minskar en del av design- och hanteringskomplexiteten. Det finns till exempel inga AD-skogar, domäner, webbplatser och replikeringslänkar som kan utformas och underhållas. Du kan fortfarande skapa skogsförtroenden mellan Domäntjänster och lokala miljöer.
För program och tjänster som körs i molnet och behöver åtkomst till traditionella autentiseringsmekanismer som Kerberos eller NTLM ger Domain Services en hanterad domänupplevelse med minimala administrativa kostnader. Mer information finns i Hanteringsbegrepp för användarkonton, lösenord och administration i Domain Services.
När du distribuerar och kör en självhanterad AD DS-miljö måste du underhålla alla tillhörande infrastruktur- och katalogkomponenter. Det finns ytterligare underhållskostnader med en självhanterad AD DS-miljö, men du kan sedan utföra ytterligare uppgifter som att utöka schemat eller skapa skogsförtroenden.
Vanliga distributionsmodeller för en självhanterad AD DS-miljö som tillhandahåller identitet till program och tjänster i molnet omfattar följande:
- Fristående AD DS endast för molnet – Virtuella Azure-datorer konfigureras som domänkontrollanter och en separat AD DS-miljö endast i molnet skapas. Den här AD DS-miljön integreras inte med en lokal AD DS-miljö. En annan uppsättning autentiseringsuppgifter används för att logga in och administrera virtuella datorer i molnet.
- Utöka den lokala domänen till Azure – Ett virtuellt Azure-nätverk ansluter till ett lokalt nätverk med hjälp av en VPN-/ExpressRoute-anslutning. Virtuella Azure-datorer ansluter till det här virtuella Azure-nätverket, vilket gör att de kan anslutas till den lokala AD DS-miljön.
- Ett alternativ är att skapa virtuella Azure-datorer och höja upp dem som replikdomänkontrollanter från den lokala AD DS-domänen. Dessa domänkontrollanter replikeras via en VPN-/ExpressRoute-anslutning till den lokala AD DS-miljön. Den lokala AD DS-domänen utökas effektivt till Azure.
I följande tabell beskrivs några av de funktioner som du kan behöva för din organisation och skillnaderna mellan en hanterad domän eller en självhanterad AD DS-domän:
| Funktion | Hanterad domän | Självhanterad AD DS |
|---|---|---|
| Hanterad tjänst | ✓ | ✕ |
| Säkra distributioner | ✓ | Administratören skyddar distributionen |
| DNS-server | √ (hanterad tjänst) | ✓ |
| Domän- eller företagsadministratörsbehörigheter | ✕ | ✓ |
| Domänanslutning | ✓ | ✓ |
| Domänautentisering med NTLM och Kerberos | ✓ | ✓ |
| Kerberos-begränsad delegering | Resursbaserad | Resursbaserad & kontobaserad |
| Anpassad organisationsenhetsstruktur | ✓ | ✓ |
| Grupprincip | ✓ | ✓ |
| Schematillägg | ✕ | ✓ |
| AD-domän/skogsförtroenden | √ (endast envägs utgående skogsförtroenden) | ✓ |
| Säker LDAP (LDAPS) | ✓ | ✓ |
| LDAP-läsning | ✓ | ✓ |
| LDAP-skrivning | √ (inom den hanterade domänen) | ✓ |
| Geo-distribuerade distributioner | ✓ | ✓ |
Domain Services och Microsoft Entra ID
Med Microsoft Entra-ID kan du hantera identiteten för enheter som används av organisationen och styra åtkomsten till företagsresurser från dessa enheter. Användare kan också registrera sina personliga enheter (en BYO-modell (bring-your-own) med Microsoft Entra-ID, vilket ger enheten en identitet. Microsoft Entra-ID autentiserar sedan enheten när en användare loggar in på Microsoft Entra-ID och använder enheten för att komma åt skyddade resurser. Enheten kan hanteras med hjälp av MDM-programvara (Mobile Enhetshantering) som Microsoft Intune. Med den här hanteringsförmågan kan du begränsa åtkomsten till känsliga resurser till hanterade och principkompatibla enheter.
Traditionella datorer och bärbara datorer kan också ansluta till Microsoft Entra-ID. Den här mekanismen erbjuder samma fördelar med att registrera en personlig enhet med Microsoft Entra-ID, till exempel att tillåta användare att logga in på enheten med sina företagsautentiseringsuppgifter.
Microsoft Entra-anslutna enheter ger dig följande fördelar:
- Enkel inloggning (SSO) för program som skyddas av Microsoft Entra-ID.
- Företagsprincipkompatibel roaming av användarinställningar mellan enheter.
- Åtkomst till Windows Store för företag med företagets autentiseringsuppgifter.
- Windows Hello för företag.
- Begränsad åtkomst till appar och resurser från enheter som är kompatibla med företagets princip.
Enheter kan anslutas till Microsoft Entra-ID med eller utan en hybriddistribution som innehåller en lokal AD DS-miljö. I följande tabell beskrivs vanliga modeller för enhetsägarskap och hur de vanligtvis ansluts till en domän:
| Typ av enhet | Enhetsplattformar | Mekanism |
|---|---|---|
| Personliga enheter | Windows 10, iOS, Android, macOS | Microsoft Entra-registrerat |
| Organisationsägd enhet som inte är ansluten till lokal AD DS | Windows 10 | Microsoft Entra-anslutning |
| Organisationsägd enhet ansluten till en lokal AD DS | Windows 10 | Hybrid Microsoft Entra-anslutning |
På en Microsoft Entra-ansluten eller registrerad enhet sker användarautentisering med moderna OAuth/OpenID-Anslut-baserade protokoll. Dessa protokoll är utformade för att fungera via Internet, så är bra för mobila scenarier där användare får åtkomst till företagsresurser var som helst.
Med Domain Services-anslutna enheter kan program använda Kerberos- och NTLM-protokollen för autentisering, så att de kan stödja äldre program som migrerats för att köras på virtuella Azure-datorer som en del av en lift-and-shift-strategi. I följande tabell beskrivs skillnader i hur enheterna representeras och kan autentisera sig mot katalogen:
| Aspekt | Microsoft Entra-anslutning | Domain Services-ansluten |
|---|---|---|
| Enhet som styrs av | Microsoft Entra-ID | Domäntjänsthanterad domän |
| Representation i katalogen | Enhetsobjekt i Microsoft Entra-katalogen | Datorobjekt i domäntjänstens hanterade domän |
| Autentisering | OAuth/OpenID Anslut-baserade protokoll | Kerberos- och NTLM-protokoll |
| Hantering | MdM-programvara (Mobile Enhetshantering) som Intune | Grupprincip |
| Nätverk | Fungerar via Internet | Måste vara anslutet till eller peer-kopplat till det virtuella nätverk där den hanterade domänen distribueras |
| Perfekt för... | Mobila enheter eller skrivbordsenheter för slutanvändare | Virtuella serverdatorer som distribuerats i Azure |
Om lokal AD DS och Microsoft Entra-ID har konfigurerats för federerad autentisering med AD FS finns det ingen (aktuell/giltig) lösenordshash tillgänglig i Azure DS. Microsoft Entra-användarkonton som skapades innan fed-autentisering implementerades kan ha en gammal lösenordshash, men detta matchar sannolikt inte en hash för deras lokala lösenord. Det innebär att Domain Services inte kan verifiera användarnas autentiseringsuppgifter
Nästa steg
Kom igång med att använda Domain Services genom att skapa en domän som hanteras av Domain Services med hjälp av administrationscentret för Microsoft Entra.
Du kan också lära dig mer om hanteringsbegrepp för användarkonton, lösenord och administration i Domain Services och hur objekt och autentiseringsuppgifter synkroniseras i en hanterad domän.