Демистификация моделей идентификации Exchange Online и аутентификации (часть 2)

• Демистификация моделей идентификации Exchange Online и аутентификации (часть 3)
• Демистификация моделей идентификации Exchange Online и аутентификации (часть 4)
• Демистификация моделей идентификации Exchange Online и аутентификации (часть 5)
• Демистификация моделей идентификации Exchange Online и аутентификации (часть 6)
• Демистификация моделей идентификации Exchange Online и аутентификации (часть 7)

Введение

В первой части этой серии статей, посвященной доступным моделям удостоверений и истории проверки подлинности для Exchange Online, я предоставил вам представление о двух из трех поддерживаемых моделей удостоверений (облачных удостоверениях и синхронизированных пользователях с включенной синхронизацией хэшей паролей). с AAD/Office 365. Я также объяснил, какие типы сценариев являются основными целями для каждой модели идентификации.

В этой части 2 мы продолжим с того места, на котором остановились в части 1.

Давайте идти. Как обычно, нам есть что рассказать.

Федеративные удостоверения

Третья и последняя модель удостоверений — это то, что мы называем моделью «федеративных удостоверений». Как и в случае с моделью «Синхронизированные удостоверения с включенным хэшем паролей», эта модель требует, чтобы мы синхронизировали наших локальных пользователей Active Directory с арендатором AAD/Office 365 с помощью одного из поддерживаемых инструментов синхронизации каталогов (предпочтительно AADConnect). Но на этом сходство заканчивается. Потому что, хотя аспекты синхронизации идентичны, части аутентификации очень разные. В отличие от модели «Синхронизированные удостоверения с включенным хэшем паролей», где хэш хэша пароля синхронизируется вместе с объектом пользователя с клиентом AAD/Office 365, в модели федеративных удостоверений используется служба федерации Active Directory (AD FS). технология для установления доверия федерации между арендатором и локальной Active Directory.

Примечание:
Вы можете комбинировать «Федеративные удостоверения» с моделью «Синхронизированные удостоверения с включенным хэшем пароля». В частности, вы можете использовать модель «Синхронизированные удостоверения с включенным хэшем паролей» в качестве резервной копии (отказоустойчивости) для модели «Федеративные удостоверения». Это означает, что в случае, если ваша ферма AD FS или даже Active Directory недоступна в течение длительного периода времени, вы можете преобразовать домен(ы) в арендаторе AAD/Office 365 из федеративных доменов в управляемые домены и тем самым разрешить пользователям пройти аутентификацию в Azure Active Directory и получить доступ к соответствующим рабочим нагрузкам Office 365. Для получения подробной информации о том, как это работает, см. эту статью TechNet Wiki.

Хотя обычно рекомендуется выбирать наименее сложную модель удостоверения, более крупные организации, имеющие один или несколько лесов Active Directory, а также сложную локальную инфраструктуру, во многих случаях хотят оставить механизмы проверки подлинности локальными, чтобы иметь больший контроль и доступные варианты, когда речь идет о детальном управлении доступом конечных пользователей. Кроме того, в настоящее время есть также значительная часть организаций, которые уже имеют ферму AD FS для других целей федерации и считают естественным шагом также использовать это решение для целей федерации AAD/Office 365.

Примечание:
Хотя основное внимание в этой статье уделяется Active Directory как поставщику удостоверений, Microsoft также поддерживает использование сторонних поставщиков удостоверений на основе SAML 2.0 для реализации единого входа (подробнее читайте здесь). Поставщики удостоверений на основе Shibboleth также поддерживаются, однако в таком сценарии поддерживается только ограниченный набор клиентов (подробнее читайте здесь).

Еще одна причина, по которой предпочтение отдается модели «Федеративные удостоверения», а не модели «Синхронизированные удостоверения с включенным хэшем паролей», заключается в том, чтобы предоставить конечным пользователям настоящее решение «единого входа» вместо решения «один и тот же вход». Правда, «единый вход» не подходит для всех сценариев клиентских версий (подробнее об этом далее в этой серии статей). Однако для организаций привлекательно то, что учетные данные Active Directory конечных пользователей используются для аутентификации в Azure Active Directory.

Рис. 1. Когда пользователь обращается к странице входа в AAD/Office 365, он перенаправляется в локальную службу федерации.

Рисунок 2: Страница входа в прокси-сервер веб-приложения

В модели «Федеративные удостоверения», когда пользователь пытается получить доступ к рабочей нагрузке Office 365, он получает маркер безопасности SAML от AD FS, который передается в Azure AD в качестве доказательства того, что ему разрешен доступ к соответствующей рабочей нагрузке, как показано на рисунке. следующую концептуальную схему. Когда дело доходит до Exchange Online, этот поток зависит от типа и версии клиента, хотя Exchange Online немного отличается, когда речь идет об аутентификации. Мы еще поговорим об этом позже в серии статей.

