Аутентификация в Office 365 (немного теории)

Всегда сложно с чего-то начинать. После долгих раздумий, я решил посвятить свою первую статью на Хабре теме, которой занимаюсь в данный момент — Office 365 во всех его проявлениях.

На сайте уже было несколько статей, описывающих те или иные компоненты данного сервиса. Писали и про настройку авторизации с помощью ADFS и синхронизацию с Active Directory, но помимо практики не помешает немного теории. Конечно рассказать все невозможно, да и не интересно, но важные, на мой взгляд, моменты отметить стоит.

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

В Office 365 существует три типа идентификаторов, используемых для аутентификации ваших пользователей в сервисах Exchange Online, Sharepoint Online, Lync Online и даже Office Pro Plus.

1. Microsoft Online ID — обычная учетная запись в Windows Azure Active Directory. Это аналог всем нам привычного Active Directory, но адаптированного для работы с «облачными» продуктами Microsoft (например, помимо Office 365, еще используется для MS Dynamics CRM Online). Пользователи создаются вручную при помощи портала администрирования или массово через CSV-файл.
2. Microsoft Online ID + DirSync — те же самые «облачные» пользователи, но представляют собой копию учетных записей из вашего AD, созданную при помощи утилиты Microsoft Directory Synchronization или сокращенно DirSync. Из локального AD переносятся почти все основные аттрибуты, но не переносятся пароли пользователей. Управление пользователями осуществляется частично череp AD, частично на портале.
3. Federated ID + DirSync — в основе системы все тот же принцип копирования учетных записей из вашего AD, с той лишь разницей, что для авторизации используется Active Directory Federation Service 2.0. Управление пользователями осуществляется через локальное AD.

Сравнение типов идентификаторов

Microsoft Online ID	Microsoft Online ID + DirSync	Federated ID + DirSync
Аудитория Малые организации без локальной службы Active Directory	Аудитория Средние организации с локальной службой Active Directory	Аудитория Крупные организации с локальной службой Active Directory
«За» Не требуются локальные серверы	«За» Локальное управление пользователями и группами Сценарии сосуществования	«За» Топология единого входа с корпоративными реквизитами Локальное управление идентификаторами Политика паролей контролируется локально Возможна двухфакторная аутентификация Сценарии сосуществования
«Против» Невозможна топология единого входа Невозможна двухфакторная аутентификация Два набора реквизитов с разными политиками паролей Управление идентификаторами из облака	«Против» Невозможна топология единого входа Невозможна двухфакторная аутентификация Два набора реквизитов с разными политиками паролей Необходимо развертывание сервера	«Против» Необходимо развертывание сервера с высокой степенью доступности

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

Если с первыми двумя вариантами в техническом плане все довольно очевидно, то при реализация аутентификации при помощи ADFS возникают сложности.

Прежде чем рассказать про механизм аутентификации, приведу реальную ситуацию из жизни: в компании 1000+ пользователей использовался Office 365 с аутентификацией через ADFS. В одно не очень прекрасное утро пользователи начали жаловаться, что их Outlook не может подключиться к почте, но при этом доступ к Outlook Web Access, SharePoint или Lync сохранился. Причина сбоя была в изменении политик сервера и, как следствие, падении службы ADFS Proxy. Для локализации данной проблемы было потрачено несколько часов, которые можно было сэкономить, понимая несколько простых вещей про аутентификацию в Office 365.

Итак, в Office 365 используется два основных механизма (их иногда еще называют профилями) аутентификации:

Пассивный механизм — применяется для авторизации в сервисах Office 365 при помощи браузера или службы единого входа.
Принцип работы данного механизма можно проиллюстрировать схемой:

1. Пользователь при помощи браузера или Lync-клиента запрашивает информацию у сервиса SharePoint Online, Exchange OWA или Lync-сервер и получает ответ с просьбой авторизоваться на платформе аутентификации (Authentication Platform)
2. Authentication Platform после получения запроса определяет, что используется федеративный идентификатор и требует предоставить User Source Id, подтверждающий валидность пользователя в локальном Active Directory), для чего перенаправляет запрос на URL ADFS сервера.
3. ADFS-сервер аутентифицирует пользователя в локальном AD и выдает ему подписанный User Source ID
4. Вооружившись своеобразным «паспортом» пользователь в очередной раз обращается к Authentication Platform, от которой на этот раз получает «облачное удостоверение» NET ID.
5. Данное удостоверение в дальнейшем используется для работы с сервисами

Активный механизм — используется для авторизации в сервисе электронной почты при помощи Outlook или при использовании протоколов ActiveSync, IMAP, POP3.
Схемой очень похожа на предыдущий вариант:

Принцип действия данного механизма авторизации повторяет все шаги, за исключением одной важной детали — пользователь пересылает сервису Exchange Online свои учетные данные в явном виде (естественно защищенные по протоколу HTTPS). Exchange Online, используя механизм имперсонализации, от имени пользователя проходит все дальнейшие этапы, включая общение с ADFS сервером и получение User Source ID.

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

DNS
При возникновении проблем, требуется всегда помнить, какой DNS-сервер используют пользователя в настоящий момент при авторизации на конкретном сервисе.

Сертификаты
Если все ваши пользователи находятся в корпоративной сети и используют для работы с Office 365 только браузер и Lync клиент, то можете забыть про этот пункт и смело использовать самоподписной сертификат вашего CA. Но как только у вас появляются внешние пользователи или вы хотите настроить ваш любимый телефон на получение корпоративной почты, потребуется валидный сертификат, выданные доверенным центром сертификации. В качестве best practice, еще на этапе перехода на Office 365, стоит сразу запланировать покупку если не wildcard, то хотя бы обычного с парой SAN, не надеясь, что у вас уникальная ситуация и внешние пользователи никогда не появятся.

Отказоустойчивость
Вроде бы самая очевидная вещь любой ИТ системы, на практике, оказывается самой болезненной. Обеспечение отказоустойчивости ADFS-сервера — важнейший и часто пропускаемый этап при настройке федеративной аутентификации. Повышение надежности ADFS вполне простая задача, заключающаяся в использовании либо стороннего NLB либо штатного Windows Load Balancer (WNLNB). Я понимаю, что говорю про очевидные вещи, но, к сожалению, многие администраторы не уделяют теме отказоустойчивости, пытаясь «когда-нибудь потом» доставить еще один сервер. Если не вдаваться в детали, на практике, отсутствие балансировки ADFS — самая распространенная причина проблем с Office 365.

Публикация
Как только в вашем сценарии использования Office 365 появляется Outlook или ActiveSync, встает вопрос о правильной публикации ADFS наружу. Для этого есть несколько возможностей:

• Выставить ADFS сервер наружу — самый плохой и небезопасный вариант, применяемый администраторами не от хорошей жизни.
• Развернуть ADFS Proxy — потребуется два дополнительных сервера и балансировка нагрузки между ними (опять же при помощи стороннего NLB или WNLB). Среди плюсов стоит отметить простоту в настройки и администрировании. Ломаться там почти нечему.
• Опубликовать через Forefront TMG/UAG — сложнее в настройке и поддержке, но намного функциональнее. Позволяет расширить функционал ADFS для внешних пользователей и реализовать более сложные сценарии авторизации Office 365. Некоторые администраторы умудряются использовать публикацию TMG и ADFS Proxy, что, в принципе, возможно, но таит в себе множество сложностей и нестабильностей, которые тяжело локализовать.
• Внешний Reverse Proxy — может быть любым решением/устройством, которое не модифицирует SAML запросы/ответы, например Citrix NetScaler или даже простой stunnel. С требованиями к reverse proxy можно ознакомиться здесь

Аутентификация в Office 365 — это тема, о которой можно писать очень долго. Сегодня я постарался рассказать, на мой взгляд, важные моменты, которые часто вызывают непонимание и ошибки. Для кого-то эта статья будет очевидной, но надеюсь, найдутся те, кому она сэкономит несколько неприятных часов локализации проблемы и килограмм нервных клеток.