Azure AD Password Protection – это один из облачных сервисов Microsoft Azure. Этот сервис позволяет в некотором роде делегировать проверку паролей ваших пользователей на надежность данному сервису. Речь идет про пароли в облачной Azure AD и наземной Active Directory. Таким образом Azure AD Password Protection позволяет блокировать ненадежные пароли и их вариации.
Перечень ненадежных паролей состоит из двух блоков. Первый блок – это пароли, которые считает таковыми компания Microsoft. Второй блок – это ваши кастомные пароли. Перечень паролей из первого блока обслуживает компания Microsoft, и вы не можете управлять этим списком. Какие пароли компания Microsoft включила в этот список нам также не известно. Вторым блоком вы можете управлять – добавлять туда ваши пароли или те фразы, которые по вашему мнению не должны присутствовать в паролях ваших сотрудников.
В подразделах ниже мы детально поговорим об архитектуре решения и его развертывании.
Общее описание и архитектура сервиса
Общая архитектура решения
В основе работы Azure AD Password Protection есть два компонента. Первый компонент – Azure AD Password Protection Proxy. Второй – Azure AD Password Protection DC Agent, как показано на схеме ниже.
Детальная информация по всех архитектуре решения приведена в официальной документации, однако мы рассмотрим основные моменты.
Основные компоненты системы:
- Password Protection Proxy – это компонент, который устанавливается на рядовой сервер и непосредственно обращается к сервису Azure AD Password. Этот сервис отдает ему политику ненадежных паролей (как общепринятых, так и ваших добавленных вручную). Он кэширует у себя ответ от сервиса, а при обращении контроллеров домена отдает им полученную политику.
- Azure AD Password Protection DC Agent – этот компонент устанавливается на контроллерах домена. Он отвечает за загрузку политики прокси из п.1 и применение политики проверки паролей непосредственно на контроллерах домена. Также выполняет непосредственную проверку паролей на соответствие политике.
- DLL фильтрации паролей сервиса DC Agent – библиотека получает запросы на смену паролей и транслирует эти запроса компоненту DC Agent.
Стоит отметить важный момент – политика будет применяться только для новых запросов на смену или установку пароля. Например, при создании учетной записи пользователя.
Поддерживается постепенное внедрение решения, т.е. вы можете добавить один или два прокси, но установить сам агент только, например, на одном контроллере домена. В таком случае на соответствие политике будут проверяться только те запросы на установку или обновление пароля, которые были направленны на этот контроллер домена с установленным агентом.
Основные принципы работы решения
Основные принципы работы решения следующие:
- Контроллеры домена не обращаются напрямую к облачному сервису. Они обращаются за политикой только на сервера с компонентом прокси.
- Дополнительные порты в настройках брандмауэров на контроллерах домена открывать не нужно.
- Внесения изменений в схему Azctive Directory не требуется.
- Требования к минимальной версии домена или леса Active Directory нет.
- Дополнительные сервисные учетные записи не требуются.
- Валидация пароля происходит непосредственнона контроллере домена. Дальше контроллера домена пароль пользователя никуда не транслируется.
Как работает Azure AD Password Protection с наземной Active Directory
Механизм работы с политикой ненадежных паролей и проверкой паролей пользователей выглядит следующим образом:
- При установке Azure AD Password Protection Proxy в Active Directory создается объект serviceConnectionPoint. Таким образом каждый контроллер домена в вашем лесу будет знать – у какого сервера можно получить актуальную политику ненадежных паролей.
- Запрос на получение политики ненадежных паролей генерируется компонентом DC Agent service. Предварительно выполняется запрос к serviceConnectionPoint в Active Directory. Запрос нужен для того, чтобы получить список серверов с компонентом Azure AD Password Protection Proxy.
- Когда необходимый сервер с сервисом прокси найдет, то на этот сервер отправляется запрос на получение актуальной политики. Затем сервер с компонентом прокси выполняет непосредственный запрос к облачному сервису и получает ответ с актуальной политикой ненадежных паролей. Этот ответ транслируется обратно контроллеру домена.
- После того, как компонент DC Agent service получил политику паролей, то он складирует её в корне в отдельную папку в корне папки sysvol. Соответственно, остальные контроллеры домена могут забирать новую политику из этой папки.
- Запрос на обновление политики отправляется на прокси. Это происходит либо при старте компонента DC Agent, либо раз в час, если не было перезапуска этого компонента.
- В момент проверки пароля на соответствии политике используется текущая версия политики, которая сейчас по факту есть на контроллере домена. Таким образом, потенциально может быть ситуация, когда еще не прошел один час и новая политика (если таковая имеет) не была загружена контроллером домена.
Дополнительные особенности
Ниже приведен перечень дополнительных особенностей решения, которые стоит принять к рассмотрению при анализе применимости этого решения к вашей инфраструктуре или решаемой задаче:
- Azure AD Password Protection привязывается к тенанту Azure. Существует только одна политику на весь тенант. Да, вы можете зарегистрировать несколько лесов наземной Active Directory в одном тенанте, но для всех лесов будет применять одна политика, которая определена на уровне тенанта Azure.
- Компонент DC Agent не принимает входящие подключения на какие-либо порты – даже от компонента прокси.
- Прокси никогда не хранит у себя кэш политики. Также прокси никогда не обращается к компоненту DC agent самостоятельно.
- Компонент DC agent всегда использует самую последнюю локальную политику. Если, например, политика еще ни разу не была загружена, то пароль пользователя принимается.
- Существует некоторый временной интервал между тем как политика паролей была изменена в Azure AD и применением этой политики на контроллере домена. Сервис не работает в режиме реального времени.
- Password Protection является дополнением к существующим политикам. Помимо вашей доменной политики, например, у вас могут быть развернуты сторонние решения по проверки паролей.
Методика проверки пароля на надежность
Перечень ненадежных паролей формируют два списка – глобальный и настраиваемый. Глобальный список ненадежных паролей уже предоставляется “из коробки” компанией Microsoft. Настраиваемый список паролей для блокировки вы можете конфигурировать самостоятельно.
Глобальный список ненадежных паролей
Глобальный список ненадежных паролей формируется компаний Microsoft на основе данных Azure AD Identity Protection и других инструментов. По мере обнаружения новых ненадежных паролей они заносятся в этот список автоматически. Глобальный список ненадежных паролей нельзя конфигурировать или дополнять самостоятельно. Его также нельзя отключить.
Настраиваемый список ненадежных паролей
Помимо глобального списка ненадежных паролей вы можете настроить свой собственный перечень паролей (и некоторых их вариаций), которые ваши пользователи не должны использовать. Этот перечень заполняется через сustom banned password list. Для того, чтобы сконфигурировать список нужно выполнить следующие действия:
- Открыть портал Azure.
- Перейти в сервис Azure Active Directory.
- Открыть раздел Security.
- Перейти в раздел Authentication methods.
- Перейти в раздел Password protection.
- Установив переключать Enforce custom list в положение Yes вы активируете дополнительный список ненадежных паролей, как показано на рисунке ниже.
В поле Custom banned password list вы можете указать перечень паролей, которые ваши пользователи не должны использовать.
Максимальная длина настраиваемого списка ненадежных паролей – 1000 записей.
Проверка пароля
Каждый раз при смене пароля пользователя Azure AD Password Protection выполняет его проверку на соответствие политике ненадежных паролей. Стоит отметить, что даже если пароль пользователя включает в себя ненадежные пароли, то он может быть принят, но при соблюдении ряда условий, про которые мы поговорим ниже.
Процесс проверки пароля состоит из двух этапов:
- Нормализация.
- Проверка пароля.
Нормализация
Непосредственно перед проверкой на надежность пароль проходит процедуру так называемой нормализации. Эта процедура позволяет опознавать различные вариации паролей. Например, когда вместо буквы “a” используют символ “@”. Или же, когда вместо буквы “s” используют символ “$”.
Процедура нормализации включает в себя следующие шаги:
- Все заглавные буквы заменяются на строчные.
- Будет выполнена замена символов, как показано в таблице ниже.
| Исходный символ | Заменяемый символ |
| 0 | o |
| 1 | l |
| $ | s |
| @ | a |
Например, в нашем глобальном списке ненадежных паролей мы занесли слово “black”. Наш пользователь попытался установить пароль “B1@cK”. Слова “B1@cK” нет в нашем списке ненадежных паролей, но в результате процедуры нормализации ” B1@cK” будет заменен на “black”:
- B -> b
- 1 -> l
- @ -> a
- c -> c
- K -> k
Пароль будет отклонен, и пользователь получит соответствующее уведомление.
Проверка пароля
После процедуры нормализации наступает этап проверки пароля. На данном этапе применяются правила, которые мы рассмотрим ниже.
Неявное соответствие
Нечеткое соответствие (fuzzy matching) – используется для того, чтобы выполнить проверить, нет ли в нормализованном пароле словосочетаний из настраиваемого или глобального списка ненедёжных паролей. Также учитываются небольшие вариации этих паролей.
Например, asdewq указан в нашем списке ненадежных паролей. Пользователь использовал следующие вариации пароля:
- asdewr – последний символ “q” был заменен на “r”.
- asdewqr – был добавлен символ “r”.
- asdew – был удален последний символ “q”.
Три приведенных пароля выше не соответствуют явно нашему паролю “asdewq” из ненадежного списка. Однако, все они будут заблокированы, т.к. находятся в пределах одного изменения от оригинального пароля (как приводится в документации “edit distance of 1”).
Соответственно приведенные выше три вариации словосочетания “asdewq” будут отклонены в качестве пароля пользователя.
Соответствие подстроке
Правило соответствия подстроке проверяет нет ли в нормализованном пароле пользователя его имени или фамилии, а также имени тенанта Azure. Однако, имя тенанта не проверяется в том случае, если агент Azure AD Password Protection установлен на локальном контроллере Active Directory.
Проверка на соответствия подстроке выполняется только в том случае, если имя или фамилия сотрудника, а также имя имеют длину 4 символа или более. Это же правило относится и к имени тенанта Azure.
Подсчет надежности пароля
Последним этапом проверки пароля является этап подсчета баллов. При подсчете количества баллов используются следующие правила:
- Каждый пароль из списка ненаджёных паролей засчитывается за один балл.
- Каждый оставшийся символ, который засчитывается за один балл.
- Для того, чтобы пароль был принят необходимо, чтобы пароль набрал пять баллов.
Более понятны правила выше будут на примере ниже.
Пусть в нашем настраиваемом списке паролей есть следующее словосочетание “asdewq” и “mobile”.
Пользователь решил сменить пароль на следующий – @sdewQM0bilE12. Детально разберем этот сценарий:
- Сначала пароль пройдет процедуру нормализации. После процедуры нормализации наш пароль будет выглядеть следующим образом – asdewqmobile12.
- При проверке соответствия мы видим, что наш пароль содержит два словосочитания из списка ненадёжных паролей – asdewq и mobile.
- Паролю будут начислены следующие баллы: [asdewq](1) + [mobile](1) + 1(1) + 2(1) = 4.
- Итого наш пароль получил 4 балла. Это меньше 5 баллов, т.е. пароль будет отклонен.
Рассмотрим другой пример.
Пользователь решил сменить пароль на следующий – @sdewQM0bilE12#. Детально разберем этот сценарий:
- Сначала пароль пройдет процедуру нормализации. После процедуры нормализации наш пароль будет выглядеть следующим образом – asdewqmobile12#.
- При проверке соответствия мы видим, что наш пароль содержит два словосочитания из списка ненадежных паролей – asdewq и mobile.
- Паролю будут начислены следующие баллы: [asdewq](1) + [mobile](1) + 1(1) + 2(1) + #(1)= 5.
- Итого за наш пароль мы получаем 5 баллов, т.е. пароль будет принят.
Требования к лицензированию
Поскольку Azure Ad Password Protection относится к облачному решению, но и лицензируется он в соответствии с лицензией Azure AD.
Более детально информация по лицензированию приведена в таблице ниже.
| Тип пользователей | Глобальный перечень ненадежных паролей | Настраиваемый перечень ненадежных паролей |
| Пользователи облачной Azure AD | Azure AD Free | Azure AD Premium P1 or P2 |
| Пользователи, импортированные из наземной Active Directory | Azure AD Premium P1 or P2 | Azure AD Premium P1 or P2 |
| Пользователи наземной Active Directory | Azure AD Premium P1 or P2 | Azure AD Premium P1 or P2 |
Заключение
В данной статье мы рассмотрели общую архитектуру сервиса Azure Ad Password Protection. Далее мы рассмотрели работу основных компонентов сервиса для локальной Active Directory – Password Protection Proxy и DC Agent.
Далее мы рассмотрели два списка ненадежных паролей – глобальный и настраиваемый. После этого мы рассмотрели логику, которую сервис использует при проверке пароля: от процедуры нормализации до процедуры подсчета баллов.
В завершении мы поговорили про то, какие необходимы лицензии для пользования сервисом.
В следующей публикации мы поговорим про установку компонентов Azure AD Password Protection в локальную инфраструктуру Active Directory.