Общие сведения о Kerberos в Azure NetApp Files

Kerberos — это протокол проверки подлинности, использующий секретный ключ для проверки удостоверения субъектов. Секретные ключи создаются путем принятия пароля участника и преобразования его в хэшированный формат криптографического ключа с помощью согласованного метода шифрования клиентом и сервером (например, AES). Ознакомьтесь с разделом терминологии Kerberos, чтобы узнать об терминах, используемых в этом документе.

Центры распространения ключей (KDCs), такие как Windows Active Directory, поддерживают базу данных субъектов Kerberos и хэшированные пароли. В Kerberos секретный ключ является подтверждением уникального удостоверения. Таким образом, KDC может быть доверенным для проверки подлинности любого субъекта в любом другом субъекте, например проверке подлинности имени субъекта-службы клиента NFS (SPN) на сервере NFS при подключении. Кроме того, это может быть доверенным для подтверждения подлинности пользователя на сервере NFS по имени главного пользователя службы для доступа к точке монтирования NAS. В качестве добавленной меры безопасности Kerberos не отправляет пароли с четким текстом для проверки подлинности по сети.

Azure NetApp Files поддерживает использование Kerberos для обеспечения безопасности во время полета для протоколов SMB и NFS.

Поддерживаемые типы шифрования

Azure NetApp Files поддерживает NFS Kerberos с определенными типами шифрования в зависимости от режима работы и используемой версии.

Чтобы убедиться, что клиент использует правильный тип шифрования, можно ограничить допустимые типы шифрования в основном объекте, расположенном в KDC (например, учетной записи компьютера) или в файлах keytab, созданных клиентом вручную, а не глобально в файле /etc/krb5.conf, так как управление многочисленными файлами krb5.conf клиента может быть затруднением управления. Централизованное управление Kerberos из KDC является более масштабируемым в крупных корпоративных средах, проще автоматизировать и заставляет клиента использовать более надежные типы шифрования при их поддержке.

Примечание.

Рекомендуется задать значение allow_weak_crypto false в файле krb5.conf на клиентах. Этот параметр предотвращает использование менее безопасных enctypes для взаимодействия по Kerberos (например, DES или 3DES).

В следующей таблице показаны поддерживаемые типы шифрования для Kerberos (SMB и NFS) для Azure NetApp Files.

Протокол Поддерживаемые типы шифрования
Малый и средний бизнес (SMB)
  • RC4-HMAC
  • AES-128
  • AES-256
Сетевая файловая система (NFS) AES-256

Поддерживаемые режимы безопасности Kerberos NFS

Помимо концепции типов шифрования, существуют также уровни безопасности и целостности в Kerberos. В зависимости от используемого режима безопасности, эти режимы помогают предотвратить атаки посредника, предлагая сквозное шифрование для трафика NFS.

В Azure NetApp Files режимы безопасности задаются в правилах политики экспорта для NFS томов и определяются на этапе начального монтирования NFS с помощью параметра монтирования sec.

Например: # mount -o sec=krb5p

Примечание.

Для SMB Kerberos режимы безопасности контролируются через параметры шифрования SMB в общей папке, защиту UNC и политики подписания или запечатывания SMB на контроллерах домена.

Следующие режимы безопасности поддерживаются Azure NetApp Files для использования с NFS Kerberos:

Режим безопасности Описание
krb5 Только шифрование для проверки подлинности.

Использует строки имен Kerberos версии 5 и имена субъектов-пользователей вместо идентификаторов локальных пользователей UNIX (UID) и идентификаторов групп (GID) для проверки подлинности пользователей.
krb5i Шифрование аутентификации и проверка целостности с шифрованием.

Использует Kerberos V5 для проверки подлинности пользователей, а также выполняет проверку целостности операций NFS с помощью безопасных контрольных сумм, чтобы предотвратить изменение данных и атаки типа 'человек посередине'.
krb5p Вся беседа NFS зашифрована.

Использует Kerberos V5 для проверки подлинности и целостности пользователей, а также шифрует весь трафик NFS, чтобы предотвратить сниффинг пакетов. Этот параметр является наиболее безопасным, но он также создает большую нагрузку на производительность.

Терминология Kerberos

В этом разделе определяются ключевые термины, используемые при описании процессов Kerberos. Этот раздел предназначен для уточнения терминов, которые могут быть незнакомы администраторам хранилища.

Термин Определение
Центр распространения ключей (KDC) KDC — это сервер проверки подлинности, включающий службу предоставления билетов (TGS) и службу проверки подлинности (AS). Термины KDC, AS и TGS используются взаимозаменяемо. В средах Майкрософт контроллер домена Active Directory (AD) является KDC. Изменение значений KDC может быть достигнуто только путем изменения параметров AD.
Область (или область Kerberos) Область (или область Kerberos) может использовать любую строку ASCII. Стандарт — использовать доменное имя в верхнем регистре; например, contoso.com становится областью CONTOSO.COM. Области Kerberos обычно настраиваются в файлах krb5.conf на клиентах и серверах.

Административно, каждый principal@REALM должен быть уникальным. Чтобы избежать одной точки сбоя, каждая область может иметь несколько ЦД, которые используют одну базу данных (субъекты и пароли) и имеют одинаковые главные ключи KDC. Microsoft Windows Active Directory выполняет это в собственном коде путем репликации Active Directory, которая выполняется каждые 15 минут по умолчанию.
Директор Термин "принципал" означает каждую сущность в базе данных Kerberos. Пользователи, компьютеры и службы назначены в качестве субъектов для проверки подлинности Kerberos. Каждый субъект должен быть уникальным в базе данных Kerberos и определяется его различаемым именем. Субъект может быть именем участника-пользователя (UPN) или именем субъекта-службы (SPN).

Основное имя состоит из трех частей:
  • Основная часть — основная часть может быть пользователем или службой, например службой NFS. Это также может быть специальная служба «host», что означает, что этот главный субъект службы настроен для предоставления разнообразных сетевых служб.
  • Экземпляр — в случае пользователя, эта часть является необязательной. Пользователь может иметь несколько субъектов, но каждый субъект должен быть уникальным в KDC. Например, у Фреда может быть учетная запись, предназначенная для повседневного использования (fred@contoso.com), и учетная запись, предназначенная для привилегированного использования, например, учетная запись системного администратора (admin-fred@contoso.com). Экземпляр требуется для учётных записей служб и определяет полное доменное имя (FQDN) узла, предоставляющего службу.
  • Область — область Kerberos — это набор субъектов Kerberos, зарегистрированных на сервере Kerberos. По соглашению имя области обычно совпадает с DNS-именем, но оно преобразуется в прописные буквы. Прописные буквы не являются обязательными, но соглашение обеспечивает простое различие между DNS-именем и именем области.
