Delen via

Kerberos begrijpen in Azure NetApp Files

Kerberos is een verificatieprotocol dat gebruikmaakt van een geheime sleutel om de identiteit van principals te valideren. Geheime sleutels worden gegenereerd door het wachtwoord van een principal te nemen en te converteren naar een gehashte cryptografische sleutelindeling met behulp van een overeengekomen versleutelingsmethode door de client en server (zoals AES). Zie de sectie Kerberos-terminologie voor meer informatie over de termen die in dit document worden gebruikt.

Key Distribution Centers (KDCs) zoals Windows Active Directory onderhouden een database met Kerberos-principals en hun hash-wachtwoorden. In Kerberos is de geheime sleutel bewijs van een unieke identiteit. Daarom kan de KDC worden vertrouwd om elke principal te verifiëren bij een andere principal, zoals het verifiëren van een NFS-clientservice-principalnaam (SPN) naar een SPN van een NFS-server bij koppelen. Het kan ook worden vertrouwd om een gebruikersprincipaal te verifiëren bij een NFS-server SPN voor gebruikerstoegang tot een NAS-koppelpunt. Als extra beveiligingsmaatregel verzendt Kerberos geen duidelijke tekstwachtwoorden voor verificatie via de kabel.

Azure NetApp Files ondersteunt het gebruik van Kerberos om in-flight beveiliging te bieden voor zowel de SMB- als NFS-protocollen.

Ondersteunde versleutelingstypen

Azure NetApp Files ondersteunt NFS Kerberos met specifieke versleutelingstypen, afhankelijk van de bedrijfsmodus en de versie die u gebruikt.

Om ervoor te zorgen dat een client het juiste versleutelingstype gebruikt, kunt u de geldige versleutelingstypen beperken op de objectprincipal op de KDC (bijvoorbeeld het computeraccount) of in het handmatig gemaakte keytab-bestand van de client in plaats van globaal in het bestand /etc/krb5.conf, indien mogelijk, omdat het beheer van talloze clientkrb5.conf-bestanden een beheerhoofdpijn kan zijn. Het centraal beheren van Kerberos vanuit de KDC is schaalbaarder in grote bedrijfsomgevingen, is eenvoudiger te automatiseren en dwingt de client om sterkere versleutelingstypen te gebruiken wanneer ze worden ondersteund.

Notitie

Het is raadzaam om de optie allow_weak_crypto in te stellen op onwaar in het krb5.conf-bestand op clients. Deze instelling voorkomt minder veilig enctypes voor Kerberos-communicatie (zoals DES of 3DES).

In de volgende tabel ziet u de ondersteunde versleutelingstypen voor Kerberos (zowel SMB als NFS) voor Azure NetApp Files.

protocol Ondersteunde versleutelingstypen
MKB
  • RC4-HMAC
  • AES-128
  • AES-256
Network File System (NFS) AES-256

Ondersteunde NFS Kerberos-beveiligingsmodi

Naast het concept van versleutelingstypen zijn er ook niveaus van beveiliging en integriteitscontrole in Kerberos. Afhankelijk van de beveiligingsmodus die wordt gebruikt, helpen deze beveiligingsmodi man-in-the-middle-aanvallen te voorkomen door end-to-end-versleuteling voor NFS-verkeer aan te bieden.

In Azure NetApp Files worden deze beveiligingsmodi opgegeven voor de exportbeleidsregels die zijn ingesteld voor het volume voor NFS en gedefinieerd tijdens de eerste NFS-koppeling via de optie sec koppelen.

Bijvoorbeeld: # mount -o sec=krb5p

Notitie

Voor SMB Kerberos worden beveiligingsmodi voor Kerberos beheerd via SMB-versleutelingsinstellingen op de share, UNC-beveiliging en beleid voor SMB-ondertekening/verzegeling op de domeincontrollers.

De volgende beveiligingsmodi worden ondersteund door Azure NetApp Files voor gebruik met NFS Kerberos:

Beveiligingsmodus Beschrijving
krb5 Alleen verificatieversleuteling.

Maakt gebruik van Kerberos V5-naamreeksen en user principal names in plaats van lokale UNIX-gebruikers-id's (UID's) en groeps-id's (GID's) om gebruikers te verifiëren.
krb5i Verificatieversleuteling en versleutelde integriteitscontrole.

Maakt gebruik van Kerberos V5 voor gebruikersverificatie en voert ook integriteitscontrole van NFS-bewerkingen uit met behulp van beveiligde controlesommen om manipulatie van gegevens en man-in-the-middle-aanvallen te voorkomen.
krb5p Volledig NFS-gesprek versleuteld.

Maakt gebruik van Kerberos V5 voor verificatie en integriteitscontrole van gebruikers en versleutelt ook al het NFS-verkeer om te voorkomen dat pakketten worden gesniffd. Deze instelling is het veiligst, maar maakt ook de meeste overhead voor prestaties.

Kerberos-terminologie

In deze sectie wordt de belangrijkste terminologie gedefinieerd die wordt gebruikt bij het beschrijven van Kerberos-processen. Deze sectie is bedoeld om termen te verduidelijken die mogelijk niet bekend zijn bij opslagbeheerders.

Termijn Definitie
KDC (Key Distribution Center) De KDC is de verificatieserver die de service ticket-granting (TGS) en de verificatieservice (AS) bevat. De termen KDC, AS en TGS worden door elkaar gebruikt. In Microsoft-omgevingen is een Ad-domeincontroller (Active Directory) een KDC. Het wijzigen van KDC-waarden kan alleen worden bereikt door AD-instellingen te wijzigen.
Realm (of Kerberos-realm) Een realm (of Kerberos realm) kan elke ASCII-tekenreeks gebruiken. De standaardwaarde is het gebruik van de domeinnaam in hoofdletters; Contoso.com wordt bijvoorbeeld de realm CONTOSO.COM. Kerberos-realms worden meestal geconfigureerd in krb5.conf-bestanden op clients en servers.

Elke principal@REALM moet uniek zijn. Om een single point of failure te voorkomen, kan elke realm meerdere KDC's hebben die dezelfde database (principals en hun wachtwoorden) delen en dezelfde KDC-hoofdsleutels hebben. Microsoft Windows Active Directory doet dit systeemeigen door middel van Active Directory-replicatie, die standaard elke 15 minuten plaatsvindt.
Schoolleider De termenprincipal verwijst naar elke entiteit in een Kerberos-database. Gebruikers, computers en services zijn allemaal toegewezen principals voor Kerberos-verificatie. Elke principal moet uniek zijn binnen de Kerberos-database en wordt gedefinieerd door de DN-naam. Een principal kan een UPN (User Principal Name) of een SPN (Service Principal Name) zijn.

Een principal-naam heeft drie onderdelen:
  • Primair : het primaire onderdeel kan een gebruiker of een service zijn, zoals de NFS-service. Het kan ook de speciale service 'host' zijn, die aangeeft dat deze service-principal is ingesteld om meerdere verschillende netwerkservices te leveren.
  • Exemplaar : dit onderdeel is optioneel in het geval van een gebruiker. Een gebruiker kan meer dan één principal hebben, maar elke principal moet uniek zijn in de KDC. Fred kan bijvoorbeeld een principal hebben die dagelijks wordt gebruikt (fred@contoso.com) en een principal die bevoegd gebruik toestaat, zoals een sysadmin-account (admin-fred@contoso.com). Het exemplaar is vereist voor service-principals en wijst de FQDN (Fully Qualified Domain Name) van de host aan die de service levert.
  • Realm : een Kerberos-realm is de set Kerberos-principals die zijn geregistreerd in een Kerberos-server. Standaard is de realmnaam meestal hetzelfde als de DNS-naam, maar deze wordt geconverteerd naar hoofdletters. Hoofdletters zijn niet verplicht, maar de conventie biedt eenvoudig onderscheid tussen de DNS-naam en de realmnaam.
