Freigeben über

Grundlegendes zu Kerberos in Azure NetApp-Dateien

  • Artikel

Kerberos ist ein Authentifizierungsprotokoll, das einen geheimen Schlüssel verwendet, um die Identität von Prinzipalen zu überprüfen. Geheime Schlüssel werden generiert, indem das Passwort eines Prinzipals verwendet und mithilfe einer vereinbarten Verschlüsselungsmethode vom Client und Server (z. B. AES) in ein Hash-Kryptografieschlüsselformat konvertiert wird. Weitere Informationen zu den in diesem Dokument verwendeten Begriffen finden Sie im Abschnitt "Kerberos-Terminologie ".

Schlüsselverteilungszentren (Key Distribution Centers, KDCs) wie Windows Active Directory verwalten eine Datenbank mit Kerberos-Prinzipale und deren gehashten Passwörter. In Kerberos ist der geheime Schlüssel der Nachweis einer eindeutigen Identität. Daher kann das KDC als vertrauenswürdig eingestuft werden, um jeden Prinzipal für jeden anderen Prinzipal zu authentifizieren, wie die Authentifizierung eines NFS-Clientdienstprinzipalnamens (SPN) bei einem NFS-Server-SPN bei der Bereitstellung. Es kann auch vertrauenswürdig sein, einen Benutzerprinzipal bei einem NFS-Server-SPN für den Benutzerzugriff auf einen NAS-Bereitstellungspunkt zu authentifizieren. Als zusätzliche Sicherheitsmaßnahme sendet Kerberos keine Klartext-Passwörter für die Authentifizierung über das Netzwerk.

Azure NetApp Files unterstützt die Verwendung von Kerberos, um In-Flight-Sicherheit für die SMB- und NFS-Protokolle bereitzustellen.

Unterstützte Verschlüsselungstypen

Azure NetApp Files unterstützt NFS Kerberos mit bestimmten Verschlüsselungstypen, abhängig vom Betriebsmodus und der Version, die Sie verwenden.

Um sicherzustellen, dass ein Client den entsprechenden Verschlüsselungstyp verwendet, können Sie die gültigen Verschlüsselungstypen für den Objektprinzipal einschränken, der sich auf dem KDC befindet (z. B. das Computerkonto) oder in der manuell erstellten Schlüsseltabellendatei des Clients und nicht global in der Datei "/etc/krb5.conf", sofern möglich, da die Verwaltung zahlreicher Clientkrb5.conf-Dateien ein Verwaltungskopf sein kann. Die zentrale Verwaltung von Kerberos aus dem KDC ist in großen Unternehmensumgebungen besser skalierbar, ist einfacher zu automatisieren und erzwingt, dass der Client stärkere Verschlüsselungstypen verwendet, wenn sie unterstützt werden.

Hinweis

Es wird empfohlen, die Option allow_weak_crypto auf "Falsch" in der Datei "krb5.conf" auf Clients festzulegen. Diese Einstellung verhindert eine weniger sichere enctypes Kerberos-Kommunikation (wie DES oder 3DES).

In der folgenden Tabelle sind die unterstützten Verschlüsselungstypen für Kerberos (sowohl SMB als auch NFS) für Azure NetApp Files aufgeführt.

Protokoll Unterstützte Verschlüsselungstypen
SMB
  • RC4-HMAC
  • AES-128
  • AES-256
NFS AES-256

Unterstützte NFS Kerberos-Sicherheitsmodi

Neben dem Konzept der Verschlüsselungstypen gibt es auch Sicherheits- und Integritätsüberprüfungen in Kerberos. Abhängig vom verwendeten Sicherheitsmodus helfen diese Sicherheitsmodi, Man-in-the-Middle-Angriffe zu verhindern, indem sie End-to-End-Verschlüsselung für NFS-Datenverkehr anbieten.

In Azure NetApp Files werden diese Sicherheitsmodi für die Exportrichtlinienregeln für das Volume für NFS festgelegt und während der ersten NFS-Bereitstellung über die Sec-Bereitstellungsoption definiert.

Beispiel: # mount -o sec=krb5p

Hinweis

Für SMB Kerberos werden Sicherheitsmodi für Kerberos über SMB-Verschlüsselungseinstellungen für die Freigabe, DIE UNC-Härtungund die SMB-Signatur-/Dichtungsrichtlinien auf den Domänencontrollern gesteuert.

Die folgenden Sicherheitsmodi werden von Azure NetApp Files für die Verwendung mit NFS Kerberos unterstützt:

Sicherheitsmodus Beschreibung
krb5 Nur Authentifizierungsverschlüsselung.

Verwendet Kerberos V5-Namenszeichenfolgen und Benutzerprinzipalnamen anstatt lokaler UNIX-Benutzer-IDs (UIDs) und Gruppen-IDs (GIDs), um Benutzer zu authentifizieren.
krb5i Authentifizierungsverschlüsselung und verschlüsselte Integritätsprüfung.

Verwendet Kerberos V5 für die Benutzerauthentifizierung und führt auch die Integritätsprüfung von NFS-Vorgängen mithilfe sicherer Prüfsummen durch, um Datenmanipulation und Man-in-the-Middle-Angriffe zu verhindern.
krb5p Gesamte NFS-Unterhaltung verschlüsselt.

Verwendet Kerberos V5 für die Benutzerauthentifizierung und Integritätsprüfung und verschlüsselt auch den gesamten NFS-Datenverkehr, um paketbasiertes Sniffing zu verhindern. Diese Einstellung ist der sicherste, aber auch der leistungsstärkste Aufwand.

Kerberos-Terminologie

Dieser Abschnitt definiert wichtige Terminologie definiert, die beim Beschreiben von Kerberos-Prozessen verwendet wird. Dieser Abschnitt soll dazu beitragen, um Begriffe zu klären, die möglicherweise nicht vertraut für Speicheradministratoren sind.

Begriff Definition
Schlüsselverteilungscenter (KDC) Der KDC ist der Authentifizierungsserver, der den Ticketgewährungsdienst (TGS) und den Authentifizierungsdienst (AS) enthält. Die Begriffe KDC, AS und TGS werden austauschbar verwendet. In Microsoft-Umgebungen ist ein Active Directory-Domänencontroller ein KDC.
Bereich (oder Kerberos-Bereich) Ein Bereich (oder Kerberos-Bereich) kann eine beliebige ASCII-Zeichenfolge verwenden. Der Standard besteht darin, den Domänennamen in Großbuchstaben zu verwenden; beispielsweise wird contoso.com zum Bereich CONTOSO.COM. Kerberos-Bereiche werden in der Regel in krb5.conf-Dateien auf Clients und Servern konfiguriert.

Jedes principal@REALM muss administrativ eindeutig sein. Um einen einzelnen Fehlerpunkt zu vermeiden, kann jeder Bereich mehrere KDCs aufweisen, die dieselbe Datenbank (Prinzipale und deren Passwörter) gemeinsam verwenden und über dieselben KDC-Masterschlüssel verfügen. Microsoft Windows Active Directory führt dies nativ über die Active Directory-Replikation aus, die standardmäßig alle 15 Minuten stattfindet.
Prinzipal Der Begriff Prinzipal bezieht sich auf jede Entität innerhalb einer Kerberos-Datenbank. Benutzern, Computern und Diensten werden alle Prinzipale für die Kerberos-Authentifizierung zugewiesen. Jeder Prinzipal muss innerhalb der Kerberos-Datenbank eindeutig sein und wird durch seinen unterschiedenen Namen definiert. Ein Prinzipal kann ein Benutzerprinzipalname (USER Principal Name, UPN) oder ein Dienstprinzipalname (Service Principal Name, SPN) sein.

Ein Prinzipalname weist drei Teile auf:
  • Primär – Der primäre Teil kann ein Benutzer oder ein Dienst wie der NFS-Dienst sein. Es kann auch der spezielle Dienst "Host" sein, der bedeutet, dass dieser Dienstprinzipal eingerichtet ist, um mehrere verschiedene Netzwerkdienste bereitzustellen.
  • Instanz – Dieser Teil ist im Fall eines Benutzers optional. Ein Benutzer kann mehrere Prinzipale haben, aber jeder Prinzipal muss im KDC eindeutig sein. Zum Beispiel könnte Fred über einen Prinzipal verfügen, der für die tägliche Verwendung (fred@contoso.com) und einen Prinzipal gilt, der privilegierte Verwendung wie ein Sysadmin-Konto (admin-fred@contoso.com) zulässt. Die Instanz ist für Dienstprinzipale erforderlich und bestimmt den vollqualifizierten Domänennamen (FQDN) des Hosts, der den Dienst bereitstellt.
  • Bereich – Ein Kerberos-Bereich ist der Satz von Kerberos-Prinzipale, die in einem Kerberos-Server registriert sind. Der Bereichsname ist in der Regel identisch mit dem DNS-Namen, wird jedoch in Großbuchstaben konvertiert. Großbuchstaben sind nicht obligatorisch, aber die Konvention bietet eine einfache Unterscheidung zwischen dem DNS-Namen und dem Bereichsnamen.
