Общие сведения об использовании LDAP с Azure NetApp Files

Статья
08/09/2023

Упрощенный протокол доступа к каталогам (LDAP) — это стандартный протокол доступа к каталогам, разработанный международным комитетом по разработке целевой группы интернета (IETF). LDAP предназначен для предоставления службы каталогов на основе сети общего назначения, которую можно использовать на разных платформах для поиска сетевых объектов.

Модели LDAP определяют, как взаимодействовать с хранилищем каталогов LDAP, как найти объект в каталоге, как описать объекты в хранилище и безопасность, используемую для доступа к каталогу. LDAP разрешает настройку и расширение объектов, описанных в хранилище. Поэтому для хранения различных типов различных сведений можно использовать хранилище LDAP. Многие начальные развертывания LDAP сосредоточены на использовании LDAP в качестве хранилища каталогов для таких приложений, как электронная почта и веб-приложения, а также хранение сведений о сотрудниках. Многие компании заменяют или заменяют сетевую информационную службу (NIS) на LDAP в качестве сетевого хранилища каталогов.

Сервер LDAP предоставляет удостоверения пользователей и групп UNIX для использования с томами NAS. В Azure NetApp Files Active Directory является единственным поддерживаемым в настоящее время сервером LDAP, который можно использовать. Эта поддержка включает как службы домен Active Directory (AD DS), так и доменные службы Microsoft Entra.

Запросы LDAP можно разбить на две основные операции.

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

LDAP может хранить следующие сведения, используемые в доступе к NAS с двумя протоколами:

Имена пользователей
Имена групп
Числовые идентификаторы пользователей (UID) и идентификаторы групп (GID)
Домашние каталоги
Оболочка входа
Netgroups, DNS-имена и IP-адреса
Членство в группе

В настоящее время Azure NetApp Files использует протокол LDAP только для сведений о пользователях и группах — нет группы или сведений о узле.

LDAP предлагает различные преимущества для пользователей и групп UNIX в качестве источника удостоверений.

LDAP является будущим подтверждением.
Поскольку больше клиентов NFS добавляют поддержку для доменов NFSv4.x, NFSv4.x id, содержащих актуальный список пользователей и групп, доступных от клиентов и хранилищ, необходимы для обеспечения оптимальной безопасности и гарантированного доступа при определении доступа. Наличие сервера управления удостоверениями, предоставляющего сопоставления имен "один к одному" для пользователей S МБ и NFS, значительно упрощает жизнь администраторов хранилища, а не только в настоящее время, но и в течение многих лет.
ПРОТОКОЛ LDAP можно масштабировать.
Серверы LDAP предлагают возможность содержать миллионы объектов пользователей и групп, а с помощью Microsoft Active Directory можно использовать несколько серверов для реплика te на нескольких сайтах для масштабирования производительности и устойчивости.
Протокол LDAP является безопасным.
LDAP обеспечивает безопасность в виде того, как система хранения может подключаться к серверу LDAP, чтобы запрашивать сведения о пользователе. Серверы LDAP предлагают следующие уровни привязки:
- Анонимный (отключен по умолчанию в Microsoft Active Directory; не поддерживается в Azure NetApp Files)
- Простой пароль (пароли обычного текста; не поддерживаются в Azure NetApp Files)
- Простой уровень проверки подлинности и безопасности (SASL) — зашифрованные методы привязки, включая TLS, SSL, Kerberos и т. д. Azure NetApp Files поддерживает протокол LDAP по протоколу TLS, подписи LDAP (с помощью Kerberos), LDAP по протоколу SSL.
ПРОТОКОЛ LDAP является надежным.
NIS, NIS+и локальные файлы предоставляют основные сведения, такие как UID, GID, пароль, домашние каталоги и т. д. Однако LDAP предлагает эти атрибуты и многое другое. Дополнительные атрибуты, которые ldap использует, делают управление двумя протоколами гораздо более интегрированным с LDAP и NIS. Только LDAP поддерживается как внешняя служба имен для управления удостоверениями с помощью Azure NetApp Files.
Microsoft Active Directory основан на LDAP.
По умолчанию Microsoft Active Directory использует серверную часть LDAP для своих записей пользователей и групп. Однако эта база данных LDAP не содержит атрибуты стиля UNIX. Эти атрибуты добавляются при расширении схемы LDAP с помощью управления удостоверениями для UNIX (Windows 2003R2 и более поздних версий), службы для UNIX (Windows 2003 и более ранних версий) или сторонних средств LDAP, таких как Centrify. Так как корпорация Майкрософт использует LDAP в качестве серверной части, она делает LDAP идеальным решением для сред, которые выбирают использование томов двойного протокола в Azure NetApp Files.

