Рекомендации по проектированию и планированию сайтов служб домен Active Directory для Azure NetApp Files

Правильная разработка и планирование служб домен Active Directory (AD DS) являются ключевыми для архитектур решений, использующих тома Azure NetApp Files. Такие функции Azure NetApp Files, как S МБ тома, тома двойного протокола и тома NFSv4.1 Kerberos предназначены для использования с AD DS.

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

Определение требований AD DS для Azure NetApp Files

Перед развертыванием томов Azure NetApp Files необходимо определить требования к интеграции AD DS для Azure NetApp Files, чтобы убедиться, что Azure NetApp Files хорошо подключен к AD DS. Неправильная или неполная интеграция AD DS с Azure NetApp Files может привести к прерыванию доступа клиента или сбоям для томов S МБ, двойного протокола или Kerberos NFSv4.1.

Поддерживаемые сценарии проверки подлинности

Azure NetApp Files поддерживает проверку подлинности на основе удостоверений по протоколу S МБ с помощью следующих методов.

  • Проверка подлинности AD DS: компьютеры с Windows, присоединенные к AD DS, могут получить доступ к общим папкам Azure NetApp Files с учетными данными Active Directory по протоколу S МБ. AD DS должны находиться в прямой видимости клиента. Если вы уже настроили AD DS локально или на виртуальной машине в Azure, где ваши устройства присоединены к ДОМЕНУ AD DS, следует использовать AD DS для проверки подлинности общей папки Azure NetApp Files.
  • Проверка подлинности доменных служб Microsoft Entra: облачные, присоединенные к доменным службам Microsoft Entra виртуальные машины Windows могут получить доступ к общим папкам Azure NetApp Files с учетными данными доменных служб Microsoft Entra. В этом решении доменные службы Microsoft Entra выполняют традиционный домен Windows Server AD от имени клиента.
  • Microsoft Entra Kerberos для гибридных удостоверений. Использование идентификатора Microsoft Entra для проверки подлинности удостоверений гибридных пользователей позволяет пользователям Microsoft Entra получать доступ к общим папкам Azure NetApp Files с помощью проверки подлинности Kerberos. Это означает, что конечные пользователи могут получить доступ к общим папкам Azure NetApp Files без необходимости обращаться к контроллерам домена из гибридных присоединений к Microsoft Entra и виртуальных машин Microsoft Entra, присоединенных к Windows или Linux. В настоящее время не поддерживаются только облачные удостоверения.
  • Проверка подлинности AD Kerberos для клиентов Linux: клиенты Linux могут использовать проверку подлинности Kerberos по протоколу S МБ для Azure NetApp Files с помощью AD DS.

Требования к сети

Для томов Azure NetApp Files S МБ, двойного протокола и Kerberos NFSv4.1 требуются надежные и низкие задержки сетевого подключения (менее 10 мс RTT) к контроллерам домена AD DS. Плохое сетевое подключение или высокая задержка сети между Azure NetApp Files и контроллерами домена AD DS могут привести к прерываниям доступа клиента или истечению времени ожидания клиента.

Убедитесь, что выполнены следующие требования к топологии сети и конфигурации:

  • Убедитесь, что используется поддерживаемая топология сети для Azure NetApp Files .
  • Убедитесь, что контроллеры домена AD DS имеют сетевое подключение из делегированной подсети Azure NetApp Files, в которую размещаются тома Azure NetApp Files.
    • Топологии одноранговых виртуальных сетей с контроллерами домена AD DS должны правильно настроить пиринг для поддержки подключения к сети контроллера домена Ad DS в Azure NetApp Files.
  • Группы безопасности сети (NSG) и брандмауэры контроллера домена AD DS должны иметь соответствующие правила для поддержки подключения Azure NetApp Files к AD DS и DNS.
  • Убедитесь, что задержка меньше 10 мс RTT между Azure NetApp Files и контроллерами домена AD DS.

Необходимые сетевые порты приведены следующим образом:

