Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Схемы упрощенного протокола доступа к каталогам (LDAP) — это способ, которым серверы LDAP организуют и собирают информацию. Схемы сервера LDAP обычно соответствуют тем же стандартам, но разные поставщики серверов LDAP могут иметь варианты представления схем.
Когда Azure NetApp Files запрашивает LDAP, схемы используются для ускорения поиска имен, так как они позволяют использовать определенные атрибуты для поиска сведений о пользователе, таких как UID. Атрибуты схемы должны существовать на сервере LDAP для Azure NetApp Files, чтобы найти запись. В противном случае запросы LDAP могут не возвращать данные, а запросы проверки подлинности могут завершиться неудачно.
Например, если UID номер (например, root=0) должен быть запрошен через Azure NetApp Files, то используется атрибут схемы RFC 2307 uidNumber Attribute. Если номер UID 0 не существует в поле uidNumber LDAP, то запрос поиска завершается ошибкой.
Тип схемы, используемый в настоящее время Azure NetApp Files, является формой схемы на основе RFC 2307bis и не может быть изменен.
RFC 2307bis является расширением RFC 2307 и добавляет поддержку posixGroup, которая обеспечивает динамический поиск вспомогательных групп с использованием атрибута uniqueMember, а не атрибута memberUid в схеме LDAP. Вместо того чтобы использовать только имя пользователя, этот атрибут содержит полное различающееся имя (DN) другого объекта в базе данных LDAP. Таким образом, группы могут иметь другие группы в качестве членов, что позволяет вложенности групп. Поддержка RFC 2307bis также добавляет поддержку класса groupOfUniqueNamesобъектов.
Это расширение RFC хорошо подходит для того, как Microsoft Active Directory управляет пользователями и группами с помощью обычных средств управления. Это связано с тем, что при добавлении пользователя Windows в группу (и если эта группа имеет допустимый числовой GID), используя стандартные методы управления Windows, запросы LDAP будут автоматически извлекать необходимые сведения о дополнительной группе из обычного атрибута Windows и находить числовые GID.
Если томам Azure NetApp Files необходимо выполнять поиски LDAP для удостоверений пользователей NFS, используется ряд атрибутов, определенных по схеме LDAP, основанной на RFC-2307bis. В следующей таблице показаны атрибуты, используемые при запросах LDAP, которые по умолчанию определены в Microsoft Active Directory при использовании атрибутов UNIX. Чтобы обеспечить правильную функциональность, убедитесь, что эти атрибуты правильно заполнены учетными записями пользователей и групп в LDAP.
| Атрибут UNIX | Значение схемы LDAP |
|---|---|
| Имя пользователя UNIX | uid* |
| Числовой идентификатор пользователя UNIX | uidNumber* |
| Имя группы UNIX | cn* |
| Групповой числовой идентификатор UNIX | gidNumber* |
| Членство в группах UNIX | член** |
| Класс объектов пользователя UNIX | Пользователь** |
| Домашний каталог UNIX | UnixHomeDirectory |
| Отображаемое имя UNIX | gecos |
| Пароль пользователя UNIX | unixПарольПользователя |
| Оболочка командной строки UNIX для входа | LoginShell |
| Учетная запись Windows, используемая для сопоставления имен | sAMAccountName** |
| Класс объектов группы UNIX | Группа** |
| Идентификатор пользователя члена UNIX | memberUid*** |
| Группа объектов UNIX уникальных имен | Группа** |
* Обязательный атрибут для правильной функциональности LDAP
** Заполнено в Active Directory по умолчанию
Не требуется
Общие сведения об индексировании атрибутов LDAP
Active Directory LDAP предоставляет метод индексирования атрибутов , которые помогают ускорить запросы поиска. Это особенно полезно в крупных средах каталогов, где запрос LDAP может превышать 10-секундное время ожидания для запросов в Azure NetApp Files. Если поиск превышает значение времени ожидания, запрос LDAP завершается ошибкой, и доступ не будет предоставлен надлежащим образом, так как служба не может подтвердить личность пользователя или группы, запрашивающих доступ.
По умолчанию Microsoft Active Directory LDAP индексирует следующие атрибуты UNIX, используемые Azure NetApp Files для поиска LDAP:
Атрибут uid не индексируется по умолчанию. В результате запросы LDAP для UID занимают больше времени, чем запросы для индексированных атрибутов.
Например, в следующем тесте запроса в среде Active Directory с более чем 20 000 пользователями и группами, поиск пользователя с индексируемым атрибутом CN занял примерно 0,015 секунд, а поиск того же пользователя с атрибутом UID (который по умолчанию не индексирован) приблизился к 0,6 секунды — 40 раз медленнее.
В небольших средах это не приводит к проблемам. Но в больших средах (или средах, где среда Active Directory находится в локальной среде или имеет высокую задержку в сети), разница может быть достаточно резкой, чтобы вызвать проблемы с доступом для пользователей, обращаюющихся к томам Azure NetApp Files. В результате рекомендуется настроить атрибут UID в LDAP для индексирования Active Directory.
Настройка атрибута UID для индексирования Active Directory
Атрибуты индексируются с помощью значения searchFlags для объекта атрибута, который можно настроить с помощью ADSI Edit в контексте именования схем. Доступ к ADSI Редактору должен осуществляться с осторожностью и требует, по крайней мере, привилегий администратора схемы.
По умолчанию для объекта атрибута uid searchFlags задано значение 0x8 (PRESERVE_ON_DELETE). Этот параметр по умолчанию гарантирует, что даже если объект в Active Directory удален, значение атрибута сохраняется в каталоге в качестве исторической записи атрибута пользователя.
Для сравнения атрибут, индексированный в Active Directory для поиска LDAP, будет иметь значение 0x1 (или некоторое сочетание, включая это значение), например uidNumber:
Из-за этого запросы по uidNumber выполняются быстрее, чем запросы по uid. Для обеспечения согласованности и производительности можно настроить searchFlags значение идентификатора (uid) на 9, добавив 0x1 к существующему значению 0x8, которое представляет собой (INDEX | PRESERVE_ON_DELETE). Это дополнение поддерживает поведение по умолчанию при добавлении индексирования атрибутов в каталог.
При индексировании поиск пользовательских атрибутов с uid выполняется так же быстро, как и поиск других индексированных атрибутов.