Билеты Билет — это временный набор учетных данных, который проверяет удостоверение субъекта для службы и содержит ключ сеанса. Тикет может быть служебным тикетом, тикетом приложения или тикетом, выдающим доступ (TGT). Билеты обмениваются между клиентом, сервером и KDC для проверки подлинности Kerberos.
Секретные ключи Kerberos использует систему симметричного ключа, в которой секретный ключ используется как для шифрования, так и для расшифровки. Секретный ключ создается из пароля Kerberos субъекта с помощью функции одностороннего хэша. KDC сохраняет пароль для каждого субъекта и может таким образом создать секретный ключ субъекта. Для пользователей, запрашивающих службу Kerberos, секретный ключ обычно является производным от пароля, представленного программе kinit. Субъекты службы и демоны обычно не используют пароль; вместо этого результат односторонней хэш-функции хранится в кейтаб.
Кейттаб (Keytab) Ключ содержит список субъектов и их секретных ключей. Секретные ключи в keytab часто создаются с помощью случайного пароля и используются в основном для субъектов-служб или управляющей программы.

Сведения о сетевом порту

В следующей таблице описывается, какие сетевые порты используются для обмена данными Kerberos. Если сетевой брандмауэр установлен, эти порты должны быть открыты, чтобы разрешить правильную функциональность Kerberos. Дополнительные сведения об этих портах можно найти в реестре номеров портов IANA и службы IANA.

Услуга Порт
Kerberos 88 (TCP или UDP)
kpasswd 464 (TCP/UDP)
Упрощенный протокол доступа к каталогу (LDAP) (для сопоставлений имен) 389 (TCP или UDP)
Сервер администрирования 749 (TCP/UDP)
Глобальный каталог (поиск пользователей Windows) 3268 (TCP/UDP)

Значения времени жизни кэша в Azure NetApp Files

В следующей таблице отображается время существования записи кэша в томе Azure NetApp Files.

Кэш Возраст кэша
Простаивающие подключения к серверу имен 60 секунд
Время тайм-аута запроса LDAP 10 секунд
Запись локального узла DNS для TTL KDC 24 ч
Возраст билета Kerberos Задано KDC* и /или клиентом

* По умолчанию используется значение 10 часов для KDCs Windows Active Directory
Учетные данные пользователя 24 ч
Отклонение времени Kerberos 5 мин

Требования к правильному функционированию сред Kerberos в Azure NetApp Files

Аутентификация Kerberos в значительной степени зависит от внешних служб для правильного функционирования. В Microsoft Active Directory большинство этих служб объединяются на один сервер во многих случаях. Например, контроллер домена Active Directory может обслуживать следующие зависимости Kerberos:

  • Службы синхронизации времени
  • DNS (Система доменных имен)
  • Распределение ключей Kerberos
  • Службы паролей и единый вход
  • Службы удостоверений (например, LDAP)

При использовании встроенного Microsoft Active Directory (единственного типа KDC, который в настоящее время поддерживается Azure NetApp Files), большинство внешних зависимостей для Kerberos в Azure NetApp Files покрыты, включая такие компоненты, как DNS, KDC и службы паролей. В некоторых случаях необходимые службы могут размещаться за пределами домена Active Directory (например , DNS). В таких случаях важно убедиться, что необходимые службы настроены правильно.

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

Службы синхронизации времени

Службы синхронизации времени являются обязательными при использовании Kerberos для проверки подлинности, так как механизмы запросов Kerberos зависят от временных отклонений между клиентом и сервером в пределах 5-минутного диапазона по умолчанию. Если параметры времени на клиенте или сервере превышают пятиминутный диапазон, проверка подлинности Kerberos вызовет ошибку из-за несоответствия времени (KRB_AP_ERR_SKEW), и доступ к общей папке NAS будет отказан. Это время ожидания является функцией безопасности, которая помогает предотвратить "атаки воспроизведения", где злоумышленник может перехватывать сообщения между центром распределения ключей (KDC) и клиентом, а затем воспроизводить эти сообщения позже, чтобы олицетворить прошедшего проверку подлинности пользователя. Ограничения на отклонение времени помогают свести к минимуму риск таких атак.

Основные рекомендации по синхронизации времени:

Дополнительные сведения см. в разделе "Максимально допустимое значение для синхронизации часов компьютера"

Системы доменных имен (DNS)

Системы доменных имен (DNS) являются обязательными для Kerberos в качестве функции безопасности. Разрешение имени узла используется для формирования служебных принципов Kerberos, используемых для проверки подлинности. В этом процессе для подключения к ресурсам, использующим проверку подлинности Kerberos, применяются прямые запросы для имен узлов (записи A/AAAA). Затем этот прямой поиск используется для формирования имени основного лица службы (SPN), используемого в запросе проверки подлинности Kerberos. Если существующий SPN не удается найти в KDC, проверка подлинности Kerberos завершается ошибкой.

В средах Windows SMB можно попробовать метод проверки подлинности резервного копирования (например, NTLM). Однако во многих случаях NTLM отключен по соображениям безопасности, что приведет к сбою доступа к общей папке при сбое проверки подлинности Kerberos. Средство просмотра событий Windows часто регистрирует первопричину сбоев (например, дублирующихся или отсутствующих SPN, сбоев поиска DNS, сбоев NTLM и т. д.).

В дополнение к разрешению SPN, DNS часто используется для разрешения имен узлов и IP-адресов для доменных служб, таких как LDAP, KDC Kerberos и т.д., через записи SRV. Дополнительные сведения о DNS в Azure NetApp Files (включая необходимые записи SRV), см. в статье "О DNS" в Azure NetApp Files.

Примечание.

Если IP-адрес используется для доступа Kerberos, поведение зависит от используемого протокола NAS (NFS или SMB). Дополнительные сведения см. в разделе IP-адресов для доступа с помощью Kerberos.

LDAP

Протокол LDAP использует серверные базы данных удостоверений для предоставления единого источника службы имен для клиентов и серверов NAS, чтобы все участвующие устройства согласились на подлинность пользователей, членство в группах и числовые идентификаторы, которые затем используются для разрешений на файлы.

Для Kerberos учетные записи пользователей и служб хранятся в записях баз данных LDAP как атрибуты учетных записей. Windows Active Directory поддерживает это по умолчанию. В некоторых случаях (например, при создании псевдонимов или субъектов-служб), пользователям и компьютерам требуется добавление или изменение имен субъектов-служб. Это требование можно выполнить с помощью консоли управления Microsoft (MMC) "Active Directory — Пользователи и компьютеры" или PowerShell. Дополнительные сведения об управлении именами субъектов-служб см. в разделе "Управление именами субъектов-служб".

Помимо имен субъектов-служб и числовых идентификаторов для проверки подлинности Kerberos, LDAP также можно использовать для удостоверений пользователей и групп UNIX, которые применяются для сопоставления имен удостоверений в Azure NetApp Files, а также для начальной проверки подлинности подключений NFS Kerberos через сопоставление имен пользователей UNIX с помощью SPN. Дополнительные сведения см. в статье о работе NFS Kerberos в Azure NetApp Files и роли LDAP с Kerberos в Azure NetApp Files.

