Megosztás a következőn keresztül:

NFSv4.1 azonosító tartomány konfigurálása az Azure NetApp Fileshoz

  • Cikk

Az NFSv4 bevezeti az azonosító-hitelesítési tartomány fogalmát. Az Azure NetApp Files a belépési értéket defaultv4iddomain.com használja hitelesítési tartományként, az NFS-ügyfelek pedig saját konfigurációjukkal hitelesítik azokat a felhasználókat, akik hozzá szeretnének férni a köteteken lévő fájlokhoz. Alapértelmezés szerint az NFS-ügyfelek a DNS-tartománynevet használják NFSv4-azonosító tartományként. Ezt a beállítást felülbírálhatja az NFSv4 nevű idmapd.confkonfigurációs fájllal.

Ha az NFS-ügyfél és az Azure NetApp Files hitelesítési tartománybeállításai nem egyeznek meg, a fájlhozzáférés megtagadható, mivel az NFSv4 felhasználó- és csoportleképezése meghiúsulhat. Ha ez történik, a nem megfelelő felhasználók és csoportok összenyomják a idmapd.conf fájlban konfigurált felhasználót és csoportot (általában senki:99), és egy esemény lesz naplózva az ügyfélen.

Ez a cikk bemutatja a felhasználói/csoportleképezés alapértelmezett viselkedését, valamint azt, hogyan konfigurálhatja az NFS-ügyfeleket helyesen a hitelesítéshez és a hozzáférés engedélyezéséhez. 

A felhasználó/csoport leképezésének alapértelmezett viselkedése

A legfelső szintű felhasználóleképezés bemutatja, mi történik, ha az Azure NetApp Files és az NFS-ügyfelek nem egyeznek. Az alkalmazások telepítési folyamata gyakran megköveteli a gyökérfelhasználó használatát. Az Azure NetApp Files konfigurálható úgy, hogy engedélyezze a hozzáférést a következőhöz root: .

A következő könyvtárlista-példában a felhasználó root egy olyan kötetet csatlakoztat egy Linux-ügyfélhez, amely az alapértelmezett konfigurációját localdomain használja az azonosító-hitelesítési tartományhoz, amely eltér az Azure NetApp Files alapértelmezett konfigurációjától defaultv4iddomain.com.

Képernyőkép a fájlkönyvtár kimenetéről.

A címtárban lévő fájlok listájában az látható, file1 hogy a rendszer megfelelteti nobodyazt, hogy mikor kell a gyökérfelhasználó tulajdonában lennie.

A hitelesítési tartomány kétféleképpen állítható be mindkét oldalon: az Azure NetApp Files NFS-kiszolgálóként, a Linux pedig NFS-ügyfelekként:

  1. Központi felhasználókezelés: Ha már használ központi felhasználófelügyeletet, például Active Directory tartományi szolgáltatások (AD DS), konfigurálhatja Linux-ügyfeleiket az LDAP használatára, és beállíthatja az AD DS-ben hitelesítési tartományként konfigurált tartományt. A kiszolgálóoldalon engedélyeznie kell az Azure NetApp Files AD tartományi szolgáltatását, és LDAP-kompatibilis köteteket kell létrehoznia. Az LDAP-kompatibilis kötetek automatikusan az AD DS-ben konfigurált tartományt használják hitelesítési tartományként.

    A folyamatról további információt az NFS-kötetek Active Directory tartományi szolgáltatások (AD DS) LDAP-hitelesítésének engedélyezése című témakörben talál.

  2. A Linux-ügyfél manuális konfigurálása: Ha nem használ központi felhasználókezelést a Linux-ügyfelekhez, manuálisan konfigurálhatja a Linux-ügyfeleket úgy, hogy megfeleljenek az Azure NetApp Files nem LDAP-kompatibilis kötetek alapértelmezett hitelesítési tartományának.

Ebben a szakaszban a Linux-ügyfél konfigurálására és az Azure NetApp Files hitelesítési tartományának módosítására fogunk összpontosítani az összes nem LDAP-kompatibilis kötet esetében.

NFSv4.1 id tartomány konfigurálása az Azure NetApp Fileson

Az Azure Portalon megadhatja a kívánt NFSv4.1 azonosítótartományt az összes nem LDAP-kötethez. Ez a beállítás az ugyanazon előfizetésben és régióban lévő összes NetApp-fiók összes nem LDAP-kötetére vonatkozik. Ez nem érinti az LDAP-kompatibilis köteteket ugyanabban a NetApp-előfizetésben és -régióban.

A funkció regisztrálása

