Förstå riktlinjer för Active Directory-domän Services-webbplatsdesign och -planering för Azure NetApp Files

Korrekt design och planering för Active Directory-domän Services (AD DS) är nyckeln till lösningsarkitekturer som använder Azure NetApp Files-volymer. Azure NetApp Files-funktioner som SMB-volymer, volymer med dubbla protokoll och NFSv4.1 Kerberos-volymer är utformade för att användas med AD DS.

Den här artikeln innehåller rekommendationer som hjälper dig att utveckla en AD DS-distributionsstrategi för Azure NetApp Files. Innan du läser den här artikeln måste du ha en god förståelse för hur AD DS fungerar på funktionsnivå.

Identifiera AD DS-krav för Azure NetApp Files

Innan du distribuerar Azure NetApp Files-volymer måste du identifiera AD DS-integreringskraven för Azure NetApp Files för att säkerställa att Azure NetApp Files är väl anslutet till AD DS. Felaktig eller ofullständig AD DS-integrering med Azure NetApp Files kan orsaka avbrott i klientåtkomsten eller avbrott för SMB-volymer, dubbla protokoll eller Kerberos NFSv4.1-volymer.

Autentiseringsscenarier som stöds

Azure NetApp Files stöder identitetsbaserad autentisering via SMB via följande metoder.

  • AD DS-autentisering: AD DS-anslutna Windows-datorer kan komma åt Azure NetApp Files-resurser med Active Directory-autentiseringsuppgifter via SMB. Klienten måste ha siktlinje för din AD DS. Om du redan har konfigurerat AD DS lokalt eller på en virtuell dator i Azure där dina enheter är domänanslutna till din AD DS bör du använda AD DS för Filresursautentisering i Azure NetApp Files.
  • Microsoft Entra Domain Services-autentisering: Molnbaserade, Microsoft Entra Domain Services-anslutna virtuella Windows-datorer kan komma åt Azure NetApp Files-filresurser med Microsoft Entra Domain Services-autentiseringsuppgifter. I den här lösningen kör Microsoft Entra Domain Services en traditionell Windows Server AD-domän åt kunden.
  • Microsoft Entra Kerberos för hybrididentiteter: Med Microsoft Entra-ID för att autentisera hybridanvändaridentiteter kan Microsoft Entra-användare komma åt Azure NetApp Files-filresurser med hjälp av Kerberos-autentisering. Det innebär att dina slutanvändare kan komma åt Azure NetApp Files-filresurser utan att behöva en siktlinje för domänkontrollanter från Microsoft Entra-hybridanslutna och Microsoft Entra-anslutna virtuella Windows- eller Linux-datorer. Molnbaserade identiteter stöds inte för närvarande.
  • AD Kerberos-autentisering för Linux-klienter: Linux-klienter kan använda Kerberos-autentisering via SMB för Azure NetApp Files med HJÄLP av AD DS.

Nätverkskrav

Azure NetApp Files SMB-, dual-protocol- och Kerberos NFSv4.1-volymer kräver tillförlitlig nätverksanslutning med låg latens (mindre än 10 ms RTT) till AD DS-domänkontrollanter. Dålig nätverksanslutning eller hög nätverksfördröjning mellan Azure NetApp Files och AD DS-domänkontrollanter kan orsaka avbrott i klientåtkomsten eller tidsgränser för klienten.

Se till att du uppfyller följande krav om nätverkstopologi och konfigurationer:

  • Se till att en nätverkstopologi som stöds för Azure NetApp Files används.
  • Se till att AD DS-domänkontrollanter har nätverksanslutning från azure NetApp Files delegerade undernät som är värd för Azure NetApp Files-volymerna.
    • Peer-kopplade virtuella nätverkstopologier med AD DS-domänkontrollanter måste ha peering korrekt konfigurerad för att stödja Nätverksanslutning för Azure NetApp Files till AD DS-domänkontrollanten.
  • Nätverkssäkerhetsgrupper (NSG: er) och AD DS-domänkontrollantbrandväggar måste ha korrekt konfigurerade regler för att stödja Azure NetApp Files-anslutning till AD DS och DNS.
  • Kontrollera att svarstiden är mindre än 10 ms RTT mellan Azure NetApp Files och AD DS-domänkontrollanter.

De nödvändiga nätverksportarna är följande:

Tjänst Port Protokoll
AD-webbtjänster 9389 TCP
DNS* 53 TCP
DNS* 53 UDP
ICMPv4 Ej tillämpligt Ekosvar
Kerberos 464 TCP
Kerberos 464 UDP
Kerberos 88 TCP
Kerberos 88 UDP
LDAP 389 TCP
LDAP 389 UDP
LDAP 389 TLS
LDAP 3268 TCP
NetBIOS-namn 138 UDP
SAM/LSA 445 TCP
SAM/LSA 445 UDP

