Freigeben über

Konfigurieren der NFSv4.1-ID Standard für Azure NetApp-Dateien

  • Artikel

NFSv4 führt das Konzept einer ID-Authentifizierung ein Standard. Azure NetApp Files verwendet den Eintragswert defaultv4iddomain.com wie die Authentifizierung Standard 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-Do Standard Namen als NFSv4-ID Standard. Sie können diese Einstellung überschreiben, indem Sie die NFSv4-Konfigurationsdatei namens idmapd.confverwenden.

Wenn die Authentifizierung Standard Einstellungen auf NFS-Client und Azure NetApp-Dateien nicht übereinstimmen, kann der Dateizugriff verweigert werden, da die NFSv4-Benutzer- und Gruppenzuordnung fehlschlägt. In diesem Fall squashen die Benutzer und Gruppen, die nicht ordnungsgemäß übereinstimmen, den In der idmapd.conf Datei konfigurierten Benutzer und die Gruppe (im Allgemeinen niemand:99) und ein Ereignis wird beim Client angemeldet.

In diesem Artikel wird das Standardverhalten der Benutzer-/Gruppenzuordnung und das Konfigurieren von NFS-Clients für die ordnungsgemäße Authentifizierung und das Zulassen 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 können so konfiguriert werden, dass der Zugriff für root.

Im folgenden Verzeichnisauflistungsbeispiel stellt der Benutzer root ein Volume auf einem Linux-Client bereit, der seine Standardkonfiguration localdomain für die ID-Authentifizierung verwendet Standard, die sich von der Standardkonfiguration von defaultv4iddomain.comAzure NetApp Files unterscheidet.

Screenshot of file directory output.

In der Auflistung der Dateien im Verzeichnis wird angezeigt, file1 wie sie zugeordnet nobodywerden, wann sie dem Stammbenutzer gehören soll.

Es gibt zwei Möglichkeiten zum Anpassen der Authentifizierung Standard auf beiden Seiten: Azure NetApp Files als NFS-Server und Linux als NFS-Clients:

  1. Zentrale Benutzerverwaltung: Wenn Sie bereits eine zentrale Benutzerverwaltung wie Active Directory-Domäne Services (AD DS) verwenden, können Sie ihre Linux-Clients so konfigurieren, dass SIE LDAP verwenden und die in AD DS als Authentifizierung konfigurierte Do Standard festlegen Standard. Auf der Serverseite müssen Sie den AD do Standard-Dienst für Azure NetApp-Dateien aktivieren und LDAP-fähige Volumes erstellen. Die LDAP-aktivierten Volumes verwenden die do Standard in AD DS als Authentifizierung konfiguriert Standard.

    Weitere Informationen zu diesem Prozess finden Sie unter Enable Active Directory-Domäne Services (AD DS) LDAP-Authentifizierung 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 Standardauthentifizierung entsprechen Standard von Azure NetApp-Dateien für nicht LDAP-aktivierte Volumes.

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

Konfigurieren der NFSv4.1-ID für Azure NetApp-Dateien Standard

Sie können eine gewünschte NFSv4.1-ID angeben Standard für alle Nicht-LDAP-Volumes mithilfe der Azure-Portal. 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 gleichen NetApp-Abonnement und derselben Region aus.

Registrieren der Funktion

Azure NetApp Files unterstützt die Möglichkeit, die NFSv4.1-ID "do Standard für alle Nicht-LDAP-Volumes in einem Abonnement mithilfe der Azure-Portal festzulegen. Diese Funktion befindet sich derzeit in der Vorschau. 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-Befehleaz 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 Do Standard aus.

  2. Wählen Sie Konfigurierenaus.

  3. Wenn Sie die Standard-Do Standard defaultv4iddomain.comverwenden möchten, wählen Sie das Kontrollkästchen neben "Standard-NFSv4 ID Do Standard" aus. Um eine andere Do Standard zu verwenden, deaktivieren Sie das Textfeld, und geben Sie den Namen der NFSv4.1-ID do Standard an.

    Screenshot with field to set NFSv4 domain.

  4. Wählen Sie Speichern.

Konfigurieren der NFSv4.1-ID Standard 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 für LDAP nicht aktiviert ist, verwenden Sie entweder die Standard-Do Standarddefaultv4iddomain.com, indem Sie die Domain = defaultv4iddomain.comNFSv4.1-ID angeben Standard wie in Azure NetApp Files konfiguriert.
    • 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 anfängliche Konfiguration vor /etc/idmapd.conf Ä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 eine aktualisierte Konfiguration von Nicht-LDAP NFSv4.1-Volumes für Die Standard-Do Standarddefaultv4iddomain.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 die Tastenkombination des 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 that shows an example of the resulting user/group change.

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

Verhalten anderer (nicht gestammt) 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) und die entsprechenden Besitz- und Berechtigungen, die Dateien oder Ordnern in NFSv4.1-Volumes zugeordnet sind. Der Dienst löst jedoch nicht automatisch 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 Host1 sind drei Benutzerkonten (testuser01, testuser02, testuser03):

Screenshot that shows that Host1 has three existing test user accounts.

Bei Host2, keine entsprechenden Benutzerkonten vorhanden, aber dasselbe Volume wird auf beiden Hosts bereitgestellt:

Resulting configuration for 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