Tickets Ein Ticket ist ein temporärer Satz von Anmeldeinformationen, die die Identität eines Prinzipals für einen Dienst überprüft und den Sitzungsschlüssel enthält. Ein Ticket kann ein Service, ein Anwendungsticket oder ein Ticket-Bewilligungsticket (TGT) sein. Tickets werden zwischen Client, Server und KDC für die Kerberos-Authentifizierung ausgetauscht.
Geheime Schlüssel Kerberos verwendet ein symmetrisches Schlüsselsystem, in dem der geheime Schlüssel sowohl für die Verschlüsselung als auch für die Entschlüsselung verwendet wird. Der geheime Schlüssel wird aus dem Kerberos-Passwort des Prinzipals mit einer unidirektionalen Hashfunktion generiert. Das KDC speichert das Passwort für jeden Prinzipal und kann somit den geheimen Schlüssel des Prinzipals generieren. Für Benutzer, die einen Kerberos-Dienst anfordern, wird der geheime Schlüssel in der Regel von einem Passwort abgeleitet, das dem Kinit-Programm angezeigt wird. Dienst- und Daemonprinzipale verwenden in der Regel kein Passwort; stattdessen wird das Ergebnis der unidirektionalen Hashfunktion in einer Schlüsseltabelle gespeichert.
-Schlüsseltabelle Eine Schlüsseltabelle enthält eine Liste der Prinzipale und deren geheime Schlüssel. Die geheimen Schlüssel in einer Schlüsseltabelle werden häufig mithilfe eines zufälligen Passworts erstellt und hauptsächlich für Dienst- oder Daemonprinzipale verwendet.

Netzwerkportinformationen

In der folgenden Tabelle wird erläutert, welche Netzwerkports für die Kerberos-Kommunikation verwendet werden. Wenn eine Netzwerkfirewall vorhanden ist, sollten diese Ports geöffnet werden, um die ordnungsgemäße Kerberos-Funktionalität zu ermöglichen. Weitere Informationen zu diesen Ports finden Sie in der IANA Service Name and Transport Protocol Port Number Registry.

Dienst Port
Kerberos 88 (TCP/UDP)
kpasswd 464 (TCP/UDP)
Lightweight Directory Access Protocol (LDAP) (für Namenszuordnungen) 389 (TCP/UDP)
Verwaltungsserver 749 (TCP/UDP)
Globaler Katalog (Windows-Benutzersuche) 3268 (TCP/UDP)

Cachealterswerte in Azure NetApp-Dateien

In der folgenden Tabelle wird die Zeitspanne angezeigt, in der ein Cacheeintrag in einem Azure NetApp Files-Volume gespeichert ist.

Cache Cachealter
Serververbindungen im Leerlauf 60 Sekunden
Timeout für LDAP-Abfrage 10 Sekunden
Lokaler DNS-Hosteintrag für KDC-TTL 24 Stunden
Kerberos-Ticketalter Angegeben durch KDC* und/oder Client

* Standardmäßig 10 Stunden für Windows Active Directory-KDCs
Benutzeranmeldeinformationen 24 Stunden
Kerberos-Zeitversatz 5 Minuten

Anforderungen für ordnungsgemäß funktionierende Kerberos-Umgebungen in Azure NetApp-Dateien

Die Kerberos-Authentifizierung ist für die ordnungsgemäße Funktionalität stark von externen Diensten abhängig. In Microsoft Active Directory werden die meisten dieser Dienste in vielen Fällen in einem einzigen Server kombiniert. Beispielsweise kann ein Active Directory-Domänencontroller die folgenden Kerberos-Abhängigkeiten verwenden:

  • Zeitsynchronisierungsdienste
  • DNS
  • Kerberos-Schlüsselverteilung
  • Passwortdienste/einmaliges Anmelden
  • Identitätsdienste (wie LDAP)

Wenn Sie systemeigenes Microsoft Active Directory verwenden (der einzige KDC-Typ, den Azure NetApp Files derzeit unterstützt), werden die meisten externen Abhängigkeiten für Kerberos in Azure NetApp-Dateien behandelt, z. B. DNS, KDC und Passwortdienste. In einigen Fällen können erforderliche Dienste außerhalb der Active Directory-Domäne (wie DNS) gehostet werden. In diesen Fällen ist es wichtig, sicherzustellen, dass die erforderlichen Dienste ordnungsgemäß konfiguriert sind.

Azure NetApp Files verfügt über bestimmte Abhängigkeiten für ordnungsgemäß funktionierende NFS Kerberos. Lesen Sie weiter, um weitere Informationen zu erfahren.

Zeitsynchronisierungsdienste

Zeitsynchronisierungsdienste sind obligatorisch, wenn Kerberos für die Authentifizierung verwendet wird, da die Kerberos-Ticketmechanismen von Zeitversätzen zwischen Client und Server innerhalb eines standardmäßigen 5-Minuten-Bereichs abhängen. Wenn die Zeiteinstellungen auf dem Client oder Server diesen fünfminütigen Bereich überschreiten, schlägt die Kerberos-Authentifizierung mit einem Zeitfehler (KRB_AP_ERR_SKEW) fehl, und der Zugriff auf die NAS-Freigabe wird verweigert. Dieses Timeout ist ein Sicherheitsfeature, das dazu beiträgt, "Replay-Angriffe" zu verhindern, bei dem ein Angreifer Nachrichten zwischen dem KDC und dem Client abfangen und diese Nachrichten zu einem späteren Zeitpunkt wiedergeben kann, um die Identität eines authentifizierten Benutzers zu imitieren. Zeitversatzgrenzen tragen dazu bei, das Risiko dieser Angriffstypen zu minimieren.

Wichtige Überlegungen zu Zeitsynchronisierungsproblemen:

Weite Informationen finden Sie unter Maximale Toleranz für die Synchronisierung der Computeruhr

Domain Name Systems (DNS)

Domain Name Systems (DNS) sind für Kerberos als Sicherheitsfeature obligatorisch. Die Hostnamenauflösung wird verwendet, um die für die Authentifizierung verwendeten Kerberos-Dienstprinzipale zu formulieren. In diesem Prozess werden Vorwärts-Lookups für Hostnamen (A/AAAA-Einträge) verwendet, um eine Verbindung mit Freigaben herzustellen, die die Kerberos-Authentifizierung nutzen. Dieser Vorwärts-Lookup wird dann verwendet, um den Dienstprinzipalnamen (Service Principal Name, SPN) zu formulieren, der in der Kerberos-Authentifizierungsanforderung verwendet wird. Wenn ein vorhandener SPN im KDC nicht gefunden werden kann, schlägt die Kerberos-Authentifizierung fehl.

In Windows-SMB-Umgebungen kann eine Sicherungsauthentifizierungsmethode (z. B. NTLM) ausprobiert werden. In vielen Fällen ist NTLM jedoch aus Sicherheitsgründen deaktiviert, was zu einem Zugriffsfehler bei der Kerberos-Authentifizierung führen würde. Die Windows-Ereignisanzeige protokolliert häufig die Ursache der Fehler (z. B. doppelte/fehlende SPNs, DNS-Nachschlagefehler, NTLM-Fehler usw.).

Neben der SPN-Auflösung wird DNS stark verwendet, um Hostnamen und IP-Adressen für Domänendienste wie LDAP, Kerberos-KDCs usw. über SRV-Einträge aufzulösen. Ausführlichere Informationen zu DNS in Azure NetApp Files (einschließlich der erforderlichen SRV-Einträge) finden Sie unter "Informationen zu DNS in Azure NetApp Files".

Hinweis

Wenn eine IP-Adresse für den Kerberos-Zugriff verwendet wird, hängt das Verhalten vom verwendeten NAS-Protokoll (NFS oder SMB) ab. Weitere Informationen finden Sie unter IP-Adressen für den Zugriff mit Kerberos.

LDAP

Das Lightweight Directory Access Protocol (LDAP) nutzt Back-End-Identitätsdatenbanken, um eine einheitliche Namensdienstquelle für NAS-Clients und -Server bereitzustellen, sodass sich alle teilnehmenden Geräte auf Benutzerauthentität, Gruppenmitgliedschaften und numerische IDs einigen, die dann für Dateiberechtigungen verwendet werden.

Bei Kerberos werden Benutzer- und Dienstprinzipale mit den Einträgen in den LDAP-Datenbanken als Attribute für die Prinzipalkonten gespeichert. Windows Active Directory unterstützt dies standardmäßig. In einigen Fällen (z. B. beim Erstellen von Aliasen oder Dienstprinzipalen) erfordern Benutzer und Computer das Hinzufügen oder Ändern von Dienstprinzipalnamen. Sie können diese Anforderung mithilfe der Microsoft Management Console (MMC) von Active Directory-Benutzern und -Computern oder mit PowerShell erfüllen. Weitere Informationen zum Verwalten von Dienstprinzipalnamen finden Sie unter Verwalten von Dienstprinzipalnamen.