Как работает SMB Kerberos в Azure NetApp Files

Kerberos SMB работает отдельно от служб Kerberos NFS, так как учетные записи компьютеров, созданные для каждого протокола, не могут совместно использовать ключи из-за возможных изменений в номере версии ключа (kvno) в одной ключевой строке, влияющей на другую службу. В результате этого, а также естественные различия в протоколах NAS рабочие процессы для служб SMB для Kerberos и NFS для Kerberos отличаются в функциональных возможностях в некоторых областях.

Начальная настройка служб SMB

Службы SMB в Azure NetApp Files изначально настраиваются путем настройки подключения Active Directory, который определяет несколько критически важных частей для взаимодействия с доменными службами, в том числе:

  • Основной DNS-сервер (обязательный)
  • Вторичный DNS
  • DNS-имя Active Directory*
  • Имя сайта Active Directory (для обнаружения контроллера домена) (обязательно)
  • Имя префикса сервера SMB
  • Подразделение (где создаются учетные записи сервера SMB)
  • Включение и отключение шифрования AES
  • Включение и отключение подписывания LDAP
  • Конфигурация LDAP
  • Шифрование SMB в контроллере домена
  • Привилегированные пользователи
  • Учетные данные имени пользователя и пароля для разрешений организационной единицы

Примечание.

Для каждой учетной записи разрешено только одно подключение Azure Active Directory (AD). После создания подключения AD любой новый том SMB Azure NetApp Files использует конфигурацию подключения AD.

Учетная запись компьютера Kerberos SMB

Учетная запись машины в Active Directory содержит соответствующие сведения для использования в запросах проверки подлинности, включая служебное имя (SPN). При создании тома SMB в Azure NetApp Files конфигурация подключений Active Directory используется для взаимодействия при создании учетной записи компьютера для обеспечения безопасного доступа к общей папке SMB через проверку подлинности Kerberos (или NTLM, если включена).

Новые учетные записи компьютера создаются при подготовке тома SMB Azure NetApp Files для определенного серверного ресурса в службе. Ниже показаны различные сценарии, в которых учетная запись компьютера SMB может быть создана или повторно использована в конфигурациях томов Azure NetApp Files.

Сценарий Результат
Первый новый том SMB Новое имя учетной записи компьютера SMB или DNS
Последующие тома SMB, созданные в коротком последовательности из первого тома SMB Повторно используется учетная запись компьютера SMB или DNS-имя (в большинстве случаев).
Последующие тома SMB, созданные гораздо позже первого тома SMB Служба определяет, требуется ли новая учетная запись компьютера. Можно создать несколько учетных записей компьютера, создающих несколько конечных точек IP-адресов.
Первый том с поддержкой двух протоколов Новое имя учетной записи компьютера SMB или DNS
Последующие тома с двумя протоколами, созданные в короткой серии после первого тома с двумя протоколами Повторно используется учетная запись компьютера SMB или DNS-имя (в большинстве случаев)
Последующие двухпротокольные тома, созданные значительно позже первого двухпротокольного тома Служба определяет, требуется ли новая учетная запись компьютера. Можно создать несколько учетных записей компьютера, создающих несколько конечных точек IP-адресов.
Первый том SMB, созданный после тома двойного протокола Новое имя учетной записи компьютера SMB или DNS
Первый том двойного протокола, созданный после тома SMB Новое имя учетной записи компьютера SMB или DNS

Учетная запись компьютера SMB, созданная для тома SMB Azure NetApp Files (или с двойным протоколом), использует соглашение об именовании, которое соответствует максимуму в 15 символов, установленному Active Directory. Имя использует структуру префикса [префикса сервера SMB, указанного в конфигурации подключения Azure AD]-[уникальный числовый идентификатор].

Например, если вы настроили подключения AD для использования префикса сервера SMB "AZURE", то учетная запись компьютера SMB, созданная Azure NetApp Files, напоминает azure-7806. Это же имя используется в пути UNC для общей папки SMB (например, \AZURE-7806) и является именем, используемым динамическими службами DNS для создания записи A/AAAA.

Примечание.

Так как имя, например AZURE-7806, может быть трудно помнить, полезно создать запись CNAME в качестве псевдонима DNS для томов Azure NetApp Files. Дополнительные сведения см. в разделе "Создание псевдонимов сервера SMB".

Схема нескольких учетных записей компьютера и записей DNS в Azure NetApp Files.

В некоторых случаях при создании нескольких томов SMB и (или) с двумя протоколами конфигурация может в конечном итоге оказаться с несколькими разрозненными учетными записями SMB компьютеров и DNS-именами.

Если требуется единое пространство имен для доступа пользователей к томам, это может вызвать проблему в конфигурации, так как один псевдоним CNAME может указывать только на одну запись узла A/AAAA. Использование нескольких идентичных псевдонимов записей A/AAAA может привести к непредсказуемости доступа к данным в томах через различные учетные записи SMB, поскольку нет гарантии, что конечная точка, которую клиент выбирает при запросе DNS, содержит ожидаемый том из-за циклического механизма выбора записей DNS в этих конфигурациях.

Чтобы устранить это ограничение, тома Azure NetApp Files могут участвовать в качестве целевых объектов в конфигурации распределенной файловой системы Майкрософт (DFS), что позволяет связать несколько томов SMB с одной точкой входа пространства имен.

Схема распределенной файловой системы в Azure NetApp Files.

Рабочий процесс создания SPN для SMB Kerberos

На следующей схеме показано, как создается имя принципала службы SMB Kerberos при создании тома SMB или тома с двумя протоколами в Azure NetApp Files. SPN SMB связаны с объектами учетных записей машин SMB в домене. SPN можно просматривать и управлять им через свойства учетной записи компьютера, используя редактор атрибутов в расширенном представлении.

Снимок экрана: свойства Azure-SMB.

Вы также можете просматривать свойства и управлять ими с помощью setspn команды.

Снимок экрана: команда setpn.

Этот процесс выполняет те же действия, что и при присоединении обычного клиента Windows к домену (DNS, LDAP, Kerberos, RPC-запросов по именованным каналам).

Схема учетной записи компьютера Kerberos.

В большинстве случаев знание подробных шагов не требуется для повседневных задач администрирования, но полезно при устранении неполадок при попытке создать том SMB в Azure NetApp Files.

Подробные инструкции

