Share via

Общие сведения о членстве в группах NFS и дополнительных группах

  • Статья

С помощью LDAP можно управлять членством в группах и возвращать дополнительные группы для пользователей NFS. Это поведение управляется атрибутами схемы на сервере LDAP.

Первичный GID

Для правильной проверки подлинности пользователя в Azure NetApp Files пользователи LDAP должны всегда иметь основной идентификатор GID. Основной GID пользователя определяется схемой gidNumber на сервере LDAP.

Вторичные, дополнительные и вспомогательные GID

Вторичные, дополнительные и вспомогательные группы — это группы, которые пользователь является членом вне их основного GID. В Azure NetApp Files протокол LDAP реализуется с помощью Microsoft Active Directory и дополнительных групп управляется с помощью стандартной логики членства в группах Windows.

При добавлении пользователя в группу Windows атрибут Member схемы LDAP заполняется в группе с различающимися именами (DN) пользователя, являющегося членом этой группы. Когда членство в группе пользователя запрашивается Azure NetApp Files, поиск LDAP выполняется для DN пользователя по атрибуту всех групп Member . Все группы с UNIX gidNumber и DN пользователя возвращаются в поиске и заполняются в качестве дополнительного членства в группах пользователя.

В следующем примере показаны выходные данные Active Directory с DN пользователя, заполненного в Member поле группы и последующим поиском LDAP, выполненным с помощью ldp.exe.

В следующем примере показано поле члена группы Windows:

Screenshot that shows the Windows group member field.

В следующем примере показаны LDAPsearch все группы, где User1 находится член:

Screenshot that shows the search of a user named `User1`.

Вы также можете запрашивать членство в группах для пользователя в Azure NetApp Files, выбрав ссылку "Список идентификаторов группы LDAP" в разделе "Поддержка и устранение неполадок " в меню томов.

Screenshot that shows the query of group memberships by using the **LDAP Group ID List** link.

Ограничения групп в NFS

Удаленный вызов процедур (RPC) в NFS имеет определенное ограничение для максимального количества вспомогательных GID, которые можно учитывать в одном запросе NFS. Максимальное AUTH_SYS/AUTH_UNIX значение составляет 16, а для AUTH_GSS (Kerberos) — 32. Это ограничение протокола влияет на все серверы NFS , а не только Azure NetApp Files. Однако многие современные серверы и клиенты NFS включают способы обойти эти ограничения.

Сведения об этом ограничении NFS в Azure NetApp Files см. в статье "Включение проверки подлинности LDAP служб домен Active Directory (AD DS) для томов NFS.

Как расширяется ограничение группы

Параметры расширения ограничения группы работают так же, как manage-gids и для других серверов NFS. В основном, вместо дампа всего списка вспомогательных GID, к которым принадлежит пользователь, параметр выполняет поиск GID в файле или папке и возвращает это значение.

В следующем примере показан пакет RPC с 16 GID.

Screenshot that shows RPC packet with 16 GIDs.

Любой GID за пределом 16 удаляется протоколом. При использовании расширенных групп в Azure NetApp Files при появлении нового запроса NFS запрашивается информация о членстве в группе пользователя.

Рекомендации по расширенным GID с помощью LDAP Active Directory

По умолчанию в серверах MaxPageSize LDAP Microsoft Active Directory атрибут по умолчанию имеет значение 1000. Этот параметр означает, что группы, превышающие 1000, будут усечены в запросах LDAP. Чтобы включить полную поддержку с 1024 значением для расширенных групп, MaxPageSize атрибут необходимо изменить, чтобы отразить значение 1024. Сведения о том, как изменить это значение, см. в статье Microsoft TechNet о том, как просмотреть и задать политику LDAP в Active Directory с помощью Ntdsutil.exe и статьи библиотеки TechNet MaxPageSize Задано слишком высоко.

Следующие шаги