Zusätzlich zu Dienstprinzipalnamen und numerischen IDs für die Kerberos-Authentifizierung kann LDAP auch für UNIX-Benutzer- und Gruppenidentitäten verwendet werden, die für die Namenszuordnung von Identitäten in Azure NetApp-Dateien sowie die anfängliche Authentifizierung für NFS Kerberos-Bereitstellungen über eine SPN -> UNIX-Benutzernamenzuordnung verwendet werden. Weitere Informationen finden Sie unter How NFS Kerberos works in Azure NetApp Files und LDAP's role with Kerberos in Azure NetApp Files.

Funktionsweise von SMB Kerberos in Azure NetApp-Dateien

SMB Kerberos funktioniert separat von NFS-Kerberos-Diensten, da die für jedes Protokoll erstellten Computerkonten keine Schlüsseltabellen freigeben können, da sich Änderungen an der Schlüsselversionsnummer (kvno) in einer Schlüsseltabelle auf den anderen Dienst auswirken können. Aus diesem Grund unterscheiden sich die Workflows für SMB-Dienste für Kerberos und NFS in einigen Bereichen in einigen Bereichen von den natürlichen Unterschieden in den NAS-Protokollen und natürlichen Unterschieden bei den NAS-Protokollen.

Erstkonfiguration von SMB-Diensten

SMB-Dienste in Azure NetApp Files werden zunächst durch Einrichten einer Active Directory-Verbindungkonfiguriert, die mehrere wichtige Teile für die Interaktion mit Domänendiensten definiert, darunter:

  • Primärer DNS-Server (erforderlich)
  • Sekundäres DNS
  • * Nur Active Directory DNS
  • Active Directory-Standortname (für DC-Ermittlung) (erforderlich)
  • SMB-Serverpräfixname
  • Organisationseinheit (in der Computerkonten in der Azure AD-Domäne gespeichert werden sollen)
  • AES-Verschlüsselung aktivieren/deaktivieren
  • LDAP-Signatur aktivieren/deaktivieren
  • LDAP-Konfiguration
  • SMB-Verschlüsselung zu DC
  • Privilegierte Benutzer
  • Benutzernamen-/Passwortanmeldeinformationen des Benutzers mit OU-Berechtigungen

Hinweis

Pro Konto ist nur eine Azure Active Directory (AD)-Verbindung zulässig. Sobald die Azure AD-Verbindung erstellt wurde, verwendet jedes neue Azure NetApp Files-SMB-Volume die Azure AD-Verbindungskonfiguration.

SMB Kerberos-Computerkonto

Ein Computerkonto in Active Directory enthält relevante Informationen für die Verwendung in Authentifizierungsanforderungen, einschließlich des Dienstprinzipalnamens (Service Principal Name, SPN). Wenn Sie ein SMB-Volume in Azure NetApp Files erstellen, wird die Active Directory-Verbindungskonfiguration für die Interaktion beim Erstellen eines Computerkontos verwendet, um sicheren Zugriff auf eine SMB-Freigabe über Kerberos-Authentifizierung (oder NTLM, falls aktiviert) bereitzustellen.

Neue Computerkonten werden erstellt, wenn ein SMB-Volume von Azure NetApp Files auf einer bestimmten Back-End-Ressource im Dienst bereitgestellt wird. Im Folgenden werden verschiedene Szenarien gezeigt, in denen ein SMB-Computerkonto in Azure NetApp Files-Volumenkonfigurationen erstellt oder wiederverwendet werden kann.

Szenario Ergebnis
Erstes neues SMB-Volumen Neuer SMB-Computerkonto/DNS-Name
Nachfolgende SMB-Volumen wurden in kurzer Folge vom ersten SMB-Volume erstellt Wiederverwendeter SMB-Computerkonto/DNS-Name (in den meisten Fällen).
Nachfolgende SMB-Volumen wurden viel später als das erste SMB-Volume erstellt Der Dienst bestimmt, ob ein neues Computerkonto erforderlich ist. Es ist möglich, dass mehrere Computerkonten erstellt werden können, wodurch mehrere IP-Adressendpunkte erstellt werden.
Erstes Dual-Protokoll-Volumen Neuer SMB-Computerkonto/DNS-Name
Nachfolgende duale Protokollvolumen wurden kurz nacheinander vom ersten dualen Protokollvolume erstellt Wiederverwendeter SMB-Computerkonto/DNS-Name (in den meisten Fällen)
Nachfolgende duale Protokollvolumen wurden viel später als das erste duale Protokollvolume erstellt Der Dienst bestimmt, ob ein neues Computerkonto erforderlich ist. Es ist möglich, dass mehrere Computerkonten erstellt werden können, wodurch mehrere IP-Adressendpunkte erstellt werden
Erstes SMB-Volumen nach dualen Protokollvolumen erstellt Neuer SMB-Computerkonto/DNS-Name
Erstes duales Protokollvolumen, das nach dem SMB-Volumen erstellt wurde Neuer SMB-Computerkonto/DNS-Name

Das für das Azure NetApp Files SMB (oder duale Protokoll) erstellte SMB-Computerkonto verwendet eine Benennungskonvention, die dem von Active Directoryerzwungenen Maximalwert von 15 Zeichen entspricht. Der Name verwendet die Struktur des [SMB-Serverpräfixes, der in der Azure AD-Verbindungskonfiguration angegeben ist]-[eindeutiger numerischer Bezeichner].

Wenn Sie beispielsweise Ihre Azure AD-Verbindungen so konfiguriert haben, dass das SMB-Serverpräfix "AZURE" verwendet wird, ähnelt das SMB-Computerkonto, das Azure NetApp Files erstellt, "AZURE-7806". Dieser Name wird im UNC-Pfad für die SMB-Freigabe (z. B. \AZURE-7806) verwendet und ist der Name, den dynamische DNS-Dienste zum Erstellen des A/AAAA-Eintrags verwenden.

Hinweis

Da ein Name wie "AZURE-7806" schwer zu merken ist, ist es vorteilhaft, einen CNAME-Eintrag als DNS-Alias für Azure NetApp Files-Volumen zu erstellen. Weitere Informationen finden Sie unter Erstellen von SMB-Serveraliasen.

Diagramm mehrerer Computerkonten/DNS-Einträge in Azure NetApp Files.

In einigen Fällen kann die Konfiguration beim Erstellen mehrerer SMB- und/oder Dualprotokollvolumen mit mehreren unterschiedlichen SMB-Computerkonten und DNS-Namen enden.

Wenn ein einzelner Namespace für den Benutzerzugriff über die Volumen hinweg gewünscht wird, kann dies eine Herausforderung in der Konfiguration darstellen, da ein einzelner CNAME-Alias nur auf einen einzelnen A/AAAA-Hostdatensatz verweisen kann, während die Verwendung mehrerer identischer A/AAAA-Datensatzaliasen dazu führen kann, dass der Datenzugriff auf Volumen über verschiedene SMB-Computerkonten hinweg unvorstellbar ist, da es keine Garantie gibt, dass der Endpunkt, den der Client im DNS-Nachschlagevorgang auswählt, das erwartete Volumen aufgrund der Roundrobin-Art der DNS-Eintragsauswahl in diesen Konfigurationen enthält.

Um diese Einschränkung zu beheben, können Azure NetApp Files-Volumen als Ziele in einer Microsoft Distributed File System (DFS) -Konfiguration teilnehmen, die eine Möglichkeit bieten kann, mehrere SMB-Volumen einem einzelnen Namespace-Einstiegspunkt zuzuordnen.

Diagramm eines verteilten Dateisystems in Azure NetApp Files.

SMB Kerberos SPN-Erstellungsworkflow

Das folgende Diagramm veranschaulicht, wie ein SMB Kerberos SPN erstellt wird, wenn ein Azure NetApp Files SMB- oder duales Protokollvolume erstellt wird. SMB-SPNs sind SMB-Computerkontoobjekten in der Domäne zugeordnet. Der SPN kann über die Computerkontoeigenschaften mithilfe des Attribut-Editors in der Erweiterten Ansicht angezeigt und verwaltet werden.

Screenshot der Azure-SMB-Eigenschaften.

Sie können Eigenschaften auch mit dem setspn Befehlanzeigen und verwalten.

Screenshot des Befehls

Dieser Prozess folgt den gleichen Schritten wie beim Beitritt eines regulären Windows-Clients zu einer Domäne (DNS, LDAP, Kerberos, RPC-Abfragen über benannte Pipes).

Diagramm des Kerberos-Computerkontos.