Примечание.

Azure NetApp Files в настоящее время поддерживает только собственные службы Microsoft Active Directory для служб LDAP.

Основы LDAP в Azure NetApp Files

В следующем разделе рассматриваются основы LDAP, относящиеся к Azure NetApp Files.

Сведения LDAP хранятся в неструктурированных файлах на сервере LDAP и организованы по схеме LDAP. Необходимо настроить клиенты LDAP таким образом, чтобы координировать свои запросы и подстановки с помощью схемы на сервере LDAP.
Клиенты LDAP инициируют запросы путем привязки LDAP, которая, по сути, является именем входа на сервер LDAP с помощью учетной записи с доступом на чтение к схеме LDAP. Конфигурация привязки LDAP на клиентах настроена для использования механизма безопасности, определенного сервером LDAP. Иногда они являются именами пользователей и обменом паролями в простом тексте (просто). В других случаях привязки защищены с помощью простых методов проверки подлинности и уровня безопасности (sasl), таких как Kerberos или LDAP через TLS. Azure NetApp Files использует учетную запись компьютера S МБ для привязки с использованием проверки подлинности SASL для обеспечения оптимальной безопасности.
Сведения о пользователях и группах, хранящихся в LDAP, запрашиваются клиентами с помощью стандартных запросов поиска LDAP, определенных в RFC 2307. Кроме того, более новые механизмы, такие как RFC 2307bis, позволяют упростить поиск пользователей и групп. Azure NetApp Files использует форму RFC 2307bis для поиска схем в Windows Active Directory.
Серверы LDAP могут хранить сведения о пользователях и группах и netgroup. Однако в настоящее время Azure NetApp Files не может использовать функции netgroup в LDAP в Windows Active Directory.
LDAP в Azure NetApp Files работает с портом 389. Этот порт в настоящее время нельзя изменить для использования пользовательского порта, например порта 636 (LDAP по протоколу SSL) или порта 3268 (поиск по глобальному каталогу Active Directory).
Зашифрованные связи LDAP можно достичь с помощью протокола LDAP по протоколу TLS (который работает через порт 389) или подписи LDAP, оба из которых можно настроить в подключении Active Directory.
Azure NetApp Files поддерживает запросы LDAP, которые занимают не более 3 секунд. Если у сервера LDAP много объектов, это время ожидания может быть превышено, и запросы проверки подлинности могут завершиться ошибкой. В этих случаях рекомендуется указать область поиска LDAP, чтобы фильтровать запросы для повышения производительности.
Azure NetApp Files также поддерживает указание предпочитаемых серверов LDAP для ускорения запросов. Используйте этот параметр, если вы хотите убедиться, что сервер LDAP ближе всего к региону Azure NetApp Files используется.

Если не задан предпочтительный сервер LDAP, доменное имя Active Directory запрашивается в DNS для записей службы LDAP, чтобы заполнить список серверов LDAP, доступных для вашего региона, расположенного в этой записи SRV. Вы можете вручную запрашивать записи службы LDAP в DNS из клиента с помощью nslookup или dig команд.

Например:

C:\>nslookup
Default Server:  localhost
Address:  ::1

> set type=SRV
> _ldap._tcp.contoso.com.

Server:  localhost
Address:  ::1

_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 0
          port           = 389
          svr hostname   = oneway.contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = ONEWAY.Contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = oneway.contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = parisi-2019dc.contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = contoso.com
oneway.contoso.com       internet address = x.x.x.x
ONEWAY.Contoso.com       internet address = x.x.x.x
oneway.contoso.com       internet address = x.x.x.x
parisi-2019dc.contoso.com        internet address = y.y.y.y
contoso.com      internet address = x.x.x.x
contoso.com      internet address = y.y.y.y

Серверы LDAP также можно использовать для выполнения сопоставления пользовательских имен для пользователей. Дополнительные сведения см. в разделе "Сопоставление пользовательских имен" с помощью LDAP.
Время ожидания запросов LDAP

По умолчанию время ожидания запросов LDAP, если они не могут быть выполнены своевременно. Если запрос LDAP завершается сбоем из-за времени ожидания, запрос пользователя и группы завершится ошибкой, и доступ к тому Azure NetApp Files может быть отклонен в зависимости от параметров разрешений тома. Ознакомьтесь с разделом "Создание подключений Active Directory и управление ими" , чтобы понять параметры времени ожидания запроса LDAP для Azure NetApp Files.

