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

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

Введение

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

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

История аутентификации для клиентов Exchange Online до сегодняшнего дня

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

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

Учетные данные должны храниться на клиентском компьютере Outlook Desktop

Еще с сентября 2007 года, когда был анонсирован стандартный пакет Microsoft Business Productivity Online (также известный как BPOS), рабочая нагрузка Exchange Online поддерживала только базовую проверку подлинности, когда речь шла о таких клиентах, как клиент Outlook Desktop, клиенты IMAP/POP, Exchange ActiveSync ( клиенты EAS), веб-службы Exchange (EWS) и SMTP-клиенты с защитой TLS.

Конечно, мы, без сомнения, прошли долгий путь с тех пор, как клиент « Microsoft Online Services Sign In », который был установлен на клиентском компьютере конечного пользователя, чтобы настроить профили Outlook (и других приложений Office) и аутентифицировать учетную запись BPOS конечного пользователя в для имитации единого входа, но корпоративные клиенты по-прежнему страдают, когда речь идет о клиентах с базовой проверкой подлинности.

Рис. 1. Помощник по входу в MSOL

Примечание:
Если вы хотите отправиться в серьезное путешествие по переулку памяти BPOS, вы можете прочитать мою серию статей о BPOS за 2007 год. Недавно я прочитал ее сам, и совершенно невероятно, что произошло с облачными сервисами Microsoft с тех пор..

С запуском первой версии Office 365 (также называемой 14-й волной, основанной на версиях соответствующих рабочих нагрузок 2010 г.) еще в октябре 2011 г. ситуация для клиентов Office еще больше улучшилась благодаря введению знака Microsoft Online Services Sign. -в Помощнике (или сокращенно MOS SIA). MOS SIA был автономным пакетом, который в основном состоял из файлов библиотеки динамической компоновки (DLL) и службы Windows (подробнее см. здесь), что улучшило процесс входа в систему для клиентов Office 2010. MOS SIA автоматически устанавливался на клиентский компьютер, если использовалось средство настройки рабочего стола Office 365. Однако, поскольку инструменту установки Office 365 для рабочего стола требовались права локального администратора на клиентском компьютере, большинство организаций развернули пакет MOS SIA с помощью своего решения для развертывания программного обеспечения, такого как SCCM.

Рис. 2. Установлен автономный пакет Microsoft Online Services Sign-in Assistant.

27 февраля 2013 г. была запущена вторая волна Office 365 (также называемая волной 15, основанной на версиях соответствующих рабочих нагрузок 2013 г. и той, которая используется на момент написания этой статьи). Примерно в то же время Office 2013 стал общедоступным. В Office 2013 MOS SIA встроен в продукт, что избавляет от необходимости устанавливать автономный пакет MOS SIA. Однако процесс входа в систему для клиентов Exchange Online не был улучшен, поскольку Exchange Online (теперь работающий с Exchange 2013) по-прежнему поддерживает только базовую проверку подлинности для вышеупомянутых клиентов, не использующих браузер.

Видите ли, несмотря на улучшения, внесенные со временем с момента создания облачных служб Microsoft, из-за требований базовой проверки подлинности учетные данные должны быть представлены в Exchange Online, например, их необходимо вводить каждый раз при запуске клиента Outlook Desktop или быть сохранены в диспетчере учетных данных Windows на клиенте. Вернитесь к предыдущей статье этой серии, чтобы узнать подробности о потоке проверки подлинности прокси-сервера, который является причиной этого требования.

Рис. 3. У конечного пользователя запрашиваются учетные данные в клиенте Outlook для настольных ПК

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

Рис. 4. Диспетчер учетных данных в клиенте Windows 10

Отсутствие реальной многофакторной аутентификации для клиентов базовой аутентификации

Многофакторная аутентификация (MFA) стала доступна конечным пользователям еще 10 февраля 2014 г. Хотя функция MFA основана на Microsoft Azure, эта функция включена в покрываемые планы Office 365 без дополнительной оплаты. Доступно многофункциональное решение MFA, но для него требуется подписка Azure AD Premium или пакет Enterprise Mobility Suite (EMS). Вы можете найти сравнение изданий MFA здесь.

Примечание:
Хотя MFA не был доступен конечным пользователям до февраля 2014 года, он стал доступен для пользователей-администраторов Office 365 с июня 2013 года.

Функция MFA, включенная в Office 365, включает поддержку мобильного приложения, телефонного звонка и SMS в качестве аутентификации на основе второго фактора и очень хорошо работает для доступа через браузер к рабочим нагрузкам Office 365, в нашем случае это Outlook в Интернете (OotW). доступ к почтовому ящику.

Рисунок 5: MFA включен для конечного пользователя, получающего доступ к своему почтовому ящику с помощью Outlook в приложении (OotW)

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

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

Рис. 6. При включенной MFA клиенты на основе базовой аутентификации используют пароли приложений

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

Как вы можете видеть на рис. 7, пароль приложения — это не то, что конечный пользователь сможет запомнить, поскольку это полный случайный набор букв, а не то, к чему он может относиться, как это часто бывает с паролями, сгенерированными конечным пользователем. сам пользователь. Это, конечно, хорошо для безопасности, но не для конечного пользователя. Я боюсь, что некоторым конечным пользователям может прийти в голову «блестящая» идея хранить этот пароль в незашифрованном виде где-нибудь на своем устройстве или клиенте, чтобы им не нужно было создавать новый, когда/если потребуется.

Рисунок 7: Пример пароля приложения

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

Хорошо, что команда современной проверки подлинности Office 365 (ранее известная как современная проверка подлинности Office 2013), которая была создана еще в начале 2014 года, была занята работой над новой историей проверки подлинности для клиентов Office 365.

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

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