In den meisten Fällen ist das Wissen detaillierter Schritte für tägliche Verwaltungsaufgaben nicht erforderlich, ist jedoch bei der Problembehandlung bei Fehlern bei dem Versuch, ein SMB-Volumen in Azure NetApp-Dateien zu erstellen, nützlich.

Ausführliche Schritte

Für detaillierte Schritte, wie ein SMB-Computerkonto in Azure NetApp Files erstellt wird, erweitern Sie die Liste.

  • Die DNS-Suche erfolgt mithilfe der DNS-Konfiguration für den SRV-Eintrag eines Kerberos-KDC. Azure NetApp Files verwendet die folgenden SRV-Einträge in ihren Anforderungen.

    • _kerberos._tcp.dc._msdcs.CONTOSO.COM
    • _kerberos._tcp.CONTOSO.COM (wenn vorherige Abfrage keine Ergebnisse zurückgibt)

  • Die DNS-Suche erfolgt mithilfe der Hostnamen, die in der SRV-Abfrage für die A/AAAA-Einträge der KDCs zurückgegeben werden.

    • Es wird ein LDAP-Ping (LDAP-Bindungs- und RootDSE-Abfrage ) ausgeführt, um mithilfe der Abfrage ( &(DnsDomain=CONTOSO.COM)(NtVer=0x00000016)) mit einem Attributfilter für NetLogon nach verfügbaren NetLogon-Servernzu suchen. Neuere Windows-Domänencontrollerversionen (größer als 2008) verfügen nicht über den NtVer vorhandenen Wert .

  • Eine DNS-Abfrage wird von Azure NetApp Files ausgeführt, um die LDAP-Server in der Domäne mithilfe der folgenden SRV-Einträge zu finden:

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

    Hinweis

    Diese Abfragen treten mehrmals im gleichen Aufruf über verschiedene Teile des Prozesses auf. DNS-Probleme können bei diesen Aufrufen Langsamkeit erzeugen oder mit Timeouts Fehler abschließen. - Wenn die Abfragen keinen Eintrag finden oder die gefundenen Einträge nicht kontaktiert werden können, schlägt die Erstellung des SMB-Volumens fehl. – Wenn die DNS-Abfragen erfolgreich sind, werden die nächsten Schritte verarbeitet.

  • ICMP (ping) wird gesendet, um zu überprüfen, ob die von DNS zurückgegebenen IP-Adressen erreichbar sind.

  • Wenn Ping im Netzwerk durch Firewallrichtlinien blockiert wird, schlägt die ICMP-Anforderung fehl. Stattdessen werden LDAP-Pings verwendet.

  • Ein weiteres LDAP-Ping wird ausgeführt, um mithilfe der Abfrage (&(&(DnsDomain=CONTOSO.COM)(Host=KDChostname.contoso.com))(NtVer=0x00000006)) mit dem Attributfilter NetLogon nach verfügbaren NetLogon-Servern zu suchen. Neuere Windows-Domänencontrollerversionen (größer als 2008) verfügen nicht über den NtVer-Wert .

  • Eine AS-REQ-Authentifizierung wird vom Azure NetApp Files-Dienst gesendet, indem der Benutzername verwendet wird, der mit der Active Directory-Verbindung konfiguriert ist.

  • Der DC antwortet mit KRB5KDC_ERR_PREAUTH_REQUIRED, der den Dienst auffordern, das Passwort für den Benutzer sicher zu senden.

  • Eine zweite AS-REQ wird mit den Vorauthentifizierungsdaten gesendet, die für die Authentifizierung beim KDC erforderlich sind, um mit der Erstellung des Computerkontos fortzufahren. Bei erfolgreicher Ausführung wird ein Ticketgewährungsticket (TGT) an den Dienst gesendet.

  • Bei erfolgreicher Ausführung wird vom Service ein TGS-REQ gesendet, um das CIFS Service Ticket (cifs/kdc.contoso.com) vom KDC mit dem im AS-REP empfangenen TGT anzufordern.

  • Eine neue LDAP-Bindung mit dem CIFS-Dienstticket wird ausgeführt. Abfragen werden von Azure NetApp Files gesendet:

    • RootDSE-Basissuche für den ConfigurationNamingContext DN der Domäne
    • OneLevel-Suche nach CN=Partitionen im DN, die für den ConfigurationNamingContext mithilfe des Filters (&(&(objectClass=crossRef)(nETBIOSName=*))(dnsRoot=CONTOSO.COM)) für das Attribut NETBIOSname abgerufen wurden.
    • Eine Basissuche mit dem Filter (|(objectClass=organizationalUnit)(objectClass=container)) wird für die in der Active Directory-Verbindungskonfiguration angegebene OU ausgeführt. Wenn nichts angegeben wird, dann wird der Standardwert OU=Computers verwendet. Dadurch wird überprüft, ob der Container vorhanden ist.
    • Eine Unterstruktursuche wird auf der Basis-DN der Domäne mithilfe des Filters (sAMAccountName=ANF-XXXX$) ausgeführt, um zu überprüfen, ob das Konto bereits vorhanden ist.
      • Wenn das Konto vorhanden ist, wird es wiederverwendet.
    • Wenn das Konto nicht vorhanden ist, wird es erstellt, vorausgesetzt, der Benutzer verfügt über Berechtigungen zum Erstellen und Ändern von Objekten im Container mithilfe eines addRequest LDAP-Befehls. Die folgenden LDAP-Attribute werden für das Konto festgelegt:
    attribute Wert
    CN ANF-XXXX
    sAMAccountName ANF-XXXX$
    objectClass
    • Top
    • Person
    • OrganizationalPerson
    • Benutzer
    • Computer
    servicePrincipalName
    • HOST/ANF-XXXX
    • HOST/anf-xxxx.contoso.com
    • CIFS/anf-xxxx.contoso.com
    userAccountControl 4096
    operatingSystem NetApp Release
    dnsHostName ANF-XXXX.CONTOSO.COM
    • Wenn der addRequest Fehler auftritt, schlägt die Volumenerstellung fehl. Ein addRequest kann aufgrund falscher Berechtigungen für das Containerobjekt fehlschlagen.
    • Wenn dies addRequest erfolgreich ist, wird eine LDAP-Suche mit dem Filter (sAMAccountName=ANF-XXXX$) zum Abrufen des objectSid-Attributs ausgeführt.
    • Eine SMB2 -Unterhaltung "Negotiate protocol" wird ausgeführt, um die unterstützte Kerberos mechTypes aus dem KDC abzurufen.
    • Ein SMB2 -Sitzungssetup mithilfe des CIFS SPN und der höchsten Unterstützung mechType und einer "Strukturverbindung" mit IPC$ wird ausgeführt.
    • Eine SMB2-Datei lsarpc wird in der IPC$-Freigabe erstellt.
    • Eine Bindung an DCERPC wird ausgeführt. Die lsarpc Datei wird dann gelesen.
    • Die folgenden LSA-Anforderungen werden dann ausgeführt:

  • Ein TGS-REQ mit dem TGT wird durchgeführt, um das Ticket für den kadmin/changepw SPN abzurufen, der dem krbtgt Konto zugeordnet ist.

  • Eine KPASSWD-Anforderung wird vom Dienst an den KDC gestellt, um das Passwort des Computerkontos zu ändern.

  • Eine LDAP-Abfrage wird mit dem Filter (sAMAccountName=ANF-XXXX) für die Attribute distinguishedName und isCriticalSystemObject.

  • Wenn das Konto isCriticalSystemObject "false" ist (Standard), wird der abgerufene DN verwendet, um ein modifyRequest Attribut msDs-SupportedEncryptionTypeszu formulieren. Dieser Wert wird auf 30 festgelegt, was DES_CBC_MD5 (2) + RC4 (4) + AES 128 (8) + AES 256 (16)entspricht.

  • Es wird ein zweites "Negotiate protocol"/Kerberos ticket exchange/"Session setup"/"Tree connect" mit IPC$ ausgeführt. Das Computerkonto des SMB-Servers (ANF-XXXX$) dient als Kerberos-Prinzipal.

  • NetLogon, NetrServer ReqChallenge/Authenticate2 Communications werden abgeschlossen.

  • Es wird ein dritter "Negotiate protocol:/Kerberos ticket exchange/"Session setup"/"Tree connect" mit IPC$ durchgeführt; Das Computerkonto des SMB-Servers (ANF-XXXX$) wird als Kerberos-Prinzipal verwendet.

  • Sowohllsarpc als auch NetLogon-Verbindungen werden als endgültige Überprüfung des Kontos vorgenommen.

SMB-Freigabeverbindungsworkflow (Kerberos)

Wenn ein Azure NetApp Files-Volume mithilfe von Kerberos bereitgestellt wird, wird während der Mehreren Sitzungseinrichtungsanforderungen ein Kerberos-Ticketaustausch verwendet, um sicheren Zugriff auf die Freigabe zu ermöglichen. In den meisten Fällen ist das Wissen detaillierter Schritte für tägliche Verwaltungsaufgaben nicht erforderlich. Dieses Wissen ist hilfreich bei der Problembehandlung bei dem Versuch, auf ein SMB-Volume in Azure NetApp Files zuzugreifen.