Kaartjes Een ticket is een tijdelijke set referenties waarmee de identiteit van een principal voor een service wordt geverifieerd en de sessiesleutel bevat. Een ticket kan een service, een aanvraagticket of een ticket voor het verlenen van tickets (TGT) zijn. Tickets worden uitgewisseld tussen client, server en KDC voor Kerberos-verificatie.
Geheime sleutels Kerberos maakt gebruik van een symmetrisch sleutelsysteem waarin de geheime sleutel wordt gebruikt voor zowel versleuteling als ontsleuteling. De geheime sleutel wordt gegenereerd op basis van het Kerberos-wachtwoord van de principal met een hash-functie in één richting. De KDC slaat het wachtwoord voor elke principal op en kan dus de geheime sleutel van de principal genereren. Voor gebruikers die een Kerberos-service aanvragen, wordt de geheime sleutel meestal afgeleid van een wachtwoord dat aan het kinit-programma wordt gepresenteerd. Service- en daemon-principals gebruiken doorgaans geen wachtwoord; In plaats daarvan wordt het resultaat van de hash-functie in één richting opgeslagen in een keytab.
Keytab Een keytab bevat een lijst met principals en de bijbehorende geheime sleutels. De geheime sleutels in een keytab worden vaak gemaakt met behulp van een willekeurig wachtwoord en worden meestal gebruikt voor service- of daemon-principals.

Netwerkpoortgegevens

In de volgende tabel wordt beschreven welke netwerkpoorten worden gebruikt voor Kerberos-communicatie. Als er een netwerkfirewall aanwezig is, moeten deze poorten worden geopend om de juiste Kerberos-functionaliteit toe te staan. Meer informatie over deze poorten vindt u in het IANA Service Name and Transport Protocol Port Number Registry.

Dienst Poort
Kerberos 88 (TCP/UDP)
kpasswd 464 (TCP/UDP)
Lightweight Directory Access Protocol (LDAP) (voor naamtoewijzingen) 389 (TCP/UDP)
Beheerserver 749 (TCP/UDP)
Globale catalogus (Windows-gebruikerszoekacties) 3268 (TCP/UDP)

Leeftijdswaarden in cache in Azure NetApp Files

In de volgende tabel ziet u hoe lang een cachevermelding zich in een Azure NetApp Files-volume bevindt.

cache Cacheleeftijd
Niet-actieve naamserververbindingen 60 seconden
Time-out voor LDAP-query 10 seconden
Lokale DNS-hostvermelding voor KDC TTL 24 uur
Kerberos-ticketleeftijd Opgegeven door KDC* en/of client

* Standaard ingesteld op 10 uur voor Windows Active Directory KDCs
Gebruikersreferenties 24 uur
Kerberos-tijdverschil 5 minuten

Vereisten voor goed functionerende Kerberos-omgevingen in Azure NetApp Files

Kerberos-verificatie is sterk afhankelijk van externe services voor de juiste functionaliteit. In Microsoft Active Directory worden de meeste van deze services in veel gevallen gecombineerd tot één server. Een Active Directory-domeincontroller kan bijvoorbeeld de volgende Kerberos-afhankelijkheden verwerken:

  • Tijdsynchronisatieservices
  • DNS (Domeinnaamsysteem)
  • Kerberos-sleuteldistributie
  • Wachtwoordservices/eenmalige aanmelding
  • Identiteitsservices (zoals LDAP)

Wanneer u systeemeigen Microsoft Active Directory gebruikt (het enige KDC-type dat momenteel door Azure NetApp Files wordt ondersteund), worden de meeste externe afhankelijkheden voor Kerberos in Azure NetApp Files behandeld, zoals DNS, KDC en wachtwoordservices. In sommige gevallen kunnen vereiste services worden gehost buiten het Active Directory-domein (zoals DNS). In dergelijke gevallen is het belangrijk om ervoor te zorgen dat de vereiste services correct zijn geconfigureerd.

Azure NetApp Files heeft specifieke afhankelijkheden voor het goed functioneren van NFS Kerberos. Lees verder voor meer informatie.

Tijdsynchronisatieservices

Tijdsynchronisatieservices zijn verplicht bij het gebruik van Kerberos voor verificatie, omdat de Kerberos-ticketmechanismen afhankelijk zijn van tijdsverschil tussen client en server binnen een standaardbereik van 5 minuten. Als de tijdinstellingen op de client of server dat bereik van vijf minuten overschrijden, mislukt kerberos-verificatie met een fout met tijdverschil (KRB_AP_ERR_SKEW) en wordt de toegang tot de NAS-share geweigerd. Deze time-out is een beveiligingsfunctie waarmee 'herhalingsaanvallen' worden voorkomen, waarbij een aanvaller berichten tussen de KDC en de client kan onderscheppen en deze berichten op een later tijdstip opnieuw kan afspelen om een geverifieerde gebruiker te imiteren. Tijdsverschillimieten helpen het risico van dergelijke aanvallen te minimaliseren.

Belangrijke overwegingen voor problemen met tijdsynchronisatie:

Zie Maximale tolerantie voor computerkloksynchronisatie voor meer informatie

Domain Name Systems (DNS)

Domain Name Systems (DNS) zijn verplicht voor Kerberos als beveiligingsfunctie. Hostnaamomzetting wordt gebruikt om de Kerberos-service-principals te formuleren die worden gebruikt voor verificatie. In dit proces worden forward lookups voor hostnamen (A/AAAA-records) gebruikt om verbinding te maken met shares die gebruikmaken van Kerberos-verificatie. Deze forward lookup wordt vervolgens gebruikt om de Service Principal Name (SPN) te formuleren die wordt gebruikt in de Kerberos-verificatieaanvraag. Als een bestaande SPN niet kan worden gevonden in de KDC, mislukt kerberos-verificatie.

