Skype for Business topologies supported with Modern Authentication
В этой статье перечислены облачные и локальные топологии, которые поддерживает современная проверка подлинности в Skype для бизнеса, а также средства безопасности, применимые к каждой из них.
Современная проверка подлинности в Skype для бизнеса
В Skype для бизнеса можно использовать преимущества современной проверки подлинности. Так как Skype для бизнеса работает в тесном контакте с Exchange, поведение входа Skype для бизнеса клиентских пользователей также будет зависеть от состояния ma exchange. Это также применимо, если используется гибридное развертывание Skype для бизнеса с разделенными доменами. Переменных компонентов очень много, но в данном случае целью является упрощенное представление списка поддерживаемых топологий.
Какие топологии поддерживаются современной проверкой подлинности в Skype для бизнеса, Skype для бизнеса Online, Exchange Server и Exchange Online?
Топологии, поддерживаемые современной проверкой подлинности в Skype для бизнеса
Потенциально существует два серверных приложения и две рабочие нагрузки Microsoft 365 или Office 365, связанные с Skype для бизнеса топологиями, используемыми MA.
локальный сервер Skype для бизнеса (CU 5)
Skype для бизнеса Online (SFBO)
Локальный сервер Exchange Server
Exchange Server Online (EXO)
Кроме того, для современной проверки подлинности важно знать, где будут проходить проверка подлинности (authN) и авторизация (authZ) пользователей. Существует два варианта.
Microsoft Entra идентификатор в Сети в Microsoft Cloud
Локальный сервер федерации Active Directory (ADFS)
Таким образом, он выглядит примерно так: exo и SFBO в облаке с идентификатором Microsoft Entra, а также Exchange Server (EXCH) и сервером Skype для бизнеса (SFB) on-prem.
Ниже представлены поддерживаемые топологии. В графиках топологий используются следующие условные обозначения.
Серым цветом выделены значки, которые недоступны в этом сценарии.
EXO — Exchange Online.
SFBO — Skype для бизнеса Online.
EXCH — локальный сервер Exchange.
SFB — локальный сервер Skype для бизнеса.
Серверы авторизации представлены треугольниками, например идентификатор Microsoft Entra представляет собой треугольник с облаком за ним.
Стрелки указывают на сервер авторизации, который будет использоваться при попытке клиентов получить доступ к заданному серверному ресурсу.
Сначала рассмотрим современную проверку подлинности с Skype для бизнеса в обеих топологиях: с использованием локально и в облаке.
Важно!
Вы готовы настроить современную проверку подлинности в Skype для бизнеса Online? Инструкции по включению этой функции приведены здесь.
Имя топологии |
Пример |
Описание |
Поддерживается |
---|---|---|---|
Только в облаке |
Размещенные пользователи или почтовые ящики: в сети |
Современная проверка подлинности включена для EXO и SFBO. Таким образом, сервер авторизации является Microsoft Entra идентификатором. |
Многофакторная проверка подлинности (MFA), проверка подлинности на основе сертификата клиента (CBA), условный доступ (CA)/управление мобильными приложениями (MAM) с Intune. * |
Только на локальном сервере |
Размещенные пользователи или почтовые ящики: локальная среда |
Современная проверка подлинности включена для локального сервера SFB. Сервер авторизации — ADFS. Сведения о конфигурации см . в этой статье. |
MFA (только для рабочих столов Windows, мобильные клиенты не поддерживаются). Функции интеграции с Exchange отсутствуют. Мы не рекомендуем этот подход. См. здесь: https://aka.ms/ModernAuthOverview |
Важно!
Рекомендуется использовать одно состояние современной проверки подлинности в Skype для бизнеса и Exchange (а также их эквивалентах в сети), чтобы сократить количество запросов.
Смешанные топологии включают в себя комбинации гибридных развертываний SFB с разделенными доменами. В настоящее время поддерживаются следующие смешанные топологии.
Имя топологии |
Пример |
Описание |
Поддерживается |
---|---|---|---|
Смешанная топология 1 |
Пользователи/почтовые ящики находятся: в EXO и SFB |
Современная проверка подлинности не включена для SFB. В этой топологии недоступны функции современной проверки подлинности для SFB. |
Функции современной проверки подлинности недоступны для SFB. |
Смешанная топология 2 |
Пользователи/почтовые ящики находятся: EXCH и SFBO |
Современная проверка подлинности включена только для SFBO. Сервер авторизации — это Microsoft Entra идентификатор для пользователей, размещенных в SFBO, а AD — для локальной среды EXCH. |
MFA, CBA, CA/MAM с Intune.* |
Смешанная топология 3 |
Пользователи/почтовые ящики находятся: в EXO + SFB или EXCH + SFB |
В этой топологии недоступны функции современной проверки подлинности для SFB. |
Функции современной проверки подлинности недоступны для SFB. |
Смешанная топология 4 |
Пользователи/почтовые ящики находятся: в EXCH +SFBO или EXCH + SFB |
MA включен для SFBO, поэтому сервер авторизации Microsoft Entra идентификатор для пользователей, размещенных в SFBO. Локальные пользователи в SFB и EXO используют AD. |
MFA, CBA, CA/MAM с Intune только для пользователей в сети.* |
Смешанная топология 5 |
Пользователи/почтовые ящики находятся: в EXO + SFBO, EXO + SFB, EXCH + SFBO или EXCH + SFB |
MA включен как в EXO, так и в SFBO, поэтому сервер авторизации является Microsoft Entra идентификатором для пользователей, размещенных в SFBO; локальные пользователи в EXCH и SFB используют AD. |
MFA, CBA, CA/MAM с Intune только для пользователей в сети.* |
Смешанный 6 |
Пользователи/почтовые ящики находятся: в EXO + SFBO, EXO + SFB, EXCH + SFBO или EXCH + SFB |
Ma включена везде, поэтому сервер авторизации является Microsoft Entra идентификатором для всех пользователей. (в сети и в локальной среде) См. https://aka.ms/ModernAuthOverview инструкции по развертыванию. |
MFA, CBA и CA/MAM (через Intune) для всех пользователей. |
* MFA включается для рабочего стола Windows, устройств на базе MAC, iOS и Android, а также в ОС Windows Phone; CBA включается для рабочего стола Windows, а также устройств iOS и Android; CA/MAM с Intune включены на устройствах Android и iOS.
Важно!
Очень важно отметить, что в некоторых случаях пользователи могут получать несколько запросов, особенно когда состояние современной проверки подлинности не одинаковое для различных ресурсов сервера, которые могут потребоваться клиентам и которые они могут запрашивать (как в случае со всеми версиями смешанных топологий).
Важно!
Кроме того, обратите внимание, что в некоторых случаях (в частности, смешанные 1, 3 и 5) раздел реестра AllowADALForNonLyncIndependentOfLync должен быть задан для правильной настройки для клиентов windows Desktop.