*DNS körs på AD DS-domänkontrollant

DNS-krav

Azure NetApp Files SMB-, dual-protocol- och Kerberos NFSv4.1-volymer kräver tillförlitlig åtkomst till DNS-tjänster (Domain Name System) och uppdaterade DNS-poster. Dålig nätverksanslutning mellan Azure NetApp Files och DNS-servrar kan orsaka avbrott i klientåtkomsten eller tidsgränser för klienten. Ofullständiga eller felaktiga DNS-poster för AD DS eller Azure NetApp Files kan orsaka avbrott i klientåtkomsten eller tidsgränser för klienten.

Azure NetApp Files stöder användning av Active Directory-integrerade DNS- eller fristående DNS-servrar.

Se till att du uppfyller följande krav om DNS-konfigurationerna:

  • Om du använder fristående DNS-servrar:
    • Kontrollera att DNS-servrarna har nätverksanslutning till det delegerade Undernätet i Azure NetApp Files som är värd för Azure NetApp Files-volymerna.
    • Se till att nätverksportarna UDP 53 och TCP 53 inte blockeras av brandväggar eller NSG:er.
  • Kontrollera att de SRV-poster som registrerats av AD DS Net-inloggningstjänsten har skapats på DNS-servrarna.
  • Se till att PTR-posterna för AD DS-domänkontrollanterna som används av Azure NetApp Files har skapats på DNS-servrarna i samma domän som din Azure NetApp Files-konfiguration.
  • Azure NetApp Files tar inte automatiskt bort pekarposter (PTR) som är associerade med DNS-poster när en volym tas bort. PTR-poster används för omvända DNS-sökningar, som mappar IP-adresser till värdnamn. De hanteras vanligtvis av DNS-serverns administratör. När du skapar en volym i Azure NetApp Files kan du associera den med ett DNS-namn. Hanteringen av DNS-poster, inklusive PTR-poster, ligger dock utanför Azure NetApp Files omfång. Azure NetApp Files ger möjlighet att associera en volym med ett DNS-namn för enklare åtkomst, men det hanterar inte de DNS-poster som är associerade med det namnet. Om du tar bort en volym i Azure NetApp Files måste de associerade DNS-posterna (till exempel A-posterna för vidarebefordran av DNS-sökningar) hanteras och tas bort från DNS-servern eller DEN DNS-tjänst som du använder.
  • Azure NetApp Files stöder standard- och säkra dynamiska DNS-uppdateringar. Om du behöver säkra dynamiska DNS-uppdateringar kontrollerar du att säkra uppdateringar har konfigurerats på DNS-servrarna.
  • Om dynamiska DNS-uppdateringar inte används måste du manuellt skapa en A-post och en PTR-post för AD DS-datorkontot som skapats i AD DS-organisationsenheten (anges i Azure NetApp Files AD-anslutningen) för att stödja Azure NetApp Files LDAP-signering, LDAP över TLS, SMB, dubbla protokoll eller Kerberos NFSv4.1-volymer.
  • För komplexa eller stora AD DS-topologier kan DNS-principer eller DNS-undernätsprioritering krävas för att stödja LDAP-aktiverade NFS-volymer.

Krav för tidskälla

Azure NetApp Files använder time.windows.com som tidskälla. Kontrollera att domänkontrollanterna som används av Azure NetApp Files är konfigurerade för att använda time.windows.com eller någon annan korrekt, stabil rot (stratum 1) tidskälla. Om det finns mer än fem minuters skevhet mellan Azure NetApp Files och klient- eller AS DS-domänkontrollanter misslyckas autentiseringen. åtkomst till Azure NetApp Files-volymer kan också misslyckas.

Bestäm vilken AD DS som ska användas med Azure NetApp Files

Azure NetApp Files stöder både Active Directory-domän Services (AD DS) och Microsoft Entra Domain Services för AD-anslutningar. Innan du skapar en AD-anslutning måste du bestämma om du vill använda AD DS eller Microsoft Entra Domain Services.

Mer information finns i Jämför självhanterade Active Directory-domän Services, Microsoft Entra-ID och hanterade Microsoft Entra Domain Services.

överväganden för Active Directory-domän Services