Чтобы увидеть пошаговые инструкции по созданию учетной записи компьютера SMB в Azure NetApp Files, разверните список.

  • Поиск DNS выполняется с использованием конфигурации DNS для SRV-записи Kerberos KDC. Azure NetApp Files использует следующие записи SRV в своих запросах.

    • _kerberos._tcp.dc._msdcs.CONTOSO.COM
    • _kerberos._tcp.CONTOSO.COM (если предыдущий запрос не возвращает результатов)

  • Поиск DNS выполняется с помощью имен узлов, возвращаемых в запросе SRV для записей A/AAAA KDCs.

    • Запрос LDAP ping (привязка LDAP и запрос RootDSE) выполняется для поиска доступных устаревших серверов NetLogon с использованием запроса (&(DnsDomain=CONTOSO.COM)(NtVer=0x00000016)) с фильтром атрибутов для NetLogon. Новые версии контроллера домена Windows (новее 2008 года) не имеют NtVer значения.

  • Dns-запрос выполняется Azure NetApp Files, чтобы найти серверы LDAP в домене с помощью следующих записей SRV:

    • _ldap._tcp.CONTOSO.COM
    • _kerberos._tcp.CONTOSO.COM

    Примечание.

    Эти запросы выполняются несколько раз в рамках одного вызова на разных этапах процесса. Проблемы с DNS могут вызывать замедление этих вызовов или приводить к полным сбоям из-за истечения времени ожидания. — Если по запросам не удается найти запись или если с найденными записями невозможно установить связь, создание тома SMB завершается сбоем. — Если запросы DNS успешно выполнены, то следующие шаги будут выполнены.

  • ICMP (ping) отправляется для проверки доступности IP-адресов, возвращаемых из DNS.

  • Если связь заблокирована в сети политиками брандмауэра, то запрос ICMP завершается сбоем. Вместо этого используются пинги LDAP.

  • Другой запрос LDAP выполняется для поиска доступных устаревших серверов NetLogon с помощью запроса (&(&(DnsDomain=CONTOSO.COM)(Host=KDChostname.contoso.com))(NtVer=0x00000006)) с фильтром атрибутов NetLogon. Более новые версии контроллера домена Windows (новее 2008 года) не имеют значения NtVer.

  • Проверка подлинности AS-REQ отправляется из службы Azure NetApp Files с помощью имени пользователя, настроенного с подключением Active Directory.

  • Контроллер домена отвечает с KRB5KDC_ERR_PREAUTH_REQUIREDзапросом службы безопасно отправить пароль для пользователя.

  • Второй AS-REQ отправляется с данными предварительной проверки подлинности, необходимыми для проверки подлинности с помощью KDC для продолжения создания учетной записи компьютера. В случае успеха билет для выдачи билетов (TGT) отправляется службе.

  • В случае успешного выполнения служба отправляет TGS-REQ, чтобы запросить билет службы CIFS (cifs/kdc.contoso.com) из KDC с помощью TGT, полученного в AS-REP.

  • Выполняется новая привязка LDAP с помощью билета службы CIFS. Запросы отправляются из Azure NetApp Files:

    • Базовый поиск rootDSE для DN домена ConfigurationNamingContext
    • Поиск OneLevel по секциям CN=секций в DN, полученном для ConfigurationNamingContext с помощью фильтра (&(&(objectClass=crossRef)(nETBIOSName=*))(dnsRoot=CONTOSO.COM)) для атрибута NETBIOSname.
    • Базовый поиск с помощью фильтра (|(objectClass=organizationalUnit)(objectClass=container)) выполняется в подразделении, указанном в конфигурации подключений Active Directory. Если не указано, используется значение по умолчанию OU=Computers . Это проверяет наличие контейнера.
    • Поиск поддерев выполняется в базовом DN домена с помощью фильтра (sAMAccountName=ANF-XXXX$), чтобы проверить, существует ли учетная запись уже.
      • Если учетная запись существует, она используется повторно.
    • Если учетная запись не существует, она создана, если у пользователя есть разрешения на создание и изменение объектов в контейнере с помощью addRequest команды LDAP. Следующие атрибуты LDAP задаются в учетной записи:
    Атрибут Значение
    Китай ANF-XXXX
    sAMAccountName ANF-XXXX$
    objectClass
    • Верх
    • Человек
    • ОрганизационныйPerson
    • Пользователь
    • Компьютер
    servicePrincipalName
    • HOST /ANF-XXXX
    • HOST/anf-xxxx.contoso.com
    • CIFS/anf-xxxx.contoso.com
    userAccountControl 4096
    операционная система Выпуск NetApp
    dnsHostName ANF-XXXX.CONTOSO.COM
    • Если addRequest выходит из строя, это приводит к сбою создания тома. Компонент addRequest может завершиться сбоем из-за неправильных разрешений на контейнере.
    • При успешном выполнении addRequest выполняется поиск LDAP с помощью фильтра (sAMAccountName=ANF-XXXX$) с целью получения атрибута objectSid.
    • Беседа SMB2 "Согласование протокола" выполняется для получения поддерживаемого Kerberos mechTypes из KDC.
    • Выполняется установка сеанса SMB2 с использованием SPN CIFS и наиболее поддерживаемой версии протокола, а также подключение к дереву IPC$.
    • Файл SMB2 lsarpc создается в общей папке IPC$.
    • Выполняется привязка к DCERPC . Затем lsarpc файл записывается, а затем читается.
    • Затем выполняются следующие запросы LSA:

  • TGS-REQ с помощью TGT выполняется для получения билета для kadmin/changepw SPN, связанного с учетной записью krbtgt.

  • Запрос KPASSWD выполняется из службы к KDC для изменения пароля учетной записи компьютера.

  • Запрос LDAP выполняется с фильтром (sAMAccountName=ANF-XXXX) для атрибутов distinguishedName и isCriticalSystemObject.

  • Если учетная запись isCriticalSystemObject имеет значение false (значение по умолчанию), извлекаемое DN используется для формирования modifyRequest атрибута msDs-SupportedEncryptionTypes. Это значение установлено на 30, что эквивалентно DES_CBC_MD5 (2) + RC4 (4) + AES 128 (8) + AES 256 (16).

  • Выполняется второй параметр "Согласование протокола"/обмена билетами Kerberos/"Настройка сеанса"/"Подключение к IPC$". Учетная запись компьютера сервера SMB (ANF-XXXX$) служит принципалом Kerberos.

  • Подключение NetLogon, NetrServer ReqChallenge/Authenticate2 завершено.

  • Выполняется третий процесс "Negotiation protocol:/Kerberos ticket exchange/"Настройка сессии"/"Соединение с деревом" с IPC$; учетная запись компьютера сервера SMB (ANF-XXXX$) используется в качестве главного субъекта Kerberos.

  • Подключения lsarpc и NetLogon выполняются в качестве окончательной проверки учетной записи.

Рабочий процесс подключения общего ресурса SMB (Kerberos)

При подключении тома Azure NetApp Files с помощью Kerberos обмен билетами Kerberos используется во время нескольких запросов на настройку сеанса, чтобы обеспечить безопасный доступ к общей папке. В большинстве случаев знание подробных шагов не требуется для повседневных задач администрирования. Эти знания полезны при устранении сбоев при попытке доступа к тому SMB в Azure NetApp Files.

Схема рабочего процесса подключения общего ресурса SMB.

