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

Общие сведения о 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, так как управление многочисленными файлами client 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 через параметр подключения с.

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

Примечание.

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

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

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

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

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

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

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

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

Термин Определение
Центр распространения ключей (KDC) KDC — это сервер проверки подлинности, включающий службу предоставления билетов (TGS) и службу проверки подлинности (AS). Термины KDC, AS и TGS используются взаимозаменяемо. В средах Майкрософт контроллер домена Active Directory — это KDC.
Область (или область 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. Это также может быть специальный узел службы, который означает, что этот субъект-служба настроен для предоставления нескольких различных сетевых служб.
  • Экземпляр — эта часть является необязательной в случае пользователя. Пользователь может иметь несколько субъектов, но каждый субъект должен быть уникальным в KDC. Например, Фред может иметь субъект, который предназначен для повседневного использования (fred@contoso.com) и субъект, который разрешает привилегированное использование, например учетную запись sysadmin (admin-fred@contoso.com). Экземпляр требуется для субъектов-служб и назначает полное доменное имя узла, предоставляющего службу.
  • Область — область Kerberos — это набор субъектов Kerberos, зарегистрированных на сервере Kerberos. По соглашению имя области обычно совпадает с DNS-именем, но оно преобразуется в прописные буквы. Прописные буквы не являются обязательными, но соглашение обеспечивает простое различие между DNS-именем и именем области.
Билеты Билет — это временный набор учетных данных, который проверяет удостоверение субъекта для службы и содержит ключ сеанса. Билет может быть службой, билетом приложения или билетом на предоставление билетов (TGT). Билеты обмениваются между клиентом, сервером и KDC для проверки подлинности Kerberos.
Секретные ключи Kerberos использует систему симметричного ключа, в которой секретный ключ используется как для шифрования, так и для расшифровки. Секретный ключ создается из пароля Kerberos субъекта с помощью функции одностороннего хэша. KDC сохраняет пароль для каждого субъекта и может таким образом создать секретный ключ субъекта. Для пользователей, запрашивающих службу Kerberos, секретный ключ обычно является производным от пароля, представленного программе kinit. Субъекты-службы и управляющая программа обычно не используют пароль; Вместо этого результат односторонняя хэш-функция хранится в keytab.
Keytab Ключ содержит список субъектов и их секретных ключей. Секретные ключи в keytab часто создаются с помощью случайного пароля и используются в основном для субъектов-служб или управляющей программы.

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

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

Service Порт
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.

Cache Возраст кэша
Подключения сервера имен бездействия 60 секунд
Время ожидания запроса LDAP 10 seconds
Запись локального узла 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). Затем этот поиск вперед используется для формирования имени субъекта-службы, используемого в запросе проверки подлинности Kerberos. Если существующее имя субъекта-службы не удается найти в KDC, проверка подлинности Kerberos завершается ошибкой.

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

Помимо разрешения имени субъекта-службы DNS часто используется для разрешения имен узлов и IP-адресов для доменных служб, таких как LDAP, KDCs 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 поддерживает это по умолчанию. В некоторых случаях (например, при создании псевдонимов или субъектов-служб), пользователям и компьютерам требуется добавление или изменение имен субъектов-служб. Это требование можно выполнить с помощью Пользователи и компьютеры Active Directory консоли управления Майкрософт (MMC) или PowerShell. Дополнительные сведения об управлении именами субъектов-служб см. в разделе "Управление именами субъектов-служб".

Помимо имен субъектов-служб и числовых идентификаторов для проверки подлинности Kerberos, ldap также можно использовать для удостоверений пользователей и групп UNIX, которые используются для сопоставления имен удостоверений в Azure NetApp Files, а также начальную проверку подлинности для подключений NFS Kerberos с помощью сопоставления имен пользователей UNIX .> Дополнительные сведения см. в статье о работе 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
  • Подразделение (где учетные записи компьютеров должны храниться в домене Azure AD)
  • Включение и отключение шифрования AES
  • Включение и отключение подписывания LDAP
  • Конфигурация LDAP
  • Шифрование SMB в контроллере домена
  • Привилегированные пользователи
  • Учетные данные пользователя и пароля с разрешениями подразделения

