Dela via

Förstå Kerberos i Azure NetApp Files

  • Artikel

Kerberos är ett autentiseringsprotokoll som använder en hemlig nyckel för att verifiera identiteten för huvudkonton. Hemliga nycklar genereras genom att ett huvudnamns lösenord tas och konverteras till ett hashat kryptografiskt nyckelformat med hjälp av en överenskommen krypteringsmetod av klienten och servern (till exempel AES). Se avsnittet Kerberos-terminologi för att lära dig mer om de termer som används i det här dokumentet.

Nyckeldistributionscenter (KDCs) som Windows Active Directory underhåller en databas med Kerberos-huvudnamn och deras hashade lösenord. I Kerberos är den hemliga nyckeln ett bevis på en unik identitet. Därför kan KDC vara betrodd för att autentisera alla huvudnamn till andra huvudnamn, till exempel autentisera ett NFS-klienttjänsthuvudnamn (SPN) till en NFS-server-SPN vid montering. Det kan också vara betrott att autentisera ett användarhuvudnamn till en NFS-server-SPN för användaråtkomst till en NAS-monteringspunkt. Som ett extra säkerhetsmått skickar Kerberos inte lösenord i klartext för autentisering över kabeln.

Azure NetApp Files stöder användning av Kerberos för att tillhandahålla säkerhet under flygning för både SMB- och NFS-protokollen.

Krypteringstyper som stöds

Azure NetApp Files stöder NFS Kerberos med specifika krypteringstyper, beroende på driftläge och vilken version du använder.

För att säkerställa att en klient använder rätt krypteringstyp kan du begränsa de giltiga krypteringstyperna på objektobjektets huvudnamn som finns på KDC (till exempel datorkontot) eller i klientens manuella nyckelfliksfil i stället för globalt i filen /etc/krb5.conf, om möjligt, eftersom hanteringen av många klient-krb5.conf-filer kan vara en hanteringshuvudvärk. Att centralt hantera Kerberos från KDC är mer skalbart i stora företagsmiljöer, är enklare att automatisera och tvingar klienten att använda starkare krypteringstyper när de stöds.

Kommentar

Vi rekommenderar att du anger alternativet allow_weak_crypto till false i filen krb5.conf på klienter. Den här inställningen förhindrar mindre säkerhet enctypes för Kerberos-kommunikation (till exempel DES eller 3DES).

I följande tabell visas de krypteringstyper som stöds för Kerberos (både SMB och NFS) för Azure NetApp Files.

Protokoll Krypteringstyper som stöds
SMB
  • RC4-HMAC
  • AES-128
  • AES-256
NFS AES-256

NFS Kerberos-säkerhetslägen som stöds

Förutom begreppet krypteringstyper finns det även nivåer av säkerhets- och integritetskontroll i Kerberos. Beroende på vilket säkerhetsläge som används kan dessa säkerhetslägen förhindra man-in-the-middle-attacker genom att erbjuda kryptering från slutpunkt till slutpunkt för NFS-trafik.

I Azure NetApp Files anges dessa säkerhetslägen på de exportprincipregler som angetts för volymen för NFS och definieras under den första NFS-monteringen via sek-monteringsalternativet.

Till exempel: # mount -o sec=krb5p

Kommentar

För SMB Kerberos styrs säkerhetslägen för Kerberos via SMB-krypteringsinställningar på resursen, UNC-härdning och SMB-signerings-/tätningsprinciper på domänkontrollanterna.

Följande säkerhetslägen stöds av Azure NetApp Files för användning med NFS Kerberos:

Säkerhetsläge beskrivning
krb5 Endast autentiseringskryptering.

Använder Kerberos V5-namnsträngar och användarnamn i stället för lokala UNIX-användar-ID:n (UID) och grupp-ID :n (GID) för att autentisera användare.
krb5i Autentiseringskryptering och krypterad integritetskontroll.

Använder Kerberos V5 för användarautentisering och utför även integritetskontroll av NFS-åtgärder med hjälp av säkra kontrollsummor för att förhindra datamanipulering och man-in-the-middle-attacker.
krb5p Hela NFS-konversationen krypterad.

Använder Kerberos V5 för användarautentisering och integritetskontroll och krypterar även all NFS-trafik för att förhindra paketsniffning. Den här inställningen är den säkraste, men den skapar också mest prestandakostnader.

Kerberos-terminologi

Det här avsnittet definierar nyckelterminologi som används när du beskriver Kerberos-processer. Det här avsnittet är avsett att hjälpa till att klargöra termer som kan vara obekanta för lagringsadministratörer.

Period Definition
Nyckeldistributionscenter (KDC) KDC är den autentiseringsserver som innehåller tjänsten för biljettbeviljande (TGS) och autentiseringstjänsten (AS). Termerna KDC, AS och TGS används omväxlande. I Microsoft-miljöer är en Active Directory-domänkontrollant en KDC.
Sfär (eller Kerberos-sfär) En sfär (eller Kerberos-sfär) kan använda valfri ASCII-sträng. Standarden är att använda domännamnet i versaler; till exempel blir contoso.com sfären CONTOSO.COM. Kerberos-sfärer konfigureras vanligtvis i krb5.conf-filer på klienter och servrar.

Administrativt måste varje principal@REALM vara unik. För att undvika en enskild felpunkt kan varje sfär ha flera KDC:er som delar samma databas (huvudnamn och lösenord) och har samma KDC-huvudnycklar. Microsoft Windows Active Directory gör detta internt genom Active Directory-replikering, vilket sker var 15:e minut som standard.
Huvudkonto Termen huvudnamn refererar till varje entitet i en Kerberos-databas. Användare, datorer och tjänster är alla tilldelade huvudnamn för Kerberos-autentisering. Varje huvudnamn måste vara unikt i Kerberos-databasen och definieras av dess unika namn. Ett huvudnamn kan vara ett UPN (User Principal Name) eller ett SPN (Service Principal Name).

Ett huvudnamn har tre delar:
  • Primär – Den primära delen kan vara en användare eller en tjänst, till exempel NFS-tjänsten. Det kan också vara den särskilda tjänsten "värd", vilket innebär att tjänstens huvudnamn har konfigurerats för att tillhandahålla flera olika nätverkstjänster.
  • Instans – Den här delen är valfri för en användare. En användare kan ha mer än ett huvudnamn, men varje huvudnamn måste vara unikt i KDC. Fred kan till exempel ha ett huvudnamn som är till för daglig användning (fred@contoso.com) och ett huvudnamn som tillåter privilegierad användning, till exempel ett sysadmin-konto (admin-fred@contoso.com). Instansen krävs för tjänstens huvudnamn och anger det fullständigt kvalificerade domännamnet (FQDN) för värden som tillhandahåller tjänsten.
  • Sfär – En Kerberos-sfär är den uppsättning Kerberos-huvudnamn som är registrerade på en Kerberos-server. Enligt konventionen är sfärnamnet vanligtvis samma som DNS-namnet, men det konverteras till versaler. Versaler är inte obligatoriska, men konventionen ger enkel skillnad mellan DNS-namnet och sfärnamnet.