Чтобы узнать, как доступ к общей папке SMB осуществляется в Azure NetApp Files, разверните список.
  • Клиент пытается получить доступ к общей папке SMB, используя UNC-путь, показанный в Azure NetApp Files. По умолчанию UNC-путь будет содержать имя сервера SMB (например, ANF-XXXX)
  • DNS запрашивается для сопоставления имени узла с IP-адресом.
  • Инициализируется начальный обмен SMB2 "Согласование протокола"
    • Запрос отправляется от клиента, чтобы узнать, какие диалекты SMB поддерживаются сервером, и включает в себя то, что поддерживает запрашивающий клиент.
    • Сервер отвечает на то, что он поддерживает, включая:
      • Режим безопасности (подпись или нет)
      • Версия SMB
      • GUID сервера
      • Поддерживаемые возможности (DFS, аренда, большой MTU, многоканальность, постоянные дескрипторы, аренда каталогов, шифрование)
      • Максимальный размер транзакции
      • Максимальный размер чтения и записи
      • Объект безопасности (Kerberos или NTLM)
  • Вторая процедура SMB2 "Согласование протокола" выполняется как "предварительная аутентификация"/вход.
    • Запрос от клиента включает:
      • Хэш предварительной авторизации
      • Поддерживаемые режимы безопасности (подписывание или нет)
      • Поддерживаемые возможности (DFS, аренда, большой MTU, многоканальность, постоянные дескрипторы, аренда каталогов, шифрование)
      • GUID клиента
      • Поддерживаемые диалекты SMB
    • Если хэш предварительной проверки подлинности принимается, сервер отвечает следующим образом:
      • Режим безопасности (подпись или нет)
      • Поддерживаемые возможности (DFS, аренда, большой MTU, многоканальность, постоянные дескрипторы, аренда каталогов, шифрование)
      • Максимальный размер транзакции
      • Максимальный размер чтения и записи
      • Объект безопасности (Kerberos или NTLM)
      • Возможности обеспечения целостности и шифрования предварительной проверки подлинности SMB
  • Если согласование протокола выполнено успешно, выполняется запрос на настройку сеанса.
    • Программа установки использует хэш предварительной проверки подлинности из согласования протокола.
    • Программа установки сообщает серверу SMB, что поддерживает запрашивающий клиент, в том числе:
      • Размер структуры
      • Флаг привязки сеанса
      • Режим безопасности (включен или требуется подписывание)
      • Возможности
      • Поддерживаемые типы шифрования Kerberos
  • Отправляется ответ "Настройка сеанса".
    • Кредиты SMB предоставляются.
    • Устанавливается идентификатор сеанса.
    • Флаги сеанса задаются (гостевые, null, зашифрованные).
    • Определяется тип шифрования Kerberos.
  • Запрос на подключение дерева отправляется клиентом для подключения к общей папке SMB.
    • Флаги и возможности общего доступа отправляются с сервера вместе с разрешениями общего доступа.
  • Команда ioctlFSCTL_QUERY_NETWORK_INTERFACE_INFO отправляется для получения IP-адреса сервера SMB.
  • Сервер SMB в Azure NetApp Files возвращает сведения о сети, в том числе: * IP-адрес * Возможность интерфейса (RSS включено или выключение) * число очередей RSS * Скорость связи
  • Запрос на подключение дерева отправляется клиентом для подключения к административному общему ресурсу IPC$.
    • Доля IPC$ — это ресурс, который использует именованные каналы, необходимые для обмена данными между программами. Ресурс общего доступа IPC$ используется во время удаленного администрирования компьютера и при просмотре его ресурсов. Невозможно изменить параметры доступа, свойства или списки управления доступом для общей папки IPC$. Вы также не можете переименовать или удалить общую папку IPC$.
    • Файл с именем srvsvc создаётся в разделе общего доступа как дескриптор службы.
  • Привязка DCERPC выполняется к объекту srvsvc для установления безопасного подключения.
    • Файл записывается в ранее извлекаемую информацию.
  • Клиент Windows выдается клиентом Kerberos TGS-REQ, чтобы получить билет на обслуживание (ST) для службы SMB.
  • Команда NetShareGetInfo выполняется клиентом SMB на сервер и отправляется ответ.
  • Билет службы SMB извлекается из KDC.
  • Azure NetApp Files пытается сопоставить пользователя Windows, запрашивающего доступ к общей папке, на допустимого пользователя UNIX.
    • Запрос TGS Kerberos выполняется с помощью учетных данных Kerberos сервера SMB, хранящихся в keytab сервера SMB с момента его первоначального создания, для использования при привязке к серверу LDAP.
    • LDAP выполняет поиск пользователя UNIX, сопоставленного с пользователем SMB, запрашивающим доступ к общей папке. Если пользователь UNIX не существует в LDAP, то пользователь UNIX по умолчанию pcuser используется в Azure NetApp Files для сопоставления имен (файлы и папки, записанные в томах с двумя протоколами, используют сопоставленного пользователя UNIX в качестве владельца UNIX).
  • Выполняется другое соединение для запроса протокола/сессии/дерева, на этот раз используется SPN Kerberos сервера SMB для ресурса IPC$ контроллера домена Active Directory.
    • Именованный канал устанавливается для общей папки через srvsvc.
    • Сеанс NETLOGON устанавливается для общей папки, и пользователь Windows проходит проверку подлинности.
  • Если пользователю разрешено это, объект доступа перечисляет файлы и папки, содержащиеся в томе.

Примечание.

Azure NetApp Files добавляет записи в кэш контекста Kerberos для клиента. Эти записи находятся в кэше в течение срока действия тикета Kerberos (устанавливается KDC и управляется политикой Kerberos).

Создание псевдонимов сервера SMB

Когда Azure NetApp Files создает сервер SMB с помощью соглашения об именовании [префикса сервера SMB, указанного в конфигурации подключения AD]-[уникальный числовый идентификатор]. (Дополнительные сведения об уникальном числовом идентификаторе см. в разделе Учетная запись компьютера SMB Kerberos). Это форматирование означает, что имена серверов SMB не создаются удобным способом. Например, имя SMB-7806 сложнее помнить, чем то, что похоже на "AZURE-FILESHARE".

Из-за этого администраторы могут создавать понятные имена псевдонимов для томов Azure NetApp Files. Для этого требуется указать каноническое имя DNS (CNAME) на существующую запись DNS A/AAAA на сервере.

При создании и использовании CNAME в запросах пути UNC (например, \\AZURE-FILESHARE вместо \\SMB-7806), DNS перенаправляет запрос CNAME (AZURE-FILESHARE.contoso.com) на соответствующую запись A/AAAA (SMB-7806.contoso.com), которая используется в извлечении имени субъекта-службы Kerberos (cifs/SMB-7806). Это позволяет Kerberos получить доступ к общей папке SMB при использовании псевдонима.

