Freigeben über

Konfigurieren der NFSv4.1-ID-Domäne für Azure NetApp Files

  • Artikel

NFSv4 führt das Konzept einer ID-Authentifizierungsdomäne ein. Azure NetApp Files verwendet den Eingabewert defaultv4iddomain.com als Authentifizierungsdomäne, und NFS-Clients verwenden ihre eigene Konfiguration, um Benutzer zu authentifizieren, die auf Dateien auf diesen Volumes zugreifen möchten. Standardmäßig verwenden NFS-Clients den DNS-Domänennamen als NFSv4-ID-Domäne. Sie können diese Einstellung überschreiben, indem Sie die NFSv4-Konfigurationsdatei namens idmapd.conf verwenden.

Wenn die Einstellungen der Authentifizierungsdomäne auf dem NFS-Client und Azure NetApp-Dateien nicht übereinstimmen, kann der Dateizugriff verweigert werden, da die NFSv4-Benutzer- und Gruppenzuordnung fehlschlägt. In diesem Fall löschen die Benutzer und Gruppen, die nicht übereinstimmen, den in der idmapd.conf Datei konfigurierten Benutzer und die Gruppe (in der Regel nobody:99), und ein Ereignis wird auf dem Client protokolliert.

In diesem Artikel wird das Standardverhalten der Benutzer-/Gruppenzuordnung und das Konfigurieren von NFS-Clients für die ordnungsgemäße Authentifizierung und das Gewähren des Zugriffs erläutert. 

Standardverhalten der Benutzer-/Gruppenzuordnung

Die Stammbenutzerzuordnung kann veranschaulichen, was passiert, wenn zwischen den Azure NetApp Files- und NFS-Clients ein Konflikt besteht. Der Installationsprozess einer Anwendung erfordert häufig die Verwendung des Stammbenutzers. Azure NetApp Files kann so konfiguriert werden, dass der Zugriff für root ermöglicht wird.

Im folgenden Verzeichnisauflistungsbeispiel stellt der Benutzer root ein Volume auf einem Linux-Client bereit, das seine Standardkonfiguration localdomain für die ID-Authentifizierungsdomäne verwendet, die sich von der Standardkonfiguration von Azure NetApp Files, defaultv4iddomain.com, unterscheidet.

Screenshot der Dateiverzeichnisausgabe.

In der Auflistung der Dateien im Verzeichnis wird file1 als zu nobody zugeordnet angezeigt, wenn der Stammbenutzer der Besitzer sein soll.

Es gibt zwei Möglichkeiten, die Authentifizierungsdomäne auf beiden Seiten anzupassen: Azure NetApp Files als NFS-Server und Linux als NFS-Clients:

  1. Zentrale Benutzerverwaltung: Wenn Sie bereits eine zentrale Benutzerverwaltung wie Active Directory Domain Services (AD DS) verwenden, können Sie Ihre Linux-Clients so konfigurieren, dass LDAP verwendet und die in AD DS konfigurierte Domäne als Authentifizierungsdomäne festgelegt wird. Auf Serverseite müssen Sie den AD-Domänendienst für Azure NetApp-Dateien aktivieren und LDAP-fähige Volumes erstellen. Die LDAP-fähigen Volumes verwenden automatisch die in AD DS konfigurierte Domäne als Authentifizierungsdomäne.

    Informationen zu dieser Option finden Sie unter Aktivieren der LDAP-Authentifizierung in Active Directory Domain Services (AD DS) für NFS-Volumes.

  2. Manuelle Konfiguration des Linux-Clients: Wenn Sie keine zentrale Benutzerverwaltung für Ihre Linux-Clients verwenden, können Sie die Linux-Clients manuell so konfigurieren, dass sie der Standardauthentifizierungsdomäne von Azure NetApp Files für nicht LDAP-aktivierte Volumes entsprechen.

In diesem Abschnitt befassen wir uns mit der Konfiguration des Linux-Clients und der Änderung der Azure NetApp Files-Authentifizierungsdomäne für alle nicht LDAP-aktivierten Volumes.

Konfigurieren der NFSv4.1-ID-Domäne für Azure NetApp Files

Sie können eine gewünschte NFSv4.1-ID-Domäne für alle Nicht-LDAP-Volumes mithilfe des Azure-Portals angeben. Diese Einstellung gilt für alle Nicht-LDAP-Volumes in allen NetApp-Konten im selben Abonnement und derselben Region. Sie wirkt sich nicht auf LDAP-fähige Volumes im selben NetApp-Abonnement und derselben Region aus.

Registrieren der Funktion

Azure NetApp Files unterstützt die Möglichkeit, die NFSv4.1-ID-Domäne für alle Nicht-LDAP-Volumes in einem Abonnement mithilfe des Azure-Portals festzulegen. Diese Funktion steht derzeit als Vorschau zur Verfügung. Sie müssen das Feature registrieren, bevor Sie sie zum ersten Mal verwenden. Nach der Registrierung ist das Feature aktiviert und funktioniert im Hintergrund.

  1. Registrieren der Funktion

    Register-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFNFSV4IDDomain

  2. Überprüfen Sie den Status der Funktionsregistrierung:

    Hinweis

    Der RegistrationState kann bis zu 60 Minuten lang den Wert Registering aufweisen, bevor er sich in Registered ändert. Warten Sie, bis der Status Registered lautet, bevor Sie fortfahren.

    Get-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFNFSV4IDDomain