Service Порт Протокол
Веб-службы AD 9389 TCP
DNS* 53 TCP
DNS* 53 UDP
ICMPv4 Н/П Ответ на запрос проверки связи
Kerberos 464 TCP
Kerberos 464 UDP
Kerberos 88 TCP
Kerberos 88 UDP
LDAP 389 TCP
LDAP 389 UDP
LDAP 389 TLS
LDAP 3268 TCP
NetBIOS-имя 138 UDP
SAM/LSA 445 TCP
SAM/LSA 445 UDP

*DNS, работающий на контроллере домена AD DS

Требования к DNS

Для azure NetApp Files S МБ, двойного протокола и томов Kerberos NFSv4.1 требуется надежный доступ к службам системы доменных имен (DNS) и актуальным записям DNS. Плохое сетевое подключение между Azure NetApp Files и DNS-серверами может привести к прерыванию доступа клиента или истечению времени ожидания клиента. Неполные или неправильные записи DNS для AD DS или Azure NetApp Files могут привести к прерыванию доступа клиента или истечению времени ожидания клиента.

Azure NetApp Files поддерживает использование интегрированных DNS-серверов Active Directory или автономных DNS-серверов.

Убедитесь, что выполнены следующие требования к конфигурациям DNS:

  • Если вы используете автономные DNS-серверы:
    • Убедитесь, что DNS-серверы имеют сетевое подключение к делегированной подсети Azure NetApp Files с томами Azure NetApp Files.
    • Убедитесь, что сетевые порты UDP 53 и TCP 53 не блокируются брандмауэрами или группами безопасности сети.
  • Убедитесь, что на DNS-серверах были созданы записи SRV, зарегистрированные службой входа AD DS Net.
  • Убедитесь, что записи PTR для контроллеров домена AD DS, используемых Azure NetApp Files, были созданы на DNS-серверах в том же домене, что и конфигурация Azure NetApp Files.
  • Azure NetApp Files не удаляет автоматически записи указателя (PTR), связанные с записями DNS при удалении тома. Записи PTR используются для обратных подстановок DNS, которые сопоставляют IP-адреса с именами узлов. Они обычно управляются администратором DNS-сервера. При создании тома в Azure NetApp Files его можно связать с DNS-именем. Однако управление записями DNS, включая записи PTR, выходит за пределы область Azure NetApp Files. Azure NetApp Files предоставляет возможность связать том с DNS-именем для упрощения доступа, но не управляет записями DNS, связанными с этим именем. При удалении тома в Azure NetApp Files связанные записи DNS (например, записи A для переадресации подстановок DNS) необходимо управлять и удалять с DNS-сервера или используемой службы DNS.
  • Azure NetApp Files поддерживает стандартные и безопасные динамические обновления DNS. Если требуется безопасное динамическое обновление DNS, убедитесь, что на DNS-серверах настроены безопасные обновления.
  • Если динамические обновления DNS не используются, необходимо вручную создать запись A и запись PTR для учетных записей компьютера AD DS, созданных в подразделении AD DS (указанного в подключении Azure NetApp Files AD) для поддержки подписывания ПРОТОКОЛА LDAP Azure NetApp Files, LDAP по протоколу TLS, S МБ, двойного протокола или томов Kerberos NFSv4.1.
  • Для сложных или крупных топологий AD DS, политик DNS или подсети DNS может потребоваться поддержка томов NFS с поддержкой LDAP.

Требования к источнику времени

Azure NetApp Files использует time.windows.com в качестве источника времени. Убедитесь, что контроллеры домена, используемые Azure NetApp Files, настроены для использования time.windows.com или другого точного, стабильного источника времени (стратум 1). Если между Azure NetApp Files и контроллерами домена AS DS больше пяти минут, проверка подлинности завершится ошибкой; Доступ к томам Azure NetApp Files также может завершиться ошибкой.

Определите, какие AD DS следует использовать с Azure NetApp Files

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

Дополнительные сведения см. в статье "Сравнение самоуправляемых служб домен Active Directory", идентификатора Microsoft Entra и управляемых доменных служб Microsoft Entra.