Az Azure NetApp Files támogatja az NFSv4.1 azonosító tartomány beállítását az előfizetés összes nem LDAP-kötetéhez az Azure Portal használatával. Ez a szolgáltatás jelenleg előzetes kiadásban elérhető. Az első használat előtt regisztrálnia kell a funkciót. A regisztráció után a funkció engedélyezve van, és a háttérben működik.

  1. A funkció regisztrálása

    Register-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFNFSV4IDDomain

  2. Ellenőrizze a szolgáltatásregisztráció állapotát:

    Feljegyzés

    A RegistrationState legfeljebb 60 percig lehet állapotbanRegistering, mielőtt átváltana.Registered Várjon, amíg az állapot folytatódik Registered .

    Get-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFNFSV4IDDomain

Használhatja az Azure CLI-parancsokat az feature register is, és az feature show regisztrálhatja a funkciót, és megjelenítheti a regisztrációs állapotot.

Lépések

  1. Az Azure NetApp Files-előfizetésben válassza az NFSv4.1 azonosítótartományt.

  2. Válassza a Konfigurálás lehetőséget.

  3. Az alapértelmezett tartomány defaultv4iddomain.comhasználatához jelölje be az Alapértelmezett NFSv4-azonosítótartomány használata melletti jelölőnégyzetet. Másik tartomány használatához törölje a jelölést a szövegmezőből, és adja meg az NFSv4.1 azonosító tartomány nevét.

    Képernyőkép az NFSv4 tartomány beállítására használható mezővel.

  4. Válassza a Mentés lehetőséget.

NFSv4.1 azonosító tartomány konfigurálása NFS-ügyfelekben

  1. Szerkessze a /etc/idmapd.conf fájlt az NFS-ügyfélen.
    Bontsa ki a sort #Domain (azaz távolítsa el a # sort), és módosítsa az értéket localdomain az alábbiak szerint:

    • Ha a kötet nincs engedélyezve az LDAP-ban, használja az alapértelmezett tartományt defaultv4iddomain.com a beállítássalDomain = defaultv4iddomain.com, vagy adja meg az NFSv4.1 azonosító tartományt az Azure NetApp Filesban konfigurált módon.
    • Ha a kötet engedélyezve van az LDAP-hoz, állítsa a Domain NetApp-fiók Active Directory-kapcsolatában konfigurált tartományra. Ha például contoso.com a NetApp-fiókban konfigurált tartomány, akkor állítsa be a beállítást Domain = contoso.com.

    Az alábbi példák a módosítások előtti kezdeti konfigurációt /etc/idmapd.conf mutatják be:

    [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

    Az alábbi példa az alapértelmezett tartomány defaultv4iddomain.comnem LDAP NFSv4.1 köteteinek frissített konfigurációját mutatja be:

    [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

    Az alábbi példa az LDAP-kompatibilis NFSv4.1 kötetek frissített konfigurációját mutatja be. Ebben a példában contoso.com a NetApp-fiókban konfigurált tartomány látható:

    [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. A jelenleg csatlakoztatott NFS-kötetek leválasztása.

  3. Frissítse a /etc/idmapd.conf fájlt.

  4. Törölje az NFS idmapper (nfsidmap -c) kulcsolását.

  5. Szükség szerint csatlakoztassa az NFS-köteteket.

    Lásd: Kötet csatlakoztatása Windows vagy Linux rendszerű virtuális gépekhez.

Az alábbi példa a felhasználó/csoport eredményének változását mutatja be:

Képernyőkép az eredményként kapott felhasználó/csoport változásáról.

Ahogy a példa is mutatja, a felhasználó/csoport mostantól a következőre nobody rootváltozott: .

Más (nemroot) felhasználók és csoportok viselkedése

Az Azure NetApp Files támogatja a helyi felhasználókat és csoportokat (amelyeket helyileg hoztak létre az NFS-ügyfélen, és amelyeket felhasználói és csoportazonosítók képviselnek), valamint az NFSv4.1 kötetekben lévő fájlokhoz vagy mappákhoz kapcsolódó tulajdonjogot és engedélyeket. A szolgáltatás azonban nem oldja meg automatikusan a helyi felhasználók és csoportok NFS-ügyfelek közötti leképezését. Az egyik gazdagépen létrehozott felhasználók és csoportok létezhetnek egy másik NFS-ügyfélen (vagy különböző felhasználó- és csoportazonosítókkal), ezért nem fognak megfelelően megfeleltetni az alábbi példában ismertetett módon.

Az alábbi példában Host1 három felhasználói fiókkal rendelkezik (testuser01, testuser02, ): testuser03

Képernyőkép arról, hogy a Host1 három meglévő tesztfelhasználói fiókkal rendelkezik.

Nincs Host2megfelelő felhasználói fiók, de ugyanez a kötet mindkét gazdagépre csatlakoztatva van:

Az NFSv4.1 eredményül kapott konfigurációja

A probléma megoldásához hozza létre a hiányzó fiókokat az NFS-ügyfélen, vagy konfigurálja az NFS-ügyfeleket az Azure NetApp Files által központilag felügyelt UNIX-identitásokhoz használt LDAP-kiszolgáló használatára.

Következő lépések