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

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

Введение

Во второй части этой серии статей, посвященной доступным моделям удостоверений и истории проверки подлинности для Exchange Online, я рассказал вам о третьей модели удостоверений, которая представляет собой федеративные удостоверения.

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

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

Аутентификация клиентов Exchange Online — прошлое и настоящее

Итак, как мы обсуждали в предыдущих двух частях этой серии статей, вы можете выбирать между тремя различными моделями идентификации. Облачные удостоверения, синхронизированные удостоверения с включенным хэшем паролей и федеративные удостоверения. В зависимости от выбранной модели при доступе к рабочей нагрузке Exchange Online вам потребуется:

• Выполняйте аутентификацию с помощью своих облачных учетных данных (UPN и пароль) при доступе к рабочей нагрузке.
• Выполните аутентификацию, используя свои облачные учетные данные (UPN и пароль), которые соответствуют локальным учетным данным AD (т.н. «такой же вход»)
• Автоматическая аутентификация с использованием локальных учетных данных AD при присоединении к домену и при подключении к домену (так называемая «единая регистрация»).

Однако когда речь идет о модели «федеративных удостоверений», в зависимости от клиента, а также от версии клиента, используемого для доступа к рабочей нагрузке Exchange Online, приведенное выше не обязательно соответствует действительности. Как вы знаете, мы можем получить доступ к нашему почтовому ящику, используя несколько разных клиентов. У нас есть клиент Outlook для настольных ПК, Outlook в Интернете (OotW), приложение Outlook для iOS и Android, клиенты на основе ActiveSync, клиенты IMAP/POP, клиенты SMTP и клиенты на основе протокола веб-служб Exchange (EWS), такие как Outlook для Мак.

Когда речь идет о разных клиентах, получающих доступ к рабочей нагрузке Exchange Online в модели «федеративных удостоверений», они используют разные конечные точки для проверки подлинности. У нас есть следующие конечные точки для аутентификации клиента Exchange:

Пассивная федерация (пассивные профили WS-Fed)

Эта конечная точка используется веб-клиентами или всеми клиентами, использующими новый современный метод проверки подлинности. Сейчас мы сосредоточимся на несовременной проверке подлинности, поэтому единственным клиентом Exchange Online, использующим эту конечную точку, является Outlook в Интернете (OotW). Клиент пассивного профиля, присоединенный к домену и расположенный во внутренней сети, проходит проверку подлинности непосредственно в локальной конечной точке AD FS (STS).

В частности, когда веб-клиент подключается к Outlook.office365.com либо путем перенаправления с локального URL-адреса OotW Exchange в сценарии гибридного развертывания, либо путем выбора заголовка приложения Outlook на портале Office, Exchange Online перенаправляет веб-клиент к конечной точке проверки подлинности в Azure Active Directory ( ).

Рис. 1. Веб-клиент перенаправлен с login.microsoftonline.com на локальную ферму AD FS

Конечная точка проверки подлинности Azure AD обнаружит, что домен UPN является федеративным, и выполнит еще одно перенаправление на внутреннюю локальную конечную точку AD FS (в моем случае « fs.azurelab.dk »), где AD FS потребует от клиента пройти проверку подлинности.

После проверки подлинности AD FS извлечет необходимую информацию, связанную с утверждениями, из Active Directory и предоставит веб-клиенту маркер, содержащий утверждения о пользователе. Клиент представит токен в Azure AD, и после успешной аутентификации веб-клиент будет перенаправлен обратно на « outlook.office365.com » и получит доступ к почтовому ящику через OotW.

Я попытался наглядно объяснить этот поток на концептуальной схеме ниже ( рис. 2 ).

Рисунок 2: Процесс аутентификации для присоединенных к домену клиентов пассивного профиля во внутренней сети

В случае, если клиент находится во внешней сети, будут применяться те же действия с той лишь разницей, что перенаправление на « fs.azurelab.dk » будет проходить через серверы прокси веб-приложения (WAP) на внутреннюю ферму AD FS, к которой внешняя DNS-запись для « fs.azurelab.dk » разрешится. Поскольку пользователь не аутентифицирован, ему необходимо пройти аутентификацию через страницу входа на серверах WAP. В противном случае применяются все шаги.

Рисунок 3: Страница входа в WAP

Поскольку и внутренний, и внешний клиент всегда будут нажимать « login.microsoftonline.com », клиент может запомнить имя участника-пользователя соответствующего пользователя ( рис. 4 ), чтобы ему не приходилось вводить его каждый раз при входе в систему. требуется для аутентификации.

