Сквозная передача Azure AD по сравнению с ADFS: что мы используем для проверки подлинности?
В моем собственном блоге я часто пишу статьи о Microsoft Exchange, Exchange Online, PowerShell и Office 365. Один вопрос, который мне постоянно задают мои читатели и мои клиенты в моей рабочей жизни, касается проверки подлинности и Office 365. Должны ли они использовать классический федерация между локальным сервером и Office 365 с ADFS, или, может быть, лучше изучить сквозную передачу Microsoft Azure AD?
Ну, если честно, на этот вопрос вообще нельзя ответить! Почему? Потому что это всегда зависит от организации компании и вашей цели.
В этой статье я напишу об обоих способах, которыми вы можете воспользоваться. Возможно, это поможет вам найти правильное решение в вашем случае или то, как вы хотите работать в будущем. Лучше всего, если вы работаете ИТ-консультантом, вы сможете выбрать правильное решение для своих проектов.
Аутентификация с помощью ADFS
В другой статье в своем блоге я описал, как нужно настраивать ADFS и как ее можно персонализировать.
Во-первых, давайте посмотрим на функциональность ADFS для аутентификации служб Office 365:
Сотрудники могут использовать рабочую станцию своей компании или любое частное устройство. Если они используют рабочую станцию компании, им придется войти на рабочую станцию с учетными данными домена компании. Если они используют частный компьютер и хотят получить доступ к среде компании, им придется сначала пройти аутентификацию в среде компании (через ADFS), после чего они смогут использовать все функции.
Локальный сайт и облачный сайт настроили федерацию между собой, которая зависит от модели удостоверения. Есть разные способы борьбы с ними. Однако, с моей точки зрения, один из лучших способов — использовать синхронизацию каталогов с федеративным удостоверением. (Это показано на изображении выше.) У пользователя компании есть локальная учетная запись Active Directory, которая синхронизируется с клиентом Office 365 с помощью AAD. Если теперь пользователь пытается подключиться к облачным службам за пределами компании, он переходит на портал Office 365 и вводит учетные данные своей компании. Они будут контролироваться (аутентификация) из локальной Active Directory через ADFS. Если все верно, пользователь сможет войти в систему.
Этот принцип работает не только для аутентификации между нашей локальной средой и Office 365 или Azure, но и для многих сторонних облачных сервисов, таких как AWS, G Suite и Salesforce.
Одна из вещей, о которой мы должны подумать при использовании этого решения, заключается в том, что настоятельно рекомендуется создавать среду ADFS локально и делать это с избыточностью. Это означает как минимум два сервера ADFS и два прокси-сервера веб-приложений (WAP).
Исходя из своего опыта, я бы сказал, что это по-прежнему самая распространенная конфигурация в этой области.
Аутентификация с помощью сквозной аутентификации Azure AD
В дополнение к моим статьям об ADFS я написал статью о том, как необходимо настроить транзитную передачу Azure AD. Давайте сначала посмотрим, как работает аутентификация с использованием сквозной передачи Azure AD:
Пользователь пытается получить доступ к приложению, например Outlook Web App (OWA). Если пользователь не вошел в систему, он будет перенаправлен на страницу входа в Azure AD, где ему нужно будет ввести свое имя пользователя и пароль. Локальный агент аутентификации получает имя пользователя и зашифрованный пароль из очереди. Агент расшифровывает пароль с помощью своего закрытого ключа и проверяет информацию с помощью Active Directory. Если вся информация верна, Azure AD оценивает ответ и отвечает пользователю соответствующим образом. Например, Azure AD либо сразу подписывает пользователя, либо отправляет запрос на многофакторную идентификацию Azure. Если вход пользователя выполнен успешно, пользователь может получить доступ к приложению.
Корпорация Майкрософт постоянно совершенствует аутентификацию с помощью Azure AD Pass-through и получает регулярные обновления функций. Но я могу рекомендовать его только для использования с аутентификацией облачных сервисов Microsoft.
Конфигурация сквозной передачи должна быть выполнена с помощью Azure AD Connect (AAD). После того, как конфигурация выполнена, мы можем подключиться к нашей Azure Active Directory, и после просмотра Azure AD Connect мы видим, что транзит включен.
Агенты службы аутентификации могут быть установлены на каждом сервере, который имеет доступ к Active Directory и ее каталогу и доступен со стороны облака. Однако, если мы сравним его со средой ADFS, которой требуется как минимум пять серверов (два ADFS, два WAP и один AAD), а также балансировщик нагрузки, мы можем сэкономить четыре из них с помощью сквозного доступа — и сохранить также балансировщик нагрузки.
Итак, сквозной доступ к Azure AD или ADFS?
Оба решения хороши. Поэтому я не могу дать рекомендацию, какой из двух вариантов вам следует использовать. Однако это никогда не было целью данной статьи. В нем показаны два способа обработки аутентификации с помощью инструментов Microsoft. На данный момент я рекомендую своим клиентам, если они используют только службы Microsoft, аутентификация с AD Pass-through является хорошим решением. Для других компаний, использующих облачные сервисы, такие как AWS, G Suite и Salesforce, ADFS имеет больше смысла.
Одно замечание: если вы используете ADFS в своей организации, переключиться на сквозную передачу несложно, и это не займет у вас много времени. Переход в обратном направлении от сквозного доступа к ADFS также возможен, но это занимает больше времени.
Если вы решите использовать сквозную передачу Azure AD, вы должны помнить, что параметр PTA является параметром для всего клиента, поэтому все учетные записи в вашем клиенте вынуждены использовать PTA. Если что-то пойдет не так в сети и ни один из агентов AuthN недоступен, никто больше не сможет войти в систему. Поэтому вам нужна облачная учетная запись администратора с именем пользователя @<tenant>.onmicrosoft.com, чтобы иметь «черный ход» для устранения неполадок.
Если вам нужно настроить недорогую аутентификацию для облачных сервисов Microsoft в вашем проекте, это может стать решением серьезной проблемы.