Типы сопоставления имен

Правила сопоставления имен можно разбить на два основных типа: симметричный и асимметричный.

Сопоставление симметричного имени — это неявное сопоставление имен между пользователями UNIX и Windows, которые используют то же имя пользователя. Например, пользователь CONTOSO\user1 Windows сопоставляется с пользователем user1UNIX.
Сопоставление асимметричных имен — это сопоставление имен между пользователями UNIX и Windows, которые используют разные имена пользователей. Например, пользователь CONTOSO\user1 Windows сопоставляется с пользователем user2UNIX.

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

Сопоставление пользовательских имен с помощью LDAP

LDAP может быть ресурсом сопоставления имен, если атрибуты схемы LDAP на сервере LDAP заполнены. Например, чтобы сопоставить пользователей UNIX с соответствующими именами пользователей Windows, которые не соответствуют одному (то есть асимметрично), можно указать другое значение в объекте пользователя, отличное от uid того, что настроено для имени пользователя Windows.

В следующем примере у пользователя есть имя Windows и необходимо сопоставить его asymmetric с удостоверением UNIXuserUNIX. Чтобы добиться этого в Azure NetApp Files, откройте экземпляр Пользователи и компьютеры Active Directory MMC. Затем найдите нужного пользователя и откройте поле свойств. (Для этого требуется включить редактор атрибутов). Перейдите на вкладку "Редактор атрибутов" и найдите поле UID, а затем заполните поле UID нужным именем UNIXuser пользователя UNIX и нажмите кнопку "Добавить " и "ОК ", чтобы подтвердить.

После выполнения этого действия файлы, написанные из Windows S МБ пользователем Windowsasymmetric, будут принадлежать UNIXuser с стороны NFS.

В следующем примере показан владелец asymmetricWindows S МБ:

В следующем примере показан владелец UNIXuser NFS (сопоставленный с пользователем asymmetric Windows с помощью LDAP):

root@ubuntu:~# su UNIXuser
UNIXuser@ubuntu:/root$ cd /mnt
UNIXuser@ubuntu:/mnt$ ls -la
total 8
drwxrwxrwx  2 root     root   4096 Jul  3 20:09 .
drwxr-xr-x 21 root     root   4096 Jul  3 20:12 ..
-rwxrwxrwx  1 UNIXuser group1   19 Jul  3 20:10 asymmetric-user-file.txt

Схемы LDAP

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

Когда Azure NetApp Files запрашивает LDAP, схемы используются для ускорения поиска имен, так как они позволяют использовать определенные атрибуты для поиска сведений о пользователе, таких как UID. Атрибуты схемы должны существовать на сервере LDAP для Azure NetApp Files, чтобы найти запись. В противном случае запросы LDAP могут возвращать данные и запросы проверки подлинности могут завершиться ошибкой.

Например, если идентификатор пользовательского интерфейса (например, root=0) должен запрашиваться Azure NetApp Files, используется атрибут схемы RFC 2307 uidNumber Attribute . Если в поле не uidNumber существует номера 0 UID, запрос поиска завершается ошибкой.

Тип схемы, используемый в настоящее время Azure NetApp Files, является формой схемы на основе RFC 2307bis и не может быть изменен.

RFC 2307bis является расширением RFC 2307 и добавляет поддержку posixGroup, которая обеспечивает динамический поиск вспомогательных групп с помощью атрибута, а не с помощью uniqueMembermemberUid атрибута в схеме LDAP. Вместо того чтобы использовать только имя пользователя, этот атрибут содержит полное различающееся имя (DN) другого объекта в базе данных LDAP. Таким образом, группы могут иметь другие группы в качестве членов, что позволяет вложенности групп. Поддержка RFC 2307bis также добавляет поддержку класса groupOfUniqueNamesобъектов.

Это расширение RFC хорошо подходит для того, как Microsoft Active Directory управляет пользователями и группами с помощью обычных средств управления. Это связано с тем, что при добавлении пользователя Windows в группу (и если эта группа имеет допустимый числовый GID), используя стандартные методы управления Windows, подстановки LDAP будут извлекать необходимые сведения о дополнительной группе из обычного атрибута Windows и находить числовые GID автоматически.

Share via

Общие сведения об использовании LDAP с Azure NetApp Files

Основы LDAP в Azure NetApp Files

Типы сопоставления имен

Сопоставление пользовательских имен с помощью LDAP

Схемы LDAP

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

Дополнительные ресурсы