Share via

NFSv4.1 ID-domein configureren voor Azure NetApp Files

  • Artikel

NFSv4 introduceert het concept van een id-verificatiedomein. Azure NetApp Files gebruikt de invoerwaarde defaultv4iddomain.com als verificatiedomein en NFS-clients gebruiken hun eigen configuratie om gebruikers te verifiëren die toegang willen tot bestanden op deze volumes. Standaard gebruiken NFS-clients de DNS-domeinnaam als het NFSv4-id-domein. U kunt deze instelling overschrijven met behulp van het NFSv4-configuratiebestand met de naam idmapd.conf.

Als de domeininstellingen voor verificatie op de NFS-client en Azure NetApp Files niet overeenkomen, wordt bestandstoegang mogelijk geweigerd omdat de NFSv4-gebruiker en groepstoewijzing mogelijk mislukken. Wanneer dit gebeurt, worden de gebruikers en groepen die niet goed overeenkomen, de gebruiker en groep die in het bestand zijn geconfigureerd (over het idmapd.conf algemeen niemand:99) verpletteren en wordt een gebeurtenis aangemeld bij de client.

In dit artikel wordt het standaardgedrag van toewijzing van gebruikers/groepen uitgelegd en wordt uitgelegd hoe u NFS-clients correct configureert om correct te verifiëren en toegang toe te staan. 

Standaardgedrag van toewijzing van gebruikers/groepen

De toewijzing van hoofdgebruikers kan illustreren wat er gebeurt als er sprake is van een onjuiste overeenkomst tussen de Azure NetApp Files- en NFS-clients. Voor het installatieproces van een toepassing is vaak het gebruik van de hoofdgebruiker vereist. Azure NetApp Files kan worden geconfigureerd om toegang toe te staan.root

In het volgende mapvoorbeeld koppelt de gebruiker root een volume aan een Linux-client die gebruikmaakt van de standaardconfiguratie localdomain voor het id-verificatiedomein, wat verschilt van de standaardconfiguratie van defaultv4iddomain.comAzure NetApp Files.

Screenshot of file directory output.

In de lijst met de bestanden in de map wordt file1 weergegeven als toegewezen aan nobody, wanneer deze eigendom moet zijn van de hoofdgebruiker.

Er zijn twee manieren om het verificatiedomein aan beide zijden aan te passen: Azure NetApp Files als NFS-server en Linux als NFS-clients:

  1. Centraal gebruikersbeheer: als u al gebruikmaakt van centraal gebruikersbeheer, zoals Active Directory-domein Services (AD DS), kunt u hun Linux-clients configureren voor het gebruik van LDAP en het domein instellen dat is geconfigureerd in AD DS als verificatiedomein. Aan de serverzijde moet u de AD-domeinservice voor Azure NetApp Files inschakelen en LDAP-volumes maken. De volumes met LDAP maken automatisch gebruik van het domein dat is geconfigureerd in AD DS als verificatiedomein.

    Zie LDAP-verificatie voor NFS-volumes inschakelen Active Directory-domein voor meer informatie over dit proces.

  2. Configureer de Linux-client handmatig: als u geen centraal gebruikersbeheer voor uw Linux-clients gebruikt, kunt u de Linux-clients handmatig configureren zodat deze overeenkomen met het standaardverificatiedomein van Azure NetApp Files voor volumes met niet-LDAP-functionaliteit.

In deze sectie richten we ons op het configureren van de Linux-client en het wijzigen van het Azure NetApp Files-verificatiedomein voor alle niet-LDAP-volumes.

NFSv4.1-id-domein configureren in Azure NetApp Files

U kunt een gewenst NFSv4.1-id-domein opgeven voor alle niet-LDAP-volumes met behulp van Azure Portal. Deze instelling geldt voor alle niet-LDAP-volumes voor alle NetApp-accounts in hetzelfde abonnement en dezelfde regio. Dit heeft geen invloed op volumes met LDAP in hetzelfde NetApp-abonnement en dezelfde regio.

De functie registreren