Если создается запись DNS A/AAAA (например, AZURE-FILESHARE.contoso.com) и предпринимается попытка использовать её в качестве псевдонима, запросы Kerberos терпят неудачу. Сбой вызван тем, что созданный SPN, используемый для проверки подлинности с общей папкой (cifs/AZURE-FILESHARE), не совпадает с SPN Kerberos для сервера SMB (cifs/SMB-7806). Сбой может быть снижен, если создается другой SPN и добавляется к учетной записи сервера SMB (например, cifs/AZURE-FILESHARE).

Поддерживаемые возможности сервера SMB в Azure NetApp Files

При выполнении запроса SMB "согласование протокола" сервер Azure NetApp Files запрашивается для проверки поддержки конкретных возможностей. В следующей таблице показаны запрашиваемые возможности и ответ, возвращаемый из тома SMB Azure NetApp Files при выполнении установки сеанса/подключения к дереву.

Возможность SMB Поддерживается Azure NetApp Files?
Цель DFS Да
Аренда Да
Большой MTU Да
SMB с несколькими каналами Да
Постоянные дескрипторы SMB Да
Аренда каталогов Нет
Шифрование SMB Да (если включена)

Поддерживаемые возможности и свойства общего доступа SMB в Azure NetApp Files

Во время доступа к общей папке SMB выполняется запрос "tree connect", а поддерживаемые возможности и свойства общего ресурса SMB запрашиваются клиентом у сервера Azure NetApp Files. В следующей таблице показаны запрашиваемые возможности общего доступа и возвращаемый ответ из тома SMB Azure NetApp Files, как это видно в захваченном пакете.

Возможность общего доступа SMB Поддерживается Azure NetApp Files?
Непрерывная доступность (ЦС) Да, для определенных рабочих нагрузок* (если включено)
Масштабирование Нет
Гроздь Нет
Асимметричный Нет
Перенаправить к владельцу Нет

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

В следующей таблице отображаются свойства разделяемого ресурса, которые запрашиваются, и ответ, возвращаемый из тома SMB Azure NetApp Files.

Возможность общего доступа SMB Поддерживается Azure NetApp Files?
Цель DFS Да
Корневой каталог DFS Нет
Ограничение эксклюзивных открытий Нет
Принудительное совместное удаление Нет
Разрешить кэширование пространства имен Нет
Перечисление на основе доступа Да (если включена)
Блокировка уровня силы II Нет
Включение хэша версии 1 Нет
Включение хэша версии 2 Нет
Требуется шифрование Да (если включена)
Удаленное управление удостоверениями Нет
Сжатый ввод-вывод Нет
Изолированный транспорт Нет

Как работает NFS Kerberos в Azure NetApp Files

NFS Kerberos работает отдельно от служб SMB, так как учетные записи машины, созданные для каждого протокола, не могут совместно использовать keytab-файлы из-за возможных изменений в номере версии ключа (kvno) в одном keytab-файле, которые могут повлиять на другую службу. В результате рабочие процессы служб SMB для Kerberos и NFS для Kerberos отличаются в функциональных возможностях в некоторых областях.

Начальная настройка области Kerberos

Область Kerberos NFS настраивается при заполнении сведений о области Kerberos на портале Azure NetApp Files на странице подключений Active Directory.

Снимок экрана: конфигурация области Kerberos.

Имя сервера AD и IP-адрес KDC используются для подключения к службам AD KDC при создании начальной учетной записи компьютера.

Примечание.

Поля "IP-адрес KDC" и "Имя сервера AD" в объекте Active Directory нельзя очистить до удаления объекта Active Directory. Его можно изменить только на допустимое непустое значение.

Служба Azure NetApp Files использует существующие сведения о домене для заполнения остальной части конфигурации области. Например:

Kerberos Realm: CONTOSO.COM
KDC Vendor: Microsoft
KDC IP Address: x.x.x.x 
KDC Port: 88
Clock Skew: 5
Active Directory Server Name: dc1.contoso.com
Active Directory Server IP Address: x.x.x.x
Comment: -
Admin Server IP Address: x.x.x.x
Admin Server Port: 749
Password Server IP Address: x.x.x.x
Password Server Port: 464
Permitted Encryption Types: aes-256
-    Configured by Azure NetApp Files administrator in the portal
-    Automatically configured by the service using Active Directory connection information/system defaults

При настройке области Kerberos NFS запись локальных узлов добавляется в службу с KDC, указанным в конфигурации. При изменении домена запись локальных узлов также изменяется в системе сервиса.

Схема конфигурации области Kerberos.

Эта запись локального узла используется как последнее средство, если происходит сбой KDC, указанного в конфигурации области, и сбой запроса резервных KDC через DNS.

Примечание.

Если KDC в области Kerberos необходимо отключить для обслуживания (например, для обновления или вывода из эксплуатации сервера), рекомендуется настроить область для использования KDC, которая не проходит обслуживание, чтобы избежать сбоев.

Начальное создание учетной записи компьютера или имени основного участника службы

Если Kerberos включен в томе Azure NetApp Files, учетная запись компьютера или принципал с именем NFS-{SMB-server-name} создается в домене в указанной организационной единице в подключениях Active Directory (Организационная единица). Имена машинных учетных записей усечены после 15 символов.

Примечание.

При добавлении клиентов Linux с именами узлов более 15 символов в домен Active Directory усекаются их SPNs (служебные имена участников) учетных записей Kerberos. Например, клиент Linux с именем MORE-THAN-FIFTEEN имеет имя учетной записи компьютера MORE-THAN-FIFT$, которое становится именем главного объекта службы MORE-THAN-FIFT$@CONTOSO.COM. Когда DNS ищет имя узла клиента, он находит более длинное имя и пытается использовать это имя в SPN-запросе ( MORE-THAN-FIFTEEN@CONTOSO.COM)). Так как такое СПН не существует, клиент пытается использовать следующее СПН в keytab в запросе (обычно host/hostname). Только SPN учетных записей машины нативно работают с Azure NetApp Files NFS Kerberos. В результате убедитесь, что имена узлов клиента Linux, используемые для NFS Kerberos с Azure NetApp Files, не превышают 15 символов. Кроме того, если вы хотите использовать имя службы узла/имя хоста (SPN), настройте пользователя UNIX в LDAP с именем пользователя "host". Эта конфигурация предоставляет сопоставление имён krb-unix для SPN.

В Azure NetApp Files блоки ключей Kerberos (или записи keytab) добавляются в службу с помощью имени учетной записи службы NFS (nfs/nfs-server-name.contoso.com@CONTOSO.COM). Создаются несколько записей: по одному для каждого поддерживаемого типа шифрования. В Azure NetApp Files поддерживается только тип шифрования AES-256 для NFS Kerberos.

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

Рабочий процесс создания NFS Kerberos SPN

На следующей схеме показано, как создается SPN NFS при создании тома NFS или двухпротокольного тома Azure NetApp Files с поддержкой Kerberos. В большинстве случаев для повседневных административных задач не требуется глубокое знание подробных действий, однако оно может быть полезным при устранении ошибок при попытке создать том SMB в Azure NetApp Files.