Рис. 4. Имя участника-пользователя запоминается в веб-клиенте

Базовая аутентификация (базовые профили аутентификации)

Эта конечная точка используется клиентами, не основанными на браузере, или клиентами с несовременной проверкой подлинности, которые проходят проверку подлинности с помощью обычной проверки подлинности. Клиенты, такие как клиент Outlook Desktop, клиенты IMAP/POP, клиенты на основе Exchange ActiveSync (EAS), клиенты на основе веб-служб Exchange (EWS) и сеансы SMTP, защищенные TLS, используют обычную проверку подлинности. Общим для клиентов на основе обычной проверки подлинности является то, что Exchange Online выполняет проверку подлинности с помощью AD FS от имени клиента, также известную как проверка подлинности прокси.

В частности, клиент отправляет учетные данные для обычной проверки подлинности в Exchange Online через SSL/TLS ( outlook.office3365.com ), а затем Exchange Online отправляет учетные данные для проверки подлинности в Azure AD, используя нечто, называемое прокси-аутентификацией (прокси-аутентификация). Azure AD возвращает соответствующую конечную точку локальной фермы AD FS (в моем случае « fs.azurelab.dk ») в Exchange Online. Обратите внимание, что Exchange Online подключается к конечной точке через серверы WAP, а не напрямую. Затем внутренние серверы AD FS проходят проверку подлинности с помощью Active Directory и получают маркер входа, содержащий необходимые утверждения пользователя. Серверы AD FS отправляют этот токен в Exchange Online, который снова отправляет его в Azure AD. Azure AD возвращает его в Exchange Online в состоянии, в котором его можно использовать для проверки подлинности клиента.

Я попытался наглядно объяснить этот поток на концептуальной схеме ниже ( рис. 5 ).

Рисунок 5: Процесс аутентификации для клиентов на основе базовой аутентификации

Хотя эта серия статей посвящена специальной проверке подлинности Exchange Online, стоит упомянуть, что существует третья конечная точка, известная как конечная точка Active Federation (WS-Trust Active Profiles), которая используется так называемыми полноценными/MEX-клиентами. Это офисные приложения (в том числе Skype для бизнеса), но, конечно, кроме настольного клиента Outlook, о котором мы говорили выше. Эти клиенты используют помощник Microsoft Online Services Sign-In Assistant (SIA) при использовании Office 2010 или встроенные файлы SIA DLL при использовании Office 2013, чтобы предоставить конечному пользователю удобные возможности единого входа. В отличие от обычной проверки подлинности, эти клиенты проходят проверку подлинности непосредственно с помощью AD FS, поскольку теперь они используют серверы WAP.

Более пристальный взгляд на конечные точки подключения AD FS в локальной среде

Давайте подробнее рассмотрим конечные точки проверки подлинности, которые веб-клиенты (на основе браузера), профили клиентов Rich/MEX и Exchange Online (при использовании клиента обычной проверки подлинности) перенаправляются в локальную среду в сценарии федеративного удостоверения. Для этого мы подключимся к нашему арендатору AAD/Office 365 с помощью модуля Azure Active Directory PowerShell и выполним следующую команду:

В моей лабораторной среде они выглядят так, как показано на рисунке 6.

Рисунок 6: Параметры свойства федерации в арендаторе Exchange Online

Конечные точки AD FS (STS) на рис. 6 используются следующим образом:

• ActiveClientSignInUrl: используется https://fs.azurelab.dk/adfs/services/trust/2005/usernamemixed.
  клиентами на основе базовой аутентификации
• FederationMetadataUrl: https://fs.azurelab.dk/adfs/services/trust/mex используется клиентами Rich/MEX.
• PassiveClientSignInUrl: https://fs.azurelab.dk/adfs/ls/ используется веб-клиентами (на основе браузера) и клиентами с включенной современной проверкой подлинности (подробнее об этом позже).

Как видно из вышеизложенного, нам нужна более стандартизированная модель потока аутентификации, которая, как мы все согласны, сегодня довольно сложна. Процесс аутентификации, конечно, немного проще для нефедеративных сценариев, но, несомненно, в будущем потребуется более стандартизированный подход. И, как я упоминал во вступлении к первой статье, именно здесь в игру вступает специальная группа проверки подлинности клиентов Office, созданная почти два года назад. Начиная со следующей части этой серии статей, мы рассмотрим, что у них есть в рукаве.

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

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