Рекомендации по службам домен Active Directory

В следующих сценариях следует использовать службы домен Active Directory (AD DS).

  • У вас есть пользователи AD DS, размещенные в локальном домене AD DS, которым требуется доступ к ресурсам Azure NetApp Files.
  • У вас есть приложения, размещенные частично локально и частично в Azure, которым требуется доступ к ресурсам Azure NetApp Files.
  • Вам не нужна интеграция доменных служб Microsoft Entra с клиентом Microsoft Entra в подписке или доменные службы Microsoft Entra несовместимы с вашими техническими требованиями.

Примечание.

Azure NetApp Files не поддерживает использование контроллеров домена только для чтения AD DS (RODC).

Если вы решили использовать AD DS с Azure NetApp Files, следуйте инструкциям в руководстве по архитектуре Azure и убедитесь, что выполнены требования к сети Azure NetApp Files и DNS для AD DS.

Рекомендации по доменным службам Microsoft Entra

Доменные службы Microsoft Entra — это управляемый домен AD DS, синхронизированный с клиентом Microsoft Entra. Основными преимуществами использования доменных служб Microsoft Entra являются следующие:

  • Доменные службы Microsoft Entra — это автономный домен. Таким образом, нет необходимости настраивать сетевое подключение между локальной средой и Azure.
  • Предоставляет упрощенный интерфейс развертывания и управления.

Доменные службы Microsoft Entra следует использовать в следующих сценариях:

  • Нет необходимости расширять AD DS из локальной среды в Azure, чтобы предоставить доступ к ресурсам Azure NetApp Files.
  • Политики безопасности не разрешают расширение локальных доменных служб ACTIVE DS в Azure.
  • У вас нет сильных знаний о AD DS. Доменные службы Microsoft Entra могут повысить вероятность хороших результатов с помощью Azure NetApp Files.

Если вы решили использовать доменные службы Microsoft Entra с Azure NetApp Files, ознакомьтесь с документацией по доменным службам Microsoft Entra для архитектуры, развертывания и управления. Убедитесь, что вы также соответствуете требованиям к сети Azure NetApp Files и DNS.

Проектирование топологии сайтов AD DS для использования с Azure NetApp Files

Для любой архитектуры решений, включающей Azure NetApp Files S МБ, двойной протокол или тома Kerberos, важно правильное проектирование топологии сайтов AD DS.

Неправильное топология или конфигурация сайта AD DS может привести к следующему поведению:

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

Помимо нескольких контроллеров домена, назначенных сайту AD DS ad в Azure NetApp Files AD Site Name, сайт Azure NetApp Files AD DS может назначить ему одну или несколько подсетей.

Примечание.

Важно, чтобы все контроллеры домена и подсети, назначенные сайту AZURE NetApp Files AD DS, были хорошо подключены (менее 10 мс задержки RTT) и доступны сетевым интерфейсам, используемым томами Azure NetApp Files.

Если вы используете стандартные сетевые функции, следует убедиться, что все пользовательские маршруты (UDR) или правила группы безопасности сети (NSG) не блокируют сетевое взаимодействие Azure NetApp Files с контроллерами домена AD DS, назначенными сайту AD DS Azure NetApp Files.

Если вы используете сетевые виртуальные устройства или брандмауэры (например, брандмауэры Palo Alto Networks или Fortinet), они должны быть настроены, чтобы не блокировать сетевой трафик между Azure NetApp Files и контроллерами домена AD DS и подсетями, назначенными сайту AD DS Azure NetApp Files.

Как Azure NetApp Files использует сведения о сайте AD DS

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

Обнаружение контроллера домена AD DS

Azure NetApp Files инициирует обнаружение контроллера домена каждые четыре часа. Azure NetApp Files запрашивает запись ресурса службы DNS для конкретного сайта (SRV), чтобы определить, какие контроллеры домена находятся на сайте AD DS, указанном в поле имени сайта AD Azure NetApp Files. Обнаружение сервера контроллера домена Azure NetApp Files проверка состояние служб, размещенных на контроллерах домена (например, Kerberos, LDAP, Net Logon и LSA) и выбирает оптимальный контроллер домена для запросов проверки подлинности.

