Большая часть организаций заполняет службу каталогов Azure AD учетными записями пользователей и групп посредством их репликации из среды Active Directory Domain Services локальной сети. Если вы таким образом создаете исходные учетные записи пользователей, существует три подхода к управлению запросами аутентификации пользователей Azure AD.
• Azure AD выполняет аутентификацию. Это возможно при условии, что хеш пароля пользователя (или скорее хеш от хеша пароля) дублируется в Azure AD. Это самый простой вариант, который не требует коммуникации с инфраструктурой AD локальной сети. Кроме того, это означает, что контроллеры домена DC локальной сети нс заботятся об аутентификации и не управляют ею.
• Используется федерация, например, службы ADFS. В этом случае Azure AD настраивается на использование федеративных отношений для аутентификации. Когда появляется запрос на аутентификацию, пользователь перенаправляется в службу федерации, которая выполняет аутентификацию, используя AD локальной сети. Это более сложное развертывание, но оно открывает перед вами всю мощь ADFS в отношении аутентификации. Данный процесс предусматривает использование аутентификации, основанной на сертификате, согласовании с другими системами многофакторной аутентификации MFA, техническом состоянии устройства и местоположении, а также других возможностей политик ADFS (или какой бы
то ни было платформы, используемой в качестве службы федерации). Обратите внимание, что, выбирая этот вариант, вы можете реплицировать хеш-пароли в Azure AD из предыдущего варианта и использовать их как альтернативный подход к аутентификации, если службы федерации недоступны.
• Используется сквозная аутентификация. Это самый новый из всех способов, который предлагается как дополнительная возможность Azure AD Connect. В этом случае в локальной сети разворачиваются агенты, которые просматривают очередь запросов на аутентификацию в Azure AD (агенты создают исходящее соединение с Azure AD. что означает отсутствие указания исключений для брандмауэра). Когда пользователь аутентифицируется на уровне Azure AD, запрос добавляется в очередь. Один из агентов сквозной аутентификации локальной сети принимает запросы, выполняет аутентификацию на контроллере домена DC локальной сети и сообщает об успешном или неудачном выполнении. Преимущество этого подхода состоит в том, что используются контроллеры домена локальной сети для выполнения реальной аутентификации. При этом организации разрешается осуществлять более жесткий контроль и возникает прозрачность аутентификации, поскольку исключаются требования к инфраструктуре, которые есть в случае с федерацией. Обратите внимание, что дополнительные копии агента сквозной аутентификации должны быть развернуты в локальной сети после развертывания одного стандартного экземпляра с Azure AD Connect для обеспечения высокой доступности службы.
Хотя я часто произношу слова «служба каталогов AD или контроллеры домена локальной сети», это не означает, что они на самом деле обязательно должны быть в локальной сети. Они могут размешаться на других ресурсах, таких как виртуальные машины Azure IaaS т. д. Я просто имею в виду, что они не располагаются в Azure AD.
Не существует правильного или неправильного подхода, поскольку у каждой организации свои требования. Если у вас довольно простая среда, где нет федерации и нет необходимости в анализе видов аутентификации локальной сети, го использование хеша пароля — это самый простой вариант. Если вам необходимо больше прозрачности при аутентификации и управление этим процессом, тогда более подходящим вариантом будет сквозная аутентификация. Если у вас более крупная организация, в которой уже есть служба федерации, то, вероятно, подход с использованием федерации как раз для вас, хотя в этом случае важно сделать шаг назад и оценить свои потребности. Если вы используете Azure AD. у вас может больше не возникнуть необходимости в собственных службах аутентификации, поскольку вы уже используете федеративные отношения Azure AD. Следовательно, использование другой федерации, вероятно, не будет идеальным вариантом, так как вам придется внедрять для нее новые виды взаимозависимости, тогда как остальные будут вести к Azure AD. Вам может понадобиться задействовать федерацию, если вы хотите применять больше передовых решений, таких как аутентификация, основанная на сертификатах, различные решения многофакторной аутентификации MFA и т. д.
Миграция и сопровождение серверов и сервисов Azure, [email protected]