- PVSM.RU - https://www.pvsm.ru -
Всегда сложно с чего-то начинать. После долгих раздумий, я решил посвятить свою первую статью на Хабре теме, которой занимаюсь в данный момент — Office 365 во всех его проявлениях.
На сайте уже было несколько статей, описывающих те или иные компоненты данного сервиса. Писали и про настройку авторизации с помощью ADFS [1] и синхронизацию с Active Directory [2], но помимо практики не помешает немного теории. Конечно рассказать все невозможно, да и не интересно, но важные, на мой взгляд, моменты отметить стоит.
По своему опыту могу сказать, что аутентификации в Office 365 довольно сложная тема, за кажущейся простотой и очевидностью которой, зачастую, скрываются тонкие нюансы, знание которых позволяет более качественно развернуть систему и снизить время, требующееся на локализацию проблемы. Вот о таких нюансах я бы хотел сегодня поговорить.
В Office 365 существует три типа идентификаторов, используемых для аутентификации ваших пользователей в сервисах Exchange Online, Sharepoint Online, Lync Online и даже Office Pro Plus.
Сравнение типов идентификаторов
Microsoft Online ID | Microsoft Online ID + DirSync | Federated ID + DirSync |
Аудитория
|
Аудитория
|
Аудитория
|
«За»
|
«За»
|
«За»
|
«Против»
|
«Против»
|
«Против»
|
На практике, чаще всего выбирают именно третий вариант т.к. это позволяет получить единообразие учетных записей и максимально упростить управление пользователями, сохраняя полный контроль над правами доступа и парольными политиками.
Если с первыми двумя вариантами в техническом плане все довольно очевидно, то при реализация аутентификации при помощи ADFS возникают сложности.
Прежде чем рассказать про механизм аутентификации, приведу реальную ситуацию из жизни: в компании 1000+ пользователей использовался Office 365 с аутентификацией через ADFS. В одно не очень прекрасное утро пользователи начали жаловаться, что их Outlook не может подключиться к почте, но при этом доступ к Outlook Web Access, SharePoint или Lync сохранился. Причина сбоя была в изменении политик сервера и, как следствие, падении службы ADFS Proxy. Для локализации данной проблемы было потрачено несколько часов, которые можно было сэкономить, понимая несколько простых вещей про аутентификацию в Office 365.
Итак, в Office 365 используется два основных механизма (их иногда еще называют профилями) аутентификации:
Пассивный механизм — применяется для авторизации в сервисах Office 365 при помощи браузера или службы единого входа.
Принцип работы данного механизма можно проиллюстрировать схемой:
Активный механизм — используется для авторизации в сервисе электронной почты при помощи 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 наружу. Для этого есть несколько возможностей:
Аутентификация в Office 365 — это тема, о которой можно писать очень долго. Сегодня я постарался рассказать, на мой взгляд, важные моменты, которые часто вызывают непонимание и ошибки. Для кого-то эта статья будет очевидной, но надеюсь, найдутся те, кому она сэкономит несколько неприятных часов локализации проблемы и килограмм нервных клеток.
Автор: Sherd
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/microsoft/17449
Ссылки в тексте:
[1] настройку авторизации с помощью ADFS: http://habrahabr.ru/post/151632/
[2] синхронизацию с Active Directory: http://habrahabr.ru/company/microsoft/blog/122913/
[3] здесь: http://technet.microsoft.com/en-us/library/hh852618(v=ws.10).aspx
Нажмите здесь для печати.