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

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

Введение

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

Когда дело доходит до улучшения истории аутентификации, бизнес-группа Office 365 действительно прислушивалась к отзывам клиентов, полученным за последние пару лет, и хотя мы не видели много изменений, если вы спросите меня, слишком долго, это не так. означает, что внутри Microsoft ничего не происходит. На самом деле команда была собрана, чтобы сосредоточиться только на улучшении истории аутентификации для пользователей/клиентов Exchange Online и пользователей/клиентов рабочей нагрузки Office 365 в целом.

Примечание:
Хотя большая часть материала, который мы рассмотрим в этой серии статей, также применима к некоторым другим рабочим нагрузкам Office 365, наше основное внимание будет сосредоточено на рабочей нагрузке Exchange Online.

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

Начиная с основ — модели идентичности

Итак, как многие из нас знают, рабочие нагрузки, включенные в предложение «Программное обеспечение как услуга» (SaaS) для Office 365, на самом деле являются просто рабочими нагрузками, включенными в арендаторе Azure Active Directory (AAD). Это означает, что подготовленные объекты (облачные удостоверения или синхронизированные пользователи) хранятся в клиенте AAD, а проверка подлинности выполняется в отношении соответствующих конечных точек проверки подлинности AAD. По этой причине одно из очень фундаментальных и важных решений, которое вам нужно принять, касается того, какую модель идентичности использовать в организации.

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

Рисунок 1: Концептуальная схема трех доступных моделей идентификации

Облачные удостоверения

Первая модель удостоверений — это облачные удостоверения, в которых пользователи подготавливаются непосредственно в клиенте AAD/Office 365 с помощью портала Office 365 или Azure. Портал также поддерживает групповую подготовку пользователей на основе файла CSV, содержащего до 250 пользователей. Для более сложных требований к подготовке вы, конечно, также можете использовать Azure Active Directory PowerShell для процесса подготовки.

Рис. 2. Пользователи, подготовленные непосредственно в арендаторе

Основное преимущество модели облачной идентификации заключается в том, что вам не нужно вносить какие-либо изменения или развертывать новые серверы в локальной инфраструктуре.

Рис. 3. Аутентификация для модели «Cloud Identities»

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

• Малые предприятия, у которых еще нет локальной службы Active Directory. Поскольку модель облачной идентификации не требует развертывания каких-либо серверов в локальной среде, предприятия могут быстро приступить к работе.
• Крупные предприятия, которые хотят попробовать Exchange Online и другие рабочие нагрузки Office 365, не внося существенных изменений в локальную Active Directory. Если вы пройдете этот сценарий, вы сможете позже перейти на одну из других моделей удостоверений, если это необходимо. Это делается путем сопоставления удостоверений облачных пользователей с соответствующими локальными пользователями Active Directory с использованием мягкого сопоставления на основе SMTP.
• Предприятия с числом пользователей почтовых ящиков до 2 000, которые по той или иной причине хотят перейти с локального Exchange на Exchange Online с помощью прямой миграции. Сам процесс прямой миграции включает подготовку пользователей в арендаторе. Как уже упоминалось, сквозная миграция поддерживает до 2000 почтовых ящиков пользователей, но это ограничение можно обойти, скрыв пользователей из глобального списка адресов или если вы имеете дело со слиянием нескольких локальных каталогов Active Directory в один AAD/Office. 365 арендатор. Если вы выполните этот сценарий, вы сможете позже перейти к одной из других моделей удостоверений, используя тот же метод, что и в предыдущем сценарии.

Если вы имеете дело с крупным предприятием, которое уже сильно зависит от Active Directory, вам не следует использовать облачные удостоверения, если только вы не соответствуете одному из приведенных выше сценариев. Введение дополнительного набора учетных данных для ваших конечных пользователей — это движение в неправильном направлении, поскольку им нужно не только использовать разные пароли и, как правило, также имя пользователя, поскольку большинство конечных пользователей на крупных предприятиях по-прежнему используют имя учетной записи SAM (доменпсевдоним) для аутентификации. целях против локальной Active Directory. Клиент AAD/Office 365 ожидает, что конечный пользователь пройдет проверку подлинности с именем участника-пользователя (UPN) в форме «[электронная почта защищена]».

Синхронизированные удостоверения с включенной синхронизацией хэшей паролей