Diagramm des SMB-Freigabeverbindungsworkflows.

Um zu erfahren, wie auf die SMB-Freigabe in Azure NetApp Files zugegriffen wird, erweitern Sie die Liste.
  • Der Client versucht, mithilfe des UNC-Pfads in Azure NetApp Files auf eine SMB-Freigabe zuzugreifen. Standardmäßig enthält der UNC-Pfad den SMB-Servernamen (wie ANF-XXXX)
  • DNS wird abgefragt, um den Hostnamen einer IP-Adresse zuzuordnen
  • Eine anfängliche SMB2-Unterhaltung "Negotiate Protocol" findet statt
    • Eine Anforderung wird vom Client gesendet, um zu ermitteln, welche SMB-Dialekte vom Server unterstützt werden und was der anfordernde Client unterstützt
    • Der Server antwortet mit dem, was er unterstützt, einschließlich:
      • Sicherheitsmodus (Signieren oder nicht)
      • SMB-Version
      • Server-GUID
      • Unterstützte Funktionen (DFS, Leasing, große MTU, Multichannel, persistente Handles, Verzeichnisleasing, Verschlüsselung)
      • Max. Transaktionsgröße
      • Max. Lese-/Schreibgröße
      • Sicherheits-Blob (Kerberos oder NTLM)
  • Eine zweite SMB2 -Unterhaltung "Negotiate Protocol" findet als "Vorautorisierung"/Anmeldung statt
    • Die Anforderung vom Client umfasst:
      • Vorautorisierungshash
      • Unterstützte Sicherheitsmodi (Signieren oder nicht)
      • Unterstützte Funktionen (DFS, Leasing, große MTU, Multichannel, persistente Handles, Verzeichnisleasing, Verschlüsselung)
      • Client-GUID
      • Unterstützte SMB-Dialekte
    • Wenn der Vorautorisierungshash akzeptiert wird, antwortet der Server mit:
      • Sicherheitsmodus (Signieren oder nicht)
      • Unterstützte Funktionen (DFS, Leasing, große MTU, Multichannel, persistente Handles, Verzeichnisleasing, Verschlüsselung)
      • Max. Transaktionsgröße
      • Max. Lese-/Schreibgröße
      • Sicherheits-Blob (Kerberos oder NTLM)
      • SMB-Vorautorisierungsintegritäts- und Verschlüsselungsfunktionen
  • Wenn die Protokollverhandlung erfolgreich verläuft, wird eine Anforderung "Sitzungssetup" gestellt.
    • Setup verwendet den Vorautorisierungshash aus der Protokollverhandlung.
    • Setup informiert den SMB-Server, was der anfordernde Client unterstützt, einschließlich:
      • Strukturgröße
      • Sitzungsbindungsflag
      • Sicherheitsmodus (Signierung aktiviert/erforderlich)
      • Capabilities
      • Unterstützte Kerberos-Verschlüsselungstypen
  • Eine Antwort „Sitzungsenrichtung“ wird gesendet.
    • SMB-Gutschriften werden gewährt.
    • Sitzungs-ID wird eingerichtet.
    • Sitzungsflags werden festgelegt (Gast, Null, verschlüsseln).
    • Der Kerberos-Verschlüsselungstyp ist definiert.
  • Eine Strukturverbindungsanforderung wird vom Client für die Verbindung mit der SMB-Freigabe gesendet.
    • Freigabekennzeichnungen/Funktionen werden zusammen mit Freigabeberechtigungen vom Server gesendet.
  • Der ioctl Befehl FSCTL_QUERY_NETWORK_INTERFACE_INFO wird gesendet, um die IP-Adresse des SMB-Servers abzurufen.
  • Der SMB-Server in Azure NetApp Files meldet die Netzwerkinformationen zurück, einschließlich: * IP-Adresse * Schnittstellenfunktion (RSS ein oder aus) * Anzahl der RSS-Warteschlangen * Linkgeschwindigkeit
  • Eine Strukturverbindungsanforderung wird vom Client für die Verbindung mit der administrativen IPC$-Freigabegesendet.
    • Die IPC$-Freigabe ist eine Ressource, die die benannten Rohre teilt, die für die Kommunikation zwischen Programmen unerlässlich sind. Die IPC$-Freigabe wird während der Remoteverwaltung eines Computers und beim Anzeigen der gemeinsam genutzten Ressourcen eines Computers verwendet. Sie können die Freigabeeinstellungen, Freigabeeigenschaften oder ACLs der IPC$-Freigabe nicht ändern. Sie können die IPC$-Freigabe auch nicht umbenennen oder löschen.
    • Eine benannte srvsvc Datei wird in der Freigabe als Diensthandleerstellt.
  • Eine DCERPC-Bindung erfolgt an die srvsvc Datei, um eine sichere Verbindungherzustellen.
    • Die Datei wird mit den zuvor abgerufenen Informationen in die Datei geschrieben.
  • Ein Kerberos TGS-REQ wird vom Windows-Client an den KDC ausgestellt, um ein Dienstticket (ST) für den SMB-Dienst zu erhalten.
  • Ein NetShareGetInfo Befehl wird vom SMB-Client an den Server ausgeführt und eine Antwort wird gesendet.
  • Das SMB-Dienstticket wird aus dem KDC abgerufen.
  • Azure NetApp Files versucht, den Windows-Benutzer zuzuordnen, der Zugriff auf die Freigabe an einen gültigen UNIX-Benutzer anfordert.
    • Eine Kerberos TGS-Anforderung wird mithilfe der Kerberos-Anmeldeinformationen des SMB-Servers durchgeführt, die mit der Schlüsseltabelle des SMB-Servers gespeichert sind, von der ursprünglichen SMB-Servererstellung zur Verwendung für eine LDAP-Serverbindung.
    • LDAP wird nach einem UNIX-Benutzer gesucht, der dem SMB-Benutzer zugeordnet ist, der den Freigabezugriff anfordert. Wenn kein UNIX-Benutzer in LDAP vorhanden ist, wird der UNIX-Standardbenutzer pcuser von Azure NetApp Files für die Namenszuordnung verwendet (Dateien/Ordner, die in dualen Protokollvolumen geschrieben wurden, verwenden den zugeordneten UNIX-Benutzer als UNIX-Besitzer).
  • Eine weitere Aushandlung der Protokoll-/Sitzungsanforderungs-/Strukturverbindung wird ausgeführt, diesmal wird der Kerberos-SPN des SMB-Servers zur IPC$-Freigabe von Active Directory DC verwendet.
    • Ein benanntes Rohr wird über die srvsvcFreigabe eingerichtet.
    • Eine NETLOGON-Sitzung wird für die Freigabe eingerichtet, und der Windows-Benutzer wird authentifiziert.
  • Wenn Berechtigungen dies für den Benutzer zulassen, listet die Freigabe die Dateien und Ordner auf, die im Volume enthalten sind.

Hinweis

Azure NetApp Files fügt dem Kerberos-Kontextcache für den Client Einträge hinzu. Diese Einträge befinden sich im Cache für die Dauer des Kerberos-Tickets (vom KDC festgelegt und von der Kerberos-Richtliniegesteuert).

Erstellen von SMB-Serveraliasen

Wenn Azure NetApp Files einen SMB-Server mit einer Benennungskonvention von [SMB-Serverpräfix in azure AD-Verbindungskonfiguration] erstellt– [eindeutiger numerischer Bezeichner]. (Ausführliche Informationen zum eindeutigen numerischen Bezeichner finden Sie unter SMB Kerberos-Computerkonto). Diese Formatierung bedeutet, dass SMB-Servernamen nicht auf benutzerfreundliche Weise erstellt werden. Beispielsweise ist ein Name von "SMB-7806" schwieriger zu merken als etwas ähnliches wie "AZURE-FILESHARE."

Aufgrund dieses Verhaltens möchten Administratoren möglicherweise benutzerfreundliche Aliasnamen für Azure NetApp Files-Volumen erstellen. Dazu muss ein DNS-kanonischer Name (CNAME) auf den vorhandenen DNS A/AAAA-Eintrag auf dem Server verweisen.

Wenn ein CNAME erstellt und in UNC-Pfadanforderungen verwendet wird (z. B. anstelle), \\SMB-7806 leitet DNS die CNAME-Anforderung (AZURE-FILESHARE.contoso.com) an den richtigen A/AAAA-Eintrag (SMB-7806.contoso.com) weiter, \\AZURE-FILESHAREder im Kerberos SPN-Abruf (cifs/SMB-7806) verwendet wird. Dadurch wird der Kerberos-Zugriff auf die SMB-Freigabe ermöglicht, während der Aliasname verwendet wird.

