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

С помощью 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:

Снимок экрана, на котором показано поле участника группы Windows.

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

Снимок экрана: поиск пользователя с именем User1.

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

Снимок экрана: запрос членства в группах с помощью ссылки **СПИСОК идентификаторов группы LDAP**.

Ограничения групп в 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.

Снимок экрана: пакет RPC с 16 GID.

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

Рекомендации по расширенным идентификаторам групп (GID) с помощью LDAP Active Directory

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

Дальнейшие шаги

  • Last updated on