In Windows SMB-omgevingen kan een back-upverificatiemethode worden geprobeerd (zoals NTLM). In veel gevallen is NTLM echter uitgeschakeld om veiligheidsredenen, wat zou leiden tot een toegangsfout in de share wanneer Kerberos-verificatie mislukt. De Windows-logboeken registreren vaak de hoofdoorzaak van de fouten (zoals dubbele/ontbrekende SPN's, DNS-zoekfouten, NTLM-fouten, enzovoort).

Naast SPN-resolutie wordt DNS intensief gebruikt om hostnamen en IP-adressen voor domeinservices, zoals LDAP, Kerberos KDCs, enzovoort, op te lossen via SRV-records. Zie Over DNS in Azure NetApp Files voor meer gedetailleerde informatie over DNS in Azure NetApp Files (inclusief de vereiste SRV-records).

Notitie

Als een IP-adres wordt gebruikt voor Kerberos-toegang, is het gedrag afhankelijk van het NAS-protocol (NFS of SMB) dat wordt gebruikt. Zie IP-adressen voor toegang met Kerberos voor meer informatie.

LDAP

Ldap (Lightweight Directory Access Protocol) maakt gebruik van back-endidentiteitsdatabases om een geïntegreerde naamservicebron te bieden voor NAS-clients en -servers, zodat alle deelnemende apparaten het eens zijn over de echtheid van de gebruiker, groepslidmaatschappen en numerieke id's, die vervolgens worden gebruikt voor bestandsmachtigingen.

Voor Kerberos worden gebruikers- en service-principals opgeslagen met de vermeldingen in de LDAP-databases als kenmerken voor de principal-accounts. Windows Active Directory ondersteunt dit standaard. In sommige gevallen (zoals bij het maken van aliassen of service-principals), moeten gebruikers en computers namen van service-principals toevoegen of wijzigen. U kunt aan deze vereiste voldoen met behulp van de Active Directory Microsoft Management Console (MMC) of met PowerShell. Zie Namen van service-principals beheren voor meer informatie over het beheren van service-principalnamen.

Naast service-principalnamen en numerieke id's voor Kerberos-verificatie kan LDAP ook worden gebruikt voor UNIX-gebruikers- en groepsidentiteiten, die worden gebruikt voor naamtoewijzing van identiteiten in Azure NetApp Files, evenals initiële verificatie voor NFS Kerberos-koppelingen via een SPN -> UNIX-gebruikersnaamtoewijzing. Zie Hoe NFS Kerberos werkt in Azure NetApp Files en de rol van LDAP met Kerberos in Azure NetApp Files voor meer informatie.

Hoe SMB Kerberos werkt in Azure NetApp Files

SMB Kerberos werkt afzonderlijk van NFS Kerberos-services, omdat de computeraccounts die voor elk protocol zijn gemaakt, geen sleuteltabs kunnen delen vanwege het potentieel voor wijzigingen in het sleutelversienummer (kvno) in één sleuteltab die van invloed is op de andere service. Hierdoor verschillen de werkstromen voor SMB-services voor Kerberos en NFS voor Kerberos voor Kerberos en NFS voor Kerberos in bepaalde gebieden in functionaliteit.

Initiële configuratie van SMB-services

SMB-services in Azure NetApp Files worden in eerste instantie geconfigureerd door een Active Directory-verbinding in te stellen, waarmee verschillende essentiële onderdelen voor interactie met domeinservices worden gedefinieerd, waaronder:

  • Primaire DNS-server (vereist)
  • Secundaire DNS
  • DNS-naam van Active Directory*
  • Active Directory-sitenaam (voor DC-detectie) (vereist)
  • SMB-servervoorvoegselnaam
  • Organisatie-eenheid (waarin SMB-servercomputeraccounts worden aangemaakt)
  • AES-versleuteling in- of uitschakelen
  • LDAP-ondertekening in- of uitschakelen
  • LDAP-configuratie
  • SMB-versleuteling naar DC
  • Gebruikers met bevoegdheden
  • Gebruikersnaam/wachtwoordreferenties van gebruiker met OE-machtigingen

Notitie

Er is slechts één Azure Active Directory-verbinding (AD) toegestaan per account. Zodra de AD-verbinding is gemaakt, maakt elk nieuw Azure NetApp Files SMB-volume gebruik van de AD-verbindingsconfiguratie.

SMB Kerberos-computeraccount

Een computeraccount in Active Directory bevat relevante informatie voor gebruik in verificatieaanvragen, waaronder de SPN (Service Principal Name). Wanneer u een SMB-volume maakt in Azure NetApp Files, wordt de configuratie van Active Directory-verbindingen gebruikt voor interactie bij het maken van een computeraccount om beveiligde toegang te bieden tot een SMB-share via Kerberos-verificatie (of NTLM, indien ingeschakeld).

Er worden nieuwe computeraccounts gemaakt wanneer een Azure NetApp Files SMB-volume wordt ingericht op een specifieke back-endresource in de service. Hieronder ziet u verschillende scenario's waarin een SMB-computeraccount kan worden gemaakt of hergebruikt in volumeconfiguraties van Azure NetApp Files.

Scenariobeschrijving Resultaat
Eerste nieuw SMB-volume Nieuw SMB-computeraccount/DNS-naam
Volgende SMB-volumes die kort na elkaar zijn gemaakt van het eerste SMB-volume Opnieuw gebruikt SMB-computeraccount/DNS-naam (in de meeste gevallen).
Volgende SMB-volumes zijn veel later gemaakt dan het eerste SMB-volume De service bepaalt of er een nieuw computeraccount nodig is. Het is mogelijk dat meerdere computeraccounts kunnen worden gemaakt, waardoor meerdere IP-adreseindpunten worden gemaakt.
Eerste volume met twee protocollen Nieuw SMB-computeraccount/DNS-naam
Volumes met twee protocollen die in snelle opeenvolging zijn gemaakt, voortkomend uit het eerste volume met twee protocollen. Opnieuw gebruikte SMB-computeraccount/DNS-naam (in de meeste gevallen)
Volgende volumes met twee protocollen die veel later zijn gemaakt dan het eerste volume met twee protocollen De service bepaalt of er een nieuw computeraccount nodig is. Het is mogelijk dat er meerdere computeraccounts kunnen worden gemaakt, waardoor er meerdere IP-adreseindpunten worden gemaakt
Eerste SMB-volume aangemaakt na een volume met dubbele protocollen Nieuw SMB-computeraccount/DNS-naam
Eerste volume met twee protocollen gemaakt na SMB-volume Nieuw SMB-computeraccount/DNS-naam

Het SMB-computeraccount dat is gemaakt voor het Azure NetApp Files SMB-volume (of dual-protocol) maakt gebruik van een naamconventie die voldoet aan het maximum van 15 tekens dat wordt afgedwongen door Active Directory. De naam maakt gebruik van de structuur van [SMB Server-voorvoegsel dat is opgegeven in de Azure AD-verbindingsconfiguratie]-[unieke numerieke id].

Als u bijvoorbeeld uw AD-verbindingen hebt geconfigureerd voor het gebruik van het SMB-servervoorvoegsel 'AZURE', lijkt het SMB-computeraccount dat Azure NetApp Files maakt op 'AZURE-7806'. Dezelfde naam wordt gebruikt in het UNC-pad voor de SMB-share (bijvoorbeeld \AZURE-7806) en is de naam die dynamische DNS-services gebruiken om de A/AAAA-record te maken.

Notitie

Omdat een naam als 'AZURE-7806' moeilijk te onthouden kan zijn, is het handig om een CNAME-record te maken als EEN DNS-alias voor Azure NetApp Files-volumes. Zie SMB-serveraliassen maken voor meer informatie.

Diagram van meerdere computeraccounts/DNS-vermeldingen in Azure NetApp Files.

In sommige gevallen kan de configuratie bij het maken van meerdere SMB- en/of dual-protocolvolumes eindigen met meerdere verschillende SMB-computeraccounts en DNS-namen.

Als een enkele naamruimte voor gebruikerstoegang in de volumes gewenst is, kan dit een uitdaging in de configuratie opleveren, omdat één CNAME-alias slechts kan verwijzen naar één A/AAAA-hostrecord, terwijl het gebruik van meerdere identieke A/AAAA-recordaliassen kan leiden tot onvoorspelbaarheid van gegevenstoegang bij het openen van volumes in verschillende SMB-computeraccounts, omdat er geen garantie is dat het eindpunt dat de client selecteert in de DNS-zoekactie het verwachte volume bevat vanwege de round robin-aard van de selectie van DNS-records in deze configuraties.

Om deze beperking te verhelpen, kunnen Azure NetApp Files-volumes deelnemen als doelen in een DFS-configuratie (Microsoft Distributed File System), die een manier kunnen bieden om meerdere SMB-volumes te koppelen aan één naamruimteinvoerpunt.

Diagram van een gedistribueerd bestandssysteem in Azure NetApp Files.

SMB Kerberos SPN-werkstroom voor maken

In het volgende diagram ziet u hoe een SMB Kerberos SPN wordt gemaakt wanneer een Azure NetApp Files SMB- of dual-protocolvolume wordt gemaakt. SMB SPN's zijn gekoppeld aan SMB-computeraccountobjecten in het domein. De SPN kan worden bekeken en beheerd via de eigenschappen van het computeraccount met behulp van de kenmerkeditor in de geavanceerde weergave.

Schermopname van Azure-SMB-eigenschappen.

U kunt eigenschappen ook weergeven en beheren met de setspn opdracht.

Schermopname van de opdracht 'setspn'.

Dit proces volgt dezelfde stappen als wanneer een gewone Windows-client lid wordt van een domein (DNS, LDAP, Kerberos, RPC-query's via named pipes).

Diagram van het Kerberos-computeraccount.

In de meeste gevallen is het kennen van gedetailleerde stappen niet nodig voor dagelijkse beheertaken, maar is het handig bij het oplossen van eventuele fouten bij het maken van een SMB-volume in Azure NetApp Files.

Gedetailleerde stappen

Vouw de lijst uit voor gedetailleerde stappen over hoe een SMB-computeraccount wordt gemaakt in Azure NetApp Files.

  • DNS-zoekactie wordt uitgevoerd met behulp van de DNS-configuratie voor de SRV-record van een Kerberos KDC. Azure NetApp Files maakt gebruik van de volgende SRV-records in de aanvragen.

    • _kerberos._tcp.dc._msdcs.CONTOSO.COM
    • _kerberos._tcp.CONTOSO.COM (als de vorige query geen resultaten retourneert)

  • DNS-zoekactie wordt uitgevoerd met behulp van de hostnamen die worden geretourneerd in de SRV-query voor de A/AAAA-records van de KDC's.

    • Er wordt een LDAP-ping (LDAP-binding en RootDSE-query ) uitgevoerd om te zoeken naar beschikbare verouderde NetLogon-servers met behulp van de query (&(DnsDomain=CONTOSO.COM)(NtVer=0x00000016)) met een kenmerkfilter voor NetLogon. Nieuwere versies van Windows-domeincontrollers (groter dan 2008) hebben niet de NtVer waarde aanwezig.

  • Een DNS-query wordt uitgevoerd door Azure NetApp Files om de LDAP-servers in het domein te vinden met behulp van de volgende SRV-records:

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

    Notitie

    Deze query's vinden meerdere keren plaats in dezelfde aanroep over verschillende delen van het proces. DNS-problemen kunnen leiden tot traagheid in deze aanroepen of, met time-outs, volledige fouten. - Als de query's geen vermelding vinden of als er geen contact kan worden gemaakt met de gevonden vermeldingen, mislukt het maken van SMB-volumes. - Als de DNS-query's slagen, worden de volgende stappen verwerkt.

  • ICMP (ping) wordt verzonden om te controleren of de IP-adressen die worden geretourneerd door DNS bereikbaar zijn.

  • Als ping op het netwerk wordt geblokkeerd door firewallbeleid, mislukt de ICMP-aanvraag. In plaats daarvan worden LDAP-pings gebruikt.

  • Er wordt een andere LDAP-ping uitgevoerd om te zoeken naar beschikbare verouderde NetLogon-servers met behulp van de query (&(&(DnsDomain=CONTOSO.COM)(Host=KDChostname.contoso.com))(NtVer=0x00000006)) met het kenmerkfilter NetLogon. Nieuwere versies van Windows-domeincontrollers (groter dan 2008) hebben niet de NtVer-waarde .

  • Er wordt een AS-REQ-verificatie verzonden vanuit de Azure NetApp Files-service met behulp van de gebruikersnaam die is geconfigureerd met de Active Directory-verbinding.

  • De domeincontroller reageert met KRB5KDC_ERR_PREAUTH_REQUIRED, waarmee de service wordt gevraagd het wachtwoord voor de gebruiker veilig te verzenden.

  • Er wordt een tweede AS-REQ verzonden met de vooraf geverifieerde gegevens die nodig zijn om te verifiëren met de KDC voor toegang om door te gaan met het maken van het computeraccount. Als dit lukt, wordt een Ticket Granting Ticket (TGT) verzonden naar de service.

  • Als dit lukt, wordt een TGS-REQ verzonden door de service om het CIFS-serviceticket (cifs/kdc.contoso.com) van de KDC aan te vragen met behulp van de TGT die is ontvangen in de AS-REP.

  • Er wordt een nieuwe LDAP-binding uitgevoerd met behulp van het CIFS-serviceticket. Query's worden verzonden vanuit Azure NetApp Files:

    • RootDSE-basisonderzoek voor de ConfigurationNamingContext DN van het domein
    • Zoeken op OneLevel van CN=partities in de DN die is opgehaald voor de ConfigurationNamingContext met behulp van het filter (&(&(objectClass=crossRef)(nETBIOSName=*))(dnsRoot=CONTOSO.COM)) voor het kenmerk NETBIOSname.
    • Een basiszoekopdracht met behulp van het filter (|(objectClass=organizationalUnit)(objectClass=container)) wordt uitgevoerd op de organisatie-eenheid die is opgegeven in de configuratie van Active Directory-verbindingen. Als dit niet is opgegeven, wordt de standaardwaarde OU=Computers gebruikt. Hiermee wordt gecontroleerd of de container bestaat.
    • Er wordt een substructuurzoekopdracht uitgevoerd op de basis-DN van het domein met behulp van het filter (sAMAccountName=ANF-XXXX$) om te controleren of het account al bestaat.
      • Als het account bestaat, wordt het opnieuw gebruikt.
    • Als het account niet bestaat, wordt het gemaakt, mits de gebruiker machtigingen heeft om objecten in de container te maken en te wijzigen met behulp van een addRequest LDAP-opdracht. De volgende LDAP-kenmerken zijn ingesteld voor het account:
    Kenmerk Weergegeven als
    China ANF-XXXX
    sAMAccountName ANF-XXXX$
    objectClass
    • Boven
    • Persoon
    • Organisatorisch Persoon
    • Gebruiker
    • Computer
    servicePrincipalName
    • HOST/ANF-XXXX
    • HOST/anf-xxxx.contoso.com
    • CIFS/anf-xxxx.contoso.com
    userAccountControl 4096
    besturingssysteem NetApp-release
    dnsHostName ANF-XXXX.CONTOSO.COM
    • Als de addRequest fout optreedt, mislukt het maken van het volume. Een addRequest kan mislukken vanwege onjuiste machtigingen voor het containerobject.
    • Als het addRequest lukt, wordt een LDAP-zoekopdracht uitgevoerd met behulp van het filter (sAMAccountName=ANF-XXXX$) om het kenmerk objectSid op te halen.
    • Er wordt een SMB2-gesprek 'Negotiate protocol' uitgevoerd om de ondersteunde Kerberos mechTypes op te halen van de KDC.
    • Er wordt een SMB2 -sessie-instelling uitgevoerd met behulp van de CIFS SPN en de hoogste ondersteunde mechType en een 'tree connect' met IPC$ uitgevoerd.
    • Er wordt een SMB2-bestand lsarpc gemaakt in de IPC$-share.
    • Er wordt een binding met DCERPC uitgevoerd. Het lsarpc bestand wordt vervolgens gelezen.
    • De volgende LSA-aanvragen worden vervolgens uitgevoerd:

  • Een TGS-REQ met behulp van de TGT wordt uitgevoerd om het ticket op te halen voor de kadmin/changepw SPN die is gekoppeld aan het krbtgt account.

  • Er wordt een KPASSWD-aanvraag gedaan van de service naar de KDC om het wachtwoord van het computeraccount te wijzigen.

  • Er wordt een LDAP-query uitgevoerd met het filter (sAMAccountName=ANF-XXXX) voor de kenmerken distinguishedName en isCriticalSystemObject.

  • Als het account isCriticalSystemObject onwaar is (de standaardinstelling), wordt de opgehaalde DN gebruikt om een modifyRequest naar het kenmerk msDs-SupportedEncryptionTypeste formuleren. Deze waarde is ingesteld op 30, die gelijk is aan DES_CBC_MD5 (2) + RC4 (4) + AES 128 (8) + AES 256 (16).

  • Er wordt een tweede "Negotiate protocol"/Kerberos ticket exchange/"Session setup"/"Tree connect" met IPC$ uitgevoerd. Het computeraccount van de SMB-server (ANF-XXXX$) fungeert als de Kerberos-principal.

  • NetLogon, NetrServer ReqChallenge/Authenticate2-communicatie is voltooid.

  • Er wordt een derde "Negotiate protocol:/Kerberos ticket exchange/"Session setup"/"Tree connect" met IPC$ uitgevoerd; het computeraccount van de SMB-server (ANF-XXXX$) wordt gebruikt als de Kerberos-principal.

  • Zowel als lsarpc NetLogon-verbindingen worden gemaakt als laatste controle van het account.

SMB-verbindingswerkstroom delen (Kerberos)

Wanneer een Azure NetApp Files-volume wordt gekoppeld met Kerberos, wordt een Kerberos-ticketuitwisseling gebruikt tijdens de installatieaanvragen voor meerdere sessies om beveiligde toegang tot de share te bieden. In de meeste gevallen is het kennen van gedetailleerde stappen niet nodig voor dagelijkse beheertaken. Deze kennis is handig bij het oplossen van fouten bij het oplossen van toegang tot een SMB-volume in Azure NetApp Files.

Diagram van de SMB-verbindingswerkstroom voor delen.

Vouw de lijst uit voor stappen waarin wordt beschreven hoe SMB-share wordt geopend in Azure NetApp Files.
  • De client probeert toegang te krijgen tot een SMB-share met behulp van het UNC-pad dat wordt weergegeven in Azure NetApp Files. Standaard bevat het UNC-pad de SMB-servernaam (zoals ANF-XXXX)
  • DNS wordt opgevraagd om de hostnaam toe te wijzen aan een IP-adres
  • Er vindt een eerste SMB2-gesprek 'Negotiate Protocol' plaats
    • Er wordt een aanvraag verzonden van de client om te ontdekken welke SMB-dialecten worden ondersteund door de server en bevat wat de aanvragende client ondersteunt
    • De server reageert met wat deze ondersteunt, waaronder:
      • Beveiligingsmodus (ondertekenen of niet)
      • SMB-versie
      • Server-GUID
      • Ondersteunde mogelijkheden (DFS, leasing, grote MTU, meerdere kanalen, permanente ingangen, directory lease, versleuteling)
      • Maximale transactiegrootte
      • Maximale lees-/schrijfgrootte
      • Beveiligingsblob (Kerberos of NTLM)
  • Een tweede SMB2 'Negotiate Protocol'-gesprek vindt plaats als 'preauthorization'/login
    • Aanvraag van client omvat:
      • Hash voor verificatie vooraf
      • Ondersteunde beveiligingsmodi (ondertekenen of niet)
      • Ondersteunde mogelijkheden (DFS, leasing, grote MTU, meerdere kanalen, permanente ingangen, directory lease, versleuteling)
      • Client-GUID
      • Ondersteunde SMB-dialecten
    • Als de hash voor verificatie vooraf wordt geaccepteerd, reageert de server met:
      • Beveiligingsmodus (ondertekenen of niet)
      • Ondersteunde mogelijkheden (DFS, leasing, grote MTU, meerdere kanalen, permanente ingangen, directory lease, versleuteling)
      • Maximale transactiegrootte
      • Maximale lees-/schrijfgrootte
      • Beveiligingsblob (Kerberos of NTLM)
      • SMB-verificatie-integriteit en versleutelingsmogelijkheden
  • Als de protocolonderhandeling slaagt, wordt er een 'Sessie-installatie' -aanvraag ingediend.
    • Setup maakt gebruik van de hash voor verificatie vooraf vanuit de protocolonderhandeling.
    • Setup informeert de SMB-server wat de aanvragende client ondersteunt, waaronder:
      • StructureNize
      • Vlag sessiebinding
      • Beveiligingsmodus (ondertekening ingeschakeld/vereist)
      • Functies
      • Ondersteunde Kerberos-versleutelingstypen
  • Er wordt een antwoord 'Sessie-instelling' verzonden.
    • SMB-tegoed wordt verleend.
    • Sessie-id is tot stand gebracht.
    • Sessievlagmen worden ingesteld (gast, null, versleutelen).
    • Kerberos-versleutelingstype is gedefinieerd.
  • Er wordt een tree connect-aanvraag verzonden door de client voor verbinding met de SMB-share.
    • Sharevlagken/-mogelijkheden worden verzonden vanaf de server, samen met sharemachtigingen.
  • De ioctl opdracht FSCTL_QUERY_NETWORK_INTERFACE_INFO wordt verzonden om het IP-adres van de SMB-server op te halen.
  • De SMB-server in Azure NetApp Files rapporteert terug met de netwerkgegevens, waaronder: * IP-adres * Interface-mogelijkheid (RSS aan of uit) * AANTAL RSS-wachtrijen * Snelheid van koppeling
  • Er wordt een tree connect-aanvraag verzonden door de client voor verbinding met de IPC$-beheershare.
    • De IPC$-share is een resource die de benoemde pijpen deelt die essentieel zijn voor communicatie tussen programma's. De IPC$-share wordt gebruikt tijdens extern beheer van een computer en bij het weergeven van de gedeelde resources van een computer. U kunt de instellingen voor delen, eigenschappen van delen of ACL's van de IPC$-share niet wijzigen. U kunt de naam van de IPC$-share ook niet wijzigen of verwijderen.
    • Er wordt een bestand met de naam srvsvc gemaakt in de share als een servicehandgreep.
  • Er wordt een DCERPC-binding met het srvsvc bestand uitgevoerd om een beveiligde verbinding tot stand te brengen.
    • Het bestand wordt naar het bestand geschreven met de eerder opgehaalde gegevens.
  • Een Kerberos TGS-REQ wordt door de Windows-client uitgegeven aan de KDC om een serviceticket (ST) voor de SMB-service op te halen.
  • Een NetShareGetInfo opdracht wordt uitgevoerd door de SMB-client naar de server en er wordt een antwoord verzonden.
  • Het SMB-serviceticket wordt opgehaald uit de KDC.
  • Azure NetApp Files probeert de Windows-gebruiker die toegang tot de share aanvraagt toe te wijzen aan een geldige UNIX-gebruiker.
    • Er wordt een Kerberos TGS-aanvraag gedaan met behulp van de Kerberos-referenties van de SMB-server die zijn opgeslagen met de sleuteltab van de SMB-server vanaf het eerste SMB-server maken dat moet worden gebruikt voor een LDAP-serverbinding.
    • LDAP wordt gezocht naar een UNIX-gebruiker die is toegewezen aan de SMB-gebruiker die sharetoegang aanvraagt. Als er geen UNIX-gebruiker in LDAP bestaat, wordt de standaard UNIX-gebruiker pcuser gebruikt door Azure NetApp Files voor naamtoewijzing (bestanden/mappen die zijn geschreven in volumes met twee protocollen, gebruiken de toegewezen UNIX-gebruiker als DE UNIX-eigenaar).
  • Er wordt een ander onderhandeld protocol/sessieaanvraag/tree connect uitgevoerd, deze keer met behulp van de Kerberos SPN van de SMB-server met de IPC$-share van de Active Directory DC.
    • Een benoemde pijp wordt tot stand gebracht aan de share via de srvsvc.
    • Er wordt een NETLOGON-sessie tot stand gebracht voor de share en de Windows-gebruiker wordt geverifieerd.
  • Als machtigingen dit toestaan voor de gebruiker, worden in de share de bestanden en mappen vermeld die zijn opgenomen in het volume.

Notitie

Azure NetApp Files voegt vermeldingen toe aan de Kerberos-contextcache voor de client. Deze vermeldingen bevinden zich in de cache voor de duur van de levensduur van het Kerberos-ticket (ingesteld door de KDC en beheerd door het Kerberos-beleid.

SMB-serveraliassen maken

Wanneer Azure NetApp Files een SMB-server maakt met behulp van een naamconventie van [SMB Server-voorvoegsel dat is opgegeven in de AD-verbindingsconfiguratie]-[unieke numerieke id]. (Zie voor meer informatie over de unieke numerieke id SMB Kerberos-computeraccount). Deze opmaak betekent dat SMB-servernamen niet op een gebruiksvriendelijke manier worden samengesteld. Een naam van 'SMB-7806' is bijvoorbeeld moeilijker te onthouden dan iets vergelijkbaars met 'AZURE-FILESHARE'.

Vanwege dit gedrag willen beheerders mogelijk gebruiksvriendelijke aliasnamen maken voor Azure NetApp Files-volumes. Hiervoor moet een DNS-canonieke naam (CNAME) worden verwijst naar de bestaande DNS A/AAAA-record op de server.

Wanneer een CNAME wordt gemaakt en gebruikt in UNC-padaanvragen (bijvoorbeeld \\AZURE-FILESHARE in plaats van \\SMB-7806), leidt DNS de CNAME-aanvraag (AZURE-FILESHARE.contoso.com) om naar de juiste A/AAAA-record (SMB-7806.contoso.com), die wordt gebruikt in de Kerberos SPN-ophaalbewerking (cifs/SMB-7806). Hierdoor heeft Kerberos toegang tot de SMB-share tijdens het gebruik van de aliasnaam.

Als er een DNS A/AAAA-record wordt gemaakt (bijvoorbeeld AZURE-FILESHARE.contoso.com) en geprobeerd te worden gebruikt als alias, mislukken Kerberos-aanvragen. De fout is het resultaat van de samengestelde SPN die wordt gebruikt voor verificatie bij de share (cifs/AZURE-FILESHARE) die niet overeenkomt met wat de Kerberos SPN is voor de SMB-server (cifs/SMB-7806). De fout kan worden opgelost als er een andere SPN wordt gemaakt en wordt toegevoegd aan het SMB-servercomputeraccount (zoals cifs/AZURE-FILESHARE).

Ondersteunde SMB-servermogelijkheden in Azure NetApp Files

Wanneer de aanvraag 'negotiate protocol' van SMB wordt ingediend, wordt de Azure NetApp Files SMB-server opgevraagd voor ondersteuning van specifieke mogelijkheden. In de volgende tabel ziet u de mogelijkheden die worden opgevraagd en het antwoord dat wordt geretourneerd van een Azure NetApp Files SMB-volume wanneer een sessie-installatie/structuurverbinding wordt uitgevoerd.

SMB-mogelijkheid Ondersteund door Azure NetApp Files?
DFS-doel Ja
Leasen Ja
Grote MTU Ja
SMB met meerdere kanalen Ja
Permanente SMB-ingangen Ja
Directoryverhuur Nee
SMB-versleuteling Ja (indien ingeschakeld)

Ondersteunde SMB-sharemogelijkheden en -eigenschappen in Azure NetApp Files

Tijdens SMB-sharetoegang wordt een 'tree connect'-aanvraag uitgevoerd en worden de ondersteunde SMB-sharemogelijkheden en -eigenschappen door de client opgevraagd bij de Azure NetApp Files-server. In de volgende tabel ziet u de mogelijkheden voor delen die zijn opgevraagd en het antwoord dat is geretourneerd van een Azure NetApp Files SMB-volume, zoals wordt weergegeven in een pakketopname.

SMB-sharemogelijkheid Ondersteund door Azure NetApp Files?
Continu beschikbaar (CA) Ja, voor specifieke workloads* (indien ingeschakeld)
Uitschalen Nee
cluster Nee
Asymmetrisch Nee
Omleiden naar eigenaar Nee

* Zie Continue beschikbaarheid inschakelen voor bestaande SMB-volumes voor ondersteunde workloads.

In de volgende tabel worden de eigenschappen van de share weergegeven waarop een query is uitgevoerd en het antwoord dat is geretourneerd van een Azure NetApp Files SMB-volume.

SMB-sharemogelijkheid Ondersteund door Azure NetApp Files?
DFS-doel Ja
DFS-hoofdmap Nee
Exclusief openen beperken Nee
Geforceerd gedeeld verwijderen Nee
Opslaan van naamruimte in cache toestaan Nee
Opsomming op basis van Access Ja (indien ingeschakeld)
Forceer niveau II oplock Nee
Hash V1 inschakelen Nee
Hash v2 inschakelen Nee
Versleuteling vereist Ja (indien ingeschakeld)
Externe identiteit Nee
Gecomprimeerde I/O Nee
Geïsoleerd transport Nee

Hoe NFS Kerberos werkt in Azure NetApp Files

NFS Kerberos werkt afzonderlijk van SMB-services, omdat de computeraccounts die voor elk protocol zijn gemaakt, geen sleuteltabs kunnen delen vanwege de mogelijke wijzigingen in het sleutelversienummer (kvno) in één sleuteltab die van invloed zijn op de andere service. Als gevolg hiervan verschillen de werkstromen voor SMB-services voor Kerberos en NFS voor Kerberos in bepaalde gebieden in functionaliteit.

Initiële configuratie van Kerberos-realm

De NFS Kerberos-realm wordt geconfigureerd wanneer de Kerberos-realmgegevens worden ingevuld in de Azure NetApp Files-portal onder de pagina Active Directory-verbindingen.

Schermopname van de kerberos-realmconfiguratie.

De AD-servernaam en het KDC-IP-adres worden gebruikt om verbinding te maken met de AD KDC-services bij het maken van het eerste computeraccount. De Azure NetApp Files-service maakt gebruik van de bestaande domeingegevens om de rest van de realmconfiguratie in te vullen. Voorbeeld:

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

Wanneer de NFS Kerberos-realm is geconfigureerd, wordt een vermelding van lokale hosts toegevoegd in de service met de KDC die is opgegeven in de configuratie. Wanneer de realm wordt gewijzigd, wordt de vermelding van de lokale hosts ook gewijzigd in de service.

Diagram van kerberos-realmconfiguratie.

Deze lokale hostvermelding fungeert als laatste redmiddel als er een KDC-storing optreedt op de KDC die is opgegeven in de realmconfiguratie en geen query's kan uitvoeren op redundante KDC's via DNS.

Notitie

Als de KDC in de Kerberos-realm moet worden afgebroken voor onderhoud (zoals voor upgrades of buiten gebruik stellen van een server), is het raadzaam om de realm te configureren voor het gebruik van een KDC die geen onderhoud ondergaat om storingen te voorkomen.

Initiële creatie van computeraccount/SPN

Wanneer Kerberos is ingeschakeld op een Azure NetApp Files-volume, wordt een computeraccount/principal met de naam NFS-{SMB-server-name} gemaakt in het domein in de opgegeven organisatie-eenheid in Active Directory-verbindingen (organisatie-eenheid). Computeraccountnamen worden na 15 tekens afgekapt.

Notitie

Wanneer u Linux-clients met hostnamen van meer dan 15 tekens toevoegt aan een Active Directory-domein, worden de SPN's van hun Kerberos-computeraccount afgekapt. Een Linux-client met een naam MORE-THAN-FIFTEEN heeft bijvoorbeeld een computeraccountnaam van MORE-THAN-FIFT$, die een SPN van MORE-THAN-FIFT$@CONTOSO.COMwordt. Wanneer DNS een clienthostnaam opzoekt, wordt de langere naam gevonden en wordt geprobeerd die naam te gebruiken in een SPN-aanvraag ( MORE-THAN-FIFTEEN@CONTOSO.COM). Omdat deze SPN niet bestaat, probeert de client de volgende SPN te gebruiken in de keytab in de aanvraag (meestal host/hostnaam). Alleen SPN's voor computeraccounts werken systeemeigen met Azure NetApp Files NFS Kerberos. Als gevolg hiervan moet u ervoor zorgen dat de hostnamen van de Linux-client die worden gebruikt voor NFS Kerberos met Azure NetApp Files niet langer zijn dan 15 tekens. Als u de host-/hostnaam SPN wilt gebruiken, configureert u een UNIX-gebruiker in LDAP met de gebruikersnaam 'host'. Deze configuratie biedt een krb-unix-naamtoewijzing voor de SPN.

In Azure NetApp Files worden Kerberos-sleutelblokkeringen (of keytab-vermeldingen) toegevoegd aan de service met de SPN van de NFS-service (nfs/nfs-server-name.contoso.com@CONTOSO.COM). Er worden meerdere vermeldingen gemaakt: één voor elk ondersteund versleutelingstype. In Azure NetApp Files wordt alleen het AES-256-versleutelingstype ondersteund voor NFS Kerberos.

In de meeste gevallen is het kennen van deze stappen niet nodig voor dagelijkse beheertaken, maar zijn ze handig bij het oplossen van eventuele fouten bij het maken van een NFS Kerberos-volume in Azure NetApp Files.

Werkstroom voor het maken van NFS Kerberos SPN

In het volgende diagram ziet u hoe een NFS SPN wordt gemaakt wanneer een Azure NetApp Files NFS- of dubbelprotocolvolume wordt gemaakt met Kerberos ingeschakeld. In de meeste gevallen zijn gedetailleerde stappen niet nodig voor dagelijkse beheertaken, maar zijn ze handig bij het oplossen van eventuele fouten bij het maken van een SMB-volume in Azure NetApp Files.

Diagram van de werkstroom voor het maken van NFS Kerberos SPN.

Vouw de lijst uit voor gedetailleerde stappen over hoe een NFS Kerberos SPN wordt gemaakt met Azure NetApp Files.
  • Beheerdersreferenties die zijn doorgegeven aan KDC die zijn opgegeven in de realmconfiguratie met behulp van de gebruikersnaam die is opgegeven voor gebruik in de Active Directory-verbinding: de gebruiker moet gemachtigd zijn om objecten in de opgegeven organisatie-eenheid weer te geven of te maken.
  • De DNS-servers die zijn opgegeven in de configuratie van de Azure NetApp Files Active Directory-verbinding, worden door Azure NetApp Files opgevraagd voor de Kerberos-servicerecords (SRV) in de volgende indelingen:
    • URI-query voor _kerberos.CONTOSO.COM
    • SRV-query voor _kerberos-master._udp. CONTOSO.COM
    • SRV-query voor _kerberos-master._tcp. CONTOSO.COM

Notitie

Deze query's vinden meerdere keren plaats in dezelfde aanroep over verschillende delen van het proces. DNS-problemen kunnen traagheid in deze aanroepen of volledige fouten tot stand brengen. Deze records lijken niet standaard te bestaan in Active Directory-implementaties en moeten handmatig worden gemaakt.

  • Als de query's geen vermelding vinden of als de gevonden vermeldingen niet kunnen worden gecontacteerd of gebruikt als hoofd-KDC, wordt een A-recordquery met behulp van de realmnaam in de NFS Kerberos-realmconfiguratie gebruikt als laatste redmiddel om via poort 88 verbinding te maken met de KDC.
  • Tijdens de configuratie van NFS Kerberos wordt een statische hostvermelding voor de opgegeven KDC als back-up toegevoegd aan het lokale hosts-bestand als DNS-zoekacties mislukken.
  • Als er een DNS-vermelding in de cache is voor de realm, wordt deze gebruikt. Zo niet, dan wordt de lokale bestandsvermelding gebruikt. Dns-vermeldingen in de cache worden live opgeslagen zolang de TTL (Time to Live) is geconfigureerd voor de DNS-record. De lokale bestandsvermelding is geconfigureerd met een TTL van 86.400 seconden (24 uur). De ns-switchconfiguratie voor hostzoekacties in Azure NetApp Files maakt eerst gebruik van bestanden en vervolgens DNS. Wanneer de lokale vermelding wordt gevonden, worden er geen query's meer uitgevoerd.
  • Het SMB-computeraccount dat is gemaakt wanneer de Active Directory-verbinding wordt gemaakt, wordt gebruikt als referenties voor een Active Directory LDAP-binding met behulp van SASL/GSS via poort 389 om te zoeken naar bestaande vermeldingen van de gewenste SPN- of computeraccountnaam. Als de SPN- of computeraccountnaam al bestaat, wordt er een fout verzonden. Als de SPN niet bestaat in de LDAP-query, wordt het maken van het computeraccount uitgevoerd in de aangewezen organisatie-eenheid met vermeldingen voor de volgende kenmerken die zijn ingesteld door Azure NetApp Files:
    • cn (NFS-MACHINE)
    • sAMAccountName (NFS-MACHINE$)
    • objectClass (top, persoon, organisatiePerson, gebruiker, computer)
    • servicePrincipalName (host/NFS-MACHINE, host/NFS-MACHINE. CONTOSO.COM, nfs/NFS-MACHINE, nfs/NFS-MACHINE. CONTOSO.COM)
    • gebruikersaccountbeheer (4096)
    • msDs-SupportedEncryptionTypes (AES-256_CTS_HMAC_SHA1_96)
    • dnsHostName (NFS-MACHINE.CONTOSO.COM)
  • Het wachtwoord voor het NFS Kerberos-computeraccount is ingesteld voor het NFS-MACHINE-account via poort 464.
  • Kerberos-sleutelblokkeringen (keytabs) voor de NFS SPN worden opgeslagen in de Azure NetApp Files-service.
  • Er wordt een statische naamtoewijzingsregel gemaakt in de Azure NetApp Files-service om ervoor te zorgen dat de hoofdgebruiker voor elke NFS Kerberos-client wordt toegewezen aan de hoofdmap wanneer Kerberos wordt gebruikt.
  • Er wordt een krb5.conf-bestand toegevoegd aan de interne systemen van de service met informatie over de NFS-realm.

NFS Kerberos-koppeling

Wanneer een Azure NetApp Files-volume wordt gekoppeld met behulp van Kerberos-beveiligingssmaak via NFS, wordt de volgende werkstroom uitgevoerd. Zie Kerberos Network Authentication Service (V5) Synopsis voor een gedetailleerder account van Kerberos.

Diagram van de NFS Kerberos-koppelingswerkstroom.

Vouw de lijst uit voor gedetailleerde stappen over hoe een NFS Kerberos-volume wordt gekoppeld aan Azure NetApp Files.
  • De client probeert een koppeling te maken naar een NFS-exportpad in Azure NetApp Files en geeft de -obeveiligingssmaak krb5 (of krb5i of krb5p) op.
  • DNS wordt gebruikt om een aanvraag voor een NFS-service-principal naar Azure NetApp Files te formuleren via een A/AAAA-record of PTR (afhankelijk van hoe de koppelingsopdracht is uitgegeven).
  • De client haalt een TGT op van de KDC via een AS-REQ-aanroep met behulp van de client-principalnaam die is gevonden in de sleuteltab van de client.
  • Het exportpad wordt gecontroleerd om te controleren of het in het bestandssysteem bestaat.
  • De exportbeleidsregel wordt gecontroleerd om ervoor te zorgen dat Kerberos-toegang tot het exportpad is toegestaan.<
  • Het NFS-serviceticket wordt aangevraagd bij de KDC door de client via een AP-REQ-aanroep. Azure NetApp Files controleert de keytab op een geldige vermelding met een geldig versleutelingstype met behulp van de TGT van de client die is verkregen van de KDC.
  • Als de TGT geldig is, wordt er een serviceticket uitgegeven.
  • De client-SPN (bijvoorbeeld CLIENT$@CONTOSO.COM) wordt toegewezen aan de hoofdgebruiker via de naamtoewijzingsregel in Azure NetApp Files.
  • De hoofdgebruiker wordt opgevraagd in de naamservicesdatabases (bestanden en LDAP) voor bestaan/groepslidmaatschappen.
  • Er wordt een LDAP-binding uitgevoerd met behulp van het SMB-servercomputeraccount om een LDAP-zoekopdracht naar de hoofdgebruiker toe te staan.
  • Omdat de hoofdmap altijd bestaat in Azure NetApp Files, kan dit geen problemen veroorzaken, maar LDAP-query's voor de hoofdmap kunnen mislukken. Deze fouten kunnen worden genegeerd.
  • Het NFS-serviceticket wordt geretourneerd naar de client en de koppeling is geslaagd. De hoofdgebruiker heeft hoofdtoegang tot de Kerberos-koppeling via de clientcomputeraccount-principal (kan worden weergegeven met de klist -e opdracht van de client).
  • Azure NetApp Files voegt vermeldingen toe aan de Kerberos-contextcache voor de client. Deze vermeldingen bevinden zich in de cache voor de duur van de levensduur van het Kerberos-ticket dat is ingesteld door de KDC en wordt beheerd door het Kerberos-beleid.
  • NFSv4.1 verzendt periodiek (elke 20 seconden) updates voor het vernieuwen van kerberos-tickets als 'keepalives'.

NFS Kerberos-koppelingstoegang met gebruikersprincipals

Wanneer een Azure NetApp Files NFS Kerberos-koppeling wordt geopend door een gebruiker (met uitzondering van de hoofdgebruiker, die gebruikmaakt van de SPN van het computeraccount), wordt de volgende werkstroom uitgevoerd.

Diagram van NFS Kerberos-koppelingstoegang met gebruikersprincipals.

Vouw de lijst uit voor gedetailleerde stappen over hoe een NFS Kerberos-volume wordt geopend met een niet-basisgebruiker met Azure NetApp Files.
  • De gebruiker meldt zich aan bij de KDC met een gebruikersnaam/wachtwoorduitwisseling of via een keytab-bestand om een TGT op te halen via een AS-REQ-aanroep die moet worden gebruikt voor het verzamelen van een serviceticket van het Azure NetApp Files-volume.
  • De exportbeleidsregel wordt gecontroleerd om ervoor te zorgen dat Kerberos-toegang is toegestaan tot het exportpad voor de clientcomputer
  • Azure NetApp Files controleert op een NFS-serviceticket in de cache. Als er geen bestaan, wordt het NFS-serviceticket aangevraagd via een AP-REQ-aanroep en controleert de service de keytab op een geldige vermelding met een geldig versleutelingstype met behulp van de TGT van de client die is verkregen van de KDC
  • Als de TGT geldig is, wordt er een serviceticket uitgegeven
  • De UPN (User Principal Name) van de gebruiker wordt toegewezen via impliciete toewijzing. Als de UPN bijvoorbeeld is user1@CONTOSO.COM, voert de service query's uit voor een UNIX-gebruiker met de naam gebruiker1. Omdat die UNIX-gebruiker niet bestaat in de database met lokale bestanden in Azure NetApp Files, wordt LDAP gebruikt.
  • Er wordt geprobeerd een LDAP-binding te maken met behulp van het SMB-servercomputeraccount om een LDAP-zoekopdracht naar de toegewezen gebruiker toe te staan. Er wordt een DNS SRV-query uitgevoerd voor Kerberos DNS-records (_kerberos en _kerberos-master). Als er geen geldige records kunnen worden gebruikt, valt de configuratie terug op de realmconfiguratie. Deze KDC DNS SRV-query's zijn geen sitebereik.
  • LDAP SRV-records worden opgevraagd voor geldige LDAP-servers. Dit zijn sitebereiken.
  • Als de gebruiker niet bestaat in LDAP of LDAP niet kan worden opgevraagd (de server is niet beschikbaar, mislukt de DNS-zoekactie, mislukt de binding, er is een time-out voor LDAP-zoekopdrachten, de gebruiker bestaat niet) mislukt de toewijzing en wordt de toegang geweigerd.
  • Als de gebruiker bestaat, worden groepslidmaatschappen verzameld.
  • De toewijzing slaagt en er wordt een NFS-serviceticket uitgegeven aan de client (te zien in klist -e opdrachten). Toegang is toegestaan op basis van de bestandsmachtigingen op het exportpad.

De rol van LDAP met Kerberos in Azure NetApp Files

Azure NetApp Files is afhankelijk van LDAP voor NFS Kerberos. Voor NFS Kerberos in Azure NetApp Files is Kerberos vereist voor UNIX-naamtoewijzingen voor binnenkomende SPN's van gebruikers. Omdat Azure NetApp Files het maken van lokale UNIX-gebruikers niet ondersteunt, is LDAP nodig om zoekacties uit te voeren voor UNIX-gebruikers wanneer een naamtoewijzing wordt aangevraagd.

  • Wanneer een Active Directory-verbinding wordt gemaakt, wordt de Active Directory-domeinnaam gebruikt om het proces op te geven voor het opzoeken van LDAP-servers.
  • Wanneer er een LDAP-server nodig is, _ldap.domain.com wordt deze gebruikt voor de SRV-zoekactie voor LDAP-servers.
  • Zodra een lijst met servers is gedetecteerd, wordt de best beschikbare server (op basis van reactietijd van ping) gebruikt als ldap-server voor verbinding via poort 389.
  • Er wordt geprobeerd een LDAP-binding te maken met behulp van het SMB-computeraccount via GSS/Kerberos.
  • Als er geen verbinding in de cache of Kerberos-referenties is, wordt er een nieuwe aanvraag voor een Kerberos-ticket uitgegeven. Verbindingen in de cache voor naamservers in Azure NetApp Files worden gedurende 60 seconden live opgeslagen. Als de verbinding langer dan 60 seconden niet actief is, wordt de verbindingscache gewist.
  • DNS wordt gebruikt om de juiste Kerberos KDCs te vinden via SRV-records.
  • Als er geen KDC's kunnen worden gevonden via DNS-query, wordt de KDC die is opgegeven in het krb5.conf-bestand voor de SMB-services gebruikt.
    • Als deze KDC onbereikbaar is of de Kerberos-aanvraag niet kan verwerken, mislukt de LDAP-binding. De naamzoekactie mislukt ook. De toegang tot de koppeling wordt geweigerd omdat er geen geldige verificatie heeft plaatsgevonden.
    • Als de binding slaagt, wordt er een LDAP-query uitgevoerd voor de gebruiker en de bijbehorende referenties. Als de zoektijd langer is dan 10 seconden, mislukt de zoekopdracht.
  • Als de zoekactie de gebruiker vindt, slaagt de toewijzing en wordt de toegang verleend via Kerberos (mits het ticket geldig is/is niet verlopen).

IP-adressen voor toegang met Kerberos

Kerberos-verificatie maakt standaard gebruik van hostnaam-naar-IP-adresomzetting om de Service Principal Name (SPN) te formuleren die wordt gebruikt om het Kerberos-ticket op te halen. Wanneer een SMB-share bijvoorbeeld wordt geopend met een UNC -pad (Universal Naming Convention), zoals \SMBVOLUME.CONTOSO.COM, wordt een DNS-aanvraag uitgegeven voor de Fully Qualified Domain Name SMBVOLUME.CONTOSO.COM en wordt het IP-adres van het Azure NetApp Files-volume opgehaald. Als er geen DNS-vermelding aanwezig is (of de huidige vermelding verschilt van wat wordt aangevraagd, zoals bij aliassen/CNAMEs), kan een juiste SPN niet worden opgehaald en mislukt de Kerberos-aanvraag. Als gevolg hiervan kan de toegang tot het volume niet worden toegestaan als de methode voor terugvalverificatie (zoals New Technology LAN Manager) is uitgeschakeld.

DNS-vermeldingen in Azure NetApp Files worden automatisch gemaakt met dynamische DNS en worden geformuleerd met behulp van de naam van de SMB-server. Voor variaties/aliassen voor de gedefinieerde naam moet een handmatige DNS CNAME-record worden gemaakt en naar de dynamische DNS-vermelding worden verwezen. Zie Dns begrijpen in Azure NetApp Files voor meer informatie.

NFSv4.1 Kerberos werkt op een vergelijkbare manier voor het ophalen van SPN, waarbij DNS-zoekopdrachten integraal zijn voor het verificatieproces en ook kunnen worden gebruikt voor kerberos-realmdetectie.

Als een IP-adres (in plaats van een hostnaam) wordt gebruikt in een toegangsaanvraag voor een Azure NetApp Files-volume, werkt een Kerberos-aanvraag anders, afhankelijk van het gebruikte protocol.

SMB Kerberos-gedrag met IP-adressen en DNS-namen

Wanneer u SMB gebruikt, probeert een aanvraag voor een UNC-pad met behulp van een IP-adres (bijvoorbeeld \\x.x.x.x) standaard NTLM te gebruiken voor verificatie. In omgevingen waarin NTLM om veiligheidsredenen niet is toegestaan, is een SMB-aanvraag met behulp van een IP-adres standaard niet in staat Kerberos of NTLM te gebruiken voor verificatie. Als gevolg hiervan wordt de toegang tot het Azure NetApp Files-volume geweigerd. In latere Versies van Windows (vanaf Windows 10 versie 1507 en Windows Server 2016) kunnen Kerberos-clients worden geconfigureerd ter ondersteuning van IPv4- en IPv6-hostnamen in SPN's voor SMB-communicatie om dit probleem te omzeilen.

NFSv4.1 Kerberos-gedrag met IP-adressen en DNS-namen

Wanneer u NFSv4.1 gebruikt, gebruikt een koppelaanvraag voor een IP-adres met behulp van een van de sec=[krb5/krb5i/krb5p] opties reverse-DNS-zoekacties via PTR om een IP-adres om te zetten naar een hostnaam. Deze hostnaam wordt vervolgens gebruikt om de SPN te formuleren voor het ophalen van Kerberos-tickets. Als u NFSv4.1 met Kerberos gebruikt, moet u een A/AAAA en PTR voor het Azure NetApp Files-volume hebben om zowel hostnaam als IP-adrestoegang tot koppels te dekken. Azure NetApp Files maakt een dynamische DNS A/AAAA-record. Als er een omgekeerde DNS-zone voor dat subnet bestaat, wordt er ook automatisch een PTR-record gemaakt. Gebruik CNAME-records voor DNS-aliassen voor afwijkingen van de standaardhostnaamconventies van Azure NetApp Files.

Zie Dns begrijpen in Azure NetApp Files voor meer informatie