Примечание.

Для каждой учетной записи разрешено только одно подключение Azure Active Directory (AD). После создания подключения Azure AD все новые тома SMB Azure NetApp Files используют конфигурацию подключения Azure 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]-[уникальный числовый идентификатор].

Например, если вы настроили подключения Azure 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.

Рабочий процесс создания имени участника-службы SMB Kerberos

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

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

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

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

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

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

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

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

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

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

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

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

  • 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 задаются в учетной записи:
    Атрибут Значение
    CN ANF-XXXX
    sAMAccountName ANF-XXXX$
    objectClass
    • Верх
    • Лицо
    • ОрганизационныйPerson
    • User
    • Компьютер
    servicePrincipalName
    • HOST/ANF-XXXX
    • HOST/anf-xxxx.contoso.com
    • CIFS/anf-xxxx.contoso.com
    userAccountControl 4096
    operatingSystem Выпуск NetApp
    dnsHostName ANF-XXXX.CONTOSO.COM
    • В случае сбоя создание тома завершается сбоем addRequest . Может addRequest завершиться сбоем из-за неправильных разрешений объекта контейнера.
    • При успешном addRequest выполнении поиск LDAP с помощью фильтра (sAMAccountName=ANF-XXXX$) выполняется для получения атрибута objectSid.
    • Беседа SMB2 "Согласование протокола" выполняется для получения поддерживаемого Kerberos mechTypes из KDC.
    • Программа SMB2 "Настройка сеанса" с использованием имени субъекта-службы CIFS и самой высокой поддержки mechType , а также выполняется подключение "Дерево" к IPC$ .
    • Файл SMB2 lsarpc создается в общей папке IPC$.
    • Выполняется привязка к DCERPC . Затем lsarpc файл записывается.
    • Затем выполняются следующие запросы LSA:

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

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

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

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

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

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

  • Выполняется третий протокол":/Kerberos ticket exchange/"Session setup"/"Tree connect" to 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 "Согласование протокола" выполняется как "предварительная аутентификация"/login
    • Запрос от клиента включает:
      • Хэш предварительной проверки подлинности
      • Поддерживаемые режимы безопасности (подписывание или нет)
      • Поддерживаемые возможности (DFS, аренду, крупный MTU, мультиканал, постоянные дескрипторы, аренду каталогов, шифрование)
      • GUID клиента
      • Поддерживаемые диалекты SMB
    • Если хэш предварительной проверки подлинности принимается, сервер отвечает следующим образом:
      • Режим безопасности (подпись или нет)
      • Поддерживаемые возможности (DFS, аренду, крупный MTU, мультиканал, постоянные дескрипторы, аренду каталогов, шифрование)
      • Максимальный размер транзакции
      • Максимальный размер чтения и записи
      • Большой двоичный объект безопасности (Kerberos или NTLM)
      • Возможности обеспечения целостности и шифрования предварительной проверки подлинности SMB
  • Если согласование протокола выполнено успешно, выполняется запрос на настройку сеанса.
    • Программа установки использует хэш предварительной проверки подлинности из согласования протокола.
    • Программа установки сообщает серверу SMB, что поддерживает запрашивающий клиент, в том числе:
      • СтруктураSize
      • Флаг привязки сеанса
      • Режим безопасности (включен или требуется подписывание)
      • Возможности
      • Поддерживаемые типы шифрования 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, хранящихся с ключами сервера SMB из первоначального создания сервера SMB для привязки сервера LDAP.
    • LDAP выполняет поиск пользователя UNIX, сопоставленного с пользователем SMB, запрашивающим доступ к общей папке. Если пользователь UNIX не существует в LDAP, то пользователь pcuser UNIX по умолчанию используется Azure NetApp Files для сопоставления имен (файлы и папки, записанные в томах с двумя протоколами, используют сопоставленного пользователя UNIX в качестве владельца UNIX).
  • Выполняется другое соединение протокола переговоров или запроса сеанса или дерева. На этот раз используется имя субъекта-службы Kerberos сервера SMB для общей папки IPC контроллера домена Active Directory.
    • Именованный канал устанавливается для общей папки через srvsvc.
    • Сеанс NETLOGON устанавливается для общей папки, и пользователь Windows проходит проверку подлинности.
  • Если разрешения позволяют пользователю, общий ресурс перечисляет файлы и папки, содержащиеся в томе.