Wenn ein DNS A/AAAA-Eintrag erstellt wird (z. B. AZURE-FILESHARE.contoso.com) und versucht, als Alias verwendet zu werden, schlagen Kerberos-Anforderungen fehl. Der Fehler ist das Ergebnis des erstellten SPN, der zur Authentifizierung bei der Freigabe verwendet wird (cifs/AZURE-FILESHARE), die nicht mit dem Kerberos-SPN für den SMB-Server (cifs/SMB-7806) übereinstimmen. Der Fehler kann verringert werden, wenn ein anderer SPN erstellt und an das SMB-Servercomputerkonto angefügt wird (wie cifs/AZURE-FILESHARE).

Unterstützte SMB-Serverfunktionen in Azure NetApp Files

Wenn die Anforderung des SMB-Protokolls "aushandeln" erfolgt, wird der SMB-Server von Azure NetApp Files zur Unterstützung bestimmter Funktionen abgefragt. Die folgende Tabelle zeigt die abgefragten Funktionen und die Antwort, die von einem SMB-Volume von Azure NetApp Files zurückgegeben wird, wenn eine Sitzungseinrichtung/Strukturverbindung ausgeführt wird.

SMB-Funktion Von Azure NetApp Files unterstützt?
DFS-Ziel Ja
Leasen Ja
Großes MTU Ja
SMB-Multikanal Ja
Persistente SMB-Handles Ja
Directory Leasing No
SMB-Verschlüsselung Ja (falls aktiviert)

Unterstützte SMB-Freigabefunktionen und -eigenschaften in Azure NetApp Files

Während des SMB-Freigabezugriffs wird eine Anforderung "Strukturverbindung" ausgeführt, und die unterstützten SMB-Freigabefunktionen und -eigenschaften werden vom Client an den Azure NetApp Files-Server abgefragt. Die folgende Tabelle zeigt die abgefragten Freigabefunktionen und die Antwort, die von einem SMB-Volume von Azure NetApp Files zurückgegeben wurde, wie in einer Paketerfassung zu sehen ist.

SMB-Freigabefunktion Von Azure NetApp Files unterstützt?
Ständig verfügbar (CA) Ja, für bestimmte Workloads* (sofern aktiviert)
Aufskalieren No
Cluster No
Asymmetrisch No
Umleitung zum Besitzer No

* Siehe Aktivieren der kontinuierlichen Verfügbarkeit auf vorhandenen SMB-Volumen für unterstützte Workloads.

In der folgenden Tabelle werden die abgefragten Freigabeeigenschaften und die von einem Azure NetApp Files SMB-Volumen zurückgegebene Antwort angezeigt.

SMB-Freigabefunktion Von Azure NetApp Files unterstützt?
DFS-Ziel Ja
DFS-Stamm No
Exklusives Öffnen einschränken No
Erzwungene freigegebene Löschung No
Zulassen der Namespacezwischenspeicherung No
Zugriffsbasierte Aufzählung Ja (falls aktiviert)
Oplock der Stufe II erzwingen No
Aktivieren von Hash V1 No
Aktivieren von Hash v2 No
Verschlüsselung erfordert Ja (falls aktiviert)
Identitätsremoting No
Komprimierte E/A No
Isolierter Transport No

Funktionsweise von NFS Kerberos in Azure NetApp-Dateien

NFS Kerberos funktioniert separat von SMB-Diensten, da die Computerkonten für jedes Protokoll aufgrund des Potenzials für Änderungen an der Schlüsselversionsnummer (kvno) in einer Schlüsseltabelle, die sich auf den anderen Dienst auswirken, nicht gemeinsam nutzen können. Daher unterscheiden sich die Workflows für SMB-Dienste für Kerberos und NFS für Kerberos in einigen Bereichen von der Funktionalität.

Anfängliche Konfiguration des Kerberos-Bereichs

Der NFS-Kerberos-Bereich wird konfiguriert, wenn die Kerberos-Bereichsinformationen im Azure NetApp Files-Portal auf der Active Directory-Verbindungsseite ausgefüllt werden.

Screenshot der Kerberos-Bereichskonfiguration.

Der Azure AD-Servername und die KDC-IP werden zum Herstellen einer Verbindung mit den Azure AD-KDC-Diensten bei der Erstellung des anfänglichen Computerkontos verwendet. Der Azure NetApp Files-Dienst nutzt die vorhandenen Domäneninformationen, um die restliche Bereichskonfiguration auszufüllen. Zum Beispiel:

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

Wenn der NFS-Kerberos-Bereich konfiguriert ist, wird ein lokaler Hosteintrag im Dienst hinzugefügt, wobei der in der Konfiguration angegebene KDC angegeben ist. Wenn der Bereich geändert wird, wird der lokale Hosteintrag auch im Dienst geändert.

Diagramm der Kerberos-Bereichskonfiguration.

Dieser lokale Hosteintrag fungiert als "letzte Möglichkeit", wenn ein KDC-Ausfall auf dem in der Bereichskonfiguration angegebenen KDC auftritt und redundante KDCs über DNS nicht abgefragt werden kann.

Hinweis

Wenn der KDC im Kerberos-Bereich für die Wartung (z. B. für Upgrades oder das Außerbetriebsetzen eines Servers) heruntergesetzt werden muss, empfiehlt es sich, den Bereich so zu konfigurieren, dass ein KDC verwendet wird, das nicht gewartet wird, um Ausfälle zu vermeiden.

Erste Erstellung des Computerkontos/SPN

Wenn Kerberos auf einem Azure NetApp Files-Volume aktiviert ist, wird ein Computerkonto/prinzipal mit dem Namen NFS-{SMB-server-name} in der Domäne in der angegebenen OU in Active Directory-Verbindungen (Organisationseinheit) erstellt. Computerkontonamen werden nach 15 Zeichen abgeschnitten.

Hinweis

Wenn Sie Linux-Clients mit Hostnamen mit mehr als 15 Zeichen zu einer Active Directory-Domäne hinzufügen, werden ihre Kerberos-Computerkonto-SPNs abgeschnitten. Zum Beispiel verfügt ein Linux-Client mit einem Namen über MORE-THAN-FIFTEEN einen Computerkontonamen MORE-THAN-FIFT$, der zu einem SPN von MORE-THAN-FIFT$@CONTOSO.COM. Wenn DNS einen Clienthostnamen nachschlagen, findet es den längeren Namen und versucht, diesen Namen in einer SPN-Anforderung ( . MORE-THAN-FIFTEEN@CONTOSO.COM) Da dieser SPN nicht vorhanden ist, versucht der Client, den nächsten SPN in der Schlüsseltabelle in der Anforderung zu verwenden (in der Regel Host/Hostname). Nur Computerkontoname SPNs arbeiten nativ mit Azure NetApp Files NFS Kerberos. Stellen Sie daher sicher, dass die Linux-Clienthosts, die für NFS Kerberos mit Azure NetApp Files verwendet werden, 15 Zeichen nicht überschreiten. Wenn Sie den Host/Hostnamen SPN verwenden möchten, konfigurieren Sie alternativ einen UNIX-Benutzer in LDAP mit dem Benutzernamen "host". Diese Konfiguration stellt eine Krb-Unix-Namenszuordnung für den SPN bereit.

In Azure NetApp Files werden Kerberos-Keyblocks (oder Schlüsseltabelleeinträge) dem Dienst mit dem NFS-Dienst SPN (nfs/nfs-server-name.contoso.com@CONTOSO.COM) hinzugefügt. Es werden mehrere Einträge erstellt: einer für jeden unterstützten Verschlüsselungstyp. In Azure NetApp Files wird nur der AES-256-Verschlüsselungstyp für NFS Kerberos unterstützt.

In den meisten Fällen ist das Kennen dieser Schritte nicht für tägliche Verwaltungsaufgaben erforderlich, sie sind jedoch bei der Problembehandlung bei Fehlern hilfreich, wenn Sie versuchen, ein NFS-Kerberos-Volume in Azure NetApp-Dateien zu erstellen.

NFS Kerberos SPN-Erstellungsworkflow

Das folgende Diagramm zeigt, wie ein NFS SPN erstellt wird, wenn ein Azure NetApp Files NFS- oder duales Protokollvolume mit aktiviertem Kerberos erstellt wird. In den meisten Fällen ist das Wissen detaillierter Schritte für tägliche Verwaltungsaufgaben nicht erforderlich, es ist jedoch bei der Problembehandlung bei Fehlern bei dem Versuch, ein SMB-Volume in Azure NetApp-Dateien zu erstellen, nützlich.

Diagramm des NFS Kerberos SPN-Erstellungsworkflows.