Biljetter Ett ärende är en tillfällig uppsättning autentiseringsuppgifter som verifierar identiteten för ett huvudnamn för en tjänst och innehåller sessionsnyckeln. En biljett kan vara en tjänst, en programbiljett eller en biljettbeviljande biljett (TGT). Biljetter utbyts mellan klient, server och KDC för Kerberos-autentisering.
Hemliga nycklar Kerberos använder ett symmetriskt nyckelsystem där den hemliga nyckeln används för både kryptering och dekryptering. Den hemliga nyckeln genereras från huvudnamnets Kerberos-lösenord med en enkelriktad hash-funktion. KDC lagrar lösenordet för varje huvudnamn och kan därför generera huvudkontots hemliga nyckel. För användare som begär en Kerberos-tjänst härleds den hemliga nyckeln vanligtvis från ett lösenord som presenteras för kinit-programmet. Tjänstens och daemons huvudnamn använder vanligtvis inte något lösenord. i stället lagras resultatet av envägshashfunktionen i en nyckelflik.
Nyckelflik En nyckelflik innehåller en lista över huvudnamn och deras hemliga nycklar. De hemliga nycklarna i en nyckelflik skapas ofta med hjälp av ett slumpmässigt lösenord och används främst för tjänst- eller daemonobjekt.

Information om nätverksport

I följande tabell beskrivs vilka nätverksportar som används för Kerberos-kommunikation. Om en nätverksbrandvägg är på plats bör dessa portar öppnas för att tillåta rätt Kerberos-funktioner. Du hittar mer information om dessa portar i IANA-tjänstens namn och transportprotokollets portnummerregister.

Tjänst Port
Kerberos 88 (TCP/UDP)
kpasswd 464 (TCP/UDP)
Lightweight Directory Access Protocol (LDAP) (för namnmappningar) 389 (TCP/UDP)
Administratörsserver 749 (TCP/UDP)
Global katalog (Windows-användarsökningar) 3268 (TCP/UDP)

Cachelagrade åldersvärden i Azure NetApp Files

I följande tabell visas hur lång tid en cachepost finns i en Azure NetApp Files-volym.

Cache Cacheålder
Serveranslutningar för inaktivt namn 60 sekunder
Tidsgräns för LDAP-fråga 10 sekund
Lokal DNS-värdpost för KDC TTL 24 timmar
Kerberos-biljettålder Anges av KDC* och/eller klient

* Standardvärdet är 10 timmar för Windows Active Directory-KDCs
Användarautentiseringsuppgifter 24 timmar
Kerberos-tidsförskjutning 5 minuter

Krav för korrekt fungerande Kerberos-miljöer i Azure NetApp Files

Kerberos-autentisering är starkt beroende av externa tjänster för korrekt funktionalitet. I Microsoft Active Directory kombineras de flesta av dessa tjänster till en enda server i många fall. Till exempel kan en Active Directory-domänkontrollant betjäna följande Kerberos-beroenden:

  • Tidssynkroniseringstjänster
  • DNS
  • Kerberos-nyckeldistribution
  • Lösenordstjänster/enkel inloggning
  • Identitetstjänster (till exempel LDAP)

När du använder inbyggd Microsoft Active Directory (den enda KDC-typ som Azure NetApp Files stöder för närvarande) täcks de flesta externa beroendena för Kerberos i Azure NetApp Files, till exempel DNS-, KDC- och lösenordstjänster. I vissa fall kan nödvändiga tjänster finnas utanför Active Directory-domänen (till exempel DNS). I sådana fall är det viktigt att se till att de nödvändiga tjänsterna är korrekt konfigurerade.

Azure NetApp Files har specifika beroenden för korrekt fungerande NFS Kerberos. Fortsätt läsa för mer information.

Tidssynkroniseringstjänster

Tidssynkroniseringstjänster är obligatoriska när du använder Kerberos för autentisering, eftersom Kerberos-biljettmekanismerna är beroende av tidsförskjutningar mellan klienten och servern inom ett standardintervall på 5 minuter. Om tidsinställningarna på klienten eller servern överskrider det femminutersintervallet misslyckas Kerberos-autentiseringen med ett tidsförskjutningsfel (KRB_AP_ERR_SKEW) och åtkomst nekas till NAS-resursen. Den här tidsgränsen är en säkerhetsfunktion som hjälper till att förhindra "reprisattacker", där en angripare kan fånga upp meddelanden mellan KDC och klienten och sedan spela upp dessa meddelanden vid ett senare tillfälle för att personifiera en autentiserad användare. Tidsförskjutningsgränser hjälper till att minimera risken för dessa typer av attacker.

Viktiga överväganden för problem med tidssynkronisering:

Mer information finns i Maximal tolerans för synkronisering av datorklocka

Domännamnssystem (DNS)

Domännamnssystem (DNS) är obligatoriska för Kerberos som en säkerhetsfunktion. Värdnamnsmatchning används för att formulera Kerberos-tjänstens huvudnamn som används för autentisering. I den här processen används framåtsökningar för värdnamn (A/AAAA-poster) för att ansluta till resurser som utnyttjar Kerberos-autentisering. Den framåtriktade sökningen används sedan för att formulera tjänstens huvudnamn (SPN) som används i Kerberos-autentiseringsbegäran. Om det inte går att hitta ett befintligt SPN i KDC misslyckas Kerberos-autentiseringen.

I Windows SMB-miljöer kan en autentiseringsmetod för säkerhetskopiering provas (till exempel NTLM). Men i många fall är NTLM inaktiverat av säkerhetsskäl, vilket skulle orsaka ett åtkomstfel till resursen när Kerberos-autentiseringen misslyckas. Windows-loggboken loggar ofta rotorsaken till felen (till exempel duplicerade/saknade SPN:er, DNS-sökningsfel, NTLM-fel osv.).

Förutom SPN-matchning används DNS kraftigt för att matcha värdnamn och IP-adresser för domäntjänster, till exempel LDAP, Kerberos KDCs osv. via SRV-poster. Mer detaljerad information om DNS i Azure NetApp Files (inklusive vilka SRV-poster som krävs) finns i Om DNS i Azure NetApp Files.

Kommentar

Om en IP-adress används för Kerberos-åtkomst beror beteendet på nas-protokollet (NFS eller SMB) som används. Mer information finns i IP-adresser för åtkomst med Kerberos.

LDAP

Lightweight Directory Access Protocol (LDAP) använder serverdelsidentitetsdatabaser för att tillhandahålla en enhetlig namntjänstkälla för NAS-klienter och -servrar så att alla deltagande enheter är överens om användarens äkthet, gruppmedlemskap och numeriska ID:n, som sedan används för filbehörigheter.

För Kerberos lagras användar- och tjänsthuvudnamn med posterna i LDAP-databaserna som attribut på huvudkontona. Windows Active Directory stöder detta som standard. I vissa fall (till exempel när du skapar alias eller tjänstens huvudnamn) kräver användare och datorer tillägg eller ändring av tjänstens huvudnamn. Du kan uppfylla detta krav med hjälp av Active Directory - användare och datorer Microsoft Management Console (MMC) eller med PowerShell. Mer information om hur du hanterar namn på tjänstens huvudnamn finns i Hantera tjänstens huvudnamn.