Записи ресурсов службы DNS (SRV) для сайта AD DS, указанного в поле имени сайта AD Azure NetApp Files AD, должны содержать список IP-адресов для контроллеров домена AD, которые будут использоваться Azure NetApp Files. Вы можете проверка допустимость записи ресурсов DNS (SRV) с помощью служебной nslookup программы.

Примечание.

Если вы вносите изменения в контроллеры домена на сайте AD DS, используемом Azure NetApp Files, подождите по крайней мере четыре часа между развертыванием новых контроллеров домена AD DS и выходом из эксплуатации существующих контроллеров домена AD DS. Это время ожидания позволяет Azure NetApp Files обнаруживать новые контроллеры домена AD DS.

Убедитесь, что устаревшие записи DNS, связанные с устаревшим контроллером домена AD DS, удаляются из DNS. Это гарантирует, что Azure NetApp Files не будет пытаться взаимодействовать с устаревшим контроллером домена.

Обнаружение сервера LDAP AD DS

Отдельный процесс обнаружения для серверов LDAP AD DS возникает при включении LDAP для тома NFS Azure NetApp Files. Когда клиент LDAP создается в Azure NetApp Files, Azure NetApp Files запрашивает запись ресурсов доменной службы AD DS (SRV) для списка всех серверов LDAP AD DS в домене, а не серверов LDAP AD DS, назначенных сайту AD DS, указанному в подключении AD DS.

В крупных или сложных топологиях AD DS может потребоваться реализовать политики DNS или подсеть DNS, чтобы убедиться, что серверы LDAP AD DS, назначенные сайту AD DS, указанному в подключении AD, возвращаются.

Кроме того, процесс обнаружения сервера LDAP AD DS можно переопределить, указав до двух предпочтительных серверов AD для клиента LDAP.

Внимание

Если Azure NetApp Files не может связаться с обнаруженным сервером LDAP AD DS во время создания клиента LDAP Azure NetApp Files, создание тома с поддержкой LDAP завершится ошибкой.

Последствия неправильной или неполной конфигурации имени сайта AD

Неправильное или неполное топология сайта AD DS или конфигурация могут привести к сбоям создания тома, проблемам с запросами клиента, сбоями проверки подлинности и ошибками изменения подключений Azure NetApp Files AD.

Внимание

Поле "Имя сайта AD" требуется для создания подключения Azure NetApp Files AD. Определенный сайт AD DS должен существовать и правильно настроен.

Azure NetApp Files использует сайт AD DS для обнаружения контроллеров домена и подсетей, назначенных сайту AD DS, определенному в имени сайта AD. Все контроллеры домена, назначенные сайту AD DS, должны иметь хорошее сетевое подключение из интерфейсов виртуальной сети Azure, используемых ANF и доступны. Виртуальные машины контроллера домена AD DS, назначенные сайту AD DS, используемому Azure NetApp Files, должны быть исключены из политик управления затратами, которые завершают работу виртуальных машин.

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

При каждом развертывании новых контроллеров домена в подсети, назначенной сайту AD DS, который используется adApp Files AD Подключение ion, необходимо обновить конфигурацию сайта AD AD. Убедитесь, что записи DNS SRV для сайта отражают любые изменения контроллеров домена, назначенных сайту AD DS, используемому Azure NetApp Files. Вы можете проверка допустимость записи ресурсов DNS (SRV) с помощью служебной nslookup программы.

Примечание.

Azure NetApp Files не поддерживает использование контроллеров домена только для чтения AD DS (RODC). Чтобы предотвратить использование AZURE NetApp Files с помощью RODC, не настраивайте поле "Имя сайта AD" подключений AD с помощью RODC.

Пример конфигурации топологии сайта AD DS для Azure NetApp Files

