Этап 1. Определение модели удостоверений в облаке

Microsoft 365 использует Azure Active Directory (Azure AD), облачную службу удостоверений пользователей и проверки подлинности, которая входит в вашу подписку Microsoft 365, для управления удостоверениями и проверкой подлинности для Microsoft 365. Правильная настройка инфраструктуры удостоверений крайне важна для управления Microsoft 365 доступа пользователей и разрешений для вашей организации.

Перед началом работы посмотрите это видео с обзором моделей удостоверений и проверки подлинности для Microsoft 365.

Первым вариантом планирования является модель удостоверений в облаке.

Модели облачных удостоверений Майкрософт

Чтобы спланировать учетные записи пользователей, сначала необходимо ознакомиться с двумя моделями удостоверений в Microsoft 365. Вы можете хранить удостоверения организации только в облаке или сохранять удостоверения доменных служб локальная служба Active Directory (AD DS) и использовать их для проверки подлинности при доступе пользователей к Microsoft 365 облачным службам.

Ниже приведены два типа удостоверений, а также их наилучшее размещение и преимущества.

Атрибут Облачное удостоверение Гибридное удостоверение
Определение Учетная запись пользователя существует только в клиенте Azure AD для Microsoft 365 подписки. Учетная запись пользователя существует в AD DS, а копия также находится в клиенте Azure AD для Microsoft 365 подписки. Учетная запись пользователя в Azure AD также может содержать хэшированные версии уже хэшированных паролей учетной записи пользователя AD DS.
Как Microsoft 365 аутентификацию учетных данных пользователя Клиент Azure AD для вашей Microsoft 365 выполняет проверку подлинности с помощью учетной записи облачного удостоверения. Клиент Azure AD для вашей Microsoft 365 либо обрабатывает процесс проверки подлинности, либо перенаправляет пользователя к другому поставщику удостоверений.
Оптимально для. Организации, которым не требуется локальная служба AD DS. Организации, использующие AD DS или другой поставщик удостоверений.
Наибольшее преимущество Простое в использовании. Дополнительные средства каталога или серверы не требуются. Пользователи могут использовать те же учетные данные при доступе к локальным или облачным ресурсам.

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

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

Ниже приведены основные компоненты облачного удостоверения.

Основные компоненты облачного удостоверения.

Как локальные, так и удаленные (сетевые) пользователи используют свои учетные записи пользователей и пароли Azure AD для доступа Microsoft 365 облачных служб. Azure AD проверяет подлинность учетных данных на основе хранимых на этой платформе учетных записей и паролей.

Администрирование

Так как учетные записи пользователей хранятся только в Azure AD, вы управляете облачными удостоверениями с помощью таких средств, как Центр администрирования Microsoft 365 и Windows PowerShell.

Гибридное удостоверение

Гибридное удостоверение использует учетные записи, которые происходят из локальной службы AD DS и имеют копию в клиенте Azure AD Microsoft 365 подписки. Большинство изменений, за исключением определенных атрибутов учетной записи, перечислены только в одном из способов. Изменения, внесенные в учетные записи пользователей AD DS, синхронизируются с их копией в Azure AD.

Azure AD Подключение обеспечивает текущую синхронизацию учетных записей. Он выполняется на локальном сервере, проверяет наличие изменений в AD DS и пересылает эти изменения в Azure AD. Azure AD Подключение позволяет фильтровать синхронизированные учетные записи и необходимость синхронизации хэшированных версий паролей пользователей, известных как синхронизация хэша паролей (PHS).

При использовании гибридного удостоверения авторитетным источником сведений об учетной записи является локальная система AD DS. Это означает, что задачи администрирования выполняются в основном локально, которые затем синхронизируются с Azure AD.

Ниже приведены компоненты гибридной идентификации.

Компоненты гибридной идентификации.

У клиента Azure AD есть копия учетных записей AD DS. В этой конфигурации как локальные, так и удаленные пользователи, которые Microsoft 365 облачные службы, будут выполнять проверку подлинности в Azure AD.

Примечание

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

Гибридная синхронизация удостоверений и каталогов для Microsoft 365

