I den här artikeln jämförs alternativ för att integrera din lokala Active Directory-miljö (AD) med ett Azure-nätverk. För varje alternativ finns en mer detaljerad referensarkitektur tillgänglig.
Många organisationer använder Active Directory Domain Services (AD DS) för att autentisera identiteter som är kopplade till användare, datorer, program eller andra resurser som ingår i ett säkerhetsområde. Katalogs- och identitetstjänster är vanligtvis lokalt värdbaserade, men om ditt program är delvis lokalt värdbaserat, delvis Azure-baserat, kan det finnas en fördröjning när autentiseringsbegäranden skickas tillbaka till den lokala tjänsten från Azure. Om katalogs- och identitetstjänster implementeras i Azure kan den här fördröjningen minskas.
Azure tillhandahåller två lösningar för att implementera katalogs- och identitetstjänster i Azure:
Använd Microsoft Entra-ID för att skapa en Active Directory-domän i molnet och ansluta den till din lokal Active Directory domän. Microsoft Entra Anslut integrerar dina lokala kataloger med Microsoft Entra-ID.
Utöka din befintliga lokala Active Directory-infrastruktur till Azure genom att distribuera en virtuell dator i Azure som kör AD DS som en domänkontrollant. Den här arkitekturen är vanligare när det lokala nätverket och det virtuella Azure-nätverket (VNet) är anslutna via en VPN- eller ExpressRoute-anslutning. Flera varianter av denna arkitektur är möjliga:
- Skapa en domän i Azure och anslut den till din lokala AD-skog.
- Skapa en separat skog i Azure som är betrodd av domäner i din lokala skog.
- Replikera en distribution av Active Directory Federation Services (AD FS) till Azure.
I de följande avsnitten får du en mer ingående beskrivning av dessa alternativ.
Integrera dina lokala domäner med Microsoft Entra-ID
Använd Microsoft Entra-ID för att skapa en domän i Azure och länka den till en lokal AD-domän.
Microsoft Entra-katalogen är inte ett tillägg för en lokal katalog. Det är i stället en kopia som innehåller samma objekt och identiteter. Ändringar som görs i dessa objekt lokalt kopieras till Microsoft Entra-ID, men ändringar som görs i Microsoft Entra-ID replikeras inte tillbaka till den lokala domänen.
Du kan också använda Microsoft Entra-ID utan att använda en lokal katalog. I det här fallet fungerar Microsoft Entra-ID som den primära källan för all identitetsinformation i stället för att innehålla data som replikeras från en lokal katalog.
Fördelar
- Du behöver inte underhålla en AD-infrastruktur i molnet. Microsoft Entra ID hanteras och underhålls helt av Microsoft.
- Microsoft Entra-ID tillhandahåller samma identitetsinformation som är tillgänglig lokalt.
- Autentisering kan utföras i Azure, vilket minskar behovet av att externa program och användare kontaktar den lokala domänen.
Utmaningar
- Du måste konfigurera anslutningen till din lokala domän för att hålla Microsoft Entra-katalogen synkroniserad.
- Program kan behöva skrivas om för att aktivera autentisering via Microsoft Entra-ID.
- Om du vill autentisera tjänst- och datorkonton måste du även distribuera Microsoft Entra Domain Services.
Referensarkitektur
AD DS i Azure har anslutits till en lokal skog
Distribuera AD Domain Services-servrar (AD DS) till Azure. Skapa en domän i Azure och anslut den till din lokala AD-skog.
Överväg det här alternativet om du behöver använda AD DS-funktioner som för närvarande inte implementeras av Microsoft Entra ID.
Fördelar
- Ger åtkomst till samma identitetsinformation som är tillgänglig lokalt.
- Du kan autentisera användar-, tjänst- och datorkonton lokalt och i Azure.
- Du behöver inte hantera en separat AD-skog. Domänen i Azure kan tillhöra den lokala skogen.
- Du kan tillämpa grupprinciper som definierats av lokala grupprincipobjekt till domänen i Azure.
Utmaningar
- Du måste distribuera och hantera dina egna AD DS-servrar och din egen AD DS-domän i molnet.
- Viss synkroniseringsfördröjning kan förekomma mellan domänservrarna i molnet och servrarna som körs lokalt.
Referensarkitektur
AD DS i Azure med en separat skog
Distribuera AD Domain Services-servrar (AD DS) till Azure, men skapa en separat Active Directory-skog som är avgränsad från den lokala skogen. Den här skogen är betrodd av domäner i din lokala skog.
Vanliga tillämpningar av den här arkitekturen är att upprätthålla separering av säkerhetsskäl för objekt och identiteter som lagras i molnet, och att migrera enskilda domäner från en lokal plats till molnet.
Fördelar
- Du kan implementera lokala identiteter och avgränsa identiteter som endast finns i Azure.
- Du behöver inte replikera från den lokala AD-skogen till Azure.
Utmaningar
- Autentisering i Azure för lokala identiteter kräver extra nätverkssteg till de lokala AD-servrarna.
- Du måste distribuera dina egna AD DS-servrar och din egen skog i molnet och upprätta lämpliga förtroenderelationer mellan skogarna.
Referensarkitektur
Utöka AD FS till Azure
Replikera en distribution av Active Directory Federation Services (AD FS) till Azure för att utföra en federerad autentisering och auktorisering för komponenter som körs i Azure.
Vanliga användningsområden för den här arkitekturen:
- Autentisera och auktorisera användare från partnerorganisationer.
- Tillåt användare att autentisera från webbläsare som körs utanför organisationens brandvägg.
- Tillåt användare att ansluta från auktoriserade externa enheter, som mobila enheter.
Fördelar
- Du kan utnyttja anspråksmedvetna program.
- Ger möjlighet att lita på externa partner för autentisering.
- Kompatibilitet med en stor uppsättning autentiseringsprotokoll.
Utmaningar
- Du måste distribuera dina egna AD DS-, AD FS- och AD FS Web Application Proxy-servrar i Azure.
- Den här arkitekturen kan vara komplicerad att konfigurera.
Referensarkitektur