Grunderna för Azure-resurshantering
Det är viktigt att förstå den struktur och de termer som är specifika för Azure-resurser. Följande bild visar ett exempel på de fyra omfångsnivåer som tillhandahålls av Azure:
Terminologi
Följande är några av de termer som du bör känna till:
Resurs – ett hanterbart objekt som görs tillgängligt via Azure. Virtuella datorer, lagringskonton, webbappar, databaser och virtuella nätverk är exempel på resurser.
Resursgrupp – en container som innehåller relaterade resurser för en Azure-lösning, till exempel en samling virtuella datorer, associerade virtuella nätverk och lastbalanserare som kräver hantering av specifika team. Resursgruppen innehåller de resurser som du vill hantera som en grupp. Du bestämmer vilka resurser som ska ingå i en resursgrupp baserat på vad som är bäst för organisationen. Resursgrupper kan också användas för att hjälpa till med livscykelhantering genom att ta bort alla resurser som har samma livslängd samtidigt. Den här metoden ger också säkerhetsfördelar genom att inte lämna några fragment som kan utnyttjas.
Prenumeration – Ur en organisationshierarki är en prenumeration en fakturerings- och hanteringscontainer för resurser och resursgrupper. En Azure-prenumeration har en förtroenderelation med en Microsoft Entra ID. En prenumeration förlitar sig på att Microsoft Entra ID autentiserar användare, tjänster och enheter.
Kommentar
En prenumeration kan bara lita på en Microsoft Entra-klientorganisation. Varje klientorganisation kan dock lita på flera prenumerationer och prenumerationer kan flyttas mellan klientorganisationer.
Hanteringsgruppen - Azure-hanteringsgrupper tillhandahåller en hierarkisk metod för att tillämpa principer och efterlevnad i olika omfång ovanför prenumerationer. Den kan finnas i klientorganisationens rothanteringsgrupp (högsta omfång) eller på lägre nivåer i hierarkin. Du kan ordna prenumerationerna i containrar som kallas hanteringsgrupper och tillämpa styrningsvillkor för hanteringsgrupperna. Alla prenumerationer i en hanteringsgrupp ärver automatiskt de villkor som tillämpas för hanteringsgruppen. Observera att principdefinitioner kan tillämpas på en hanteringsgrupp eller prenumeration.
Resursprovider – en tjänst som tillhandahåller Azure-resurser. En vanlig resursprovider är till exempel Microsoft. Compute, som tillhandahåller resursen för den virtuella datorn. Microsoft. Lagring är en annan vanlig resursprovider.
Resource Manager-mall – En JSON-fil (JavaScript Object Notation) som definierar en eller flera resurser som ska distribueras till en resursgrupp, prenumeration, klientorganisation eller hanteringsgrupp. Mallen kan användas för att distribuera resurserna på ett konsekvent sätt och upprepade gånger. Se Översikt över malldistribution. Dessutom kan Bicep-språket användas i stället för JSON.
Azure Resource Management-modell
Varje Azure-prenumeration är associerad med kontroller som används av Azure Resource Manager. Resource Manager är distributions- och hanteringstjänsten för Azure, den har en förtroenderelation med Microsoft Entra-ID för identitetshantering för organisationer och Microsoft-kontot (MSA) för enskilda användare. Resource Manager tillhandahåller ett hanteringslager som gör att du kan skapa, uppdatera och ta bort resurser i din Azure-prenumeration. Du använder hanteringsfunktioner som åtkomstkontroll, lås och taggar för att skydda och organisera dina resurser efter distributionen.
Kommentar
Före ARM fanns det en annan distributionsmodell med namnet Azure Service Manager (ASM) eller "klassisk". Mer information finns i Azure Resource Manager jämfört med klassisk distribution. Att hantera miljöer med ASM-modellen ligger utanför omfånget för det här innehållet.
Azure Resource Manager är klientdelstjänsten som är värd för DE REST-API:er som används av PowerShell, Azure Portal eller andra klienter för att hantera resurser. När en klient skickar en begäran om att hantera en specifik resurs skickar Resource Manager begäran till resursprovidern för att slutföra begäran. Om en klient till exempel skickar en begäran om att hantera en virtuell datorresurs skickar Resource Manager begäran till Microsoft. Beräkningsresursprovider. Resource Manager kräver att klienten anger en identifierare för både prenumerationen och resursgruppen för att hantera den virtuella datorresursen.
Innan en resurshanteringsbegäran kan köras av Resource Manager kontrolleras en uppsättning kontroller.
Giltig användarkontroll – Användaren som begär att hantera resursen måste ha ett konto i Microsoft Entra-klientorganisationen som är associerat med prenumerationen på den hanterade resursen.
Kontroll av användarbehörighet – Behörigheter tilldelas till användare med rollbaserad åtkomstkontroll (RBAC). En RBAC-roll anger en uppsättning behörigheter som en användare kan ta på en specifik resurs. RBAC hjälper dig att hantera vem som har åtkomst till Azure-resurser, vad de kan göra med dessa resurser och vilka områden de har åtkomst till.
Azure-principkontroll - Azure-principer anger vilka åtgärder som tillåts eller uttryckligen nekas för en specifik resurs. En princip kan till exempel ange att användare endast tillåts (eller inte tillåts) att distribuera en viss typ av virtuell dator.
Följande diagram sammanfattar den resursmodell som vi precis beskrev.
Azure Lighthouse - Azure Lighthouse möjliggör resurshantering mellan klientorganisationer. Organisationer kan delegera roller på prenumerations- eller resursgruppsnivå till identiteter i en annan klientorganisation.
Prenumerationer som aktiverar delegerad resurshantering med Azure Lighthouse har attribut som anger klient-ID:n som kan hantera prenumerationer eller resursgrupper och mappning mellan den inbyggda RBAC-rollen i resursklientorganisationen till identiteter i tjänstleverantörens klientorganisation. Vid körning använder Azure Resource Manager dessa attribut för att auktorisera token som kommer från tjänstleverantörens klientorganisation.
Det är värt att notera att Själva Azure Lighthouse är modellerat som en Azure-resursprovider, vilket innebär att aspekter av delegeringen i en klientorganisation kan riktas via Azure-principer.
Microsoft 365 Lighthouse - Microsoft 365 Lighthouse är en administratörsportal som hjälper hanterade tjänstleverantörer att skydda och hantera enheter, data och användare i stor skala för små och medelstora företagskunder (SMB) som använder Microsoft 365 Business Premium, Microsoft 365 E3 eller Windows 365 Business.
Azure-resurshantering med Microsoft Entra-ID
Nu när du har en bättre förståelse för resurshanteringsmodellen i Azure ska vi kortfattat undersöka några av funktionerna i Microsoft Entra-ID:t som kan tillhandahålla identitets- och åtkomsthantering för Azure-resurser.
Fakturering
Fakturering är viktigt för resurshantering eftersom vissa faktureringsroller interagerar med eller kan hantera resurser. Fakturering fungerar annorlunda beroende på vilken typ av avtal du har med Microsoft.
Azure företagsavtal s
Azure företagsavtal-kunder (Azure EA) registreras i Azure EA-portalen när deras kommersiella kontrakt med Microsoft har körts. Vid registrering är en identitet associerad med en "rot"-faktureringsroll för företagsadministratör. Portalen innehåller en hierarki med hanteringsfunktioner:
Avdelningar hjälper dig att segmentera kostnader i logiska grupper och gör att du kan ange en budget eller kvot på avdelningsnivå.
Konton används för att ytterligare segmentera avdelningar. Du kan använda konton för att hantera prenumerationer och komma åt rapporter. EA-portalen kan auktorisera Microsoft-konton (MSA) eller Microsoft Entra-konton (identifieras i portalen som "Arbets- eller skolkonton"). Identiteter med rollen "Kontoägare" i EA-portalen kan skapa Azure-prenumerationer.
Företagsfakturering och Microsoft Entra-klienter
När en kontoägare skapar en Azure-prenumeration inom ett enterprise-avtal konfigureras identitets- och åtkomsthanteringen för prenumerationen på följande sätt:
Azure-prenumerationen är associerad med samma Microsoft Entra-klientorganisation för kontoägaren.
Kontoägaren som skapade prenumerationen tilldelas rollerna Tjänstadministratör och Kontoadministratör. (Azure EA-portalen tilldelar Azure Service Manager -roller (ASM) eller "klassiska" roller för att hantera prenumerationer. Mer information finns i Azure Resource Manager jämfört med klassisk distribution.)
Ett företagsavtal kan konfigureras för att stödja flera klienter genom att ange autentiseringstypen "Arbets- eller skolkonto mellan klientorganisationer" i Azure EA-portalen. Med tanke på ovanstående kan organisationer ange flera konton för varje klientorganisation och flera prenumerationer för varje konto, enligt diagrammet nedan.
Det är viktigt att observera att standardkonfigurationen som beskrivs ovan ger Azure EA-kontots ägare behörighet att hantera resurserna i alla prenumerationer som de har skapat. För prenumerationer som innehåller produktionsarbetsbelastningar bör du överväga att avkoda fakturering och resurshantering genom att ändra tjänstadministratören för prenumerationen direkt efter att du har skapat den.
För att ytterligare frikoppla och förhindra att kontoägaren återfår tjänstadministratörens åtkomst till prenumerationen kan prenumerationens klientorganisation ändras när den har skapats. Om kontoägaren inte har något användarobjekt i Microsoft Entra-klientorganisationen som prenumerationen flyttas till kan de inte återfå rollen som tjänstägare.
Mer information finns i Azure-roller , Microsoft Entra-roller och klassiska administratörsroller för prenumerationer.
Microsoft-kundavtal
Kunder som registrerats med en Microsoft-kundavtal (MCA) har ett annat faktureringshanteringssystem med sina egna roller.
Ett faktureringskonto för Microsoft-kundavtal innehåller en eller flera faktureringsprofiler som gör det möjligt att hantera fakturor och betalningsmetoder. Varje faktureringsprofil innehåller ett eller flera fakturaavsnitt för att ordna kostnader på faktureringsprofilens faktura.
I en Microsoft-kundavtal kommer faktureringsroller från en enda Microsoft Entra-klientorganisation. Om du vill etablera prenumerationer för flera klienter måste prenumerationerna först skapas i samma Microsoft Entra-klientorganisation som MCA och sedan ändras. I diagrammet nedan flyttades prenumerationerna för företagets IT-förproduktionsmiljö till ContosoSandbox-klientorganisationen efter skapandet.
RBAC och rolltilldelningar i Azure
I avsnittet Grunderna för Microsoft Entra lärde du dig att Azure RBAC är auktoriseringssystemet som ger detaljerad åtkomsthantering till Azure-resurser och innehåller många inbyggda roller. Du kan skapa anpassade roller och tilldela roller i olika omfång. Behörigheter tillämpas genom att tilldela RBAC-roller till objekt som begär åtkomst till Azure-resurser.
Microsoft Entra-roller fungerar på begrepp som rollbaserad åtkomstkontroll i Azure. Skillnaden mellan dessa två rollbaserade åtkomstkontrollsystem är att Azure RBAC använder Azure Resource Management för att styra åtkomsten till Azure-resurser som virtuella datorer eller lagring, och Microsoft Entra-roller styr åtkomsten till Microsoft Entra-ID, program och Microsoft-tjänster som Office 365.
Både Microsoft Entra-roller och Azure RBAC-roller integreras med Microsoft Entra Privileged Identity Management för att aktivera just-in-time-aktiveringsprinciper som arbetsflöde för godkännande och MFA.
ABAC och rolltilldelningar i Azure
Attributbaserad åtkomstkontroll (ABAC) är ett auktoriseringssystem som definierar åtkomst baserat på attribut som är associerade med säkerhetsobjekt, resurser och miljö. Med ABAC kan du ge ett säkerhetsobjekt åtkomst till en resurs baserat på attribut. Azure ABAC avser implementeringen av ABAC för Azure.
Azure ABAC bygger på Azure RBAC genom att lägga till rolltilldelningsvillkor baserat på attribut i samband med specifika åtgärder. Ett villkor för rolltilldelning är ytterligare en kontroll som du kan lägga till i rolltilldelningen för att ge mer detaljerad åtkomstkontroll. Ett villkor filtrerar ned behörigheter som beviljats som en del av rolldefinitionen och rolltilldelningen. Du kan till exempel lägga till ett villkor som kräver att ett objekt har en specifik tagg för att läsa objektet. Du kan inte uttryckligen neka åtkomst till specifika resurser med hjälp av villkor.
Villkorlig åtkomst
Villkorsstyrd åtkomst i Microsoft Entra kan användas för att hantera åtkomst till Azure-hanteringsslutpunkter. Principer för villkorlig åtkomst kan tillämpas på Windows Azure Service Management API-molnappen för att skydda Azure-resurshanteringsslutpunkter som:
Azure Resource Manager-provider (tjänster)
Azure Resource Manager-API:er
Azure PowerShell
Azure CLI
Azure Portal
En administratör kan till exempel konfigurera en princip för villkorsstyrd åtkomst, som gör att en användare endast kan logga in på Azure Portal från godkända platser och även kräver multifaktorautentisering (MFA) eller en Hybrid Microsoft Entra-domänansluten enhet.
Hanterade Identiteter i Azure
En vanlig utmaning vid utvecklingen av molnprogram är hur man ska hantera autentiseringsuppgifterna i koden som krävs för autentisering mot molntjänsterna. Det är viktigt att dessa autentiseringsuppgifter skyddas. Helst bör autentiseringsuppgifterna aldrig visas på utvecklarnas arbetsstationer eller checkas in i källkontrollen. Hanterade identiteter för Azure-resurser tillhandahåller Azure-tjänster med en automatiskt hanterad identitet i Microsoft Entra-ID. Du kan använda identiteten för att autentisera till alla tjänster som stöder Microsoft Entra-autentisering utan några autentiseringsuppgifter i koden.
Det finns två typer av hanterade identiteter:
En systemtilldelad hanterad identitet aktiveras direkt på en Azure-resurs. När resursen är aktiverad skapar Azure en identitet för resursen i den associerade prenumerationens betrodda Microsoft Entra-klientorganisation. När identiteten har skapats etableras autentiseringsuppgifterna på resursen. Livscykeln för en systemtilldelad identitet är direkt kopplad till Azure-resursen. Om resursen tas bort rensar Azure automatiskt autentiseringsuppgifterna och identiteten i Microsoft Entra-ID:t.
En användartilldelad hanterad identitet skapas som en fristående Azure-resurs. Azure skapar en identitet i Microsoft Entra-klientorganisationen som är betrodd av den prenumeration som resursen är associerad med. När identiteten har skapats kan identiteten tilldelas till en eller flera Azure-resurser. Livscykeln för en användartilldelad identitet hanteras separat från livscykeln för de Azure-resurser som den har tilldelats.
Internt är hanterade identiteter tjänstens huvudnamn av en särskild typ, som endast ska användas av specifika Azure-resurser. När den hanterade identiteten tas bort tas motsvarande tjänsthuvudnamn bort automatiskt. Noe att auktorisering av Graph API-behörigheter endast kan göras av PowerShell, så alla funktioner i hanterad identitet är inte tillgängliga via portalgränssnittet.
Microsoft Entra Domain Services
Microsoft Entra Domain Services tillhandahåller en hanterad domän för att underlätta autentisering för Azure-arbetsbelastningar med hjälp av äldre protokoll. Servrar som stöds flyttas från en lokal AD DS-skog och ansluts till en hanterad Domän för Microsoft Entra Domain Services och fortsätter att använda äldre protokoll för autentisering (till exempel Kerberos-autentisering).
Azure AD B2C-kataloger och Azure
En Azure AD B2C-klientorganisation är länkad till en Azure-prenumeration i fakturerings- och kommunikationssyfte. Azure AD B2C-klientorganisationer har en fristående rollstruktur i katalogen, som är oberoende av Azure RBAC-privilegierade roller i Azure-prenumerationen.
När Azure AD B2C-klientorganisationen först etableras måste användaren som skapar B2C-klientorganisationen ha deltagar- eller ägarbehörigheter i prenumerationen. De kan senare skapa andra konton och tilldela dem till katalogroller. Mer information finns i Översikt över rollbaserad åtkomstkontroll i Microsoft Entra-ID.
Observera att ägare och deltagare i den länkade Microsoft Entra-prenumerationen kan ta bort länken mellan prenumerationen och katalogen, vilket påverkar den löpande faktureringen för Azure AD B2C-användningen.
Identitetsöverväganden för IaaS-lösningar i Azure
Det här scenariot omfattar identitetsisoleringskrav som organisationer har för IaaS-arbetsbelastningar (Infrastruktur som en tjänst).
Det finns tre viktiga alternativ för isoleringshantering av IaaS-arbetsbelastningar:
Virtuella datorer som är anslutna till fristående Active Directory-domän Services (AD DS)
Microsoft Entra Domain Services-anslutna virtuella datorer
Logga in på virtuella datorer i Azure med Microsoft Entra-autentisering
Ett viktigt begrepp att ta itu med med de två första alternativen är att det finns två identitetssfärer som är inblandade i dessa scenarier.
När du loggar in på en virtuell Azure Windows Server-dator via fjärrskrivbordsprotokoll (RDP) loggar du vanligtvis in på servern med dina domänautentiseringsuppgifter, som utför en Kerberos-autentisering mot en lokal AD DS-domänkontrollant eller Microsoft Entra Domain Services. Om servern inte är domänansluten kan du också använda ett lokalt konto för att logga in på de virtuella datorerna.
När du loggar in på Azure Portal för att skapa eller hantera en virtuell dator autentiserar du mot Microsoft Entra-ID (eventuellt med samma autentiseringsuppgifter om du har synkroniserat rätt konton), och detta kan resultera i en autentisering mot dina domänkontrollanter om du använder Active Directory Federation Services (AD FS) (AD FS) eller PassThrough-autentisering.
Virtuella datorer som är anslutna till fristående Active Directory-domän Services
AD DS är den Windows Server-baserade katalogtjänsten som organisationer till stor del har antagit för lokala identitetstjänster. AD DS kan distribueras när det finns ett krav på att distribuera IaaS-arbetsbelastningar till Azure som kräver identitetsisolering från AD DS-administratörer och användare i en annan skog.
Följande överväganden måste göras i det här scenariot:
AD DS-domänkontrollanter: Minst två AD DS-domänkontrollanter måste distribueras för att säkerställa att autentiseringstjänster är mycket tillgängliga och högpresterande. Mer information finns i DESIGN och planering för AD DS.
DESIGN och planering för AD DS – En ny AD DS-skog måste skapas med följande tjänster konfigurerade på rätt sätt:
AD DS Domain Name Services (DNS) – AD DS DNS måste konfigureras för relevanta zoner i AD DS för att säkerställa att namnmatchningen fungerar korrekt för servrar och program.
AD DS-webbplatser och -tjänster – Dessa tjänster måste konfigureras för att säkerställa att programmen har låg svarstid och högpresterande åtkomst till domänkontrollanter. Relevanta virtuella nätverk, undernät och datacenterplatser som servrar finns i bör konfigureras på platser och tjänster.
AD DS FSMOs – FSMO-rollerna (Flexible Single Master Operation) som krävs bör granskas och tilldelas lämpliga AD DS-domänkontrollanter.
AD DS-domänanslutning – Alla servrar (exklusive "jumpboxar") som kräver AD DS för autentisering, konfiguration och hantering måste anslutas till den isolerade skogen.
AD DS-grupprincip (GPO) – AD DS-grupprincipobjekt måste konfigureras för att säkerställa att konfigurationen uppfyller säkerhetskraven och att konfigurationen är standardiserad i skogen och domänanslutna datorer.
AD DS Organisationsenheter (OU) – AD DS OUs måste definieras för att säkerställa gruppering av AD DS-resurser i logisk hantering och konfigurationsilor för administration och tillämpning av konfiguration.
Rollbaserad åtkomstkontroll – RBAC måste definieras för administration och åtkomst till resurser som är anslutna till den här skogen. Detta omfattar:
AD DS-grupper – Grupper måste skapas för att använda lämpliga behörigheter för användare till AD DS-resurser.
Administrationskonton – Som vi nämnde i början av det här avsnittet krävs två administrationskonton för att hantera den här lösningen.
Ett AD DS-administrationskonto med minst privilegierad åtkomst som krävs för att utföra den administration som krävs i AD DS och domänanslutna servrar.
Ett Microsoft Entra-administrationskonto för Azure Portal åtkomst för att ansluta, hantera och konfigurera virtuella datorer, virtuella nätverk, nätverkssäkerhetsgrupper och andra nödvändiga Azure-resurser.
AD DS-användarkonton – Relevanta användarkonton måste etableras och läggas till i rätt grupper för att tillåta användaråtkomst till program som hanteras av den här lösningen.
Virtuella nätverk (VNet) – Konfigurationsvägledning
AD DS-domänkontrollantens IP-adress – Domänkontrollanterna ska inte konfigureras med statiska IP-adresser i operativsystemet. IP-adresserna bör reserveras i det virtuella Azure-nätverket för att säkerställa att de alltid förblir desamma och att domänkontrollanten ska konfigureras att använda DHCP.
VNet DNS-server – DNS-servrar måste konfigureras på virtuella nätverk som ingår i den här isolerade lösningen för att peka på domänkontrollanterna. Detta krävs för att säkerställa att program och servrar kan matcha nödvändiga AD DS-tjänster eller andra tjänster som är anslutna till AD DS-skogen.
Nätverkssäkerhetsgrupper (NSG:er) – Domänkontrollanterna ska finnas på sitt eget virtuella nätverk eller undernät med NSG:er definierade för att endast tillåta åtkomst till domänkontrollanter från nödvändiga servrar (till exempel domänanslutna datorer eller jumpboxar). Jumpboxar bör läggas till i en programsäkerhetsgrupp (ASG) för att förenkla skapandet och administrationen av NSG.
Utmaningar: Listan nedan belyser viktiga utmaningar med att använda det här alternativet för identitetsisolering:
Ytterligare en AD DS-skog för att administrera, hantera och övervaka, vilket resulterar i mer arbete för IT-teamet att utföra.
Ytterligare infrastruktur kan krävas för hantering av korrigeringar och programvarudistributioner. Organisationer bör överväga att distribuera Azure Update Management, grupprincip (GPO) eller System Center Configuration Manager (SCCM) för att hantera dessa servrar.
Ytterligare autentiseringsuppgifter för användare att komma ihåg och använda för att komma åt resurser.
Viktigt!
För den här isolerade modellen antas det att det inte finns någon anslutning till eller från domänkontrollanterna från kundens företagsnätverk och att inga förtroenden har konfigurerats med andra skogar. En jumpbox- eller hanteringsserver bör skapas för att tillåta en punkt där AD DS-domänkontrollanterna kan hanteras och administreras.
Microsoft Entra Domain Services-anslutna virtuella datorer
När det finns ett krav på att distribuera IaaS-arbetsbelastningar till Azure som kräver identitetsisolering från AD DS-administratörer och användare i en annan skog, kan en hanterad Domän för Microsoft Entra-domäntjänster distribueras. Microsoft Entra Domain Services är en tjänst som tillhandahåller en hanterad domän för att underlätta autentisering för Azure-arbetsbelastningar med hjälp av äldre protokoll. Detta ger en isolerad domän utan den tekniska komplexiteten att skapa och hantera din egen AD DS. Följande överväganden måste göras.
Microsoft Entra Domain Services-hanterad domän – Endast en hanterad Domän för Microsoft Entra-tjänster kan distribueras per Microsoft Entra-klientorganisation och detta är bundet till ett enda virtuellt nätverk. Vi rekommenderar att det här virtuella nätverket utgör "hubben" för Microsoft Entra Domain Services-autentisering. Från den här hubben kan "ekrar" skapas och länkas för att tillåta äldre autentisering för servrar och program. Ekrarna är ytterligare virtuella nätverk där Microsoft Entra Domain Services-anslutna servrar finns och är länkade till hubben med hjälp av Azure-nätverksgatewayer eller VNet-peering.
Hanterad domänplats – En plats måste anges när du distribuerar en hanterad Domän för Microsoft Entra Domain Services. Platsen är en fysisk region (datacenter) där den hanterade domänen distribueras. Vi rekommenderar att du:
Överväg en plats som är geografiskt stängd för de servrar och program som kräver Microsoft Entra Domain Services-tjänster.
Överväg regioner som tillhandahåller Tillgänglighetszoner funktioner för krav på hög tillgänglighet. Mer information finns i Regioner och Tillgänglighetszoner i Azure.
Objektetablering – Microsoft Entra Domain Services synkroniserar identiteter från Microsoft Entra-ID:t som är associerat med prenumerationen som Microsoft Entra Domain Services distribueras till. Det är också värt att notera att om det associerade Microsoft Entra-ID:t har konfigurerats med Microsoft Entra Connect (användarskogsscenario) kan livscykeln för dessa identiteter också återspeglas i Microsoft Entra Domain Services. Den här tjänsten har två lägen som kan användas för att etablera användar- och gruppobjekt från Microsoft Entra-ID.
Alla: Alla användare och grupper synkroniseras från Microsoft Entra-ID till Microsoft Entra Domain Services.
Omfattning: Endast användare i en grupps omfång synkroniseras från Microsoft Entra-ID till Microsoft Entra Domain Services.
När du först distribuerar Microsoft Entra Domain Services konfigureras en automatisk enkelriktad synkronisering för att replikera objekten från Microsoft Entra-ID. Den här enkelriktade synkroniseringen fortsätter att köras i bakgrunden för att hålla Microsoft Entra Domain Services-hanterade domänen uppdaterad med eventuella ändringar från Microsoft Entra-ID. Det sker inte någon synkronisering från Microsoft Entra Domain Services tillbaka till Microsoft Entra ID. Mer information finns i Hur objekt och autentiseringsuppgifter synkroniseras i en hanterad Domän för Microsoft Entra Domain Services.
Det är värt att notera att om du behöver ändra typen av synkronisering från Alla till Omfång (eller vice versa), måste den hanterade Domänen för Microsoft Entra Domain Services tas bort, återskapas och konfigureras. Dessutom bör organisationer betrakta användningen av "begränsad" etablering för att minska identiteterna till endast de som behöver åtkomst till Microsoft Entra Domain Services-resurser som en bra metod.
grupprincip Objects (GPO) – Om du vill konfigurera grupprincipobjekt i en hanterad domän i Microsoft Entra Domain Services måste du använda grupprincip hanteringsverktyg på en server som har domänanslutits till den hanterade domänen Microsoft Entra Domain Services. Mer information finns i Administrera grupprincip i en hanterad Domän för Microsoft Entra Domain Services.
Säker LDAP – Microsoft Entra Domain Services tillhandahåller en säker LDAP-tjänst som kan användas av program som kräver det. Den här inställningen är inaktiverad som standard och för att aktivera säker LDAP måste ett certifikat dessutom laddas upp, och den NSG som skyddar det virtuella nätverk som Microsoft Entra Domain Services distribueras till måste dessutom tillåta port 636-anslutning till microsoft Entra Domain Services-hanterade domäner. Mer information finns i Konfigurera säker LDAP för en hanterad Domän för Microsoft Entra Domain Services.
Administration – För att utföra administrationsuppgifter på Microsoft Entra Domain Services (till exempel domänanslutningsdatorer eller redigera grupprincipobjekt) måste kontot som används för den här uppgiften ingå i gruppen Microsoft Entra DC-administratörer. Konton som är medlemmar i den här gruppen kan inte logga in direkt på domänkontrollanter för att utföra hanteringsuppgifter. I stället skapar du en virtuell hanteringsdator som är ansluten till den hanterade domänen Microsoft Entra Domain Services och installerar sedan dina vanliga AD DS-hanteringsverktyg. Mer information finns i Hanteringsbegrepp för användarkonton, lösenord och administration i Microsoft Entra Domain Services.
Lösenordshashvärden – För att autentisering med Microsoft Entra Domain Services ska fungera måste lösenordshashvärden för alla användare vara i ett format som är lämpligt för NT LAN Manager (NTLM) och Kerberos-autentisering. För att säkerställa att autentisering med Microsoft Entra Domain Services fungerar som förväntat måste följande krav utföras.
Användare som synkroniserats med Microsoft Entra Connect (från AD DS) – De äldre lösenordshasherna måste synkroniseras från lokal AD DS till Microsoft Entra-ID.
Användare som skapats i Microsoft Entra-ID – Behöver återställa sitt lösenord för att rätt hashvärden ska genereras för användning med Microsoft Entra Domain Services. Mer information finns i Aktivera synkronisering av lösenordshashvärden.
Nätverk – Microsoft Entra Domain Services distribueras till ett virtuellt Azure-nätverk, så överväganden måste göras för att säkerställa att servrar och program skyddas och kan komma åt den hanterade domänen på rätt sätt. Mer information finns i Designöverväganden för virtuella nätverk och konfigurationsalternativ för Microsoft Entra Domain Services.
Microsoft Entra Domain Services måste distribueras i ett eget undernät: Använd inte ett befintligt undernät eller ett gateway-undernät.
En nätverkssäkerhetsgrupp (NSG) – skapas under distributionen av en Microsoft Entra Domain Services-hanterad domän. Den här nätverkssäkerhetsgruppen innehåller de regler som krävs för korrekt tjänstkommunikation. Skapa eller använd inte en befintlig nätverkssäkerhetsgrupp med egna anpassade regler.
Microsoft Entra Domain Services kräver 3–5 IP-adresser – Kontrollera att ip-adressintervallet för undernätet kan ange det här antalet adresser. Att begränsa tillgängliga IP-adresser kan hindra Microsoft Entra Domain Services från att underhålla två domänkontrollanter.
VNet DNS Server – Som tidigare diskuterats om "hub and spoke"-modellen är det viktigt att DNS har konfigurerats korrekt på de virtuella nätverken för att säkerställa att servrar som är anslutna till den hanterade domänen Microsoft Entra Domain Services har rätt DNS-inställningar för att matcha den hanterade domänen Microsoft Entra Domain Services. Varje virtuellt nätverk har en DNS-serverpost som skickas till servrar när de hämtar en IP-adress och dessa DNS-poster måste vara IP-adresserna för den hanterade domänen Microsoft Entra Domain Services. Mer information finns i Uppdatera DNS-inställningar för det virtuella Azure-nätverket.
Utmaningar – Följande lista belyser viktiga utmaningar med att använda det här alternativet för identitetsisolering.
Vissa Microsoft Entra Domain Services-konfigurationer kan bara administreras från en Microsoft Entra Domain Services-ansluten server.
Endast en hanterad Domän för Microsoft Entra-tjänster kan distribueras per Microsoft Entra-klientorganisation. Som vi beskriver i det här avsnittet rekommenderas hubb- och ekermodellen att tillhandahålla Microsoft Entra Domain Services-autentisering till tjänster på andra virtuella nätverk.
Ytterligare infrastruktur kanske krävs för hantering av korrigeringar och programvarudistributioner. Organisationer bör överväga att distribuera Azure Update Management, grupprincip (GPO) eller System Center Configuration Manager (SCCM) för att hantera dessa servrar.
För den här isolerade modellen förutsätts det att det inte finns någon anslutning till det virtuella nätverk som är värd för microsoft Entra Domain Services-hanterade domänen från kundens företagsnätverk och att det inte finns några förtroenden konfigurerade med andra skogar. En jumpbox- eller hanteringsserver bör skapas för att tillåta en punkt där Microsoft Entra Domain Services kan hanteras och administreras.
Logga in på virtuella datorer i Azure med Microsoft Entra-autentisering
När det finns ett krav på att distribuera IaaS-arbetsbelastningar till Azure som kräver identitetsisolering är det sista alternativet att använda Microsoft Entra-ID för inloggning till servrar i det här scenariot. Detta ger möjlighet att göra Microsoft Entra-ID till identitetssfären för autentiseringsändamål och identitetsisolering kan uppnås genom att etablera servrarna i den relevanta prenumerationen, som är länkad till den nödvändiga Microsoft Entra-klientorganisationen. Följande överväganden måste göras.
Operativsystem som stöds: Inloggning på virtuella datorer i Azure med Microsoft Entra-autentisering stöds för närvarande i Windows och Linux. Mer information om operativsystem som stöds finns i dokumentationen för Windows och Linux.
Autentiseringsuppgifter: En av de viktigaste fördelarna med att logga in på virtuella datorer i Azure med Microsoft Entra-autentisering är möjligheten att använda samma federerade eller hanterade Microsoft Entra-autentiseringsuppgifter som du normalt använder för åtkomst till Microsoft Entra-tjänster för inloggning på den virtuella datorn.
Kommentar
Microsoft Entra-klientorganisationen som används för inloggning i det här scenariot är Microsoft Entra-klientorganisationen som är associerad med den prenumeration som den virtuella datorn har etablerats i. Den här Microsoft Entra-klientorganisationen kan vara en som har identiteter synkroniserade från lokal AD DS. Organisationer bör göra ett välgrundat val som överensstämmer med deras isoleringsobjekt när de väljer vilken prenumeration och Microsoft Entra-klient som de vill använda för inloggning på dessa servrar.
Nätverkskrav: Dessa virtuella datorer måste ha åtkomst till Microsoft Entra-ID för autentisering, så du måste se till att nätverkskonfigurationen för virtuella datorer tillåter utgående åtkomst till Microsoft Entra-slutpunkter på 443. Mer information finns i dokumentationen för Windows och Linux .
Rollbaserad åtkomstkontroll (RBAC): Två RBAC-roller är tillgängliga för att ge lämplig åtkomstnivå till dessa virtuella datorer. Dessa RBAC-roller kan konfigureras via Azure Portal eller via Azure Cloud Shell Experience. Mer information finns i Konfigurera rolltilldelningar för den virtuella datorn.
Inloggning för virtuell datoradministratör: Användare med den här rollen tilldelad kan logga in på en virtuell Azure-dator med administratörsbehörighet.
Användarinloggning för virtuella datorer: Användare med den här rollen tilldelad kan logga in på en virtuell Azure-dator med regelbunden användarbehörighet.
Villkorsstyrd åtkomst: En viktig fördel med att använda Microsoft Entra-ID för att logga in på virtuella Azure-datorer är möjligheten att framtvinga villkorlig åtkomst som en del av inloggningsprocessen. Detta ger organisationer möjlighet att kräva att villkor uppfylls innan åtkomst till den virtuella datorn tillåts och att använda multifaktorautentisering för att tillhandahålla stark autentisering. Mer information finns i Använda villkorlig åtkomst.
Kommentar
Fjärranslutning till virtuella datorer som är anslutna till Microsoft Entra-ID tillåts endast från Windows 10-, Windows 11- och Cloud PC-datorer som är Microsoft Entra-anslutna eller Microsoft Entra-hybridanslutningar till samma katalog som den virtuella datorn.
Utmaningar: Listan nedan belyser viktiga utmaningar med att använda det här alternativet för identitetsisolering.
Ingen central hantering eller konfiguration av servrar. Det finns till exempel inga grupprincip som kan tillämpas på en grupp servrar. Organisationer bör överväga att distribuera Uppdateringshantering i Azure för att hantera korrigeringar och uppdateringar av dessa servrar.
Inte lämplig för program med flera nivåer som har krav på att autentiseras med lokala mekanismer, till exempel Windows-integrerad autentisering på dessa servrar eller tjänster. Om detta är ett krav för organisationen rekommenderar vi att du utforskar de fristående Active Directory-domän Services eller scenarierna för Microsoft Entra Domain Services som beskrivs i det här avsnittet.
För den här isolerade modellen förutsätts det att det inte finns någon anslutning till det virtuella nätverk som är värd för de virtuella datorerna från kundens företagsnätverk. En jumpbox- eller hanteringsserver bör skapas för att tillåta en punkt där dessa servrar kan hanteras och administreras.