Du bör använda Active Directory-domän Services (AD DS) i följande scenarier:

  • Du har AD DS-användare i en lokal AD DS-domän som behöver åtkomst till Azure NetApp Files-resurser.
  • Du har program som delvis finns lokalt och delvis i Azure som behöver åtkomst till Azure NetApp Files-resurser.
  • Du behöver inte Microsoft Entra Domain Services-integrering med en Microsoft Entra-klientorganisation i din prenumeration, eller så är Microsoft Entra Domain Services inte kompatibelt med dina tekniska krav.

Kommentar

Azure NetApp Files stöder inte användning av SKRIVSKYDDADE DOMÄNKONTROLLanter (RODC) för AD DS.

Om du väljer att använda AD DS med Azure NetApp Files följer du vägledningen i Guiden Utöka AD DS till Azure Architecture och ser till att du uppfyller Azure NetApp Files-nätverketoch DNS-kraven för AD DS.

Överväganden för Microsoft Entra Domain Services

Microsoft Entra Domain Services är en hanterad AD DS-domän som synkroniseras med din Microsoft Entra-klientorganisation. De största fördelarna med att använda Microsoft Entra Domain Services är följande:

  • Microsoft Entra Domain Services är en fristående domän. Därför behöver du inte konfigurera nätverksanslutningen mellan lokalt och Azure.
  • Ger en förenklad distributions- och hanteringsupplevelse.

Du bör använda Microsoft Entra Domain Services i följande scenarier:

  • Du behöver inte utöka AD DS från en lokal plats till Azure för att ge åtkomst till Azure NetApp Files-resurser.
  • Dina säkerhetsprinciper tillåter inte tillägget av lokal AD DS till Azure.
  • Du har ingen stark kunskap om AD DS. Microsoft Entra Domain Services kan förbättra sannolikheten för goda resultat med Azure NetApp Files.

Om du väljer att använda Microsoft Entra Domain Services med Azure NetApp Files kan du läsa dokumentationen om Microsoft Entra Domain Services för vägledning om arkitektur, distribution och hantering. Se till att du även uppfyller Azure NetApp Files Network - och DNS-kraven.

Utforma AD DS-platstopologi för användning med Azure NetApp Files

En korrekt design för AD DS-platstopologin är viktig för alla lösningsarkitekturer som omfattar Azure NetApp Files SMB, dual-protocol eller NFSv4.1 Kerberos-volymer.

Felaktig AD DS-platstopologi eller konfiguration kan resultera i följande beteenden:

En AD DS-platstopologi för Azure NetApp Files är en logisk representation av Azure NetApp Files-nätverket. Att utforma en AD DS-platstopologi för Azure NetApp Files omfattar planering för placering av domänkontrollanter, utformning av platser, DNS-infrastruktur och nätverksundernät för att säkerställa god anslutning mellan Azure NetApp Files-tjänsten, Azure NetApp Files-lagringsklienter och AD DS-domänkontrollanter.

Förutom flera domänkontrollanter som tilldelats AD DS-platsen som konfigurerats i Azure NetApp Files AD-webbplatsnamnet kan Azure NetApp Files AD DS-webbplatsen ha ett eller flera undernät tilldelade till sig.

Kommentar

Det är viktigt att alla domänkontrollanter och undernät som tilldelats azure NetApp Files AD DS-platsen måste vara väl anslutna (mindre än 10 ms RTT-svarstid) och nåbara av de nätverksgränssnitt som används av Azure NetApp Files-volymerna.

Om du använder standardnätverksfunktioner bör du se till att alla användardefinierade vägar (UDR) eller NSG-regler (Network Security Group) inte blockerar Azure NetApp Files-nätverkskommunikation med AD DS-domänkontrollanter som tilldelats Azure NetApp Files AD DS-webbplatsen.

Om du använder virtuella nätverksinstallationer eller brandväggar (till exempel Palo Alto Networks eller Fortinet-brandväggar) måste de konfigureras för att inte blockera nätverkstrafik mellan Azure NetApp Files och AD DS-domänkontrollanterna och undernäten som tilldelats Azure NetApp Files AD DS-platsen.

Så här använder Azure NetApp Files AD DS-webbplatsinformation

Azure NetApp Files använder AD-webbplatsnamnet som konfigurerats i Active Directory-anslutningarna för att identifiera vilka domänkontrollanter som finns för autentisering, domänanslutning, LDAP-frågor och Kerberos-biljettåtgärder.

Identifiering av AD DS-domänkontrollant

Azure NetApp Files initierar identifiering av domänkontrollant var fjärde timme. Azure NetApp Files frågar resursposten för platsspecifik DNS-tjänst (SRV) för att avgöra vilka domänkontrollanter som finns på AD DS-platsen som anges i fältet AD-platsnamn i Azure NetApp Files AD-anslutningen. Azure NetApp Files domänkontrollantserveridentifiering kontrollerar statusen för de tjänster som finns på domänkontrollanterna (till exempel Kerberos, LDAP, Net Logon och LSA) och väljer den optimala domänkontrollanten för autentiseringsbegäranden.