Ausführliche Schritte dazu, wie ein NFS Kerberos SPN mit Azure NetApp Files erstellt wird, erweitern Sie die Liste.
  • Administratoranmeldeinformationen, die an KDC übergeben werden, die in der Bereichskonfiguration mithilfe des Benutzernamens angegeben wurden, der für die Verwendung in der Active Directory-Verbindung vorgesehen ist – Der Benutzer muss über die Berechtigung zum Anzeigen/Erstellen von Objekten in der angegebenen OU verfügen.
  • Die in der Active Directory-Verbindungskonfiguration von Azure NetApp Files angegebenen DNS-Server werden von Azure NetApp Files für die Kerberos-Diensteinträge (SRV) in den folgenden Formaten abgefragt:
    • URI-Abfrage für _kerberos.CONTOSO.COM
    • SRV-Abfrage für _kerberos-master._udp. CONTOSO.COM
    • SRV-Abfrage für _kerberos-master._tcp. CONTOSO.COM

Hinweis

Diese Abfragen treten mehrmals im gleichen Aufruf über verschiedene Teile des Prozesses auf. DNS-Probleme können zu Langsamkeit bei diesen Aufrufen oder zum Abschließen von Fehlern führen. Diese Datensätze sind in Active Directory-Bereitstellungen nicht standardmäßig vorhanden und müssen manuell erstellt werden.

  • Wenn die Abfragen keinen Eintrag finden oder die gefundenen Einträge nicht kontaktiert oder als Master-KDC verwendet werden können, wird eine A-Datensatzabfrage mit dem Bereichsnamen in der NFS Kerberos-Bereichskonfiguration als letztes Mittel verwendet, um eine Verbindung mit dem KDC über Port 88 herzustellen.
  • Während der Konfiguration von NFS Kerberos wird der lokalen Hostdatei ein statischer Hosteintrag für die angegebene KDC-Datei als Sicherung hinzugefügt, wenn DNS-Nachschlagevorgänge fehlschlagen.
  • Wenn ein zwischengespeicherter DNS-Eintrag für den Bereich vorhanden ist, wird er verwendet. Wenn nicht, wird der lokale Dateieintrag verwendet. Zwischengespeicherte DNS-Einträge leben so lange, wie die Time to Live (TTL) für den DNS-Eintrag konfiguriert ist. Der lokale Dateieintrag ist mit einer TTL von 86.400 Sekunden (24 Stunden) konfiguriert. Die Konfiguration "ns-switch" für Hostsuche in Azure NetApp Files verwendet zuerst Dateien und dann DNS. Wenn der lokale Eintrag gefunden wird, werden keine weiteren Abfragen ausgeführt.
  • Das beim Erstellen der Active Directory-Verbindung erstellte SMB-Computerkonto wird als Anmeldeinformationen für eine Active Directory-LDAP-Bindung mit SASL/GSS über Port 389 verwendet, um nach vorhandenen Einträgen des gewünschten SPN- oder Computerkontonamens zu suchen. Wenn der Name des SPN- oder Computerkontos bereits vorhanden ist, wird ein Fehler gesendet. Wenn der SPN in der LDAP-Abfrage nicht vorhanden ist, wird die Erstellung des Computerkontos in der angegebenen OU mit Einträgen für die folgenden Attribute ausgeführt, die von Azure NetApp Files festgelegt wurden:
    • cn (NFS-MACHINE)
    • sAMAccountName (NFS-MACHINE$)
    • objectClass (top, person, organizationalPerson, user, computer)
    • servicePrincipalName (host/NFS-MACHINE, host/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)
  • Das Passwort für das NFS-Kerberos-Computerkonto wird für das NFS-MACHINE-Konto über Port 464 festgelegt.
  • Kerberos-Schlüsselblocks (Schlüsseltabellen) für den NFS-SPN werden im Azure NetApp Files-Dienst gespeichert.
  • Im Azure NetApp Files-Dienst wird eine statische Namenszuordnungsregel erstellt, um sicherzustellen, dass der Stammbenutzer für jeden NFS-Kerberos-Client dem Stamm zugeordnet wird, wenn Kerberos verwendet wird.
  • Eine Datei krb5.conf wird den internen Systemen des Diensts mit den NFS-Bereichsinformationen hinzugefügt.

NFS Kerberos-Bereitstellungen

Wenn ein Azure NetApp Files-Volume mithilfe von Kerberos-Sicherheitsaromen über NFS bereitgestellt wird, wird der folgende Workflow ausgeführt. Ausführlichere Informationen zu Kerberos finden Sie unter Kerberos Network Authentication Service (V5) Synopsis.

Diagramm des NFS Kerberos-Bereitstellungsworkflows.

Ausführliche Schritte dazu, wie ein NFS Kerberos-Volume mit Azure NetApp Files bereitgestellt wird, erweitern Sie die Liste.
  • Der Client versucht eine Bereitstellung an einem NFS-Exportpfad in Azure NetApp Files und gibt den -oKrb5-Sicherheitsgeschmack (oder krb5i oder krb5p) an.
  • DNS wird verwendet, um eine Anforderung für einen NFS-Dienstprinzipal an Azure NetApp Files über A/AAAA-Eintrag oder PTR zu formulieren (je nachdem, wie der Bereitstellungsbefehl ausgegeben wurde).
  • Der Client ruft einen TGT aus dem KDC über einen AS-REQ-Aufruf mithilfe des CLIENT-Prinzipalnamens ab, der in der Schlüsseltabelle des Clients zu finden ist.
  • Der Exportpfad wird überprüft, um sicherzustellen, dass er im Dateisystem vorhanden ist.
  • Die Exportrichtlinienregel wird überprüft, um sicherzustellen, dass der Kerberos-Zugriff auf den Exportpfad zulässig ist.<
  • Das NFS-Dienstticket wird vom KDC vom Client über einen AP-REQ-Aufrufangefordert. Azure NetApp Files überprüft die Schlüsseltabelle auf einen gültigen Eintrag mit einem gültigen Verschlüsselungstyp unter Verwendung des TGT vom Client, der vom KDC abgerufen wurde.
  • Wenn die TGT gültig ist, wird ein Dienstticket ausgestellt.
  • Der Client-SPN (z. B. CLIENT$@CONTOSO.COM) wird dem Stammbenutzer über die Namenszuordnungsregel in Azure NetApp Files zugeordnet.
  • Der Stammbenutzer wird in den Namensdienstdatenbanken (Dateien und LDAP) zur Existenz-/Gruppenmitgliedschaft abgefragt.
  • Eine LDAP-Bindung mithilfe des SMB-Servercomputerkontos wird ausgeführt, um eine LDAP-Suche für den Stammbenutzer zuzulassen.
  • Da der Stamm immer in Azure NetApp-Dateien vorhanden ist, sollte dies keine Probleme verursachen, aber LDAP-Abfragen für den Stamm können fehlschlagen. Diese Fehler können ignoriert werden.
  • Das NFS-Dienstticket wird an den Client zurückgegeben und die Bereitstellung ist erfolgreich. Der Stammbenutzer verfügt über Stammzugriff auf die Kerberos-Bereitstellung über den Computerkontoprinzipal des Clients (sichtbar mit dem klist -e Befehl vom Client).
  • Azure NetApp Files fügt dem Kerberos-Kontextcache für den Client Einträge hinzu. Diese Einträge befinden sich im Cache für die Dauer des Kerberos-Tickets, das vom KDC festgelegt und von der Kerberos-Richtliniegesteuert wird.
  • NFSv4.1 sendet regelmäßig (alle 20 Sekunden) Aktualisierungsupdates für Kerberos-Tickets als "keepalives.“

NFS Kerberos-Bereitstellungszugriff mit Benutzerprinzipalen

Wenn von einem Benutzer (außer dem Stammbenutzer, der das Computerkonto SPN verwendet) auf eine AZURE NetApp Files NFS Kerberos-Bereitstellung zugegriffen wird, wird der folgende Workflow ausgeführt.

Diagramm des NFS Kerberos-Bereitstellungszugriffs mit Benutzerprinzipalen.

