В прошлой публикации мы рассмотрели архитектуру сервиса Azure AD Password Protection. Теперь мы пройдем все необходимые шаги для того, чтобы этот сервис можно было использовать с локальной Active Directory. При таком сценарии сначала будут использоваться локальные политики (групповые политики домена Active Directory) проверки пароля, а затем будут применяться правила проверки надежности пароля в соответствии с настройками сервера Azure AD Password Protection.
Что необходимо сделать для настройки Azure AD Password Protection в локальной Active Directory:
- Включить в настройках сервиса проверку паролей в локальной Active Directory.
- Установить AAD Password Protection proxy service.
- Установить AAD Password Protection DC agent.
- Выполнить проверку работы сервиса с локальной Active Directory.
Приступим к выполнению пунктов выше.
Схема решения
В нашей демонстрации мы будем использовать следующую схему:
SRV-APP01 – это рядовой сервер домена, на котором будет установлен компонент AAD Password Protection proxy service. Серверов с этим компонентом может быть несколько – для обеспечения отказоустойчивости. Причем, это даже рекомендованный сценарий. Для нашей же тестовой среды мы будем использовать один сервер. Основная задача этого компонента – загрузить политику ненадежных паролей с сервиса AAD Password Protection. Как следует из описания назначения компонента – у сервера с этим компонентом должен быть выход в Интернет. По крайней мере до сервиса AAD Password Protection.
SRV-DC01 – это контроллер домена. На нем будет установлен компонент Azure AD Password ProtectionDC Agent. Этот компонент выполняет непосредственную фильтрацию паролей на основе политики. Вы можете развертывать этот компонент постепенно. Дополнительная фильтрация на основе политики AAD Password Protection будет выполняться только на тех контроллерах, на которых установлен этот компонент. Контроллеры домена подключаются к компоненту AAD Password Protection proxy service для получения актуальной политики ненадежных паролей.
В качестве опорного материала при настройке мы будем использовать соответствующий раздел руководства.
Настройка сервиса Azure AD Password Protection для работы с локальной Active Directory
Для того, чтобы сервис по фильтрации паролей работал с наземной Active Directory в его настройках необходимо включить соответствующую опцию.
Для этого нужно выполнить следующие шаги:
- Открыть портал Azure.
- Перейти в сервис Azure Active Directory.
- Открыть раздел Security.
- Перейти в раздел Authentication methods.
- Перейти в раздел Password protection.
- Установив переключать Enable password protectionon Windows Server Active Directory в положение Yes вы включите проверку паролей в соответствии со списком ненадежных паролей в наземной Active Directory.
Переключатель Mode определяет, что именно контроллер Active Directory будет делать с ненадежным паролем.
Если переключатель установлен в позицию Audit, то пароль будет принят, но в соответствующем журнале событий будет зарегистрирован этот факт. Этот режим удобен на этапе внедрения или аудита, т.е. выгрузив, например, скриптом все соответствующие события из журнала вы можете собрать некую аналитику по тому, как часто ваши пользователи используют ненадежные пароли.
Если переключатель установлен в позицию Enforced, то ненадежный пароль будет отклонен и пользователь получит соответствующее уведомление. В журнале будет отмечен этот факт.
В остальном режиме Enforced и Audit ничем не отличаются в логике своей работы.
Установка Azure AD Password Protection proxy service
AAD Password Protection proxy service непосредственно подключается к сервису для получения актуальной политики ненадежных паролей, а затем предоставляет эту политику контроллерам домена (на которых установлен компонент Password Protection DC agent), т.к. контроллеры домена не подключаются напрямую к сервису через Интернет.
Предварительные требования
Предварительны требования для установки компонента Password Protection proxy service приведены ниже:
- Операционная система сервера, на котором будет устанавливаться компонент, должна быть Windows Server 2012 R2 или выше. Редакция Server Core поддерживается.
- Необходим .NET 4.7.2 или выше.
- Сервера, на которых установлен компонент Password Protection proxy service, должны быть сконфигурированы так, чтобы разрешить подключение контроллерам домена к сервису Password Protection proxy service. Для этого в настройке привилегий “Access this computer from the network” необходимо внести соответствующие записи.
- На всех серверах должен быть разрешен исходящий TLS 1.2 HTTP траффик.
- Необходима учетная запись Azure AD Global Administrator для того, чтобы выполнить первоначальную регистрацию компонента в сервисе AAD Password Protection.
- Необходимо сконфигурировать сетевое оборудование и сервера на разрешения следующих сетевых портов и URL.
Особенности и рекомендации
При установке компонента необходимо руководствоваться следующими особенностями и рекомендациями:
- Каждый сервер с компонентов Password Protection proxy service может предоставлять сервис только в пределах одного леса. Вариант работы одного сервера с несколькими лесами не предусмотрен.
- Компонент Password Protection proxy service можно устанавливать на любой домен в пределах леса – как root домен, так и дочерний, либо и на root и на дочерний домен.
- Необходимо, чтобы как минимум один контроллер домена мог подключаться к серверу с компонентом Password Protection proxy service.
- Поддерживается установка компонента Password Protection proxy service на контроллер домена, но такой сценарий рекомендован только для PoC (Proof of Concept) развертываний или тестирования, т.к. в этом случае контроллеру домена нужен выход в Интернет.
- Рекомендуется как минимум два сервера с компонентов Password Protection proxy service. Если один сервер будет недоступен, то второй сервер сможет загрузить актуальную политику.
- Установка на контроллеры домена только для чтения не поддерживается.
Установка компонента
Загрузить дистрибутив компонента можно по следующей ссылке. Имя файла “AzureADPasswordProtectionProxySetup.msi”.
Для установки компонента необходимо выполнить следующие действия:
1. Выполнить установку дистрибутива:
AzureADPasswordProtectionProxySetup.msi /quiet
Важный момент – служба Windows Firewall должна быть включена в момент установки дистрибутива. В противном случае установка может завершиться с ошибкой.
Соответственно, если вы используете сторонний брандмауэр, то в его настройках необходимо разрешить входящий 135/TCP порт и proxy RPC порты (49152 – 65535/TCP).
В случае успешного завершения процедуры установки мы увидим соответствующую запись в журнале событий.
2. Убедимся, что сервис запущен:
Get-Service AzureADPasswordProtectionProxy | fl
3. Импортируем необходимый модуль PowerShell:
Import-Module AzureADPasswordProtection
4. Следующее, что нам необходимо сделать – это выполнить регистрацию сервиса. Чтобы зарегистрировать наш сервис, нам необходима учетная запись глобального администратора Azure AD. Регистрация выполняется следующим командлетом:
Register-AzureADPasswordProtectionProxy -AccountUpn 'yourglobaladmin@yourtenant.onmicrosoft.com'
Если у вас включена многофакторная аутентификация, то необходимо будет подтвердить второй фактор.
Регистрацию сервера необходимо выполнить только на самом первом сервер с компонентом Password Protection proxy service. На последующих серверах регистрацию выполнять не нужно.
5. Далее необходимо зарегистрировать наш лес Active Directory в сервисе AAD Password Protection:
Register-AzureADPasswordProtectionForest -AccountUpn 'yourglobaladmin@yourtenant.onmicrosoft.com'
Для регистрации необходима учетная запись Global Administrator или Security Administrator в Azure AD.
Регистрацию леса можно выполнять с любого сервера с компонентом Password Protection proxy service.
Операция выполняется один раз для всего леса.
6. Если в вашей организации для выхода в Интренет используется прокси, то необходимо выполнить соответствующие настройки сервиса, как указано в документации.
На остальных серверах установка выполняется аналогично.
Установка Azure AD Password Protection DC agent
AAD Password Protection DC agent выполняет непосредственную проверку паролей. Если, пароль, который пользователь пытается установить для своей учетной записи, является ненадежным, то DC agent может его либо отклонить (при установленным Enforced режиме), либо принять, но сделать соответствующую запись в журнал (при Audit режиме).
Предварительные требования
Предварительны требования для установки компонента Password Protection proxy service приведены ниже:
- Операционная система сервера, на котором будет устанавливаться компонент, должна быть Windows Server 2012 или выше. Редакция Server Core поддерживается.
- Требований к функциональному уровню леса или домена нет.
- Необходим .NET 4.7.2 или выше.
- Все контроллеры домена, на которых планируется установить компонент, должны использовать Distributed File System Replication (DFSR) для тома sysvol.
Установка компонента
Загрузить дистрибутив компонента можно по следующей ссылке. Имя файла “AzureADPasswordProtectionDCAgentSetup.msi“.
Для установки компонента необходимо выполнить следующие действия:
1. Выполнить установку дистрибутива:
msiexec.exe /i AzureADPasswordProtectionDCAgentSetup.msi /quiet /qn /norestart
В случае успешной установке в журнале приложений мы должны увидеть следующее сообщение:
2. Выполнить перезагрузка контроллера домена. Перезагрузка необходима для того, чтобы сервис мог загрузить необходимую DLL для фильтрации пароля.
На остальных контроллерах домена установка выполняется аналогично.
Проверка работоспособности сервиса
Как мы можем проверить, что мы все сделали правильно? Можно, например, попробовать на любом клиенте установить заведомо известный ненадежный пароль 🙂 Но мы пойдем другим путем – мы соберем диагностическую информацию о работе сервиса.
Первое, что мы сделаем – это проверим информацию о наших контроллерах:
Get-AzureADPasswordProtectionDCAgent
В списке мы должны увидеть все контроллеры домена, на которые мы устанавливали компонент DC agent.
Аналогичным образом посмотрим информацию и серверам с компонентом proxy service:
Следующим шагом мы проверим состояние нашего прокси сервиса. На машине с компонентом proxy service выполним соответствующим командлет:
Test-AzureADPasswordProtectionProxyHealth -TestAll
Из результатов диагностики мы видим, что TLS у нас сконфигурирован правильно, прокси сервис был успешно зарегистрирован в сервисе AAD Password Protection и наш прокси сервис может успешно обратиться за актуальной политикой ненадежных паролей
Далее проверим состояние нашего агента на серверах контроллерах домена. Для этого на контроллере домена с агентом выполним командлет:
Test-AzureADPasswordProtectionDCAgentHealth -TestAll
Как мы видим, все тесты также завершились успешно.
Последним шагом мы можем заглянуть в журнал событий Azure AD Password Protection.
Как мы видим из скриншота выше – политика успешно применилась. Собственно, об этом нам и написали в журнале.
Косвенно по результатам диагностики мы можем сделать вывод, что мы все настроили верно и наши контроллеры домена теперь будут отклонять ненадежные пароли.
Если что-то пошло не так
К сожалению, не всегда настройка какого-то нового сервиса завершается успешно с первого раза в силу разных причин. Алгоритм действия при диагностике проблемы может быть построен на основе шагов из предыдущего раздела.
Дополнительно мы можем выполнить командлет, который проверим – видит ли наш контроллер сервер с компонентом прокси. Командлет необходимо выполнить на контроллере домена:
Test-AzureADPasswordProtectionDCAgentHealth -VerifyProxyConnectivity bpl2.bpl.com
Дополнительно можем проверить – может ли сервер с компонентом прокси подключиться к сервису от имени нашего контроллера домена. Командлет необходимо выполнить на контроллере домена:
Test-AzureADPasswordProtectionDCAgentHealth -VerifyAzureConnectivityViaSpecificProxy bpl2.bpl.com
На серверах с компонентами DC agent и proxy service есть отдельная ветка в журнале для AAD Password Protection. Возможно, какую-то информацию для диагностики можно будет подчерпнуть оттуда:
Компания Microsoft собрала наиболее часто встречаемые проблем и способы их решения в отдельной ветке документации. Вероятно, на какие-то вопросы можно найти ответы там.
Взгляд со стороны клиента
Теперь рассмотрим сервис со стороны наших пользователей.
В нашем настраиваемом списке ненадежных паролей есть вот такой – StringCompare123. Предположим, что пароль нашего пользователя уже скоро потребуется менять. О чем пользователь получил соответствующее уведомление и решил сменить пароль на StringCompare123.
Именно такое сообщение получит наш пользователь. Если мы посмотрим ветку журнала событий сервиса AAD Password Protection на контроллере домена (на том КД, на котором обрабатывался запрос), то мы можем найти следующую запись.
Мы можем получить небольшой сводный отчет выполнив следующий командлет:
Get-AzureADPasswordProtectionSummaryReport
Нам будет предоставлена небольшая сводная информация по каждому из контроллеров домена.
Заключение
В прошлой публикации мы рассмотрели основную архитектуру сервиса. В данной публикации мы на практике выполнили непосредственную настройку сервиса.
Мы поговорили про предварительные требования для установки компонентов сервиса, поговорили про особенности установки компонентов.
В соответствующих разделах мы пошагово выполнили процесс установки каждого из компонентов в отдельности.
Отдельно мы говорили о том, как выполнить проверку корректности работы всего сервиса в целом.
Также мы посмотрели, что видят наши пользователи, когда пытаются сменить свой пароль на один из ненадежных паролей.