Sie können auch die Azure CLI-Befehle az feature register und az feature show verwenden, um das Feature zu registrieren und den Registrierungsstatus anzuzeigen.

Schritte

  1. Wählen Sie unter dem Azure NetApp Files-Abonnement NFSv4.1-ID-Domäne aus.

  2. Wählen Sie Konfigurierenaus.

  3. Um die Standarddomäne defaultv4iddomain.com zu verwenden, aktivieren Sie das Feld neben Standard-NFSV4-ID-Domäne verwenden. Wenn Sie eine andere Domäne verwenden möchten, deaktivieren Sie das Textfeld, und geben Sie den Namen der NFSv4.1-ID-Domäne an.

    Screenshot mit dem Feld zum Festlegen der NFSv4-Domäne.

  4. Wählen Sie Speichern.

Konfigurieren der NFSv4.1-ID-Domäne in NFS-Clients

  1. Bearbeiten Sie die Datei /etc/idmapd.conf auf dem NFS-Client.
    Heben Sie die Auskommentierung der Zeile #Domain auf (d. h., entfernen Sie das # aus der Zeile), und ändern Sie den Wert localdomain wie folgt:

    • Wenn das Volume nicht für LDAP aktiviert ist, verwenden Sie entweder die Standarddomäne defaultv4iddomain.com, indem Sie Domain = defaultv4iddomain.com angeben, oder geben Sie die NFSv4.1-ID-Domäne als in Azure NetApp Files konfiguriert an.
    • Wenn das Volume für LDAP aktiviert ist, legen Sie Domain auf die Domäne fest, die in der Active Directory-Verbindung für Ihr NetApp-Konto konfiguriert ist. Wenn beispielsweise contoso.com die konfigurierte Domäne im NetApp-Konto ist, legen Sie Domain = contoso.com fest.

    Die folgenden Beispiele zeigen die Erstkonfiguration von /etc/idmapd.conf vor Änderungen:

    [General]
Verbosity = O 
Pipefs—Directory = /run/rpc_pipefs 
# set your own domain here, if it differs from FQDN minus hostname 
# Domain = localdomain 

[Mapping] 
Nobody-User = nobody 
Nobody-Group = nogroup

    Das folgende Beispiel zeigt die aktualisierte Konfiguration von NFSv4.1-Volumes ohne LDAP für die Standarddomäne defaultv4iddomain.com:

    [General]
Verbosity = O 
Pipefs—Directory = /run/rpc_pipefs 
# set your own domain here, if it differs from FQDN minus hostname 
Domain = defaultv4iddomain.com 

[Mapping] 
Nobody-User = nobody 
Nobody-Group = nogroup

    Das folgende Beispiel zeigt die aktualisierte Konfiguration von LDAP-fähigen NFSv4.1-Volumes. In diesem Beispiel ist contoso.com die konfigurierte Domäne im NetApp-Konto:

    [General]
Verbosity = O 
Pipefs—Directory = /run/rpc_pipefs 
# set your own domain here, if it differs from FQDN minus hostname 
Domain = contoso.com

[Mapping] 
Nobody-User = nobody 
Nobody-Group = nogroup

  2. Heben Sie die Bereitstellung aller aktuell bereitgestellten NFS-Volumes auf.

  3. Aktualisieren Sie die /etc/idmapd.conf-Datei.

  4. Löschen Sie den Schlüsselbund für das NFS idmapper (nfsidmap -c).

  5. Binden Sie die NFS-Volumes nach Bedarf ein.

    Weitere Informationen finden Sie unter Einbinden oder Aufheben der Einbindung eines Volumes auf virtuellen Windows- oder Linux-Computern.

Das folgende Beispiel zeigt die resultierende Benutzer-/Gruppenänderung:

Screenshot, der ein Beispiel für die sich ergebende Benutzer-/Gruppenänderung zeigt.

Wie das Beispiel zeigt, hat sich der Benutzer/die Gruppe nun von nobody in root geändert.

Verhalten anderer (nicht-root) Benutzer und Gruppen

Azure NetApp Files unterstützt lokale Benutzer und Gruppen (lokal auf dem NFS-Client erstellt und durch Benutzer- und Gruppen-IDs dargestellt) sowie das entsprechende Eigentum und die Berechtigungen, die Dateien oder Ordnern in NFSv4.1-Volumes zugeordnet sind. Der Dienst ist jedoch keine automatische Lösung für die Zuordnung lokaler Benutzer und Gruppen über NFS-Clients hinweg. Benutzer und Gruppen, die auf einem Host erstellt wurden, sind möglicherweise auf einem anderen NFS-Client (oder mit unterschiedlichen Benutzer- und Gruppen-IDs) vorhanden und werden daher nicht ordnungsgemäß zugeordnet, wie im folgenden Beispiel beschrieben.

Im folgenden Beispiel verfügt Host1 über drei Benutzerkonten (testuser01, testuser02, testuser03):

Screenshot, der zeigt, dass Host1 drei bestehende Testbenutzerkonten besitzt.

Oder Host2 ohne entsprechende Benutzerkonten, aber dasselbe Volume ist für beide Hosts bereitgestellt:

Resultierende Konfiguration für NFSv4.1

Um dieses Problem zu beheben, erstellen Sie entweder die fehlenden Konten auf dem NFS-Client, oder konfigurieren Sie Ihre NFS-Clients für die Verwendung des LDAP-Servers, den Azure NetApp Files für zentral verwaltete UNIX-Identitäten verwendet.

Nächste Schritte