Azure NetApp Files ondersteunt de mogelijkheid om het NFSv4.1-id-domein in te stellen voor alle niet-LDAP-volumes in een abonnement met behulp van Azure Portal. Deze functie is momenteel beschikbaar in preview. U moet de functie registreren voordat u deze voor het eerst gebruikt. Na de registratie is de functie ingeschakeld en werkt deze op de achtergrond.

  1. De functie registreren

    Register-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFNFSV4IDDomain

  2. Controleer de status van de functieregistratie:

    Notitie

    De RegistrationState kan maximaal 60 minuten in de Registering status zijn voordat u overgaat naar Registered. Wacht totdat de status is Registered ingesteld voordat u doorgaat.

    Get-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFNFSV4IDDomain

U kunt ook Azure CLI-opdrachtenaz feature register gebruiken en az feature show de functie registreren en de registratiestatus weergeven.

Stappen

  1. Selecteer onder het Azure NetApp Files-abonnement NFSv4.1-id-domein.

  2. Selecteer Configureren.

  3. Als u het standaarddomein defaultv4iddomain.comwilt gebruiken, schakelt u het selectievakje naast Standaard NFSv4-id-domein gebruiken in. Als u een ander domein wilt gebruiken, schakelt u het tekstvak uit en geeft u de naam op van het id-domein NFSv4.1.

    Screenshot with field to set NFSv4 domain.

  4. Selecteer Opslaan.

NFSv4.1-id-domein configureren in NFS-clients

  1. Bewerk het /etc/idmapd.conf bestand op de NFS-client.
    Verwijder opmerkingen bij de regel #Domain (verwijder de # regel uit de regel) en wijzig de waarde localdomain als volgt:

    • Als het volume niet is ingeschakeld voor LDAP, gebruikt u het standaarddomein defaultv4iddomain.com door Domain = defaultv4iddomain.comhet NFSv4.1-id-domein op te geven, zoals geconfigureerd in Azure NetApp Files.
    • Als het volume is ingeschakeld voor LDAP, stelt u Domain in op het domein dat is geconfigureerd in de Active Directory-Verbinding maken ion op uw NetApp-account. Als dit bijvoorbeeld contoso.com het geconfigureerde domein in het NetApp-account is, stelt u deze in Domain = contoso.com.

    In de volgende voorbeelden ziet u de eerste configuratie van /etc/idmapd.conf vóór wijzigingen:

    [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

    In het volgende voorbeeld ziet u de bijgewerkte configuratie van niet-LDAP NFSv4.1-volumes voor het standaarddomein 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

    In het volgende voorbeeld ziet u een bijgewerkte configuratie van NFSv4.1-volumes met LDAP.1 . In dit voorbeeld contoso.com is het geconfigureerde domein in het NetApp-account:

    [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. Ontkoppel alle momenteel gekoppelde NFS-volumes.

  3. Werk het /etc/idmapd.conf bestand bij.

  4. Wis de sleutelring van de NFS idmapper (nfsidmap -c).

  5. Koppel de NFS-volumes indien nodig.

    Zie Een volume koppelen voor Virtuele Windows- of Linux-machines.

In het volgende voorbeeld ziet u de resulterende wijziging van de gebruiker/groep:

Screenshot that shows an example of the resulting user/group change.

Zoals in het voorbeeld wordt weergegeven, is de gebruiker/groep nu gewijzigd van nobody .root

Gedrag van andere (niet-basis) gebruikers en groepen

Azure NetApp Files ondersteunt lokale gebruikers en groepen (lokaal gemaakt op de NFS-client en vertegenwoordigd door gebruikers- en groeps-id's) en bijbehorende eigendom en machtigingen die zijn gekoppeld aan bestanden of mappen in NFSv4.1-volumes. De service lost echter niet automatisch op voor het toewijzen van lokale gebruikers en groepen aan NFS-clients. Gebruikers en groepen die op één host zijn gemaakt, kunnen al dan niet bestaan op een andere NFS-client (of bestaan met verschillende gebruikers- en groeps-id's) en worden daarom niet correct toegewezen zoals beschreven in het onderstaande voorbeeld.

In het volgende voorbeeld Host1 zijn er drie gebruikersaccounts (testuser01, testuser02, ): testuser03

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

Er Host2bestaan geen bijbehorende gebruikersaccounts, maar hetzelfde volume wordt op beide hosts gekoppeld:

Resulting configuration for NFSv4.1

U kunt dit probleem oplossen door de ontbrekende accounts op de NFS-client te maken of uw NFS-clients te configureren voor het gebruik van de LDAP-server die Azure NetApp Files gebruikt voor centraal beheerde UNIX-identiteiten.

Volgende stappen