Förutom tjänstens huvudnamn och numeriska ID:n för Kerberos-autentisering kan LDAP också användas för UNIX-användar- och gruppidentiteter, som används för namnmappning av identiteter i Azure NetApp Files, samt inledande autentisering för NFS Kerberos-monteringar via en SPN –> UNIX-användarnamnmappning. Mer information finns i Så här fungerar NFS Kerberos i Azure NetApp Files och LDAP:s roll med Kerberos i Azure NetApp Files.

Så här fungerar SMB Kerberos i Azure NetApp Files

SMB Kerberos fungerar separat från NFS Kerberos-tjänster, eftersom datorkontona som skapats för varje protokoll inte kan dela nyckelflikar på grund av risken för ändringar i nyckelversionsnumret (kvno) på en nyckelflik som påverkar den andra tjänsten. Som ett resultat av detta, liksom naturliga skillnader i NAS-protokollen, skiljer sig arbetsflödena för SMB-tjänster för Kerberos och NFS för Kerberos åt i vissa områden.

Inledande konfiguration av SMB-tjänster

SMB-tjänster i Azure NetApp Files konfigureras först genom att konfigurera en Active Directory-anslutning, som definierar flera viktiga delar för interaktion med domäntjänster, inklusive:

  • Primär DNS-server (krävs)
  • Sekundär DNS
  • Active Directory DNS-namn*
  • Active Directory-platsnamn (för DC-identifiering) (krävs)
  • SMB-serverprefixnamn
  • Organisationsenhet (där datorkonton ska lagras i Azure AD-domänen)
  • Aktivera/inaktivera AES-kryptering
  • Aktivera/inaktivera LDAP-signering
  • LDAP-konfiguration
  • SMB-kryptering till DC
  • Privilegierade användare
  • Autentiseringsuppgifter för användarnamn/lösenord för användare med organisationsenhetsbehörighet

Kommentar

Endast en Azure Active Directory-anslutning (AD) tillåts per konto. När Azure AD-anslutningen har skapats använder alla nya Azure NetApp Files SMB-volymer Azure AD-anslutningskonfigurationen.

SMB Kerberos-datorkonto

Ett datorkonto i Active Directory innehåller relevant information för användning i autentiseringsbegäranden, inklusive tjänstens huvudnamn (SPN). När du skapar en SMB-volym i Azure NetApp Files används Konfigurationen av Active Directory-anslutningar för interaktion när du skapar ett datorkonto för att ge säker åtkomst till en SMB-resurs via Kerberos-autentisering (eller NTLM, om den är aktiverad).

Nya datorkonton skapas när en Azure NetApp Files SMB-volym etableras på en specifik serverdelsresurs i tjänsten. Följande visar olika scenarier där ett SMB-datorkonto kan skapas eller återanvändas i Volymkonfigurationer för Azure NetApp Files.

Scenario Result
Första nya SMB-volymen Nytt SMB-datorkonto/DNS-namn
Efterföljande SMB-volymer som skapats i kort följd från den första SMB-volymen Återanvänd SMB-datorkonto/DNS-namn (i de flesta fall).
Efterföljande SMB-volymer som skapats mycket senare än den första SMB-volymen Tjänsten avgör om det behövs ett nytt datorkonto. Det är möjligt att flera datorkonton kan skapas, vilket skapar flera IP-adressslutpunkter.
Första volym med dubbla protokoll Nytt SMB-datorkonto/DNS-namn
Efterföljande volymer med dubbla protokoll som skapats i kort följd från den första volymen med dubbla protokoll Återanvända SMB-datorkonto/DNS-namn (i de flesta fall)
Efterföljande volymer med dubbla protokoll som skapats mycket senare än den första volymen med dubbla protokoll Tjänsten avgör om ett nytt datorkonto behövs. Det är möjligt att flera datorkonton kan skapas, vilket skapar flera IP-adressslutpunkter
Första SMB-volymen som skapats efter volym med dubbla protokoll Nytt SMB-datorkonto/DNS-namn
Första volym med dubbla protokoll som skapats efter SMB-volymen Nytt SMB-datorkonto/DNS-namn

SMB-datorkontot som skapats för volymen Azure NetApp Files SMB (eller dubbla protokoll) använder en namngivningskonvention som följer det maximala 15 tecken som tillämpas av Active Directory. Namnet använder strukturen för [SMB Server-prefixet som anges i Azure AD-anslutningskonfigurationen]-[unik numerisk identifierare].

Om du till exempel har konfigurerat dina Azure AD-anslutningar för att använda SMB-serverprefixet "AZURE" liknar SMB-datorkontot som Azure NetApp Files skapar "AZURE-7806". Samma namn används i UNC-sökvägen för SMB-resursen (till exempel \AZURE-7806) och är det namn som dynamiska DNS-tjänster använder för att skapa A/AAAA-posten.

Kommentar

Eftersom ett namn som "AZURE-7806" kan vara svårt att komma ihåg är det fördelaktigt att skapa en CNAME-post som ett DNS-alias för Azure NetApp Files-volymer. Mer information finns i Skapa SMB-serveralias.

Diagram över flera datorkonton/DNS-poster i Azure NetApp Files.

I vissa fall, när du skapar flera SMB- och/eller dubbla protokollvolymer, kan konfigurationen sluta med flera olika SMB-datorkonton och DNS-namn.

Om ett enda namnområde för användaråtkomst mellan volymerna önskas kan detta innebära en utmaning i konfigurationen, eftersom ett enda CNAME-alias bara kan peka på en enda A/AAAA-värdpost, medan användning av flera identiska A/AAAA-postalias kan leda till oförutsägbar dataåtkomst vid åtkomst till volymer mellan olika SMB-datorkonton. eftersom det inte finns någon garanti för att slutpunkten som klienten väljer i DNS-sökningen innehåller den förväntade volymen på grund av resursallokeringstypen för valet av DNS-post i dessa konfigurationer.

För att åtgärda den här begränsningen kan Azure NetApp Files-volymer delta som mål i en DFS-konfiguration (Microsoft Distributed File System), vilket kan ge ett sätt att associera flera SMB-volymer med en enda startpunkt för namnområdet.

Diagram över ett distribuerat filsystem i Azure NetApp Files.

Arbetsflöde för att skapa SMB Kerberos SPN

Följande diagram visar hur ett SMB Kerberos SPN skapas när en Azure NetApp Files SMB- eller dubbelprotokollvolym skapas. SMB-SPN:er är associerade med SMB-datorkontoobjekt i domänen. SPN kan visas och hanteras via egenskaperna för datorkontot med hjälp av attributredigeraren i vyn Avancerat.

Skärmbild av Azure-SMB-egenskaper.

Du kan också visa och hantera egenskaper med setspn kommandot .

Skärmbild av kommandot setpn.

Den här processen följer samma steg som när en vanlig Windows-klient ansluter till en domän (DNS, LDAP, Kerberos, RPC-frågor över namngivna pipes).

Diagram över Kerberos-datorkonto.

I de flesta fall är det inte nödvändigt att känna till detaljerade steg på djupet för dagliga administrationsuppgifter, men det är användbart när du felsöker eventuella fel när du försöker skapa en SMB-volym i Azure NetApp Files.

Detaljerade steg

