В статье показано, как реализовать многофакторную проверку подлинности для классических клиентов Outlook, обращаюющихся к Microsoft Exchange. Существует четыре архитектуры, которые соответствуют четырем различным возможностям Microsoft Exchange с почтовым ящиком пользователя:
Примечание.
На схемах черные дефисы отображают основные взаимодействия между локальными компонентами Active Directory, Microsoft Entra Подключение, Идентификатором Microsoft Entra, AD FS и прокси-сервером веб-приложения. Вы можете узнать об этих взаимодействиях в гибридных удостоверениях, необходимых портам и протоколам.
Архитектура (Exchange Online)
Скачайте файл Visio всех схем в этой статье.
В этом сценарии пользователям необходимо использовать версию клиента Outlook, поддерживающую современную проверку подлинности. Дополнительные сведения см. в статье о том, как работает современная проверка подлинности для клиентских приложений Office 2013, Office 2016 и Office 2019. Эта архитектура охватывает Как Outlook для Windows, так и Outlook для Mac.
Рабочий процесс (Exchange Online)
- Пользователь пытается получить доступ к Exchange Online через Outlook.
- Exchange Online предоставляет URL-адрес конечной точки Microsoft Entra для получения маркера доступа для получения доступа к почтовому ящику.
- Outlook подключается к идентификатору Microsoft Entra с помощью этого URL-адреса.
- Как только домен федеративный, идентификатор Microsoft Entra перенаправляет запрос в локальную службу AD FS.
- Пользователь вводит учетные данные на странице входа AD FS.
- AD FS перенаправляет сеанс обратно в идентификатор Microsoft Entra.
- Идентификатор Microsoft Entra применяет политику условного доступа Azure с требованием многофакторной проверки подлинности для мобильных приложений и классических клиентов. Сведения о настройке этой политики см. в разделе развертывания этой статьи.
- Политика условного доступа вызывает многофакторную проверку подлинности Microsoft Entra. Пользователь получает запрос на завершение многофакторной проверки подлинности.
- Пользователь завершает многофакторную проверку подлинности.
- Идентификатор Microsoft Entra id выдает проблемы с доступом и обновлением маркеров и возвращает их клиенту.
- С помощью маркера доступа клиент подключается к Exchange Online и извлекает содержимое.
Конфигурация (Exchange Online)
Чтобы заблокировать попытки доступа к Exchange Online с помощью устаревшей проверки подлинности (красная дефишированная строка на схеме), необходимо создать политику проверки подлинности, которая отключает устаревшую проверку подлинности для протоколов, используемых службой Outlook. Это определенные протоколы, которые необходимо отключить: автообнаружения, MAPI, автономные адресные книги и EWS. Ниже приведена соответствующая конфигурация:
AllowBasicAuthAutodiscover: False
AllowBasicAuthMapi : False
AllowBasicAuthOfflineAddressBook : False
AllowBasicAuthWebServices: False
AllowBasicAuthRpc : False
Протокол удаленного вызова процедур (RPC) больше не поддерживается для Office 365, поэтому последний параметр не влияет на клиенты.
Ниже приведен пример команды для создания этой политики проверки подлинности:
New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -AllowBasicAuthRpc:$false -AllowBasicAuthMapi:$false -AllowBasicAuthAutodiscover:$false
-AllowBasicAuthWebServices:$false -AllowBasicAuthOfflineAddressBook:$false
Примечание.
По умолчанию после создания политики устаревшие проверки подлинности для всех других протоколов (например, IMAP, POP и ActiveSync) также отключены. Чтобы изменить это поведение, можно включить протоколы с помощью команды PowerShell, как показано ниже.
Set-AuthenticationPolicy -Identity BlockOutlook -AllowBasicAuthImap:$true
После создания политики проверки подлинности вы можете сначала назначить ее пилотной группе пользователей с помощью Set-User user01 -AuthenticationPolicy <name_of_policy> команды. После тестирования можно развернуть политику, чтобы включить всех пользователей. Чтобы применить политику на уровне организации, используйте Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> команду. Для этой конфигурации необходимо использовать Exchange Online PowerShell.
Архитектура (Exchange Online, AD FS)
Скачайте файл Visio всех схем в этой статье.
Этот сценарий совпадает с предыдущим, за исключением того, что он использует другой триггер для многофакторной проверки подлинности. В предыдущем сценарии мы использовали локальную ad FS для проверки подлинности. Затем мы перенаправили сведения об успешной проверке подлинности в идентификатор Microsoft Entra, где политика условного доступа применяет многофакторную проверку подлинности. В этом сценарии вместо использования условного доступа для применения многофакторной проверки подлинности мы создадим политику управления доступом на уровне AD FS и применяем многофакторную проверку подлинности. Остальная часть архитектуры совпадает с предыдущей.
Примечание.
Этот сценарий рекомендуется использовать только в том случае, если вы не сможете использовать предыдущий.
В этом сценарии пользователям необходимо использовать версию клиента Outlook, поддерживающую современную проверку подлинности. Дополнительные сведения см. в статье о том, как работает современная проверка подлинности для клиентских приложений Office 2013, Office 2016 и Office 2019. Эта архитектура охватывает Как Outlook для Windows, так и Outlook для Mac.
Рабочий процесс (Exchange Online, AD FS)
Пользователь пытается получить доступ к Exchange Online через Outlook.
Exchange Online предоставляет URL-адрес конечной точки Microsoft Entra для получения маркера доступа для получения доступа к почтовому ящику.
Outlook подключается к идентификатору Microsoft Entra с помощью этого URL-адреса.
Если домен федеративный, идентификатор Microsoft Entra перенаправляет запрос в локальную службу AD FS.
Пользователь вводит учетные данные на странице входа AD FS.
Отвечая на политику управления доступом AF DS, AD FS вызывает многофакторную проверку подлинности Microsoft Entra для завершения проверки подлинности. Ниже приведен пример политики управления доступом AD FS:
Пользователь получает запрос на завершение многофакторной проверки подлинности.
Пользователь завершает многофакторную проверку подлинности.
AD FS перенаправляет сеанс обратно в идентификатор Microsoft Entra.
Идентификатор Microsoft Entra id выдает проблемы с доступом и обновлением маркеров и возвращает их клиенту.
С помощью маркера доступа клиент подключается к Exchange Online и извлекает содержимое.
Конфигурация (Exchange Online, AD FS)
Примечание.
Политика управления доступом, реализованная на шаге 6, применяется на уровне доверия проверяющей стороны, поэтому она влияет на все запросы проверки подлинности для всех служб Office 365, которые проходят через AD FS. Для применения дополнительных фильтров можно использовать правила проверки подлинности AD FS. Однако мы рекомендуем использовать политику условного доступа (описанную в предыдущей архитектуре), а не использовать политику управления доступом AD FS для служб Microsoft 365. Предыдущий сценарий более распространен, и с его помощью вы можете добиться лучшей гибкости.
Чтобы заблокировать попытки доступа к Exchange Online с помощью устаревшей проверки подлинности (красная дефишированная строка на схеме), необходимо создать политику проверки подлинности, которая отключает устаревшую проверку подлинности для протоколов, используемых службой Outlook. Это определенные протоколы, которые необходимо отключить: автообнаружения, MAPI, автономные адресные книги и EWS. Ниже приведена соответствующая конфигурация:
AllowBasicAuthAutodiscover: False
AllowBasicAuthMapi : False
AllowBasicAuthOfflineAddressBook : False
AllowBasicAuthWebServices: False
AllowBasicAuthRpc : False
Протокол RPC больше не поддерживается для Office 365, поэтому последний параметр не влияет на клиенты.
Ниже приведен пример команды для создания этой политики проверки подлинности:
New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -AllowBasicAuthRpc:$false -AllowBasicAuthMapi:$false -AllowBasicAuthAutodiscover:$false
-AllowBasicAuthWebServices:$false -AllowBasicAuthOfflineAddressBook:$false
Архитектура (локальная среда Exchange)
Скачайте файл Visio всех схем в этой статье.
Эта архитектура охватывает Как Outlook для Windows, так и Outlook для Mac.
Рабочий процесс (локальная среда Exchange)
- Пользователь с почтовым ящиком на Exchange Server запускает клиент Outlook. Клиент Outlook подключается к Exchange Server и указывает, что он имеет современные возможности проверки подлинности.
- Exchange Server отправляет клиенту ответ, запрашивающий получение маркера из идентификатора Microsoft Entra.
- Клиент Outlook подключается к URL-адресу Microsoft Entra, предоставленному Exchange Server.
- Azure определяет, что домен пользователя федеративн, поэтому он отправляет запросы в AD FS (через прокси веб-приложения).
- Пользователь вводит учетные данные на странице входа AD FS.
- AD FS перенаправляет сеанс обратно в идентификатор Microsoft Entra.
- Идентификатор Microsoft Entra применяет политику условного доступа Azure с требованием многофакторной проверки подлинности для мобильных приложений и классических клиентов. Сведения о настройке этой политики см. в разделе развертывания этой статьи.
- Политика условного доступа вызывает многофакторную проверку подлинности Microsoft Entra. Пользователь получает запрос на завершение многофакторной проверки подлинности.
- Пользователь завершает многофакторную проверку подлинности.
- Идентификатор Microsoft Entra id выдает проблемы с доступом и обновлением маркеров и возвращает их клиенту.
- Пользователь представляет маркер доступа к Exchange Server, а Exchange разрешает доступ к почтовому ящику.
Конфигурация (локальная среда Exchange)
Чтобы заблокировать попытки доступа к локальной среде Exchange через устаревшую проверку подлинности (красная дефисовая строка на схеме), необходимо создать политику проверки подлинности, которая отключает устаревшую проверку подлинности для протоколов, используемых службой Outlook. Это определенные протоколы, которые необходимо отключить: автообнаружения, MAPI, автономные адресные книги, EWS и RPC. Ниже приведена соответствующая конфигурация:
BlockLegacyAuthAutodiscover: True
BlockLegacyAuthMapi : True
BlockLegacyAuthOfflineAddressBook : True
BlockLegacyAuthRpc : True
BlockLegacyAuthWebServices: True
Протокол RPC не поддерживает современную проверку подлинности, поэтому он не поддерживает многофакторную проверку подлинности Microsoft Entra. Корпорация Майкрософт рекомендует протокол MAPI для клиентов Outlook для Windows.
Ниже приведен пример команды для создания этой политики проверки подлинности:
New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -BlockLegacyAuthAutodiscover -BlockLegacyAuthMapi -BlockLegacyAuthOfflineAddressBook -BlockLegacyAuthRpc
После создания политики проверки подлинности вы можете сначала назначить ее пилотной группе пользователей с помощью Set-User user01 -AuthenticationPolicy <name_of_policy> команды. После тестирования можно развернуть политику, чтобы включить всех пользователей. Чтобы применить политику на уровне организации, используйте Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> команду. Для этой конфигурации необходимо использовать Локальную среду Exchange PowerShell.
Архитектура (локальная среда Exchange, AD FS)
Скачайте файл Visio всех схем в этой статье.
Этот сценарий похож на предыдущий. Однако в этом сценарии многофакторная проверка подлинности активируется AD FS. Эта архитектура охватывает Как Outlook для Windows, так и Outlook для Mac.
Примечание.
Этот сценарий рекомендуется использовать только в том случае, если вы не можете использовать предыдущий.
Рабочий процесс (Локальная среда Exchange, AD FS)
Пользователь запускает клиент Outlook. Клиент подключается к Exchange Server и указывает, что он имеет современные возможности проверки подлинности.
Exchange Server отправляет клиенту ответ, запрашивающий получение маркера из идентификатора Microsoft Entra. Exchange Server предоставляет клиенту URL-адрес идентификатора Microsoft Entra.
Клиент использует URL-адрес для доступа к идентификатору Microsoft Entra.
В этом сценарии домен федеративный. Идентификатор Microsoft Entra перенаправляет клиент в AD FS через прокси-сервер веб-приложения.
Пользователь вводит учетные данные на странице входа AD FS.
AD FS активирует многофакторную проверку подлинности. Ниже приведен пример политики управления доступом AD FS:
Пользователь получает запрос на завершение многофакторной проверки подлинности.
Пользователь завершает многофакторную проверку подлинности.
AD FS перенаправляет сеанс обратно в идентификатор Microsoft Entra.
Идентификатор Microsoft Entra выдает проблемы с доступом и обновлением маркеров для пользователя.
Клиент представляет маркер доступа к локальному серверу Exchange. Exchange разрешает доступ к почтовому ящику пользователя.
Конфигурация (локальная среда Exchange, AD FS)
Примечание.
Политика управления доступом, реализованная на шаге 6, применяется на уровне доверия проверяющей стороны, поэтому она влияет на все запросы проверки подлинности для всех служб Office 365, которые проходят через AD FS. Для применения дополнительных фильтров можно использовать правила проверки подлинности AD FS. Однако мы рекомендуем использовать политику условного доступа (описанную в предыдущей архитектуре), а не использовать политику управления доступом AD FS для служб Microsoft 365. Предыдущий сценарий более распространен, и с его помощью вы можете добиться лучшей гибкости.
Чтобы заблокировать попытки доступа к локальной среде Exchange через устаревшую проверку подлинности (красная дефисовая строка на схеме), необходимо создать политику проверки подлинности, которая отключает устаревшую проверку подлинности для протоколов, используемых службой Outlook. Это определенные протоколы, которые необходимо отключить: автообнаружения, MAPI, автономные адресные книги, EWS и RPC. Ниже приведена соответствующая конфигурация:
BlockLegacyAuthAutodiscover: True
BlockLegacyAuthMapi : True
BlockLegacyAuthOfflineAddressBook : True
BlockLegacyAuthRpc : True
BlockLegacyAuthWebServices: True
Протокол RPC не поддерживает современную проверку подлинности, поэтому он не поддерживает многофакторную проверку подлинности Microsoft Entra. Корпорация Майкрософт рекомендует протокол MAPI для клиентов Outlook для Windows.
Ниже приведен пример команды для создания этой политики проверки подлинности:
New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -BlockLegacyAuthAutodiscover -BlockLegacyAuthMapi -BlockLegacyAuthOfflineAddressBook -BlockLegacyAuthRpc
После создания политики проверки подлинности вы можете сначала назначить ее пилотной группе пользователей с помощью Set-User user01 -AuthenticationPolicy <name_of_policy> команды. После тестирования можно развернуть политику, чтобы включить всех пользователей. Чтобы применить политику на уровне организации, используйте Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> команду. Для этой конфигурации необходимо использовать Локальную среду Exchange PowerShell.
Компоненты
- Идентификатор Microsoft Entra. Идентификатор Microsoft Entra — это облачная служба управления удостоверениями и доступом Майкрософт. Она обеспечивает современную проверку подлинности, которая, по сути, основана на EvoSTS (службе маркеров безопасности, используемой идентификатором Microsoft Entra). Он используется в качестве сервера проверки подлинности для локальной среды Exchange Server.
- Многофакторная проверка подлинности Microsoft Entra. Многофакторная проверка подлинности — это процесс, в котором пользователи запрашиваются во время входа в другую форму идентификации, например код на мобильном телефоне или сканирование отпечатков пальцев.
- Условный доступ Microsoft Entra. Условный доступ — это функция, которую идентификатор Microsoft Entra использует для применения политик организации, таких как многофакторная проверка подлинности.
- AD FS. AD FS обеспечивает федеративное управление удостоверениями и доступом путем совместного использования цифровых удостоверений и прав на права в пределах безопасности и корпоративных границ с улучшенной безопасностью. В этих архитектурах используется для упрощения входа для пользователей с федеративными удостоверениями.
- Прокси веб-приложения. Прокси-сервер веб-приложения предварительно проверяет подлинность доступа к веб-приложениям с помощью AD FS. Он также работает в качестве прокси-сервера AD FS.
- Microsoft Intune. Intune — это облачное управление унифицированных конечных точек, управление конечными точками в операционных системах Windows, Android, Mac, iOS и Linux.
- Exchange Server. Exchange Server размещает почтовые ящики пользователей в локальной среде. В этих архитектурах используется маркеры, выданные пользователю идентификатором Microsoft Entra, для авторизации доступа к почтовым ящикам.
- Службы Active Directory. Службы Active Directory хранят сведения о членах домена, включая устройства и пользователей. В этих архитектурах учетные записи пользователей принадлежат службам Active Directory и синхронизируются с идентификатором Microsoft Entra.
- Outlook для бизнеса. Outlook — это клиентское приложение, которое поддерживает современную проверку подлинности.
Подробности сценария
Корпоративная инфраструктура обмена сообщениями (EMI) — это ключевая служба для организаций. Переход от более старых, менее безопасных методов проверки подлинности и авторизации к современной проверке подлинности является критической проблемой в мире, в котором распространена удаленная работа. Реализация требований к многофакторной проверке подлинности для доступа к службе обмена сообщениями является одним из наиболее эффективных способов удовлетворения этой проблемы.
В этой статье описывается четыре архитектуры для повышения безопасности в сценарии доступа к классическому клиенту Outlook с помощью многофакторной проверки подлинности Microsoft Entra.
Это четыре архитектуры в соответствии с четырьмя разными возможностями Microsoft Exchange:
Все четыре архитектуры охватывают Outlook для Windows и Outlook для Mac.
Сведения о применении многофакторной проверки подлинности в других сценариях гибридного обмена сообщениями см. в следующих статьях:
- Инфраструктура гибридного обмена сообщениями с расширенной безопасностью в сценарии веб-доступа
- Инфраструктура гибридного обмена сообщениями с расширенной безопасностью в сценарии мобильного доступа
В этой статье не рассматриваются другие протоколы, такие как IMAP или POP. Как правило, эти сценарии не используют эти протоколы.
Общие примечания
- Эти архитектуры используют федеративную модель удостоверений Microsoft Entra. Для синхронизации хэша паролей и моделей сквозной проверки подлинности логика и поток одинаковы. Единственное различие связано с тем, что идентификатор Microsoft Entra id не перенаправляет запрос проверки подлинности в службы федерации локальная служба Active Directory (AD FS).
- В локальной среде Exchange мы имеем в виду Exchange 2019 с последними обновлениями и ролью почтового ящика.
- В реальной среде у вас не будет только одного сервера. У вас будет массив серверов Exchange с балансировкой нагрузки для обеспечения высокой доступности. Описанные здесь сценарии подходят для этой конфигурации.
Потенциальные варианты использования
Эта архитектура относится к следующим сценариям:
- Повышение безопасности EMI.
- Примите стратегию безопасности нулевого доверия.
- Примените стандартный высокий уровень защиты для локальной службы обмена сообщениями во время перехода к Exchange Online или сосуществования.
- Применение строгих требований к безопасности или соответствию требованиям в закрытых или высокозащищенных организациях, таких как в финансовом секторе.
Рекомендации
Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, которая является набором руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.
Надежность
Надежность гарантирует, что ваше приложение может выполнять обязательства, которые вы выполняете вашим клиентам. Дополнительные сведения см. в разделе "Обзор основы надежности".
Доступность
Общая доступность зависит от доступности участвующих компонентов. Сведения о доступности см. в следующих ресурсах:
- Продвижение доступности Microsoft Entra
- Облачные службы, которым можно доверять: доступность Office 365
- Что такое архитектура Microsoft Entra?
Доступность локальных компонентов решения зависит от реализации проектирования, доступности оборудования и внутренних операций и процедур обслуживания. Сведения о доступности некоторых из этих компонентов см. в следующих ресурсах:
- Настройка развертывания AD FS с помощью групп доступности AlwaysOn
- Развертывание высокого уровня доступности и устойчивости сайта в Exchange Server
- Прокси-служба веб-приложения в Windows Server 2016
Чтобы использовать гибридную современную проверку подлинности, необходимо убедиться, что все клиенты в сети могут получить доступ к идентификатору Microsoft Entra. Кроме того, необходимо постоянно поддерживать порты брандмауэра Office 365 и открытия диапазона IP-адресов.
Требования к протоколам и портам для Exchange Server см. в статье "Требования к клиенту и протоколу Exchange" в обзоре гибридной современной проверки подлинности для использования с локальными Skype для бизнеса и серверами Exchange.
Диапазоны и порты IP-адресов Office 365 см. в разделе URL-адреса и диапазоны IP-адресов Office 365.
Дополнительные сведения о гибридной современной проверке подлинности и мобильных устройствах см. в статье о конечной точке AutoDetect в других конечных точках, не включенных в веб-службу IP-адреса и URL-адреса Office 365.
Устойчивость
Сведения о устойчивости компонентов в этой архитектуре см. в следующих ресурсах.
- Для идентификатора Microsoft Entra: повышение доступности Microsoft Entra
- Для сценариев, использующих AD FS: развертывание AD FS с высокой доступностью между географическими регионами AD FS в Azure с Диспетчер трафика Azure
- Для локального решения Exchange: высокий уровень доступности Exchange
Безопасность
Безопасность обеспечивает гарантии от преднамеренного нападения и злоупотребления ценными данными и системами. Дополнительные сведения см. в разделе "Общие сведения о компоненте безопасности".
Дополнительные сведения о безопасности и гибридной современной проверке подлинности см. в статье "Подробное руководство. Как работает гибридная проверка подлинности".
Для закрытых организаций, имеющих традиционную надежную защиту периметра, существуют проблемы безопасности, связанные с гибридными классическими конфигурациями Exchange. Гибридная конфигурация Exchange Hybrid Modern не поддерживает гибридную современную проверку подлинности.
Сведения об идентификаторе Microsoft Entra см . в руководстве по операциям безопасности Microsoft Entra.
Сведения о сценариях, использующих безопасность AD FS, см. в следующих статьях:
- Рекомендации по защите AD FS и прокси-сервера веб-приложений
- Настройка смарт-блокировки экстрасети AD FS
Оптимизация затрат
Оптимизация затрат заключается в поиске способов уменьшения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в разделе Обзор критерия "Оптимизация затрат".
Стоимость реализации зависит от стоимости лицензии Microsoft Entra ID и лицензий Microsoft 365. Общая стоимость также включает затраты на программное обеспечение и оборудование для локальных компонентов, ИТ-операций, обучения и образования, а также реализации проектов.
Для этих решений требуется по крайней мере идентификатор Microsoft Entra ID P1. Сведения о ценах см. в разделе о ценах Microsoft Entra.
Дополнительные сведения о AD FS и прокси-сервере веб-приложения см. в разделе "Цены и лицензирование" для Windows Server 2022.
Дополнительные сведения о ценах см. в следующих ресурсах:
Уровень производительности
Эффективность производительности — это возможность масштабирования рабочей нагрузки в эффективном режиме для удовлетворения требований, которые ваши пользователи размещают на нем. Дополнительные сведения см. в разделе "Общие сведения о эффективности производительности".
Производительность рабочей нагрузки зависит от производительности компонентов, участвующих и от производительности сети. Дополнительные сведения см. в статье о настройке производительности Office 365 с использованием базовых показателей и журнала производительности.
Сведения о локальных факторах, влияющих на производительность сценариев, включающих службы AD FS, см. в следующих ресурсах:
Сведения о масштабируемости AD FS см. в разделе "Планирование емкости сервера AD FS".
Сведения о локальной масштабируемости Exchange Server см . в статье Об предпочтительной архитектуре Exchange 2019.
Развертывание этого сценария
Ниже приведены основные действия.
- Защита доступа к рабочему столу Outlook путем настройки гибридной конфигурации Exchange и включения гибридной современной проверки подлинности.
- Блокировать все устаревшие попытки проверки подлинности на уровне идентификатора Microsoft Entra. Блокировать устаревшие попытки проверки подлинности на уровне служб обмена сообщениями с помощью политики проверки подлинности.
Настройка политики условного доступа
Чтобы настроить политику условного доступа Microsoft Entra, которая обеспечивает многофакторную проверку подлинности, как описано в некоторых архитектурах в этой статье:
В окне "Клиенты" выберите мобильные приложения и классические клиенты:
Примените требование многофакторной проверки подлинности в окне Grant :
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник.
Основные авторы:
- Павел Кондрашов | Архитектор облачных решений
- Элла Паркум | Главный архитектор решения клиента— проектирование
Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.
Следующие шаги
- Объявление о гибридной современной проверке подлинности для локальной среды Exchange
- Общие сведения о гибридной современной проверке подлинности и предварительные требования для использования с локальными серверами Exchange
- Использование проверки подлинности на основе утверждений AD FS с Outlook в Интернете
- Как настроить локальную версию Exchange Server для использования гибридной современной проверки подлинности
- Предпочитаемая архитектура Exchange 2019
- Развертывание AD FS с высоким уровнем доступности в нескольких регионах Azure с помощью диспетчера трафика Azure
- Использование гибридной современной проверки подлинности с Outlook для iOS и Android
- Настройка учетной записи с современной проверкой подлинности в Exchange Online