DNS-tjänstens (SRV) resursposter för AD DS-platsen som anges i fältet AD-platsnamn i Azure NetApp Files AD-anslutningen måste innehålla listan över IP-adresser för AD DS-domänkontrollanterna som ska användas av Azure NetApp Files. Du kan kontrollera giltigheten för DNS-resursposten (SRV) med hjälp nslookup av verktyget.

Kommentar

Om du gör ändringar i domänkontrollanterna på AD DS-webbplatsen som används av Azure NetApp Files väntar du minst fyra timmar mellan att distribuera nya AD DS-domänkontrollanter och dra tillbaka befintliga AD DS-domänkontrollanter. Med den här väntetiden kan Azure NetApp Files identifiera de nya AD DS-domänkontrollanterna.

Se till att inaktuella DNS-poster som är associerade med den tillbakadragna AD DS-domänkontrollanten tas bort från DNS. Detta säkerställer att Azure NetApp Files inte försöker kommunicera med den tillbakadragna domänkontrollanten.

AD DS LDAP-serveridentifiering

En separat identifieringsprocess för AD DS LDAP-servrar inträffar när LDAP är aktiverat för en Azure NetApp Files NFS-volym. När LDAP-klienten skapas på Azure NetApp Files frågar Azure NetApp Files ad DS-domäntjänstens resurspost (SRV) för en lista över alla AD DS LDAP-servrar i domänen och inte AD DS LDAP-servrarna som tilldelats AD DS-platsen som anges i AD-anslutningen.

I stora eller komplexa AD DS-topologier kan du behöva implementera DNS-principer eller DNS-undernätsprioritering för att säkerställa att AD DS LDAP-servrar som tilldelats till AD DS-platsen som anges i AD-anslutningen returneras.

Alternativt kan AD DS LDAP-serveridentifieringsprocessen åsidosättas genom att ange upp till två föredragna AD-servrar för LDAP-klienten.

Viktigt!

Om Azure NetApp Files inte kan nå en identifierad AD DS LDAP-server när Azure NetApp Files LDAP-klienten skapas misslyckas skapandet av den LDAP-aktiverade volymen.

Konsekvenser av felaktig eller ofullständig AD-platsnamnskonfiguration

Felaktig eller ofullständig AD DS-platstopologi eller konfiguration kan leda till problem med att skapa volymer, problem med klientfrågor, autentiseringsfel och fel vid ändring av Azure NetApp Files AD-anslutningar.

Viktigt!

Fältet AD-webbplatsnamn krävs för att skapa en Azure NetApp Files AD-anslutning. Den definierade AD DS-platsen måste finnas och vara korrekt konfigurerad.

Azure NetApp Files använder AD DS-webbplatsen för att identifiera de domänkontrollanter och undernät som tilldelats TILL AD DS-webbplatsen som definierats i AD-webbplatsnamnet. Alla domänkontrollanter som tilldelats AD DS-platsen måste ha en bra nätverksanslutning från de virtuella Azure-nätverksgränssnitt som används av ANF och vara nåbara. Virtuella AD DS-domänkontrollantdatorer som är tilldelade till AD DS-platsen som används av Azure NetApp Files måste undantas från kostnadshanteringsprinciper som stänger av virtuella datorer.

Om Azure NetApp Files inte kan nå några domänkontrollanter som tilldelats TILL AD DS-platsen frågar domänkontrollantens identifieringsprocess AD DS-domänen efter en lista över alla domänkontrollanter. Listan över domänkontrollanter som returneras från den här frågan är en osorterad lista. Därför kan Azure NetApp Files försöka använda domänkontrollanter som inte kan nås eller är väl anslutna, vilket kan orsaka problem med att skapa volymer, problem med klientfrågor, autentiseringsfel och fel vid ändring av Ad-anslutningar i Azure NetApp Files.

Du måste uppdatera AD DS-platskonfigurationen när nya domänkontrollanter distribueras till ett undernät som tilldelats AD DS-platsen som används av Azure NetApp Files AD-Anslut ion. Se till att DNS SRV-posterna för webbplatsen återspeglar alla ändringar i de domänkontrollanter som tilldelats AD DS-webbplatsen som används av Azure NetApp Files. Du kan kontrollera giltigheten för DNS-resursposten (SRV) med hjälp nslookup av verktyget.

Kommentar