Detaljerad information om hur ett SMB-datorkonto skapas i Azure NetApp Files finns i listan.

  • DNS-sökning utförs med hjälp av DNS-konfigurationen för SRV-posten för en Kerberos KDC. Azure NetApp Files använder följande SRV-poster i sina begäranden.

    • _kerberos._tcp.dc._msdcs.CONTOSO.COM
    • _kerberos._tcp.CONTOSO.COM (om föregående fråga inte returnerar några resultat)

  • DNS-sökning utförs med hjälp av värdnamnen som returneras i SRV-frågan för A/AAAA-posterna för KDC:erna.

    • En LDAP-ping (LDAP-bindning och RootDSE-fråga ) utförs för att söka efter tillgängliga äldre NetLogon-servrar med hjälp av frågan (&(DnsDomain=CONTOSO.COM)(NtVer=0x00000016)) med ett attributfilter för NetLogon. Nyare Versioner av Windows-domänkontrollanter (större än 2008) har inte det NtVer aktuella värdet .

  • En DNS-fråga utförs av Azure NetApp Files för att hitta LDAP-servrarna i domänen med hjälp av följande SRV-poster:

    • _ldap._tcp.CONTOSO.COM
    • _kerberos._tcp.CONTOSO.COM

    Kommentar

    Dessa frågor inträffar flera gånger i samma anrop över olika delar av processen. DNS-problem kan skapa långsamhet i dessa anrop eller, med tidsgränser, fullständiga fel. – Om frågorna inte hittar en post eller om posterna som hittas inte kan kontaktas misslyckas SMB-volymskapandet. – Om DNS-frågorna lyckas bearbetas nästa steg.

  • ICMP (ping) skickas för att kontrollera att IP-adresserna som returneras från DNS kan nås.

  • Om ping blockeras i nätverket av brandväggsprinciper misslyckas ICMP-begäran. I stället används LDAP-pingar.

  • En annan LDAP-ping utförs för att söka efter tillgängliga äldre NetLogon-servrar med hjälp av frågan (&(&(DnsDomain=CONTOSO.COM)(Host=KDChostname.contoso.com))(NtVer=0x00000006)) med attributfiltret NetLogon. Nyare Windows-domänkontrollantversioner (större än 2008) har inte NtVer-värdet närvarande.

  • En AS-REQ-autentisering skickas från Azure NetApp Files-tjänsten med hjälp av användarnamnet som konfigurerats med Active Directory-anslutningen.

  • Domänkontrollanten svarar med KRB5KDC_ERR_PREAUTH_REQUIRED, som ber tjänsten att skicka lösenordet för användaren på ett säkert sätt.

  • En andra AS-REQ skickas med de förautentiseringsdata som behövs för att autentisera med KDC för åtkomst för att fortsätta med skapandet av datorkontot. Om det lyckas skickas en biljettbeviljande biljett (TGT) till tjänsten.

  • Om det lyckas skickas en TGS-REQ av tjänsten för att begära CIFS-tjänstbiljetten (cifs/kdc.contoso.com) från KDC med hjälp av TGT som tagits emot i AS-REP.

  • En ny LDAP-bindning med hjälp av CIFS-tjänstbiljetten utförs. Frågor skickas från Azure NetApp Files:

    • RootDSE-bassökning för ConfigurationNamingContext DN för domänen
    • OneLevel-sökning av CN=partitioner i DN som hämtats för ConfigurationNamingContext med hjälp av filtret (&(&(objectClass=crossRef)(nETBIOSName=*))(dnsRoot=CONTOSO.COM)) för attributet NETBIOSname.
    • En bassökning med filtret (|(objectClass=organizationalUnit)(objectClass=container)) utförs på den organisationsenhet som anges i konfigurationen för Active Directory-anslutningar. Om det är ospecificerat används standardvärdet OU=Computers . Detta verifierar att containern finns.
    • En underträdssökning utförs på domänens grundläggande DN med hjälp av filtret (sAMAccountName=ANF-XXXX$) för att kontrollera om kontot redan finns.
      • Om kontot finns återanvänds det.
    • Om kontot inte finns skapas det, förutsatt att användaren har behörighet att skapa och ändra objekt i containern med hjälp av ett addRequest LDAP-kommando. Följande LDAP-attribut anges för kontot:
    Attribut Värde
    CN ANF-XXXX
    sAMAccountName ANF-XXXX$
    objectClass
    • Främsta
    • Person
    • Organisationsperson
    • User
    • Dator
    servicePrincipalName
    • VÄRD/ANF-XXXX
    • VÄRD/anf-xxxx.contoso.com
    • CIFS/anf-xxxx.contoso.com
    userAccountControl 4096
    operatingSystem NetApp-version
    dnsHostName ANF-XXXX.CONTOSO.COM
    • Om felet addRequest misslyckas misslyckas volymskapandet. En addRequest kan misslyckas på grund av felaktiga behörigheter för containerobjektet.
    • Om lyckas addRequest utförs en LDAP-sökning med filtret (sAMAccountName=ANF-XXXX$) för att hämta attributet objectSid.
    • En SMB2-konversation med "Negotiate Protocol" utförs för att hämta Kerberos mechTypes som stöds från KDC.
    • En SMB2 "Sessionskonfiguration" med HJÄLP av CIFS SPN och högst stöd mechType och en "Trädanslutning" till IPC$ utförs.
    • En SMB2-fil lsarpc skapas i IPC$-resursen.
    • En bindning till DCERPC utförs. Filen lsarpc skrivs och läs sedan.
    • Följande LSA-begäranden utförs sedan:

  • En TGS-REQ med TGT utförs för att hämta biljetten för det kadmin/changepw SPN som är associerat med krbtgt kontot.

  • En KPASSWD-begäran görs från tjänsten till KDC för att ändra lösenordet för datorkontot.

  • En LDAP-fråga utförs med filtret (sAMAccountName=ANF-XXXX) för attributen distinguishedName och isCriticalSystemObject.

  • Om kontots isCriticalSystemObject är falskt (standardvärdet) används det hämtade DN:et för att formulera ett modifyRequest till attributet msDs-SupportedEncryptionTypes. Det här värdet är inställt på 30, vilket motsvarar DES_CBC_MD5 (2) + RC4 (4) + AES 128 (8) + AES 256 (16).

  • En andra "Negotiate protocol"/Kerberos ticket exchange/"Session setup"/"Tree connect" till IPC$ utförs. SMB-serverns datorkonto (ANF-XXXX$) fungerar som Kerberos-huvudnamn.

  • NetLogon, NetrServer ReqChallenge/Authenticate2-kommunikationen har slutförts.

  • Ett tredje "Negotiate protocol:/Kerberos ticket exchange/"Session setup"/"Tree connect" till IPC$ utförs. SMB-serverns datorkonto (ANF-XXXX$) används som Kerberos-huvudnamn.

  • Både lsarpc och NetLogon-anslutningar görs som en slutlig kontroll av kontot.

Arbetsflöde för SMB-delningsanslutning (Kerberos)

När en Azure NetApp Files-volym monteras med Kerberos används ett Kerberos-biljettutbyte under begäranden om konfiguration av flera sessioner för att ge säker åtkomst till resursen. I de flesta fall är det inte nödvändigt att känna till detaljerade steg på djupet för dagliga administrationsuppgifter. Den här kunskapen är användbar vid felsökning av fel vid försök att komma åt en SMB-volym i Azure NetApp Files.

