Använda Azure Files med flera Active Directory-skogar
Många organisationer vill använda identitetsbaserad autentisering för SMB Azure-filresurser i miljöer som har flera ad DS-skogar (lokal Active Directory Domain Services). Detta är ett vanligt IT-scenario, särskilt efter fusioner och förvärv, där det förvärvade bolagets AD-skogar isoleras från moderbolagets AD-skogar. Den här artikeln beskriver hur förtroenderelationer för skogar fungerar och innehåller stegvisa instruktioner för konfiguration och validering av flera skogar.
Viktigt!
Om du vill ange behörigheter på resursnivå för specifika Microsoft Entra-användare eller -grupper med hjälp av rollbaserad åtkomstkontroll i Azure (RBAC) måste du först synkronisera de lokala AD-kontona till Microsoft Entra ID med hjälp av Microsoft Entra Connect. Annars kan du använda en standardbehörighet på resursnivå.
Gäller för
Typ av filresurs | SMB | NFS |
---|---|---|
Standardfilresurser (GPv2), LRS/ZRS | ||
Standardfilresurser (GPv2), GRS/GZRS | ||
Premiumfilresurser (FileStorage), LRS/ZRS |
Förutsättningar
- Två AD DS-domänkontrollanter med olika skogar och i olika virtuella nätverk (VNET)
- Tillräcklig AD-behörighet för att utföra administrativa uppgifter (till exempel domänadministratör)
- Om du använder Azure RBAC måste båda skogarna kunna nås av en enda Microsoft Entra Connect Sync-server
Så här fungerar förtroenderelationer i skogen
Lokal AD DS-autentisering i Azure Files stöds endast mot AD-skogen för domäntjänsten som lagringskontot är registrerat på. Du kan som standard bara få åtkomst till Azure-filresurser med AD DS-autentiseringsuppgifter från en enskild skog. Om du behöver komma åt din Azure-filresurs från en annan skog måste du konfigurera ett skogsförtroende.
Ett skogsförtroende är ett transitivt förtroende mellan två AD-skogar som gör att användare i någon av domänerna i en skog kan autentiseras i någon av domänerna i den andra skogen.
Konfiguration av flera skogar
För att konfigurera en installation med flera skogar utför vi följande steg:
- Samla in domäninformation och VNET-anslutningar mellan domäner
- Upprätta och konfigurera ett skogsförtroende
- Konfigurera identitetsbaserad autentisering och hybridanvändarkonton
Samla in domäninformation
I den här övningen har vi två lokala AD DS-domänkontrollanter med två olika skogar och i olika virtuella nätverk.
Skog | Domän | VNET |
---|---|---|
Skog 1 | onpremad1.com | DomainServicesVNet WUS |
Skog 2 | onpremad2.com | vnet2/arbetsbelastningar |
Upprätta och konfigurera förtroende
För att klienter från Skog 1 ska kunna komma åt Azure Files-domänresurser i Skog 2 måste vi upprätta ett förtroende mellan de två skogarna. Följ de här stegen för att upprätta förtroendet.
Kommentar
Endast skogsförtroenden stöds för Azure Files. Andra förtroendetyper, till exempel externa förtroenden, stöds inte.
Om du redan har konfigurerat ett förtroende kan du kontrollera dess typ genom att logga in på en dator som är domänansluten till Skog 2, öppna konsolen Active Directory-domän s och förtroenden, högerklicka på den lokala domänen onpremad2.com och sedan välja fliken Förtroenden. Om ditt befintliga förtroende inte är ett skogsförtroende, och om ett skogsförtroende uppfyller miljöns krav, måste du ta bort det befintliga förtroendet och återskapa ett skogsförtroende i dess ställe. Följ anvisningarna nedan för att göra detta.
Logga in på en dator som är domänansluten till Forest 2 och öppna konsolen Active Directory-domän s and Trusts.
Högerklicka på den lokala domänen onpremad2.com och välj sedan fliken Förtroenden .
Välj Nya förtroenden för att starta guiden Nytt förtroende.
Ange det domännamn som du vill skapa förtroende med (i det här exemplet onpremad1.com) och välj sedan Nästa.
För Förtroendetyp väljer du Skogsförtroende och sedan Nästa.
För Förtroenderiktning väljer du Tvåvägs och sedan Nästa.
För Sidor av förtroende väljer du Endast den här domänen och väljer sedan Nästa.
Användare i den angivna skogen kan autentiseras för att använda alla resurser i den lokala skogen (skogsomfattande autentisering) eller endast de resurser som du väljer (selektiv autentisering). För Utgående förtroendeautentiseringsnivå väljer du Skogsomfattande autentisering, vilket är det bästa alternativet när båda skogarna tillhör samma organisation. Välj Nästa.
Ange ett lösenord för förtroendet och välj sedan Nästa. Samma lösenord måste användas när du skapar den här förtroenderelationen i den angivna domänen.
Du bör se ett meddelande om att förtroenderelationen har skapats. Om du vill konfigurera förtroendet väljer du Nästa.
Bekräfta det utgående förtroendet och välj Nästa.
Ange användarnamnet och lösenordet för en användare som har administratörsbehörighet från den andra domänen.
När autentiseringen har godkänts upprättas förtroendet och du bör kunna se den angivna domänen onpremad1.com i listan på fliken Förtroenden .
Konfigurera identitetsbaserad autentisering och hybridanvändarkonton
När förtroendet har upprättats följer du de här stegen för att skapa ett lagringskonto och en SMB-filresurs för varje domän, aktivera AD DS-autentisering på lagringskontona och skapa hybridanvändarkonton som synkroniserats med Microsoft Entra-ID.
Logga in på Azure Portal och skapa två lagringskonton som onprem1sa och onprem2sa. För optimala prestanda rekommenderar vi att du distribuerar lagringskontona i samma region som de klienter som du planerar att komma åt resurserna från.
Kommentar
Det är inte nödvändigt att skapa ett andra lagringskonto. De här instruktionerna är avsedda att visa ett exempel på hur du får åtkomst till lagringskonton som tillhör olika skogar. Om du bara har ett lagringskonto kan du ignorera de andra installationsanvisningarna för lagringskontot.
Skapa en SMB Azure-filresurs och tilldela behörigheter på resursnivå för varje lagringskonto.
Synkronisera din lokala AD till Microsoft Entra-ID med hjälp av Microsoft Entra Connect Sync-programmet .
Domänanslut en virtuell Azure-dator i Skog 1 till din lokala AD DS. Information om hur du ansluter till domän finns i Ansluta en dator till en domän.
Aktivera AD DS-autentisering på lagringskontot som är associerat med Forest 1, till exempel onprem1sa. Då skapas ett datorkonto i din lokala AD med namnet onprem1sa för att representera Azure Storage-kontot och ansluta lagringskontot till onpremad1.com domänen. Du kan kontrollera att DEN AD-identitet som representerar lagringskontot skapades genom att titta i Active Directory - användare och datorer efter onpremad1.com. I det här exemplet visas ett datorkonto med namnet onprem1sa.
Skapa ett användarkonto genom att gå till Active Directory > onpremad1.com. Högerklicka på Användare, välj Skapa, ange ett användarnamn (till exempel onprem1user) och markera rutan Lösenord upphör aldrig att gälla (valfritt).
Valfritt: Om du vill använda Azure RBAC för att tilldela behörigheter på resursnivå måste du synkronisera användaren till Microsoft Entra-ID med hjälp av Microsoft Entra Connect. Normalt uppdateras Microsoft Entra Connect Sync var 30:e minut. Du kan dock tvinga den att synkronisera omedelbart genom att öppna en upphöjd PowerShell-session och köra
Start-ADSyncSyncCycle -PolicyType Delta
. Du kan behöva installera ADSync-modulen först genom att köraImport-Module ADSync
. Om du vill kontrollera att användaren har synkroniserats med Microsoft Entra-ID loggar du in på Azure Portal med Azure-prenumerationen som är associerad med din klientorganisation för flera skogar och väljer Microsoft Entra-ID. Välj Hantera > användare och sök efter den användare som du har lagt till (till exempel onprem1user). Lokal synkronisering aktiverad bör säga Ja.Ange behörigheter på resursnivå med antingen Azure RBAC-roller eller en standardbehörighet på resursnivå.
- Om användaren synkroniseras med Microsoft Entra-ID kan du bevilja en behörighet på resursnivå (Azure RBAC-roll) till användaren onprem1user på lagringskontot onprem1sa så att användaren kan montera filresursen. Det gör du genom att gå till den filresurs som du skapade i onprem1sa och följa anvisningarna i Tilldela behörigheter på resursnivå för specifika Microsoft Entra-användare eller -grupper.
- Annars kan du använda en standardbehörighet på resursnivå som gäller för alla autentiserade identiteter.
Upprepa steg 4–8 för Forest2-domänen onpremad2.com (lagringskonto onprem2sa/user onprem2user). Om du har fler än två skogar upprepar du stegen för varje skog.
Konfigurera katalog- och filnivåbehörigheter (valfritt)
I en miljö med flera skogar använder du kommandoradsverktyget i icacls för att konfigurera katalog- och filnivåbehörigheter för användare i båda skogarna. Se Konfigurera Windows-ACL:er med icacls.
Om icacls misslyckas med ett åtkomstfel nekas följer du de här stegen för att konfigurera katalog- och filnivåbehörigheter genom att montera resursen med lagringskontonyckeln.
Ta bort den befintliga resursmonteringen:
net use * /delete /y
Montera resursen igen med hjälp av lagringskontonyckeln:
net use <driveletter> \\storageaccount.file.core.windows.net\sharename /user:AZURE\<storageaccountname> <storageaccountkey>
Ange icacls-behörigheter för användare i Forest2 på lagringskonto som är anslutet till Forest1 från klienten i Forest1.
Kommentar
Vi rekommenderar inte att du använder Utforskaren för att konfigurera ACL:er i en miljö med flera skogar. Även om användare som tillhör skogen som är domänansluten till lagringskontot kan ha fil-/katalognivåbehörigheter angivna via Utforskaren, fungerar det inte för användare som inte tillhör samma skog som är domänansluten till lagringskontot.
Konfigurera domänsuffix
Som beskrivs ovan är sättet som Azure Files registrerar i AD DS nästan detsamma som en vanlig filserver, där den skapar en identitet (som standard ett datorkonto, kan också vara ett konto för tjänstinloggning) som representerar lagringskontot i AD DS för autentisering. Den enda skillnaden är att det registrerade tjänstens huvudnamn (SPN) för lagringskontot slutar med file.core.windows.net, vilket inte matchar domänsuffixet. På grund av det olika domänsuffixet måste du konfigurera en suffixroutningsprincip för att aktivera autentisering med flera skogar.
Eftersom suffixet file.core.windows.net är suffixet för alla Azure Files-resurser i stället för ett suffix för en specifik AD-domän vet inte klientens domänkontrollant vilken domän som begäran ska vidarebefordras till och misslyckas därför med alla begäranden där resursen inte finns i sin egen domän.
När till exempel användare i en domän i Skog 1 vill nå en filresurs med lagringskontot registrerat mot en domän i Skog 2 fungerar detta inte automatiskt eftersom tjänstens huvudnamn för lagringskontot inte har ett suffix som matchar suffixet för någon domän i Skog 1.
Du kan konfigurera domänsuffix med någon av följande metoder:
- Ändra lagringskontosuffix och lägg till en CNAME-post (rekommenderas – fungerar med två eller flera skogar)
- Lägg till suffix för anpassat namn och routningsregel (fungerar inte med fler än två skogar)
Ändra suffixet för lagringskontonamn och lägg till CNAME-post
Du kan lösa problemet med domänroutning genom att ändra suffixet för lagringskontonamnet som är associerat med Azure-filresursen och sedan lägga till en CNAME-post för att dirigera det nya suffixet till slutpunkten för lagringskontot. Med den här konfigurationen kan domänanslutna klienter komma åt lagringskonton som är anslutna till alla skogar. Detta fungerar för miljöer som har två eller flera skogar.
I vårt exempel har vi domänerna onpremad1.com och onpremad2.com, och vi har onprem1sa och onprem2sa som lagringskonton som är associerade med SMB Azure-filresurser i respektive domäner. Dessa domäner finns i olika skogar som litar på varandra för att komma åt resurser i varandras skogar. Vi vill tillåta åtkomst till båda lagringskontona från klienter som tillhör varje skog. För att göra detta måste vi ändra SPN-suffixen för lagringskontot:
onprem1sa.onpremad1.com -> onprem1sa.file.core.windows.net
onprem2sa.onpremad2.com -> onprem2sa.file.core.windows.net
Detta gör att klienter kan montera resursen med net use \\onprem1sa.onpremad1.com
eftersom klienter i antingen onpremad1 eller onpremad2 vet att söka onpremad1.com för att hitta rätt resurs för lagringskontot.
Utför följande steg för att använda den här metoden:
Kontrollera att du har upprättat förtroende mellan de två skogarna och konfigurera identitetsbaserad autentisering och hybridanvändarkonton enligt beskrivningen i föregående avsnitt.
Ändra SPN för lagringskontot med hjälp av setpn-verktyget. Du hittar
<DomainDnsRoot>
genom att köra följande Active Directory PowerShell-kommando:(Get-AdDomain).DnsRoot
setspn -s cifs/<storage-account-name>.<DomainDnsRoot> <storage-account-name>
Lägg till en CNAME-post med Active Directory DNS Manager och följ stegen nedan för varje lagringskonto i domänen som lagringskontot är anslutet till. Om du använder en privat slutpunkt lägger du till CNAME-posten för att mappa till det privata slutpunktsnamnet.
Öppna Active Directory DNS Manager.
Gå till din domän (till exempel onpremad1.com).
Gå till "Framåtblickande zoner".
Välj noden med namnet efter din domän (till exempel onpremad1.com) och högerklicka på Nytt alias (CNAME).
Ange namnet på ditt lagringskonto för aliasnamnet.
För det fullständigt kvalificerade domännamnet (FQDN) anger du
<storage-account-name>
.<domain-name>
, till exempel mystorageaccount.onpremad1.com.För målvärdens FQDN anger du
<storage-account-name>
.file.core.windows.netVälj OK.
Från domänanslutna klienter bör du nu kunna använda lagringskonton som är anslutna till valfri skog.
Kommentar
Se till att värdnamnsdelen av FQDN matchar lagringskontots namn enligt beskrivningen ovan. Annars får du ett felmeddelande om nekad åtkomst: "Syntaxen för filnamn, katalognamn eller volymetikett är felaktig." En nätverksspårning visar meddelandet STATUS_OBJECT_NAME_INVALID (0xc0000033) under SMB-sessionskonfigurationen.
Lägg till suffix för anpassat namn och routningsregel
Om du redan har ändrat suffixet för lagringskontots namn och lagt till en CNAME-post enligt beskrivningen i föregående avsnitt kan du hoppa över det här steget. Om du inte vill göra DNS-ändringar eller ändra suffixet för lagringskontonamn kan du konfigurera en suffixroutningsregel från Skog 1 till Skog 2 för ett anpassat suffix med file.core.windows.net.
Kommentar
Att konfigurera namnsuffixroutning påverkar inte möjligheten att komma åt resurser i den lokala domänen. Det krävs bara att klienten vidarebefordrar begäran till domänen som matchar suffixet när resursen inte hittas i en egen domän.
Lägg först till ett nytt anpassat suffix i Skog 2. Kontrollera att du har rätt administrativa behörigheter för att ändra konfigurationen och att du har upprättat förtroende mellan de två skogarna. Följ sedan de här stegen:
- Logga in på en dator eller virtuell dator som är ansluten till en domän i Skog 2.
- Öppna konsolen Active Directory-domän och förtroenden.
- Högerklicka på Active Directory-domän och förtroenden.
- Välj Egenskaper och välj sedan Lägg till.
- Lägg till "file.core.windows.net" som UPN-suffix.
- Välj Använd och sedan OK för att stänga guiden.
Lägg sedan till suffixets routningsregel i Skog 1 så att den omdirigeras till Skog 2.
- Logga in på en dator eller virtuell dator som är ansluten till en domän i Skog 1.
- Öppna konsolen Active Directory-domän och förtroenden.
- Högerklicka på domänen som du vill komma åt filresursen, välj sedan fliken Förtroenden och välj Skog 2-domän från utgående förtroenden.
- Välj Egenskaper och sedan Namn på Suffixroutning.
- Kontrollera om suffixet "*.file.core.windows.net" visas. Om inte väljer du Uppdatera.
- Välj "*.file.core.windows.net" och välj sedan Aktivera och Använd.
Kontrollera att förtroendet fungerar
Nu ska vi kontrollera att förtroendet fungerar genom att köra klist-kommandot för att visa innehållet i Kerberos-autentiseringsuppgifternas cache och nyckeltabell.
- Logga in på en dator eller virtuell dator som är ansluten till en domän i Skog 1 och öppna en Windows-kommandotolk.
- Om du vill visa cacheminnet för autentiseringsuppgifter för det domänanslutna lagringskontot i Forest 2 kör du något av följande kommandon:
- Om du använde suffixet Ändra lagringskontonamn och lägger till CNAME-postmetod kör du:
klist get cifs/onprem2sa.onpremad2.com
- Om du använde metoden Lägg till suffix för anpassat namn och routningsregel kör du:
klist get cifs/onprem2sa.file.core.windows.net
- Om du använde suffixet Ändra lagringskontonamn och lägger till CNAME-postmetod kör du:
- Du bör se utdata som liknar följande. Klist-utdata skiljer sig något beroende på vilken metod du använde för att konfigurera domänsuffix.
Client: onprem1user @ ONPREMAD1.COM
Server: cifs/onprem2sa.file.core.windows.net @ ONPREMAD2.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
Start Time: 11/22/2022 18:45:02 (local)
End Time: 11/23/2022 4:45:02 (local)
Renew Time: 11/29/2022 18:45:02 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x200 -> DISABLE-TGT-DELEGATION
Kdc Called: onprem2.onpremad2.com
- Logga in på en dator eller virtuell dator som är ansluten till en domän i Skog 2 och öppna en Windows-kommandotolk.
- Om du vill visa cacheminnet för autentiseringsuppgifter för det domänanslutna lagringskontot i Skog 1 kör du något av följande kommandon:
- Om du använde suffixet Ändra lagringskontonamn och lägger till CNAME-postmetod kör du:
klist get cifs/onprem1sa.onpremad1.com
- Om du använde metoden Lägg till suffix för anpassat namn och routningsregel kör du:
klist get cifs/onprem1sa.file.core.windows.net
- Om du använde suffixet Ändra lagringskontonamn och lägger till CNAME-postmetod kör du:
- Du bör se utdata som liknar följande. Klist-utdata skiljer sig något beroende på vilken metod du använde för att konfigurera domänsuffix.
Client: onprem2user @ ONPREMAD2.COM
Server: krbtgt/ONPREMAD2.COM @ ONPREMAD2.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40e10000 -> forwardable renewable pre_authent name_canonicalize
Start Time: 11/22/2022 18:46:35 (local)
End Time: 11/23/2022 4:46:35 (local)
Renew Time: 11/29/2022 18:46:35 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x1 -> PRIMARY
Kdc Called: onprem2
Client: onprem2user @ ONPREMAD2.COM
Server: cifs/onprem1sa.file.core.windows.net @ ONPREMAD1.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
Start Time: 11/22/2022 18:46:35 (local)
End Time: 11/23/2022 4:46:35 (local)
Renew Time: 11/29/2022 18:46:35 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x200 -> DISABLE-TGT-DELEGATION
Kdc Called: onpremad1.onpremad1.com
Om du ser ovanstående utdata är du klar. Om du inte gör det följer du de här stegen för att tillhandahålla alternativa UPN-suffix för att få multiskogsautentisering att fungera.
Viktigt!
Den här metoden fungerar bara i miljöer med två skogar. Om du har fler än två skogar använder du en av de andra metoderna för att konfigurera domänsuffix.
Lägg först till ett nytt anpassat suffix i Skog 1.
- Logga in på en dator eller virtuell dator som är ansluten till en domän i Skog 1.
- Öppna konsolen Active Directory-domän och förtroenden.
- Högerklicka på Active Directory-domän och förtroenden.
- Välj Egenskaper och välj sedan Lägg till.
- Lägg till ett alternativt UPN-suffix, till exempel "onprem1sa.file.core.windows.net".
- Välj Använd och sedan OK för att stänga guiden.
Lägg sedan till suffixets routningsregel i Skog 2.
- Logga in på en dator eller virtuell dator som är ansluten till en domän i Skog 2.
- Öppna konsolen Active Directory-domän och förtroenden.
- Högerklicka på domänen som du vill komma åt filresursen, välj sedan fliken Förtroenden och välj utgående förtroende för Skog 2 där suffixets routningsnamn lades till.
- Välj Egenskaper och sedan Namn på Suffixroutning.
- Kontrollera om suffixet "onprem1sa.file.core.windows.net" visas. Om inte väljer du Uppdatera.
- Välj "onprem1sa.file.core.windows.net" och välj sedan Aktivera och Tillämpa.
Nästa steg
Mer information finns i de här resurserna: