Какие методы аутентификации следует использовать для Azure AD?

Большая часть организаций заполняет службу каталогов 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 AD?

И нет, и да. Единый способ аутентификации настраивается в домене Azure AD (UPN). Вы не можете выбрать несколько вариантов даже для разных групп пользователей внутри одного домена. Однако, если у вас есть разные домены (UPN) внутри экземпляра Azure AD, тогда каждый домен имеет собственные выбранные виды аутентификации.

Могу ли я зарегистрировать системы Linux в своей динамической службе DNS, интегрированной с AD?

Служба DNS, интегрированная с AD, использует безопасное обновление по умолчанию. Это означает, что только системы, которые можно аутентифицировать, смогут регистрировать записи. Если вы хотите иметь реестр систем Linux, то существует два набора параметров, однако они обеспечивают менее безопасную настройку и, как правило, этого не рекомендуется делать. Другой вариант — вручную регистрировать записи Linux. Если вы хотите, чтобы система Linux делала это автоматически, то прежде всего настройте службу DHCP, чтобы регистрировать записи хоста (А) и указателя (PTR) от имени клиентов, которые не регистрируют их сами:

  1. Откройте диспетчер DHCP Manager.
  2. Откройте свойства диапазона.
  3. Выберите вкладку DNS.
  4. Активируйте вариант динамического обновления Dynamically update DNS records for DHCP clients that do not request updates.
  5. Нажмите кнопку ОК.

Затем настройте DNS, для того чтобы поддерживать незащищенные обновления:

  1. Откройте диспетчер DHCP Manager.
  2. Откройте свойства диапазона.
  3. На вкладке General настройте динамические обновления как Nonsecure and secure.
  4. Нажмите кнопку ОК.

Какие службы федерации работают с Azure AD?

Одним из вариантов аутентификации в Azure AD является использование федерации. Обычно применяется служба ADFS, но могут использоваться и другие службы федерации. Список служб федерации доступен по адресу: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-federation- compatibility. Если вы хотите задействовать решение с федеративными отношениями, которого нет в списке, это не означает, что оно не будет работать. Это означает только то, что данное решение не тестировалось. Понять федерацию довольно сложно, поскольку это не просто протоколы Oauth2, SAML 2.0 и т. д. Это и формат ответа, процессы обмена метаданными, обмен сертификатами и пр. Зачастую можно задействовать веб-процессы (операции взаимодействия с браузером), но более сложные сценарии, например работа с графическими клиентскими приложениями или по ActiveSync, становятся проблематичными. Единственный способ узнать, будут ли они работать, — это выполнить тестирование.

Я хочу развернуть диспетчер контейнеров в Azure, но служба Azure Container Service не предоставляет те возможности, которые мне нужны для сгенерированного решения. Что предпринять?

Azure Container Service представляет собой решение Azure, которое позволяет автоматически развернуть решение по оркестровке контейнеров, а именно Docker Swarm, Kubernetes или DC/OS в стиле лучших решений развертывания в виртуальных машинах Azure IaaS. Вы можете обнаружить, что развертывание не соответствует требованиям вашей среды. Например, сейчас развертывание не поддерживает управляемый диск. Альтернативный вариант — использование механизма ACS Engine (он сам по себе может быть запущен в контейнере), который после проведения желаемой настройки выведет файл JSON. Этот файл впоследствии может использоваться для реального создания ресурсов в Azure. Решение можно загрузить по адресу: https://github.com/Azure/acs-engine.