Azure Active Authentication для Office 365 - подробности
Всё больше и больше запросов от наших клиентов поступает на услугу двухфакторной аутентификации при доступе к сервисам Office 365. Чтобы обеспечить работу 2FA, Microsoft приобрела компанию PhoneFactor, одного из ведущих игроков на рынке поставщиков данных услуг.
Двухфакторная аутентификация для аккаунтов Azure (а значит и для пользователей Office 365) подразумевает использование двух подтверждений аутентичности пользователя:
- Логин и пароль
- Предоставление кода, высылаемого на мобильный номер, либо подтверждение звонка на мобильный/офисный номер от колл-центра Azure.
Рассмотрим предмет подробнее, упор будем делать на модель применения 2FA для нужд Office 365.
Активация сервиса
Услуга 2FA активируется через портал управления Windows Azure. Нужно понимать, что это платная услуга (только для учёток глобальных администраторов она будет бесплатна). Её настройка возможна только при наличии подписки Azure.
Администратор тенанта O365 активирует провайдера Active Authentication Provider для своего тенанта Azure:
Обратите внимание на настройку Usage model = возможен биллинг услуги по двум разным показателям:
- per enabled user – по количеству пользователей, для которых эта услуга активирована (этот вариант наиболее подходит для O365),
- per authentication – по общему количеству аутентификаций
Посмотреть подробности по тарифным планам можно здесь.
После того как провайдер настроен, и выбрана модель “per enabled user”, можно приступать к подключению 2FA для пользовательских аккаунтов.
Если пользователь является администратором Office 365, ему можно подключить 2FA непосредственно с портала O365: Admin > Users and Groups > Set stronger verification requirements:
Далее из списка учётных записей с административными привилегиями выбираются те, кому нужно подключить 2FA, и нажимается ОК.
Если пользователь не является администратором, ему сервис подключается из портала Azure: AD > Users > выбрать учётную запись > активировать настройку “Require milti-factor authentication”:
Изменения вступают в силу немедленно после нажатия кнопки ОК.
Если пользователей много, им можно подключить 2FA с помощью скрипта PowerShell:
$st = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement $st.RelyingParty = "*" $sta = @($st) Set-MsolUser -UserPrincipalName bsimon@contoso.com -StrongAuthenticationRequirements $sta
Как это работает для пользователя? Сперва обсудим вариант когда пользователь не федеративный. То есть имеет отдельный пароль для облачной учётки. Даже если он совпадает с доменным, потому что используется Azure DirSync с синхронизацией паролей.
Первый вход пользователя после настройки для него 2FA
Всегда производится через веб.
Пользователь хочет зайти на портал Office 365, вбивает своё UPN-имя и пароль. Система верифицирует логин/пароль, определяет что для данного пользователя включена 2FA. Если это первый вход пользователя после включения 2FA, ему будет предложено сконфигурировать сервис – определить, какой метод второй аутентификации будет использоваться, ввести номер телефона:
Пользователь сам выбирает метод верификации из имеющихся в наличии. На сотовый либо офисный телефон , номер которого указывается чуть ниже, поступает звонок. Или поступает SMS на сотовый. В случае звонка следует поднять трубку, выслушать короткое голосовое сообщение и нажать кнопку с решёткой: #. В случае с SMS нужно будет вбить в появившееся в браузере поле присланный шестизначный код.
После этого осуществляется вход в портал O365.
Далее при каждом последующем входе пользователь будет проверяться тем способом, который был настроен.
Сценарий 1: доступ к сервисам Office 365 через веб.
Пользователь хочет зайти на портал Office 365, вбивает своё UPN-имя и пароль. Система верифицирует логин/пароль, определяет что для данного пользователя включена 2FA. Активирует второй метод проверки согласно проведённым ранее настройкам.
Если проверка не получается – например, у телефона села батарейка, но при первой настройке предусмотрительно был вбит номер телефона офиса, или альтернативный номер мобильного, можно из окошка выбрать “Other verification code” и попробовать другой способ проверки, только для этого входа.
Чтобы изменить способ проверки на постоянной основе, нужно войти в настройки:
В разделе Password нужно в пользовательском портале нажать ссылку “Update my phone numbers used for account security”. В результате откроется окошко, где можно провести изменения:
Заметим, что в данном окошке больше опций чем при первой настройке. Появился раздел MOBILE APP, и два дополнительных метода проверки: “Notify me through app” и “Show one-time code in app”. Что это такое?
Для мобильных платформ Windows Phone, Android, и IOS разработано специальное приложение. Его нужно установить на соответствующее мобильное устройство, скачав из Магазина.
После установки приложение нужно активировать – связать с сервером Active Auth. Пользователь делает это так.
Сперва настраивает MOBILE APP через веб-портал – активирует галочку перед Active Authentication app (см. скриншот выше), и нажимает кнопку Configure. В появившемся окне есть barcode и некая информация:
На мобильном устройстве, подключённом к Интернету, пользователь запускает приложение Active Auth, и либо считывает баркод с экрана, либо вбивает в поля соответствующие код и URL:
Активация успешна, если на экране мобильника появляются цифры:
Далее пользователь выбирает способ вторичной аутентификации.
- Show one-time code in app: в приложении раз в некий период времени меняется отображаемый на экране код; его нужно вбить в веб-окошко подтверждения 2FA при входе и нажать sigh in до смены кода; похоже на аутентификацию по SMS-уведомлению.
- Notify me through app: этот режим будет работать если есть подключение мобильного устройства к Интернету; после ввода логина-пароля на мобильное приложение приходит запрос с просьбой подтвердить вход:
Если пользователь получил просьбу подтвердить вход, но на самом деле не заходил на облачный портал, значит кто-то пытается сделать это за него. Имеется возможность проинформировать об этом администратора: Cancel and report fraud.
Нужно помнить, что метод с подтверждением будет работать только при наличии Интернета. А метод с набором цифр можно использовать и если Интернета нет.
Сценарий 2: доступ к сервисам Office 365 с помощью приложений (rich clients: Outlook. Lync, ActiveSync).
Вы наверняка обратили внимание, что на скриншоте где мы включали Active Auth для учётной записи под галочкой было написано: “This user will not be able to sign using any non-browser applications such as Outlook, Lync, or Windows PowerShell”.
Значит ли это, что rich-клиенты не поддерживаются двухфакторной аутентификацией Active Auth?
Ответ уклончив. Пока нельзя сказать что поддерживается в полном объёме. То есть, решение которое есть сейчас, сложно назвать полноценным 2FA.
Для аутентификации rich-клиентов используется WS-Trust, в отличие от веб-аутентификации (WS-Federation). Этот механизм не приспособлен в полной мере к подобному же поведению как в случае с веб-клиентами – открытию дополнительных окон, выбору метода второй проверки подлинности, т.п. Очень надеемся что в будущем что-то изменится.
Пока же представлено другое решение, называемое App Passwords. Это некая альтернатива. Каждый лицензированный пользователь O365, для которого активирована услуга 2FA, у себя на портале может инициировать генерацию некоего 16-значного сложного пароля: O365 settings > раздел Password > выбрать “app passwords”. Вот так:
(имя вбивает сам пользователь, оно может быть абсолютно любым)
Этот пароль можно скопировать в память. Далее пользователь открывает rich-клиент, например Outlook. Клиент запрашивае логин-пароль. И вот тут в качестве пароля подставляется не пароль учётной записи, а вот этот самый сгенерированный пароль. Нажимается галочка перед “сохранить пароль”. Всё, клиент начинает работать.
App Password не доступен для учётных записей с администраторскими полномочиями.
Сами можете судить, что данный метод нельзя назвать 100% двухфакторной аутентификацией. Однако у него есть определённые преимущества перед стандартной проверкой. Пароль генерится системой а не пользователем, составляет 16 символов – значит его криптостойкость улучшенная. Сохранив пароль, пользователь не может повторно его посмотреть или изменить, только удалить. Также можно создать несколько паролей – для разных клиентов. Например, один для Outlook, второй для Lync, третий для ActiveSync. (На самом деле, каждый из этих паролей можно будет использовать для всех клиентских приложений, поэтому ценность такой возможности сомнительна. Я не нашёл как можно привязать определённый пароль к конкретному клиенту).
App Password для федеративных пользователей
Вариант использования Active Authentication с федеративными учётными записями обсудим в другом посте. Пока только скажем, что это возможно.
Также, ещё не охваченным остаётся вопрос управления сервисом. Это тоже возможно, через веб можно управлять настройками и формировать отчёты. Осветим эту тему позднее.
Заключение
Напоследок пара советов начинающим. Не стоит подключать Azure Active Auth единственному администратору тенанта. При неблагоприятных обстоятельствах можно лишиться управления тенантом. Лучше делать это когда есть хотя бы два админа. Также, не стоит терять мобильные телефоны. Ибо с Active Auth без них трудно обойтись.
Источники