Diagram över arbetsflödet för SMB-delningsanslutning.

För steg som beskriver hur SMB-resursen nås i Azure NetApp Files, expanderar du listan.
  • Klienten försöker komma åt en SMB-resurs med hjälp av UNC-sökvägen som visas i Azure NetApp Files. UNC-sökvägen innehåller som standard SMB-servernamnet (till exempel ANF-XXXX)
  • DNS efterfrågas för att mappa värdnamnet till en IP-adress
  • En inledande SMB2-konversation med "Negotiate Protocol" äger rum
    • En begäran skickas från klienten för att identifiera vilka SMB-dialekter som stöds av servern och innehåller vad den begärande klienten stöder
    • Servern svarar med vad den stöder, inklusive:
      • Säkerhetsläge (signering eller inte)
      • SMB-version
      • Server-GUID
      • Funktioner som stöds (DFS, leasing, stor MTU, multichannel, beständiga referenser, katalogleasing, kryptering)
      • Maximal transaktionsstorlek
      • Maximal läs-/skrivstorlek
      • Säkerhetsblob (Kerberos eller NTLM)
  • En andra SMB2-konversation med "Negotiate Protocol" äger rum som "förauktorisering"/inloggning
    • Begäran från klienten omfattar:
      • Hash för förauktorisering
      • Säkerhetslägen som stöds (signering eller inte)
      • Funktioner som stöds (DFS, leasing, stor MTU, multichannel, beständiga referenser, katalogleasing, kryptering)
      • Klient-GUID
      • SMB-dialekter som stöds
    • Om förauktoriseringshashen godkänns svarar servern med:
      • Säkerhetsläge (signering eller inte)
      • Funktioner som stöds (DFS, leasing, stor MTU, multichannel, beständiga referenser, katalogleasing, kryptering)
      • Maximal transaktionsstorlek
      • Maximal läs-/skrivstorlek
      • Säkerhetsblob (Kerberos eller NTLM)
      • SMB-förautentiseringsintegritet och krypteringsfunktioner
  • Om protokollförhandlingen lyckas görs en begäran om sessionskonfiguration .
    • Installationsprogrammet använder förauktoriseringshashen från protokollförhandlingen.
    • Installationen informerar SMB-servern om vad den begärande klienten stöder, inklusive:
      • StructureSize
      • Sessionsbindningsflagga
      • Säkerhetsläge (signering aktiverat/obligatoriskt)
      • Funktioner
      • Kerberos-krypteringstyper som stöds
  • Ett "Sessionskonfigurationssvar" skickas.
    • SMB-krediter beviljas.
    • Sessions-ID upprättas.
    • Sessionsflaggor anges (gäst, null, kryptera).
    • Kerberos-krypteringstyp har definierats.
  • En trädanslutningsbegäran skickas av klienten för anslutning till SMB-resursen.
    • Dela flaggor/funktioner skickas från servern, tillsammans med resursbehörigheter.
  • Kommandot ioctlFSCTL_QUERY_NETWORK_INTERFACE_INFO skickas för att hämta IP-adressen för SMB-servern.
  • SMB-servern i Azure NetApp Files rapporterar tillbaka med nätverksinformationen, inklusive: * IP-adress * Gränssnittsfunktion (RSS på eller av) * RSS-köantal * Länkhastighet
  • En trädanslutningsbegäran skickas av klienten för anslutning till den administrativa IPC$-resursen.
    • IPC$-resursen är en resurs som delar de namngivna pipes som är viktiga för kommunikation mellan program. IPC$-resursen används under fjärradministration av en dator och när du visar en dators delade resurser. Du kan inte ändra resursinställningar, resursegenskaper eller ACL:er för IPC$-resursen. Du kan inte heller byta namn på eller ta bort IPC$-resursen.
  • En DCERPC-bindning görs till srvsvc filen för att upprätta en säker anslutning.
    • Filen skrivs till med den tidigare hämtade informationen.
  • En Kerberos TGS-REQ utfärdas av Windows-klienten till KDC för att hämta en tjänstbiljett (ST) för SMB-tjänsten.
  • Ett NetShareGetInfo kommando körs av SMB-klienten till servern och ett svar skickas.
  • SMB-tjänstbiljetten hämtas från KDC.
  • Azure NetApp Files försöker mappa Windows-användaren som begär åtkomst till resursen till en giltig UNIX-användare.
    • En Kerberos TGS-begäran görs med SMB-serverns Kerberos-autentiseringsuppgifter som lagras med SMB-serverns nyckelflik från den första SMB-servergenereringen som ska användas för en LDAP-serverbindning.
    • LDAP söks efter en UNIX-användare som mappas till den SMB-användare som begär resursåtkomst. Om det inte finns någon UNIX-användare i LDAP används unix-standardanvändaren pcuser av Azure NetApp Files för namnmappning (filer/mappar skrivna i volymer med dubbla protokoll använder den mappade UNIX-användaren som UNIX-ägare).
  • En annan förhandlingsprotokoll-/sessionsbegäran/trädanslutning utförs, den här gången med hjälp av SMB-serverns Kerberos SPN till Active Directory DC:s IPC$-resurs.
    • Ett namngivet rör upprättas till resursen srvsvcvia .
    • En NETLOGON-session upprättas för resursen och Windows-användaren autentiseras.
  • Om behörigheter tillåter det för användaren visar resursen de filer och mappar som finns i volymen.

Kommentar