Примечание.

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

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

Когда Azure NetApp Files создает сервер SMB с помощью соглашения об именовании [префикса сервера SMB, указанного в конфигурации подключения Azure 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 завершаются ошибкой. Сбой является результатом созданного имени субъекта-службы, используемого для проверки подлинности в общей папке (cifs/AZURE-FILESHARE), не совпадающей с тем, что является поставщиком службы Kerberos для сервера SMB (cifs/SMB-7806). Сбой может быть устранен, если создается и добавляется другая имя субъекта-службы к учетной записи сервера SMB (например, cifs/AZURE-FILESHARE).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Имя сервера Azure AD и IP-адрес KDC используются для подключения к службам Azure AD KDC при создании начальной учетной записи компьютера. Служба 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, указанном в конфигурации области, и сбой запроса избыточных KDCs через DNS.

Примечание.

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

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

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

Примечание.

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

В 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

На следующей схеме показано, как создается имя субъекта-службы 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 для поиска всех существующих записей требуемого имени субъекта-службы или учетной записи компьютера. Если имя учетной записи субъекта-службы или компьютера уже существует, отправляется сообщение об ошибке. Если имя субъекта-службы отсутствует в запросе 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)
    • userAccountControl (4096)
    • msDs-SupportedEncryptionTypes (AES-256_CTS_HMAC_SHA1_96)
    • dnsHostName (NFS-MACHINE.CONTOSO.COM)
  • Пароль учетной записи компьютера NFS kerberos устанавливается для учетной записи NFS-MACHINE через порт 464.
  • Блоки ключей Kerberos (keytabs) для имени участника-службы NFS сохраняются в службе Azure NetApp Files.
  • Правило сопоставления статических имен создается в службе Azure NetApp Files, чтобы гарантировать, что корневой пользователь для каждого клиента Kerberos NFS сопоставляется с корнем при использовании Kerberos.
  • Файл krb5.conf добавляется во внутренние системы службы с информацией о области NFS.

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

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

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

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

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

Когда подключение 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 действителен, выдается запрос на обслуживание
  • Имя участника-пользователя сопоставляется с помощью неявного сопоставления. Например, если имя участника-пользователя имеет user1@CONTOSO.COMимя участника-пользователя, то запросы службы для пользователя UNIX с именем user1. Так как этот пользователь UNIX не существует в локальной базе данных файлов в Azure NetApp Files, используется LDAP.
  • Привязка LDAP с помощью учетной записи сервера SMB пытается разрешить поиск LDAP сопоставленного пользователя. Запрос SRV DNS выполняется для записей DNS Kerberos (_kerberos и _kerberos-master). Если допустимые записи не могут использоваться, конфигурация возвращается к конфигурации области. Эти запросы SRV DNS KDC не являются областью действия сайта.
  • Записи SRV LDAP запрашиваются для допустимых серверов 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 для входящих имен пользователей. Так как Azure NetApp Files не поддерживает создание локальных пользователей UNIX, ldap требуется для поиска пользователей UNIX при запросе сопоставления имен.

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

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

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

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

NFSv4.1 Kerberos работает аналогичным образом для извлечения имени участника-службы, где поиск 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 в именах узлов spNs для обмена данными SMB, чтобы обойти эту проблему.

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

При использовании NFSv4.1 запрос на подключение к IP-адресу с помощью одного из sec=[krb5/krb5i/krb5p] вариантов использует обратный поиск DNS через PTR для разрешения IP-адреса имени узла. Затем это имя узла используется для формирования имени участника-службы для получения билета 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