В зависимости от бизнес-потребностей и технических требований модель гибридной идентификации и синхронизация каталогов является наиболее распространенным вариантом для корпоративных клиентов, которые внедряют Microsoft 365. Синхронизация каталогов позволяет управлять удостоверениями в доменные службы Active Directory (AD DS), а все обновления учетных записей пользователей, групп и контактов синхронизируются с клиентом Azure Active Directory (Azure AD) подписки Microsoft 365.

Примечание

Когда учетные записи пользователей AD DS синхронизируются в первый раз, им не назначается лицензия Microsoft 365 и они не могут получить доступ к Microsoft 365, например электронной почте. Сначала необходимо назначить им расположение для использования. Затем назначьте лицензию этим учетным записям пользователей по отдельности или динамически с помощью членства в группе.

Проверка подлинности для гибридной идентификации

Существует два типа проверки подлинности при использовании гибридной модели идентификации:

  • Управляемая проверка подлинности.

    Azure AD обрабатывает процесс проверки подлинности с помощью локально хранимой хэшированной версии пароля или отправляет учетные данные локальному агенту программного обеспечения для проверки подлинности локальной службой AD DS.

  • Федеративная проверка подлинности

    Azure AD перенаправляет клиентский компьютер, запрашивая проверку подлинности, другому поставщику удостоверений.

Управляемая проверка подлинности.

Существует два типа управляемой проверки подлинности:

  • Синхронизация хэша паролей (PHS)

    Проверка подлинности выполняется с помощью Azure AD.

  • Сквозная проверка подлинности (PTA)

    Проверка подлинности выполняется с помощью доменных служб Aсtive Directory в Azure AD.

Синхронизация хэша паролей (PHS)

С помощью PHS вы синхронизируете учетные записи пользователей AD DS с Microsoft 365 и управляете пользователями в локальной среде. Хэши паролей пользователей синхронизируются из AD DS в Azure AD, чтобы пользователи могли использовать одинаковый пароль локально и в облаке. Это самый простой способ включить проверку подлинности для удостоверений AD DS в Azure AD.

Синхронизация хэша паролей (PHS).

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

Дополнительные сведения см. в статье о выборе правильного метода проверки подлинности.

Сквозная проверка подлинности (PTA)

PTA обеспечивает простую проверку паролей для служб проверки подлинности Azure AD с помощью агента программного обеспечения, запущенного на одном или нескольких локальных серверах, для проверки пользователей непосредственно с помощью AD DS. С помощью PTA вы синхронизируете учетные записи пользователей AD DS с Microsoft 365 и управляете пользователями в локальной среде.

Сквозная проверка подлинности (PTA).

PTA позволяет пользователям входить в локальные и Microsoft 365 ресурсы и приложения с помощью локальной учетной записи и пароля. Эта конфигурация проверяет пароли пользователей непосредственно в локальной службе AD DS без хранения хэша паролей в Azure AD.

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

Дополнительные сведения см. в статье о выборе правильного метода проверки подлинности.

Федеративная проверка подлинности

Федеративная проверка подлинности в основном предназначена для крупных корпоративных организаций с более сложными требованиями к проверке подлинности. Удостоверения доменных служб Active Directory синхронизируются с Microsoft 365, а учетные записи пользователей управляются локально. При федеративной проверке подлинности пользователи имеют одинаковый пароль локально и в облаке, и им не нужно повторно входить в систему, чтобы использовать Microsoft 365.

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

Дополнительные сведения см. в статье о выборе правильного метода проверки подлинности.

Для сторонних поставщиков проверки подлинности и удостоверений локальные объекты каталогов могут быть синхронизированы с доступом к Microsoft 365 и облачным ресурсам, которыми в основном управляет сторонний поставщик удостоверений (IdP). Если ваша организация использует стороннее решение федерации, вы можете настроить вход в это решение для Microsoft 365 при условии, что стороннее решение федерации совместимо с Azure AD.

Дополнительные сведения см. в списке совместимости федерации Azure AD .

Администрирование

Так как исходные и полномочные учетные записи пользователей хранятся в локальной службе AD DS, вы управляете удостоверениями с помощью тех же средств, что и для управления AD DS.

Для управления синхронизированными учетными записями пользователей в Azure AD не Центр администрирования Microsoft 365 powerShell или PowerS Microsoft 365 hell.

Следующий этап

Защита привилегированных Microsoft 365 учетных записей

Перейдите к шагу 2, чтобы защитить учетные записи глобального администратора.