Azure NetApp Files lägger till poster i Kerberos-kontextcachen för klienten. Dessa poster finns i cacheminnet under kerberos-biljettens livslängd (anges av KDC och styrs av Kerberos-principen.

Skapa SMB-serveralias

När Azure NetApp Files skapar en SMB-server med hjälp av en namngivningskonvention för [SMB Server-prefixet som anges i Azure AD-anslutningskonfigurationen]-[unik numerisk identifierare]. (Mer information om den unika numeriska identifieraren finns i SMB Kerberos-datorkonto). Den här formateringen innebär att SMB-servernamn inte konstrueras på ett användarvänligt sätt. Till exempel är namnet "SMB-7806" svårare att komma ihåg än något som liknar "AZURE-FILESHARE".

På grund av det här beteendet kanske administratörer vill skapa användarvänliga aliasnamn för Azure NetApp Files-volymer. Detta kräver att du pekar ett DNS-kanoniskt namn (CNAME) på den befintliga DNS A/AAAA-posten på servern.

När ett CNAME skapas och används i UNC-sökvägsbegäranden (till exempel \\AZURE-FILESHARE i stället \\SMB-7806för ) omdirigerar DNS CNAME-begäran (AZURE-FILESHARE.contoso.com) till rätt A/AAAA-post (SMB-7806.contoso.com), som används i Kerberos SPN-hämtningen (cifs/SMB-7806). Detta ger Kerberos åtkomst till SMB-resursen när du använder det aliaserade namnet.

Om en DNS A/AAAA-post skapas (till exempel AZURE-FILESHARE.contoso.com) och försöker användas som ett alias misslyckas Kerberos-begäranden. Felet är resultatet av att det konstruerade SPN som används för att autentisera till resursen (cifs/AZURE-FILESHARE) inte matchar vad Kerberos SPN är för SMB-servern (cifs/SMB-7806). Felet kan åtgärdas om ett annat SPN skapas och läggs till i SMB-serverdatorkontot (till exempel cifs/AZURE-FILESHARE).

SMB-serverfunktioner som stöds i Azure NetApp Files

När SMB-begäran om "förhandla protokoll" görs, efterfrågas Azure NetApp Files SMB-servern för stöd för specifika funktioner. I följande tabell visas de funktioner som efterfrågas och svaret som returneras från en Azure NetApp Files SMB-volym när en sessionsinstallation/trädanslutning utförs.

SMB-funktion Stöds av Azure NetApp Files?
DFS-mål Ja
Leasing Ja
Stor MTU Ja
SMB multi-channel Ja
SMB-beständiga referenser Ja
Katalogleasing Nej
SMB-kryptering Ja (om aktiverat)

Funktioner och egenskaper för SMB-resurser som stöds i Azure NetApp Files

Under SMB-resursåtkomst utförs en "trädanslutningsbegäran" och de SMB-resursfunktioner och egenskaper som stöds efterfrågas av klienten till Azure NetApp Files-servern. I följande tabell visas de resursfunktioner som efterfrågas och svaret som returneras från en Azure NetApp Files SMB-volym enligt en paketinsamling.

SMB-resursfunktion Stöds av Azure NetApp Files?
Kontinuerligt tillgänglig (CA) Ja, för specifika arbetsbelastningar* (om aktiverat)
Utskalning Nej
Kluster Nej
Asymmetrisk Nej
Omdirigera till ägare Nej

* Se Aktivera kontinuerlig tillgänglighet på befintliga SMB-volymer för arbetsbelastningar som stöds.

I följande tabell visas de resursegenskaper som efterfrågas och svaret som returneras från en Azure NetApp Files SMB-volym.

SMB-resursfunktion Stöds av Azure NetApp Files?
DFS-mål Ja
DFS-rot Nej
Begränsa exklusiva öppningar Nej
Tvingad delad borttagning Nej
Tillåt cachelagring av namnområde Nej
Åtkomstbaserad uppräkning Ja (om aktiverat)
Force level II oplock Nej
Aktivera hash V1 Nej
Aktivera hash v2 Nej
Kryptering krävs Ja (om aktiverat)
Identitetsmoting Nej
Komprimerad I/O Nej
Isolerad transport Nej

Så här fungerar NFS Kerberos i Azure NetApp Files

NFS Kerberos fungerar separat från SMB-tjänster, eftersom datorkonton som skapats för varje protokoll inte kan dela nyckelflikar på grund av risken för ändringar i nyckelversionsnumret (kvno) på en nyckelflik som påverkar den andra tjänsten. Därför skiljer sig arbetsflödena för SMB-tjänster för Kerberos och NFS för Kerberos åt i vissa områden.

Inledande konfiguration av Kerberos-sfär

NFS Kerberos-sfären konfigureras när Kerberos-sfärinformationen fylls i i Azure NetApp Files-portalen under sidan Active Directory-anslutningar.

Skärmbild av Kerberos-sfärkonfiguration.

Azure AD-servernamnet och KDC IP används för att ansluta till Azure AD KDC-tjänsterna när det första datorkontot skapas. Azure NetApp Files-tjänsten utnyttjar den befintliga domäninformationen för att fylla i resten av sfärkonfigurationen. Till exempel:

Kerberos Realm: CONTOSO.COM
KDC Vendor: Microsoft
KDC IP Address: x.x.x.x 
KDC Port: 88
Clock Skew: 5
Active Directory Server Name: dc1.contoso.com
Active Directory Server IP Address: x.x.x.x
Comment: -
Admin Server IP Address: x.x.x.x
Admin Server Port: 749
Password Server IP Address: x.x.x.x
Password Server Port: 464
Permitted Encryption Types: aes-256
-    Configured by Azure NetApp Files administrator in the portal
-    Automatically configured by the service using Active Directory connection information/system defaults

När NFS Kerberos-sfären har konfigurerats läggs en lokal värdpost till i tjänsten med KDC som anges i konfigurationen. När sfären ändras ändras även posten lokala värdar i tjänsten.

Diagram över Kerberos-sfärkonfiguration.

Den här lokala värdposten fungerar som en "sista utväg" om ett KDC-avbrott inträffar på KDC som anges i sfärkonfigurationen och det inte går att köra frågor mot redundanta KDC:er via DNS.

Kommentar

Om KDC i Kerberos-sfären behöver tas ned för underhåll (till exempel för uppgraderingar eller avaktivering av en server) rekommenderar vi att du konfigurerar sfären så att den använder en KDC som inte genomgår underhåll för att undvika avbrott.

Första skapandet av datorkonto/SPN

När Kerberos är aktiverat på en Azure NetApp Files-volym skapas ett datorkonto/huvudnamn med namnet NFS-{SMB-server-name} i domänen i den angivna organisationsenheten i Active Directory-anslutningar (organisationsenhet). Datorkontonamn trunkeras efter 15 tecken.

Kommentar

När du lägger till Linux-klienter med värdnamn som är större än 15 tecken i en Active Directory-domän trunkeras deras Kerberos-datorkonto-SPN:er. Till exempel har en Linux-klient med namnet MORE-THAN-FIFTEEN på ett datorkontonamn MORE-THAN-FIFT$, som blir ett SPN för MORE-THAN-FIFT$@CONTOSO.COM. När DNS söker efter ett klientvärdnamn hittar den det längre namnet och försöker använda det namnet i en SPN-begäran ( MORE-THAN-FIFTEEN@CONTOSO.COM). Eftersom spn inte finns försöker klienten använda nästa SPN på nyckelfliken i begäran (vanligtvis värd/värdnamn). Endast datorkontonamnet SPN fungerar internt med Azure NetApp Files NFS Kerberos. Därför bör du se till att Linux-klientens värdnamn som används för NFS Kerberos med Azure NetApp Files inte överskrider 15 tecken. Om du vill använda värd-/värdnamnet SPN kan du också konfigurera en UNIX-användare i LDAP med användarnamnet "värd". Den här konfigurationen tillhandahåller en krb-unix-namnmappning för SPN.

I Azure NetApp Files läggs Kerberos-nyckelblock (eller nyckelfliksposter) till i tjänsten med NFS-tjänsten SPN (nfs/nfs-server-name.contoso.com@CONTOSO.COM). Flera poster skapas: en för varje krypteringstyp som stöds. I Azure NetApp Files stöds endast krypteringstypen AES-256 för NFS Kerberos.

I de flesta fall är det inte nödvändigt att känna till de här stegen på djupet för dagliga administrationsuppgifter, men är användbara för att felsöka eventuella fel när du försöker skapa en NFS Kerberos-volym i Azure NetApp Files.

Arbetsflöde för skapande av NFS Kerberos SPN

Följande diagram visar hur ett NFS SPN skapas när en Azure NetApp Files NFS- eller dubbelprotokollvolym skapas med Kerberos aktiverat. I de flesta fall är det inte nödvändigt att känna till detaljerade steg på djupet för dagliga administrationsuppgifter, men är användbara för att felsöka eventuella fel när du försöker skapa en SMB-volym i Azure NetApp Files.

Diagram över arbetsflödet för skapande av NFS Kerberos SPN.

Detaljerade steg om hur ett NFS Kerberos SPN skapas med Azure NetApp Files finns i listan.
  • Administratörsautentiseringsuppgifter som skickas till KDC som anges i sfärkonfigurationen med det användarnamn som anges för användning i Active Directory-anslutningen – användaren måste ha behörighet att visa/skapa objekt i den angivna organisationsenheten.
  • DNS-servrarna som anges i Azure NetApp Files Active Directory-anslutningskonfigurationen efterfrågas av Azure NetApp Files för Kerberos-tjänstposter (SRV) i följande format:
    • URI-fråga för _kerberos.CONTOSO.COM
    • SRV-fråga för _kerberos-master._udp. CONTOSO.COM
    • SRV-fråga för _kerberos-master._tcp. CONTOSO.COM

Kommentar

Dessa frågor inträffar flera gånger i samma anrop över olika delar av processen. DNS-problem kan skapa långsamhet i dessa anrop eller fullständiga fel. Dessa poster verkar inte finnas som standard i Active Directory-distributioner och måste skapas manuellt.

  • Om frågorna inte hittar en post eller om posterna som hittas inte kan kontaktas eller användas som huvud-KDC, används en A-postfråga med sfärnamnet som finns i NFS Kerberos-sfärkonfigurationen som en sista utväg för att ansluta till KDC via port 88.
  • Under konfigurationen av NFS Kerberos läggs en statisk värdpost för den angivna KDC till i den lokala värdfilen som en säkerhetskopia om DNS-sökningar misslyckas.
  • Om det finns en cachelagrad DNS-post för sfären används den. Annars används den lokala filposten. Cachelagrade DNS-poster live så länge TTL (Time to Live) har konfigurerats för DNS-posten. Den lokala filposten konfigureras med en TTL på 86 400 sekunder (24 timmar). NS-växelkonfigurationen för värdsökningar i Azure NetApp Files använder filer först och sedan DNS. När den lokala posten hittas utförs inga fler frågor.
  • Det SMB-datorkonto som skapades när Active Directory-anslutningen skapades används som autentiseringsuppgifter för en Active Directory LDAP-bindning med SASL/GSS via port 389 för att söka efter befintliga poster i önskat SPN- eller datorkontonamn. Om SPN- eller datorkontonamnet redan finns skickas ett fel. Om SPN inte finns i LDAP-frågan utförs skapandet av datorkontot i den avsedda organisationsenheten med poster för följande attribut som angetts av Azure NetApp Files:
    • cn (NFS-MACHINE)
    • sAMAccountName (NFS-MACHINE$)
    • objectClass (topp, person, organisationPerson, användare, dator)
    • servicePrincipalName (värd/NFS-MACHINE, värd/NFS-MACHINE. CONTOSO.COM, nfs/NFS-MACHINE, nfs/NFS-MACHINE. CONTOSO.COM)
    • userAccountControl (4096)
    • msDs-SupportedEncryptionTypes (AES-256_CTS_HMAC_SHA1_96)
    • dnsHostName (NFS-MACHINE.CONTOSO.COM)
  • Lösenordet för NFS kerberos-datorkontot har angetts för NFS-MACHINE-kontot via port 464.
  • Kerberos-nyckelblock (nyckelflikar) för NFS SPN sparas i Azure NetApp Files-tjänsten.
  • En regel för mappning av statiska namn skapas i Azure NetApp Files-tjänsten för att säkerställa att rotanvändaren för varje NFS Kerberos-klient mappas till rot när Kerberos används.
  • En krb5.conf-fil läggs till i tjänstens interna system med NFS-sfärinformationen.

NFS Kerberos-monteringar

När en Azure NetApp Files-volym monteras med Kerberos-säkerhetssmak över NFS utförs följande arbetsflöde. Ett mer detaljerat konto för Kerberos finns i Kerberos Network Authentication Service (V5) Synopsis.

Diagram över NFS Kerberos-monteringsarbetsflöde.

Detaljerad information om hur en NFS Kerberos-volym monteras med Azure NetApp Files finns i listan.
  • Klienten försöker montera en NFS-exportsökväg i Azure NetApp Files och anger säkerhetssmaken -okrb5 (eller krb5i eller krb5p).
  • DNS används för att formulera en begäran om ett NFS-tjänsthuvudnamn till Azure NetApp Files via antingen A/AAAA-post eller PTR (beroende på hur monteringskommandot utfärdades).
  • Klienten hämtar en TGT från KDC via ett AS-REQ-anrop med klienthuvudnamnet som finns i klientens nyckelflik.
  • Exportsökvägen är markerad för att säkerställa att den finns i filsystemet.
  • Exportprincipregeln kontrolleras för att säkerställa att Kerberos-åtkomst tillåts till exportsökvägen.<
  • NFS-tjänstbiljetten begärs från KDC av klienten via ett AP-REQ-anrop. Azure NetApp Files kontrollerar nyckelfliken för en giltig post med en giltig krypteringstyp med hjälp av TGT från klienten som hämtats från KDC.
  • Om TGT är giltig utfärdas ett serviceärende.
  • Klient-SPN (till exempel CLIENT$@CONTOSO.COM) mappas till rotanvändaren via namnmappningsregeln i Azure NetApp Files.
  • Rotanvändaren efterfrågas i namntjänstdatabaserna (filer och LDAP) för existens-/gruppmedlemskap.
  • En LDAP-bindning med SMB-serverdatorkontot utförs för att tillåta en LDAP-sökning efter rotanvändaren.
  • Eftersom roten alltid finns i Azure NetApp Files bör detta inte orsaka några problem, men LDAP-frågor för roten kan misslyckas. Dessa fel kan ignoreras.
  • NFS-tjänstbiljetten returneras till klienten och monteringen lyckas. Rotanvändaren har rotåtkomst till Kerberos-monteringen via klientens huvudnamn för datorkontot (kan visas med klist -e kommandot från klienten).
  • Azure NetApp Files lägger till poster i Kerberos-kontextcachen för klienten. Dessa poster finns i cacheminnet under hela kerberos-biljettens livslängd som angetts av KDC och styrs av Kerberos-principen.
  • NFSv4.1 skickar regelbundet (var 20:e sekund) uppdateringar av Kerberos-biljettuppdateringar som "keepalives".

NFS Kerberos monterar åtkomst med användarens huvudnamn

När en Azure NetApp Files NFS Kerberos-montering nås av en användare (förutom rotanvändaren, som använder datorkontot SPN), utförs följande arbetsflöde.

Diagram över NFS Kerberos-monteringsåtkomst med användarens huvudnamn.

Detaljerad information om hur en NFS Kerberos-volym nås med en icke-root-användare med Azure NetApp Files finns i listan.
  • Användaren loggar in på KDC antingen med ett användarnamn/lösenordsutbyte eller via en nyckelfliksfil för att hämta en TGT via ett AS-REQ-anrop som ska användas för att samla in en tjänstbiljett från Azure NetApp Files-volymen.
  • Exportprincipregeln kontrolleras för att säkerställa att Kerberos-åtkomst tillåts till exportsökvägen för klientdatorn
  • Azure NetApp Files söker efter en cachelagrad NFS-tjänstbiljett. Om det inte finns någon begärs NFS-tjänstbiljetten via ett AP-REQ-anrop och tjänsten kontrollerar nyckelfliken efter en giltig post med en giltig krypteringstyp med hjälp av TGT från klienten som hämtats från KDC
  • Om TGT är giltig utfärdas ett serviceärende
  • Användarens huvudnamn (UPN) mappas via implicit mappning. Om UPN till exempel är user1@CONTOSO.COMfrågar tjänsten efter en UNIX-användare med namnet user1. Eftersom UNIX-användaren inte finns i den lokala fildatabasen i Azure NetApp Files används LDAP.
  • En LDAP-bindning med SMB-serverdatorkontot försöker tillåta en LDAP-sökning efter den mappade användaren. En DNS SRV-fråga görs för Kerberos DNS-poster (_kerberos och _kerberos-master). Om inga giltiga poster kan användas återgår konfigurationen till sfärkonfigurationen. Dessa KDC DNS SRV-frågor är inte webbplatsomfång.
  • LDAP SRV-poster efterfrågas för giltiga LDAP-servrar. Dessa är webbplatsomfattande.
  • Om användaren inte finns i LDAP eller om LDAP inte kan frågas (servern är nere, DNS-sökningen misslyckas, bindningen misslyckas, LDAP-sökningen överskrider tidsgränsen, användaren finns inte) misslyckas mappningen och åtkomst nekas.
  • Om användaren finns samlas gruppmedlemskap in.
  • Mappningen lyckas och en NFS-tjänstbiljett utfärdas till klienten (visas i klist -e kommandon). Åtkomst tillåts baserat på filbehörigheterna på exportsökvägen.

LDAP:s roll med Kerberos i Azure NetApp Files

Azure NetApp Files förlitar sig på LDAP för NFS Kerberos. NFS Kerberos i Azure NetApp Files kräver Kerberos för UNIX-namnmappningar för inkommande användar-SPN. Eftersom Azure NetApp Files inte stöder skapande av lokala UNIX-användare krävs LDAP för att utföra sökningar för UNIX-användare när en namnmappning begärs.

  • När en Azure AD-anslutning skapas används Active Directory-domännamnet för att ange processen för att söka efter LDAP-servrar.
  • När en LDAP-server behövs _ldap.domain.com används för SRV-sökning för LDAP-servrar.
  • När en lista över servrar har identifierats används den bästa tillgängliga servern (baserat på pingsvarstid) som LDAP-server för anslutning via port 389.
  • En LDAP-bindning görs med hjälp av SMB-datorkontot via GSS/Kerberos.
  • Om det inte finns någon cachelagrad anslutning eller Kerberos-autentiseringsuppgifter utfärdas en ny begäran om en Kerberos-biljett. Cachelagrade anslutningar för namnservrar i Azure NetApp Files live i 60 sekunder. Om den är inaktiv i mer än 60 sekunder rensas anslutningscachen.
  • DNS används för att hitta lämpliga Kerberos KDCs via SRV-poster.
  • Om inga KDC:er kan hittas via DNS-frågan används den KDC som anges i filen krb5.conf för SMB-tjänsterna.
    • Om KDC inte kan nås eller inte kan bearbeta Kerberos-begäran misslyckas LDAP-bindningen. Namnsökningen misslyckas också. Åtkomst nekas till monteringen eftersom ingen giltig autentisering ägde rum.
    • Om bindningen lyckas utförs en LDAP-fråga för användaren och dess autentiseringsuppgifter. Om söktiden överskrider 10 sekunder misslyckas sökningen.
  • Om sökningen hittar användaren lyckas mappningen och åtkomst beviljas via Kerberos (förutsatt att biljetten är giltig/inte har upphört att gälla).

IP-adresser för åtkomst med Kerberos

Som standard använder Kerberos-autentisering upplösningen värdnamn till IP-adress för att formulera det tjänsthuvudnamn (SPN) som används för att hämta Kerberos-biljetten. När till exempel en SMB-resurs nås med en unc-sökväg (Universal Naming Convention), till exempel \SMBVOLUME.CONTOSO.COM, utfärdas en DNS-begäran för det fullständigt kvalificerade domännamnet SMBVOLUME.CONTOSO.COM och IP-adressen för Azure NetApp Files-volymen hämtas. Om det inte finns någon DNS-post (eller om den aktuella posten skiljer sig från vad som begärs, till exempel med alias/CNAMEs), kan ett korrekt SPN inte hämtas och Kerberos-begäran misslyckas. Därför kan åtkomst till volymen inte tillåtas om återställningsautentiseringsmetoden (till exempel New Technology LAN Manager) är inaktiverad.

DNS-poster i Azure NetApp Files skapas automatiskt med dynamisk DNS och formuleras med SMB-serverns namn. För eventuella variationer/alias till det definierade namnet ska en manuell DNS CNAME-post skapas och pekas på den dynamiska DNS-posten. Mer information finns i Förstå DNS i Azure NetApp Files.

NFSv4.1 Kerberos fungerar på ett liknande sätt för SPN-hämtning, där DNS-sökningar är integrerade i autentiseringsprocessen och kan även användas för Kerberos-sfäridentifiering.

Om en IP-adress (i stället för ett värdnamn) används i en åtkomstbegäran till en Azure NetApp Files-volym fungerar en Kerberos-begäran annorlunda beroende på vilket protokoll som används.

SMB Kerberos-beteende med IP-adresser och DNS-namn

När du använder SMB försöker en begäran om en UNC-sökväg med en IP-adress (till exempel \\x.x.x.x) som standard använda NTLM för autentisering. I miljöer där NTLM inte tillåts av säkerhetsskäl kan en SMB-begäran som använder en IP-adress inte använda Kerberos eller NTLM för autentisering som standard. Därför nekas åtkomst till Azure NetApp Files-volymen. I senare Windows-versioner (från och med Windows 10 version 1507 och Windows Server 2016) kan Kerberos-klienter konfigureras för att stödja IPv4- och IPv6-värdnamn i SPN för att SMB-kommunikation ska lösa problemet.

NFSv4.1 Kerberos-beteende med IP-adresser och DNS-namn

När du använder NFSv4.1 använder en monteringsbegäran till en IP-adress med något av sec=[krb5/krb5i/krb5p] alternativen omvänd DNS-sökningar via PTR för att matcha en IP-adress till ett värdnamn. Värdnamnet används sedan för att formulera SPN för Kerberos-biljetthämtning. Om du använder NFSv4.1 med Kerberos bör du ha en A/AAAA- och PTR för Azure NetApp Files-volymen för att täcka både värdnamn och IP-adressåtkomst till monteringar. Azure NetApp Files skapar en dynamisk DNS A/AAAA-post. Om det finns en omvänd DNS-zon för det undernätet skapas även en PTR-post automatiskt. För avvikelser från standardkonventionerna för Värdnamn för Azure NetApp Files använder du CNAME-poster för DNS-alias.

Mer information finns i Förstå DNS i Azure NetApp Files