Схема рабочего процесса создания служебного принципала NFS Kerberos.

Чтобы получить подробные инструкции по созданию имени участника-службы Kerberos NFS в Azure NetApp Files, разверните список.
  • Учетные данные администратора, передаваемые в KDC, указанные в конфигурации области, с помощью имени пользователя, предоставленного для использования в подключении Active Directory, пользователь должен иметь разрешение на просмотр и создание объектов в указанном подразделении.
  • DNS-серверы, указанные в конфигурации подключения Azure NetApp Files Active Directory, запрашиваются Azure NetApp Files для записей службы Kerberos (SRV) в следующих форматах:
    • Запрос URI для _kerberos.CONTOSO.COM
    • Запрос SRV для _kerberos-master._udp. CONTOSO.COM
    • Запрос SRV для _kerberos-master._tcp. CONTOSO.COM

Примечание.

Эти запросы выполняются несколько раз в рамках одного вызова на разных этапах процесса. Проблемы с DNS могут вызывать замедление этих вызовов или полные сбои. Эти записи, как представляется, не существуют по умолчанию в развертываниях Active Directory и должны быть созданы вручную.

  • Если запросы не удается найти запись или если найденные записи не могут быть связаны или использоваться в качестве главного KDC, запрос записи с именем области, найденным в конфигурации области NFS Kerberos, используется в качестве последнего способа подключения к KDC через порт 88.
  • Во время настройки Kerberos NFS в файл локальных узлов добавляется статическая запись узла для указанного KDC в качестве резервной копии, если запросы DNS не удаются.
  • Если для области есть кэшированная запись DNS, она используется. В противном случае используется запись локального файла. Кэшированные записи DNS живут столько, сколько установлено время жизни (TTL) для записей DNS. Запись локального файла настроена с 86 400-секундным TTL (24 часа). Конфигурация ns-switch для поиска узлов в Azure NetApp Files сначала использует файлы, а затем DNS. При обнаружении локальной записи больше не выполняются запросы.
  • Учетная запись компьютера SMB, созданная при создании подключения Active Directory, используется в качестве учетных данных для привязки LDAP Active Directory по протоколу SASL/GSS через порт 389 для поиска любых существующих записей требуемого имени SPN или учетной записи машины. Если имя SPN или учетной записи компьютера уже существует, возникает ошибка. Если SPN отсутствует в запросе LDAP, то создание учетной записи компьютера выполняется в указанной организационной единице, с записью следующих атрибутов, заданной Azure NetApp Files:
    • cn (NFS-MACHINE)
    • sAMAccountName (NFS-MACHINE$)
    • objectClass (top, person, организацииPerson, user, computer)
    • servicePrincipalName (host/NFS-MACHINE, host/NFS-MACHINE. CONTOSO.COM, nfs/NFS-MACHINE, nfs/NFS-MACHINE. CONTOSO.COM)
    • контроль учетной записи пользователя (4096)
    • msDs-SupportedEncryptionTypes (AES-256_CTS_HMAC_SHA1_96)
    • имя узла DNS (NFS-MACHINE.CONTOSO.COM)
  • Пароль учетной записи машины NFS с использованием Kerberos устанавливается для учетной записи NFS-MACHINE через порт 464.
  • Блоки ключей Kerberos (keytabs) для имени участника-службы NFS сохраняются в службе Azure NetApp Files.
  • Правило мэппинга статических имен создается в службе Azure NetApp Files, чтобы гарантировать, что корневой пользователь для каждого клиента Kerberos NFS сопоставлен с root при использовании Kerberos.
  • Файл krb5.conf добавляется во внутренние системы службы с информацией о области NFS.

Подключения Kerberos NFS

При подключении тома Azure NetApp Files с использованием типов безопасности Kerberos по NFS выполняется следующий рабочий процесс. Более подробное описание Kerberos см. в Kerberos Network Authentication Service (V5) Synopsis.

Схема рабочего процесса подключения NFS Kerberos.

Развернув список, вы найдете подробные инструкции по установке тома NFS Kerberos с помощью Azure NetApp Files.
  • Клиент пытается подключиться к каталогу экспорта NFS в Azure NetApp Files и задает -oтип безопасности krb5 (или krb5i или krb5p).
  • DNS используется для формирования запроса основного имени службы NFS в Azure NetApp Files с помощью записи A/AAAA или PTR (в зависимости от того, как была выполнена команда монтирования).
  • Клиент получает TGT из KDC через вызов AS-REQ с использованием имени клиента, найденного в keytab клиента.
  • Путь экспорта проверяется, чтобы убедиться, что он существует в файловой системе.
  • Правило политики экспорта проверяется, чтобы обеспечить доступ Kerberos к пути экспорта.<
  • Клиент запрашивает билет службы NFS из KDC через вызов AP-REQ. Azure NetApp Files проверяет в keytab наличие допустимой записи с корректным типом шифрования, используя TGT от клиента, полученный из KDC.
  • Если TGT действителен, выдается служебный билет.
  • SPN клиента (например, CLIENT$@CONTOSO.COM) сопоставляется с корневым пользователем с помощью правила сопоставления имен в Azure NetApp Files.
  • Корневой пользователь ищется в базах данных служб имен (файлы и LDAP) на предмет существования и членства в группах.
  • Выполняется привязка LDAP с использованием учетной записи компьютера SMB, чтобы разрешить выполнение поиска в LDAP для корневого пользователя.
  • Так как корневой каталог всегда существует в Azure NetApp Files, это не должно вызывать никаких проблем, но запросы LDAP для корневого каталога могут завершиться ошибкой. Эти ошибки можно игнорировать.
  • Билет службы NFS возвращается клиенту и подключение выполнено успешно. Корневой пользователь имеет полный доступ к точке монтирования Kerberos посредством главного элемента (principal) учетной записи клиента (просмотр доступен с помощью команды klist -e на клиенте).
  • Azure NetApp Files добавляет записи в кэш контекста Kerberos для клиента. Эти записи будут находиться в кэше в течение срока действия билета Kerberos, заданного KDC и контролируемым политикой Kerberos.
  • NFSv4.1 периодически (каждые 20 секунд) отправляет обновления билета Kerberos как "keepalives".

Доступ к подключению NFS Kerberos с использованием учётных записей пользователей

Когда пользователь (кроме корневого пользователя, использующего SPN машинной учетной записи) получает доступ к подключению Azure NetApp Files NFS Kerberos, выполняется следующий рабочий процесс.

Схема подключения NFS Kerberos с помощью субъектов-пользователей.