Ausführliche Schritte dazu, wie auf ein NFS-Kerberos-Volume mit einem nichtroot-Benutzer mit Azure NetApp Files zugegriffen wird, erweitern Sie die Liste.
  • Der Benutzer meldet sich beim KDC entweder mit einem Benutzernamen-/Passwortaustausch oder über eine Schlüsseltabellen-Datei an, um einen TGT über einen AS-REQ-Aufruf abzurufen, der zum Sammeln eines Diensttickets vom Azure NetApp Files-Volume verwendet werden soll.
  • Die Exportrichtlinienregel wird überprüft, um sicherzustellen, dass der Kerberos-Zugriff auf den Exportpfad für den Clientcomputer zulässig ist
  • Azure NetApp Files sucht nach einem zwischengespeicherten NFS-Dienstticket. Wenn keine vorhanden ist, wird das NFS-Dienstticket über einen AP-REQ-Aufruf angefordert, und der Dienst überprüft die Schlüsseltabelle auf einen gültigen Eintrag mit einem gültigen Verschlüsselungstyp unter Verwendung des TGT vom Client, der vom KDC erworben wurde
  • Wenn die TGT gültig ist, wird ein Dienstticket ausgestellt
  • Der Benutzerprinzipalname (USER Principal Name, UPN) wird über die implizite Zuordnung zugeordnet. Wenn der UPN beispielsweise lautet user1@CONTOSO.COM, fragt der Dienst einen UNIX-Benutzer mit dem Namen "user1" ab. Da dieser UNIX-Benutzer in der lokalen Dateidatenbank in Azure NetApp Files nicht vorhanden ist, wird LDAP verwendet.
  • Es wird versucht, eine LDAP-Bindung mithilfe des SMB-Servercomputerkontos zuzulassen, um eine LDAP-Suche für den zugeordneten Benutzer zuzulassen. Eine DNS SRV-Abfrage wird für Kerberos-DNS-Einträge (_kerberos und _kerberos master) durchgeführt. Wenn keine gültigen Datensätze verwendet werden können, greift die Konfiguration auf die Bereichskonfiguration zurück. Diese KDC-DNS-SRV-Abfragen sind nicht websitebereichsbezogenen.
  • LDAP SRV-Einträge werden für gültige LDAP-Server abgefragt. Diese sind websitebereichsbezogen.
  • Wenn der Benutzer in LDAP oder LDAP nicht vorhanden ist (Server ist nicht abgefragt, DNS-Suche schlägt fehl, Bindung schlägt fehl, LDAP-Suchzeitüberschreitung, Benutzer ist nicht vorhanden), schlägt die Zuordnung fehl, und der Zugriff wird verweigert.
  • Wenn der Benutzer vorhanden ist, werden Gruppenmitgliedschaften gesammelt.
  • Die Zuordnung ist erfolgreich, und ein NFS-Dienstticket wird an den Client ausgestellt (siehe Befehle klist -e ). Der Zugriff ist basierend auf den Dateiberechtigungen für den Exportpfad zulässig.

Rolle von LDAP mit Kerberos in Azure NetApp-Dateien

Azure NetApp Files basiert auf LDAP für NFS Kerberos. NFS Kerberos in Azure NetApp Files erfordert Kerberos für UNIX-Namenszuordnungen für eingehende Benutzer-SPNs. Da Azure NetApp Files die Erstellung lokaler UNIX-Benutzer nicht unterstützt, ist LDAP erforderlich, um Nachschlagevorgänge für UNIX-Benutzer durchzuführen, wenn eine Namenszuordnung angefordert wird.

  • Wenn eine Azure AD-Verbindung erstellt wird, wird der Active Directory-Domänenname verwendet, um den Prozess zum Nachschlagen von LDAP-Servern anzugeben.
  • Wenn ein LDAP-Server benötigt wird, _ldap.domain.com wird für die SRV-Suche für LDAP-Server verwendet.
  • Sobald eine Liste der Server ermittelt wurde, wird der beste verfügbare Server (basierend auf der Ping-Antwortzeit) als LDAP-Server für die Verbindung über Port 389 verwendet.
  • Es wird versucht, eine LDAP-Bindung mithilfe des SMB-Computerkontos über GSS/Kerberos zu verwenden.
  • Wenn keine zwischengespeicherten Verbindungs- oder Kerberos-Anmeldeinformationen vorhanden sind, wird eine neue Anforderung für ein Kerberos-Ticket ausgestellt. Zwischengespeicherte Verbindungen für Namenserver in Azure NetApp Files sind 60 Sekunden lang live. Wenn der Leerlauf länger als 60 Sekunden dauert, wird der Verbindungscache gelöscht.
  • DNS wird verwendet, um die entsprechenden Kerberos-KDCs über SRV-Einträge zu finden.
  • Wenn keine KDCs über DNS-Abfrage gefunden werden können, wird der in der Datei krb5.conf für die SMB-Dienste angegebene KDC verwendet.
    • Wenn dieser KDC nicht erreichbar ist oder die Kerberos-Anforderung nicht verarbeiten kann, schlägt die LDAP-Bindung fehl. Die Namenssuche schlägt ebenfalls fehl. Der Zugriff auf die Bereitstellung wird verweigert, da keine gültige Authentifizierung erfolgt ist.
    • Wenn die Bindung erfolgreich ist, wird eine LDAP-Abfrage für den Benutzer und seine Anmeldeinformationen ausgeführt. Wenn die Suchzeit 10 Sekunden überschreitet, schlägt die Suche fehl.
  • Wenn die Suche den Benutzer findet, wird die Zuordnung erfolgreich ausgeführt, und der Zugriff wird über Kerberos gewährt (vorausgesetzt, das Ticket ist gültig/ist nicht abgelaufen).

IP-Adressen für den Zugriff mit Kerberos

Standardmäßig verwendet die Kerberos-Authentifizierung die Hostname-zu-IP-Adressauflösung, um den Dienstprinzipalnamen (Service Principal Name, SPN) zu formulieren, der zum Abrufen des Kerberos-Tickets verwendet wird. Zum Beispiel, wenn auf eine SMB-Freigabe mit einem UNC-Pfad (Universal Naming Convention) wie \SMB-Volumen.CONTOSO.COM zugegriffen wird, dann wird eine DNS-Anforderung für den voll qualifizierten SMB.CONTOSO.COM ausgegeben, und die IP-Adresse des Azure NetApp Files-Volumen wird abgerufen. Wenn kein DNS-Eintrag vorhanden ist (oder der aktuelle Eintrag sich von den angeforderten Einträgen unterscheidet, z. B. mit Aliasen/CNAMEs), kann kein ordnungsgemäßer SPN abgerufen werden, und die Kerberos-Anforderung schlägt fehl. Daher kann der Zugriff auf das Volume nicht zulässig sein, wenn die Fallbackauthentifizierungsmethode (z. B. New Technology LAN Manager) deaktiviert ist.

DNS-Einträge in Azure NetApp Files werden automatisch mit dynamischem DNS erstellt und mit dem Namen des SMB-Servers formuliert. Bei Variationen/Aliasen für den definierten Namen sollte ein manueller DNS-CNAME-Eintrag erstellt und auf den dynamischen DNS-Eintrag verwiesen werden. Weitere Informationen finden Sie unter Grundlegendes zu großen Volumen in Azure NetApp Files.

NFSv4.1 Kerberos funktioniert ähnlich für den SPN-Abruf, wobei DNS-Lookup-Vorgänge für den Authentifizierungsprozess integral sind und auch für die Kerberos-Bereichsermittlung verwendet werden können.

Wenn eine IP-Adresse (anstatt eines Hostname) in einer Zugriffsanforderung auf ein Azure NetApp Files-Volume verwendet wird, funktioniert eine Kerberos-Anforderung je nach verwendetem Protokoll unterschiedlich.

SMB Kerberos-Verhalten mit IP-Adressen und DNS-Namen

Bei Verwendung von SMB versucht eine Anforderung für einen UNC-Pfad standardmäßig mithilfe einer IP-Adresse (z \\x.x.x.x. B. ) NTLM für die Authentifizierung zu verwenden. In Umgebungen, in denen NTLM aus Sicherheitsgründen nicht zulässig ist, ist eine SMB-Anforderung mit einer IP-Adresse standardmäßig nicht in der Lage, Kerberos oder NTLM für die Authentifizierung zu verwenden. Daher wird der Zugriff auf das Azure NetApp Files-Volume verweigert. In späteren Windows-Versionen (ab Windows 10, Version 1507 und Windows Server 2016) können Kerberos-Clients so konfiguriert werden, dass IPv4- und IPv6-Hostnamen in SPNs für die SMB-Kommunikation unterstützt werden, um dieses Problem zu umgehen.

NFSv4.1 Kerberos-Verhalten mit IP-Adressen und DNS-Namen

Bei Verwendung von NFSv4.1 verwendet eine Bereitstellungsanforderung an eine IP-Adresse mithilfe einer der sec=[krb5/krb5i/krb5p] Optionen Reverse-DNS-Lookups über PTR, um eine IP-Adresse in einen Hostnamen aufzulösen. Dieser Hostname wird dann verwendet, um den SPN für den Kerberos-Ticketabruf zu formulieren. Wenn Sie NFSv4.1 mit Kerberos verwenden, sollten Sie über ein A/AAAA- und PTR-Volume für das Azure NetApp Files-Volume verfügen, um Hostnamen- und IP-Adresszugriff auf Einbindungen abzudecken. Azure NetApp Files erstellt einen dynamischen DNS A/AAAA-Eintrag. Wenn für dieses Subnetz eine Reverse-DNS-Zone vorhanden ist, wird automatisch auch ein PTR-Eintrag erstellt. Verwenden Sie für Abweichungen von den standardmäßigen Azure NetApp Files-Hostnamenkonventionen CNAME-Einträge für DNS-Aliase.

Weitere Informationen finden Sie unter Grundlegendes zu DNS in Azure NetApp Files