Топология сайта AD DS — это логическое представление сети, в которой развертывается Azure NetApp Files. В этом разделе описан пример сценария конфигурации для топологии сайта AD DS, который будет отображать базовый дизайн сайта AD DS для Azure NetApp Files. Это не единственный способ разработки сетевой или топологии сайта AD для Azure NetApp Files.

Внимание

Для сценариев, которые включают сложные топологии AD DS или сложные сетевые топологии, необходимо проверить сеть Azure NetApp Files и проект сайта AD.

На следующей схеме показан пример топологии сети: sample-network-topology.png Схема, демонстрирующая топологию сети.

В примере топологии сети локальный домен AD DS (anf.local) расширяется в виртуальную сеть Azure. Локальная сеть подключена к виртуальной сети Azure с помощью канала Azure ExpressRoute.

Виртуальная сеть Azure имеет четыре подсети: подсеть шлюза, подсеть Бастиона Azure, подсеть AD DS и делегированную подсеть Azure NetApp Files. Избыточные контроллеры домена AD DS, присоединенные к домену anf.local , развертываются в подсети AD DS. Подсеть AD DS назначается диапазон IP-адресов 10.0.0.0/24.

Azure NetApp Files может использовать только один сайт AD DS, чтобы определить, какие контроллеры домена будут использоваться для проверки подлинности, запросов LDAP и Kerberos. В примере сценария создаются и назначаются два объекта подсети, вызываемые ANF с помощью служебной программы сайтов и служб Active Directory. Один объект подсети сопоставляется с подсетью AD DS, 10.0.0.0/24, а другой объект подсети сопоставляется с делегированной подсетью ANF, 10.0.2.0/24.

В средстве "Сайты и службы Active Directory" убедитесь, что контроллеры домена AD DS, развернутые в подсети AD DS, назначены сайту ANF :

Снимок экрана: окно

Чтобы создать объект подсети, сопоставленный с подсетью AD DS в виртуальной сети Azure, щелкните правой кнопкой мыши контейнер подсетей в служебной программе "Сайты и службы Active Directory" и выберите "Создать подсеть...". В диалоговом окне "Новый объект — подсеть" диапазон IP-адресов 10.0.0.0/24 для подсети AD DS вводится в поле префикса. Выберите ANF объект сайта для подсети. Нажмите кнопку "ОК ", чтобы создать объект подсети и назначить его сайту ANF .

Снимок экрана: меню

Чтобы убедиться, что новый объект подсети назначен правильному сайту, щелкните правой кнопкой мыши объект подсети 10.0.0.0/24 и выберите "Свойства". Поле "Сайт" должно отображать ANF объект сайта:

Снимок экрана: меню свойств с красным полем, окружающим поле сайта, которое считывает ANF.

Чтобы создать объект подсети, сопоставленный с делегированной подсетью Azure NetApp Files в виртуальной сети Azure, щелкните правой кнопкой мыши контейнер подсетей в служебной программе "Сайты и службы Active Directory" и выберите "Создать подсеть...".

Рекомендации по реплика между регионами

Реплика tion между регионами Azure NetApp Files позволяет реплика отправлять тома Azure NetApp Files из одного региона в другой регион для поддержки требований к непрерывности бизнес-процессов и аварийного восстановления (BC/DR).

Azure NetApp Files S МБ, двойной протокол и тома NFSv4.1 Kerberos поддерживают реплика между регионами. Для репликации этих томов требуется следующее:

  • Учетная запись NetApp, созданная как в исходном, так и в целевом регионах.
  • Подключение Azure NetApp Files Active Directory в учетной записи NetApp, созданной в исходных и целевых регионах.
  • Контроллеры домена AD DS развертываются и выполняются в целевом регионе.
  • Для обеспечения хорошей сетевой связи Azure NetApp Files с контроллерами домена AD DS в целевом регионе необходимо развернуть правильное сетевое взаимодействие Azure NetApp Files с контроллерами домена AD DS в целевом регионе.
  • Подключение Active Directory в целевом регионе должно быть настроено для использования ресурсов САЙТА DNS и AD в целевом регионе.

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