Az NFS-csoporttagságok és a kiegészítő csoportok ismertetése

Cikk
02/03/2024

Az LDAP használatával szabályozhatja a csoporttagságokat, és kiegészítő csoportokat adhat vissza az NFS-felhasználók számára. Ezt a viselkedést az LDAP-kiszolgáló sémaattribútumai vezérlik.

Elsődleges GID

Ahhoz, hogy az Azure NetApp Files megfelelően hitelesíthessen egy felhasználót, az LDAP-felhasználóknak mindig meg kell határozniuk egy elsődleges GID-t. A felhasználó elsődleges GID-jét az LDAP-kiszolgálón lévő séma gidNumber határozza meg.

Másodlagos, kiegészítő és kiegészítő GID-k

A másodlagos, kiegészítő és kiegészítő csoportok olyan csoportok, amelyeknek a felhasználó tagja az elsődleges GID-n kívül. Az Azure NetApp Filesban az LDAP a Microsoft Active Directory használatával van implementálva, a kiegészítő csoportokat pedig szabványos Windows-csoporttagság-logika vezérli.

Amikor hozzáad egy felhasználót egy Windows-csoporthoz, az LDAP sémaattribútum Member a csoporthoz tartozó felhasználó megkülönböztető nevével (DN) lesz feltöltve. Ha egy felhasználó csoporttagságát lekérdezi az Azure NetApp Files, a rendszer LDAP-keresést végez a felhasználó DN-jén az összes csoport attribútumán Member . A UNIX-tal gidNumber és a felhasználó DN-jével rendelkező összes csoport megjelenik a keresésben, és a felhasználó kiegészítő csoporttagságaként lesz feltöltve.

Az alábbi példa az Active Directory kimenetét mutatja be, amelyben egy felhasználó DN-jét tölti ki egy Member csoport mezőjében, és egy későbbi LDAP-keresést végez a használatával ldp.exe.

Az alábbi példában a Windows-csoporttag mező látható:

Az alábbi példa az összes olyan csoportot mutatja be LDAPsearch , ahol User1 tag:

A felhasználók csoporttagságait az Azure NetApp Filesban is lekérdezheti, ha a kötet menüjében a Támogatás + hibaelhárítás területen válassza az LDAP-csoportazonosító-lista hivatkozását.

Csoportkorlátok az NFS-ben

A távoli eljáráshívás (RPC) az NFS-ben meghatározott korlátozással rendelkezik az egyetlen NFS-kérelemben betartható kiegészítő GID-k maximális számára vonatkozóan. A maximális érték AUTH_SYS/AUTH_UNIX 16, a AUTH_GSS (Kerberos) esetében pedig 32. Ez a protokollkorlátozás az összes NFS-kiszolgálót érinti – nem csak az Azure NetApp Filest. Számos modern NFS-kiszolgáló és -ügyfél azonban többféleképpen is megkerülheti ezeket a korlátozásokat.

Az Azure NetApp Filesban az NFS-korlátozás megkerüléséhez lásd: Active Directory tartományi szolgáltatások (AD DS) LDAP-hitelesítés engedélyezése NFS-kötetekhez.

A csoportkorlátozás kiterjesztése

A csoportkorlátozás kiterjesztésének lehetőségei ugyanúgy működnek, mint a manage-gids többi NFS-kiszolgáló esetében. Alapvetően ahelyett, hogy a felhasználóhoz tartozó kiegészítő GID-k teljes listáját memóriaképezi, a beállítás a gid keresését hajtja végre a fájlban vagy mappában, és ezt az értéket adja vissza.

Az alábbi példa 16 GID-vel rendelkező RPC-csomagot mutat be.

A protokoll minden 16-os korláton túli GID-t elvet. Az Azure NetApp Files kiterjesztett csoportjai esetén, amikor új NFS-kérés érkezik, a rendszer információkat kér a felhasználó csoporttagságáról.

Megfontolandó szempontok az Active Directory LDAP-vel rendelkező kiterjesztett GID-k esetében

Alapértelmezés szerint a Microsoft Active Directory LDAP-kiszolgálókon az MaxPageSize attribútum alapértelmezett értéke 1000. Ez a beállítás azt jelenti, hogy az 1000-et meghaladó csoportok csonkolt lesznek az LDAP-lekérdezésekben. A kiterjesztett csoportok 1024 értékének teljes körű támogatásához az MaxPageSize attribútumot úgy kell módosítani, hogy az az 1024 értéket tükrözze. Az érték módosításáról a Microsoft TechNet how to View and Set LDAP Policy in Active Directory by Using Ntdsutil.exe and the TechNet library article MaxPageSize is Set Too High (Túl magas) című cikkéből tájékozódhat.