Redigera

Dela via


Jämför integreringsalternativ för lokal Active Directory med ett Azure-nätverk

Microsoft Entra ID

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 associerade med användare, datorer, program eller andra resurser som ingår i en säkerhetsgräns. Katalog- och identitetstjänster finns vanligtvis lokalt, men om ditt program delvis finns lokalt och delvis i Azure kan det finnas svarstider när autentiseringsbegäranden skickas från Azure tillbaka till den lokala miljön. Implementering av katalog- och identitetstjänster i Azure kan minska den här svarstiden.

Azure tillhandahåller två lösningar för att implementera katalog- 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 lokala Active Directory-domän. Microsoft Entra Connect 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 domänkontrollant. Den här arkitekturen är vanligare när det lokala nätverket och det virtuella Azure-nätverket (VNet) ansluts via en VPN- eller ExpressRoute-anslutning. Flera varianter av den här arkitekturen ä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 AD FS-distribution (Active Directory Federation Services) till Azure.

I nästa avsnitt beskrivs vart och ett av dessa alternativ mer detaljerat.

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. I stället är det 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 ske i Azure, vilket minskar behovet av externa program och användare att kontakta 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 en grupprincip som definierats av lokala grupprincipobjekt på domänen i Azure.

utmaningar

  • Du måste distribuera och hantera dina egna AD DS-servrar och domäner i molnet.
  • Det kan finnas viss synkroniseringsfördröjning 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 separat från den lokala skogen. Den här skogen är betrodd av domäner i din lokala skog.

Typiska användningsområden för den här arkitekturen är att upprätthålla säkerhetsavgränsning för objekt och identiteter som finns i molnet och migrera enskilda domäner från en lokal plats till molnet.

fördelar

  • Du kan implementera lokala identiteter och separata identiteter endast 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ätverkshopp till de lokala AD-servrarna.
  • Du måste distribuera dina egna AD DS-servrar och skogar i molnet och upprätta lämpliga förtroenderelationer mellan skogar.

Referensarkitektur

Utöka AD FS till Azure

Replikera en AD FS-distribution (Active Directory Federation Services) till Azure för att utföra 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, till exempel mobila enheter.

fördelar

  • Du kan använda 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 komplex att konfigurera.

Referensarkitektur