Рисунок 3: Процесс аутентификации Federated Identities

Как уже упоминалось, использование модели «федеративных удостоверений» имеет смысл для организаций, которым требуется больше контроля и возможностей, когда речь идет о детальном управлении доступом конечных пользователей, но вы должны иметь в виду, что для этой модели требуется как минимум четыре локальных сервера ( два сервера ADFS во внутренней сети и два сервера WAP в сети периметра). Хотя одного сервера AD FS и одного WAP-сервера достаточно в качестве конечной точки аутентификации для нескольких тысяч пользователей (конечно, в зависимости от параллелизма пользователей и т. д.), в AAD/Office 365 вам может потребоваться развернуть высокодоступную ферму федерации. Причина этого в том, что если служба федерации станет недоступной, ваши конечные пользователи не смогут пройти аутентификацию в AAD и по этой причине также не смогут получить доступ ни к одной из рабочих нагрузок Office 365, если вы не инициируете отработку отказа для синхронизации хэшей паролей. что в зависимости от вашей конкретной топологии может занять несколько часов.

Некоторые из наиболее важных причин, по которым вы хотите использовать модель «федеративных удостоверений», перечислены ниже:

• В организации уже есть ферма AD FS, и она хочет использовать ее для целей федерации AAD/Office 365.
• В организации уже есть смарт-карта или решение для многофакторной проверки подлинности (MFA), и она не хочет (или еще не готова) переключаться на решение MFA, предоставляемое Azure AD (требуется подписка Azure AD Premium).
• В организации действует политика безопасности, согласно которой хэш хэша локального пароля не должен синхронизироваться с клиентом AAD/Office 365.
• Организация хочет использовать функцию блокировки экстрасети AD FS для защиты пользователей в корпоративной сети от блокировки учетных записей AD и атак методом подбора пароля. Политика блокировки учетной записи Office 365 — это 10 неудачных попыток, после чего конечный пользователь принудительно проходит через диалоговое окно CAPTHA как часть входа в систему.
• Организация хочет иметь настоящее решение единого входа, а не одно и то же решение входа. Имейте в виду, однако, что настоящий SSO невозможен для многофункциональных клиентов (таких как клиент Outlook для настольных компьютеров), которые используют обычную проверку подлинности. Для Outlook 2013 и более поздних версий эту проблему можно решить, включив современную проверку подлинности (подробнее об этом далее в этой серии статей).
• Организация хочет контролировать, в какое время конечным пользователям разрешен доступ к рабочим нагрузкам Office 365, используя часы входа. Примечание. Лично я никогда не сталкивался с заказчиком с таким требованием.
• Организация хочет использовать политики клиентского доступа, чтобы контролировать, какие клиенты могут получать доступ к Office 365 в зависимости от местоположения (т. е. блокировать мобильный Outlook из внешней сети).
• Организация хочет, чтобы учетная запись пользователя, отключенная в Active Directory, «немедленно» отражалась для доступа к AAD/Office 365. Это произойдет не сразу, но быстрее, чем в случае с моделью «Синхронизированные удостоверения с включенным хэшем паролей».
• Организация хочет использовать условный доступ на основе AD FS (присоединение к рабочему месту, членство в группах, регистрация устройств, доступ на основе сертификатов и т. д.).
• Организация хочет включить уведомления об истечении срока действия пароля для конечных пользователей (будет отображаться на портале Office 365).
• Организация хочет использовать настраиваемые правила утверждений для более детального контроля аудита.
• Организация хочет предоставить конечным пользователям прозрачную процедуру входа в систему для веб-доступа к Office 365 с использованием смарт-ссылок.
• Организации требуются подробные сведения о попытках входа (аудит), которые будут регистрироваться в журнале событий Windows на серверах AD FS.
• Организация не может изменить/использовать имя участника-пользователя по мере необходимости и вместо этого хочет использовать альтернативные идентификаторы входа.

На этом завершается часть 2 этой статьи, состоящей из нескольких частей, в которой я расскажу вам о новой истории современной проверки подлинности и о том, как она влияет на клиентов, подключающихся к Exchange Online.

• Демистификация моделей идентификации Exchange Online и аутентификации (часть 3)
• Демистификация моделей идентификации Exchange Online и аутентификации (часть 4)
• Демистификация моделей идентификации Exchange Online и аутентификации (часть 5)
• Демистификация моделей идентификации Exchange Online и аутентификации (часть 6)
• Демистификация моделей идентификации Exchange Online и аутентификации (часть 7)