Вторая модель удостоверений — это синхронизированные удостоверения, при которых существующие пользователи в локальной Active Directory синхронизируются с клиентом AAD/Office 365 с помощью средства синхронизации каталогов. На сегодняшний день существует три инструмента синхронизации каталогов Microsoft. У нас есть первый выпущенный файл под названием «DirSync», который все еще полностью поддерживается, и тот, который будет загружен, если вы выполните шаги на портале Office 365. Второй инструмент — это Azure AD Sync (AADSync), который был выпущен для предоставления инструмента, поддерживающего сценарии с несколькими лесами и многое другое. Хотя инструмент AADSync по-прежнему поддерживается корпорацией Майкрософт, загрузить его больше невозможно, так как он был заменен третьим выпущенным инструментом. Третий инструмент называется Azure AD Connect (AADConnect) и является рекомендуемым инструментом синхронизации каталогов в будущем, поскольку именно здесь будут использоваться ресурсы. AADConnect поддерживает все функции, включенные в инструмент AADSync, и многое другое. Кроме того, мастер установки включает шаги по настройке серверов AD FS в вашей локальной среде, если вы хотите использовать федеративные удостоверения.

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

Рисунок 4: Включение синхронизации хэшей паролей

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

Если вы имеете дело с очень большой организацией, вам также может понадобиться использовать выделенную базу данных SQL, поскольку локальный экземпляр SQL Express, установленный по умолчанию, поддерживает «только» до 100 000 синхронизированных объектов (включая пользователей, группы и контакты).

Рисунок 5: Пользователи, синхронизированные из локальной Active Directory

Основное преимущество использования этой модели удостоверений по сравнению с облачными удостоверениями заключается в том, что пользователи будут автоматически подготовлены с помощью инструмента синхронизации каталогов и смогут использовать тот же набор учетных данных, который они уже используют в своей локальной Active Directory, что не приведет к «единый вход», но сценарий «один и тот же вход», когда объект пользователя и пароли управляются в локальной Active Directory. В сценарии «такой же регистрации» конечный пользователь, как уже упоминалось, сможет использовать свои существующие учетные данные, но ему необходимо пройти аутентификацию при доступе к рабочей нагрузке Office 365.

Рисунок 6: Процесс аутентификации для модели «Синхронизированные удостоверения с включенной синхронизацией хэшей паролей»

При проверке подлинности будет создан файл cookie, поэтому пользователю необходимо пройти проверку подлинности только при первом доступе к рабочей нагрузке Office 365 в течение рабочего дня. В этом случае файл cookie обычно сохраняется. Однако это, конечно, зависит от конкретных пользовательских шаблонов в организации.

Также стоит упомянуть, что пользователь не может использовать имя своей учетной записи SAM для доступа к рабочим нагрузкам Office 365, вместо этого ему необходимо использовать свое имя участника-пользователя (UPN), что означает, что конечный пользователь может увидеть его как предоставленное с новым именем пользователя как он обычно использует имя своей учетной записи SAM для аутентификации на основе Active Directory.

В отличие от атрибутов пользователя в локальном объекте Active Directory, которые в случае изменения синхронизируются средством синхронизации каждые три часа, пароль пользователя проверяется каждую вторую минуту и синхронизируется в случае изменения пароля.

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

Синхронизированные удостоверения с включенной синхронизацией паролей в первую очередь предназначены для:

• Малые и крупные предприятия, которые уже имеют локальную службу Active Directory и хотят, чтобы конечные пользователи получали автоматическую подготовку, а также управляли пользователями в локальной службе Active Directory, а также разрешали конечным пользователям использовать свой существующий пароль Active Directory (через тот же вход). метод on) для доступа к рабочим нагрузкам Office 365. Все это без необходимости внесения серьезных изменений в локальную инфраструктуру, как при развертывании только одного локального сервера.
• Крупные предприятия, которые хотят опробовать Exchange Online и другие рабочие нагрузки Office 365, не внося существенных изменений в локальную Active Directory. Если вы пройдете этот сценарий, вы сможете позже перейти к модели федеративных удостоверений, если это необходимо. Это делается путем сопоставления идентификаторов облачных пользователей с соответствующими локальными пользователями Active Directory с использованием жесткого сопоставления с помощью «ImmutableID» или мягкого сопоставления на основе SMTP.

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

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