Для получения подробных инструкций о том, как получить доступ к тому Kerberos NFS с нерутовым пользователем, используя Azure NetApp Files, разверните список.
  • Пользователь входит в KDC либо с помощью обмена имени пользователя или пароля, либо с помощью файла keytab, чтобы получить TGT с помощью вызова AS-REQ, который будет использоваться для сбора запроса на обслуживание из тома Azure NetApp Files.
  • Правило политики экспорта проверяется, чтобы убедиться, что доступ Kerberos разрешен к пути экспорта для клиентского компьютера
  • Azure NetApp Files проверяет наличие кэшированного билета службы NFS. Если нет, запрос на обслуживание NFS запрашивается через вызов AP-REQ, а служба проверяет ключ для допустимой записи с допустимым типом шифрования с использованием TGT от клиента, полученного из KDC.
  • Если TGT действителен, выдается служебный билет
  • Принципиальное имя пользователя (UPN) сопоставляется с помощью неявного сопоставления. Например, если UPN - user1@CONTOSO.COM, то служба выполняет запросы для пользователя UNIX с именем user1. Так как этот пользователь UNIX не существует в локальной базе данных файлов в Azure NetApp Files, используется LDAP.
  • Привязка LDAP с помощью учетной записи сервера SMB пытается разрешить поиск LDAP сопоставленного пользователя. Запрос SRV DNS выполняется для записей DNS Kerberos (_kerberos и _kerberos-master). Если допустимые записи не могут быть использованы, конфигурация возвращается к конфигурации домена. Эти SRV-запросы DNS KDC не ограничены областью действия сайта.
  • Для получения информации о допустимых LDAP серверах выполняется запрос записей SRV LDAP. Они ограничены пределами сайта.
  • Если пользователь не существует в LDAP или запрос к LDAP не может быть выполнен (сервер отключен, ошибка при поиске DNS, ошибка привязки, превышено время ожидания поиска LDAP, пользователь не существует), то сопоставление завершается ошибкой, и доступ запрещается.
  • Если пользователь существует, собираются принадлежности к группам.
  • Сопоставление успешно выполнено, а запрос службы NFS выдан клиенту (как показано в klist -e командах). Доступ разрешен на основе разрешений файла на пути экспорта.

Роль LDAP в сочетании с Kerberos в Azure NetApp Files

Azure NetApp Files использует протокол LDAP для Kerberos NFS. Для NFS Kerberos в Azure NetApp Files требуется сопоставление имен Kerberos для UNIX для входящих SPN пользователей. Так как Azure NetApp Files не поддерживает создание локальных пользователей UNIX, ldap требуется для поиска пользователей UNIX при запросе сопоставления имен.

  • При создании подключения Active Directory доменное имя Active Directory используется для указания процесса поиска серверов LDAP.
  • Если требуется сервер LDAP, _ldap.domain.com используется для поиска SRV для серверов LDAP.
  • После обнаружения списка серверов наилучший доступный сервер (на основе времени отклика по ping) используется в качестве сервера LDAP, подключающегося через порт 389.
  • Попытка выполнить привязку LDAP с использованием машинной учетной записи SMB через GSS/Kerberos.
  • Если кэшированные подключения или учетные данные Kerberos отсутствуют, запрашивается новый билет Kerberos. Кэшированные подключения для серверов имен в Azure NetApp Files действуют на протяжении 60 секунд. Если неактивно более 60 секунд, кэш подключений очищается.
  • DNS используется для поиска соответствующих Kerberos KDC с помощью записей SRV.
  • Если не удается найти KDCs с помощью DNS-запроса, используется KDC, указанный в файле krb5.conf для служб SMB.
    • Если KDC недоступен или не может обработать запрос Kerberos, попытка привязки LDAP завершится ошибкой. Поиск имен также завершается ошибкой. Доступ к устройству запрещен, так как не произошла действительная аутентификация.
    • Если привязка выполнена успешно, запрос LDAP выполняется для пользователя и его учетных данных. Если время поиска превышает 10 секунд, поиск завершается ошибкой.
  • Если поиск находит пользователя, сопоставление успешно выполнено и доступ предоставляется через Kerberos (если билет действителен или не истек).

IP-адреса для доступа с помощью Kerberos

По умолчанию, проверка подлинности Kerberos использует преобразование имени хоста в IP-адрес для создания имени участника службы (SPN), которое используется для получения билета Kerberos. Например, при доступе к общей папке SMB с помощью пути универсального соглашения об именовании (UNC), например \SMBVOLUME.CONTOSO.COM, запрос DNS создается для полного доменного имени SMBVOLUME.CONTOSO.COM, а IP-адрес тома Azure NetApp Files извлекается. Если отсутствует запись DNS (или текущая запись отличается от запрошенной, например, из-за псевдонимов или CNAME-записей), то правильный SPN не может быть получен, и запрос Kerberos завершается ошибкой. В результате доступ к тому может быть запрещен, если резервный метод проверки подлинности (например, New Technology LAN Manager) отключен.

Записи DNS в Azure NetApp Files создаются автоматически с помощью динамического DNS и формулируются с помощью имени сервера SMB. Для любых вариантов или псевдонимов определенного имени необходимо вручную создать запись DNS CNAME и направить её на динамическую запись DNS. Дополнительные сведения см. в статье "Общие сведения о DNS" в Azure NetApp Files.

NFSv4.1 Kerberos работает аналогично для извлечения основного имени службы (SPN), где поиск DNS является неотъемлемой частью процесса аутентификации и также может использоваться для определения области Kerberos.

Если IP-адрес (а не имя узла) используется в запросе на доступ к тому Azure NetApp Files, запрос Kerberos работает по-разному в зависимости от используемого протокола.

Поведение SMB Kerberos с IP-адресами и DNS-именами

При использовании SMB запрос на UNC-путь с помощью IP-адреса (например, \\x.x.x.x) по умолчанию пытается использовать NTLM для проверки подлинности. В средах, где NTLM запрещено по соображениям безопасности, по умолчанию запрос SMB с использованием IP-адреса не может использовать Kerberos или NTLM для проверки подлинности. В результате доступ к тому Azure NetApp Files запрещен. В более поздних выпусках Windows (начиная с Windows 10 версии 1507 и Windows Server 2016) клиентов Kerberos можно настроить для поддержки имен узлов IPv4 и IPv6 в SPN, чтобы обмен данными по SMB происходил без этой проблемы.

Поведение NFSv4.1 Kerberos с IP-адресами и DNS-именами

При использовании NFSv4.1 запрос на подключение к IP-адресу с помощью одного из sec=[krb5/krb5i/krb5p] вариантов использует обратный поиск DNS через PTR для разрешения имени узла из IP-адреса. Затем этот hostname используется для формирования SPN (Service Principal Name) для получения билета Kerberos. Если вы используете NFSv4.1 с Kerberos, у вас должны быть записи A/AAAA и PTR для тома Azure NetApp Files, чтобы обеспечить доступ по имени узла и IP-адресу для монтирования. Azure NetApp Files создает динамическую запись DNS A/AAAA. Если для этой подсети существует обратная зона DNS, то также создается запись PTR. Для отклонений от стандартных соглашений об именах узлов Azure NetApp Files используйте записи CNAME для псевдонимов DNS.

Дополнительные сведения см. в статье "Общие сведения о DNS" в Azure NetApp Files

  • Last updated on