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

Статья
06/13/2024

Упрощенный протокол доступа к каталогам (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, содержащих актуальный список пользователей и групп, доступных от клиентов и хранилищ, необходимы для обеспечения оптимальной безопасности и гарантированного доступа при определении доступа. Наличие сервера управления удостоверениями, предоставляющего сопоставления имен для пользователей SMB и NFS, значительно упрощает жизнь администраторов хранилища, а не только в настоящее время, но и в течение многих лет.
ПРОТОКОЛ LDAP можно масштабировать.
Серверы LDAP предлагают возможность содержать миллионы объектов пользователей и групп, а с помощью Microsoft Active Directory можно использовать несколько серверов для репликации на нескольких сайтах для масштабирования производительности и устойчивости.
Протокол 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 использует учетную запись компьютера SMB для привязки с использованием проверки подлинности 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 SMB, будут принадлежать UNIXuser пользователю asymmetric Windows с стороны NFS.

В следующем примере показан владелец asymmetricSMB Windows:

В следующем примере показан владелец 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

Доступ локальных пользователей NFS с LDAP

Когда пользователь пытается получить доступ к тому Azure NetApp Files через NFS, запрос поступает в числовой идентификатор. По умолчанию Azure NetApp Files поддерживает расширенные членства в группах для пользователей NFS (чтобы выйти за пределы стандартного 16 групп). В результате Azure NetApp-файлы попытаются принять этот числовый идентификатор и найти его в LDAP в попытке разрешить членство в группах для пользователя, а не передавать членство в группах в пакетЕ RPC. В связи с этим поведением, если этот числовый идентификатор не может быть разрешен пользователю в LDAP, поиск завершится ошибкой и доступ будет отклонен, даже если запрашивающий пользователь имеет разрешение на доступ к тому или структуре данных. Разрешение локальных пользователей NFS с параметром LDAP в подключениях Active Directory предназначено для отключения этих запросов LDAP для запросов NFS, отключив расширенные функции группы. Он не предоставляет "локальное создание и управление пользователями" в Azure NetApp Files.

Если включен параметр "Разрешить локальным пользователям NFS с протоколом LDAP", числовые идентификаторы передаются в Azure NetApp Files, а поиск LDAP не выполняется. Это создает разное поведение для различных сценариев, как описано ниже.

NFSv3 с томами стиля безопасности UNIX

Числовые идентификаторы не нужно переводить в имена пользователей. Параметр "Разрешить локальным пользователям NFS с помощью LDAP" не влияет на доступ к тому, но может повлиять на то, как на клиенте NFS отображаются права владения пользователями или группами (перевод имен). Например, если числовый идентификатор 1001 является user1 в LDAP, но является пользователем2 в локальном файле сквозной передачи клиента NFS, клиент будет отображать "user2" в качестве владельца файла, если числовой идентификатор равен 1001.

NFSv4.1 с томами стиля безопасности UNIX

Числовые идентификаторы не нужно переводить в имена пользователей. По умолчанию NFSv4.1 использует строки имен (user@CONTOSO.COM) для проверки подлинности. Однако Azure NetApp Files поддерживает использование числовых идентификаторов с NFSV4.1, что означает, что запросы NFSv4.1 будут поступать на сервер NFS с числовым идентификатором. Если в локальных файлах или службах имен, таких как LDAP, для тома Azure NetApp Files нет числовых идентификаторов для перевода имен пользователей, число будет представлено клиенту. Если числовый идентификатор преобразуется в имя пользователя, будет использоваться строка имени. Если строка имени не соответствует, клиент будет сквашивать имя анонимному пользователю, указанному в файле idmapd.conf клиента. Включение параметра "Разрешить локальным пользователям NFS с помощью LDAP" не повлияет на доступ NFSv4.1, так как это приведет к стандартному поведению NFSv3, если Azure NetApp Files не может разрешить числовый идентификатор имени пользователя в локальной пользовательской базе данных NFS. Azure NetApp Files имеет набор пользователей UNIX по умолчанию, которые могут быть проблемными для некоторых клиентов и сквош к пользователю "никто", если строки идентификатора домена не совпадают.

Локальные пользователи включают: root (0), pcuser (65534), никто (65535).
Локальные группы включают: root (0), управляющая программа (1), pcuser (65534), никто (65535).

Чаще всего корневой каталог может отображаться неправильно в подключении клиента NFSv4.1 при неправильной настройке идентификатора домена NFSv4.1. Дополнительные сведения о домене идентификатора NFSv4.1 см. в разделе "Настройка домена идентификатора NFSv4.1 для Azure NetApp Files".

Списки управления доступом NFSv4.1 можно настроить с помощью строки имени или числового идентификатора. Если используются числовые идентификаторы, преобразование имен не требуется. Если используется строка имени, для правильного разрешения ACL потребуется перевод имен. При использовании списков управления доступом NFSv4.1 включение параметра "Разрешить локальным пользователям NFS с помощью LDAP" может привести к неправильному поведению ACL NFSv4.1 в зависимости от конфигурации ACL.

NFS (версия 3 и 4.1) с томами стиля безопасности NTFS в конфигурациях двойного протокола

Тома стиля безопасности UNIX используют разрешения на стиль UNIX (биты режима и списки управления доступом NFSv4.1). Для этих типов томов NFS использует только проверку подлинности в стиле UNIX, используя числовый идентификатор или строку имени в зависимости от описанных выше сценариев. Однако тома безопасности NTFS используют разрешения на стиль NTFS. Эти разрешения назначаются пользователям и группам Windows. Когда пользователь NFS пытается получить доступ к тому с разрешением стиля NTFS, сопоставление имен UNIX с Windows должно выполняться для обеспечения надлежащих элементов управления доступом. В этом сценарии числовый идентификатор NFS по-прежнему передается тому Azure NetApp Files NFS, но для преобразования числового идентификатора в имя пользователя UNIX требуется сопоставить с именем пользователя Windows для первоначальной проверки подлинности. Например, если числовый идентификатор 1001 пытается получить доступ к подключению NFS с разрешениями на стиль безопасности NTFS, которые позволяют получить доступ к пользователю Windows user1, то 1001 потребуется разрешить в LDAP имя пользователя "user1", чтобы получить ожидаемый доступ. Если пользователь с числовым идентификатором "1001" не существует в LDAP или если протокол LDAP неправильно настроен, будет выполнено 1001@contoso.comсопоставление имен UNIX с Windows. В большинстве случаев пользователи с таким именем не существуют, поэтому проверка подлинности завершается ошибкой и доступ запрещен. Аналогичным образом, если числовый идентификатор 1001 разрешает неправильное имя пользователя (например, user2), запрос NFS сопоставляется с непредвиденным пользователем Windows, а разрешения для пользователя будут использовать элементы управления доступом "user2".

Включение параметра "Разрешить локальным пользователям NFS с помощью LDAP" отключит все преобразования числовых идентификаторов LDAP на имена пользователей, которые эффективно прерывают доступ к томам стиля безопасности NTFS. Таким образом, использование этого параметра с томами стиля безопасности NTFS очень не рекомендуется.

Схемы 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 автоматически.

Поделиться через