Azure NetApp Files stöder inte användning av SKRIVSKYDDADE DOMÄNKONTROLLanter (RODC) för AD DS. Om du vill förhindra att Azure NetApp Files använder en RODC ska du inte konfigurera fältet AD-platsnamn för AD-anslutningarna med en RODC.

Exempel på konfiguration av AD DS-platstopologi för Azure NetApp Files

En AD DS-platstopologi är en logisk representation av nätverket där Azure NetApp Files distribueras. I det här avsnittet avser exempelkonfigurationsscenariot för AD DS-platstopologi att visa en grundläggande AD DS-webbplatsdesign för Azure NetApp Files. Det är inte det enda sättet att utforma nätverks- eller AD-platstopologi för Azure NetApp Files.

Viktigt!

För scenarier som omfattar komplexa AD DS eller komplexa nätverkstopologier bör du ha en Microsoft Azure CSA-granskning av Azure NetApp Files-nätverk och AD-webbplatsdesign.

Följande diagram visar en nätverkstopologiexempel: sample-network-topology.png Diagram som illustrerar nätverkstopologi.

I exempelnätverkstopologin utökas en lokal AD DS-domän (anf.local) till ett virtuellt Azure-nätverk. Det lokala nätverket är anslutet till det virtuella Azure-nätverket med hjälp av en Azure ExpressRoute-krets.

Det virtuella Azure-nätverket har fyra undernät: Gateway-undernät, Azure Bastion-undernät, AD DS-undernät och ett delegerat Undernät för Azure NetApp Files. Redundanta AD DS-domänkontrollanter som är anslutna till domänen anf.local distribueras till AD DS-undernätet. AD DS-undernätet tilldelas IP-adressintervallet 10.0.0.0/24.

Azure NetApp Files kan bara använda en AD DS-webbplats för att avgöra vilka domänkontrollanter som ska användas för autentisering, LDAP-frågor och Kerberos. I exempelscenariot skapas två undernätsobjekt och tilldelas till en plats som anropas ANF med verktyget Active Directory-platser och tjänster. Ett undernätsobjekt mappas till AD DS-undernätet, 10.0.0.0/24, och det andra undernätsobjektet mappas till det ANF-delegerade undernätet 10.0.2.0/24.

Kontrollera att DE AD DS-domänkontrollanter som distribueras till AD DS-undernätet har tilldelats platsen ANF i verktyget Active Directory-platser och -tjänster:

Skärmbild av fönstret Active Directory-webbplatser och -tjänster med en röd ruta som uppmärksammar katalogen ANF-servrar > .

Om du vill skapa undernätsobjektet som mappar till AD DS-undernätet i det virtuella Azure-nätverket högerklickar du på containern Undernät i verktyget Active Directory-platser och tjänster och väljer Nytt undernät.... I dialogrutan Nytt objekt – undernät anges IP-adressintervallet 10.0.0.0/24 för AD DS-undernätet i fältet Prefix. Välj ANF som platsobjekt för undernätet. Välj OK för att skapa undernätsobjektet och tilldela det till ANF platsen.

Skärmbild av menyn Nytt objekt – undernät.

Om du vill kontrollera att det nya undernätsobjektet har tilldelats till rätt plats högerklickar du på undernätsobjektet 10.0.0.0/24 och väljer Egenskaper. Fältet Webbplats ska visa ANF platsobjektet:

Skärmbild av egenskapsmenyn med en röd ruta som omger webbplatsfältet med texten

Om du vill skapa det undernätsobjekt som mappar till det delegerade undernätet Azure NetApp Files i det virtuella Azure-nätverket högerklickar du på containern Undernät i verktyget Active Directory-platser och tjänster och väljer Nytt undernät....

Överväganden för replikering mellan regioner

Med Azure NetApp Files replikering mellan regioner kan du replikera Azure NetApp Files-volymer från en region till en annan region för att stödja krav på affärskontinuans och haveriberedskap (BC/DR).

Azure NetApp Files SMB- och NFSv4.1 Kerberos-volymer stöder replikering mellan regioner. Replikering av dessa volymer kräver:

  • Ett NetApp-konto som skapats i både käll- och målregionerna.
  • En Azure NetApp Files Active Directory-anslutning i NetApp-kontot som skapats i käll- och målregionerna.
  • AD DS-domänkontrollanter distribueras och körs i målregionen.
  • Korrekt Azure NetApp Files-nätverk, DNS och AD DS-webbplatsdesign måste distribueras i målregionen för att möjliggöra bra nätverkskommunikation av Azure NetApp Files med AD DS-domänkontrollanterna i målregionen.
  • Active Directory-anslutningen i målregionen måste konfigureras för att använda DNS- och AD-platsresurserna i målregionen.

Nästa steg