В опубликованном в апреле 2013 года отчете Microsoft о результатах финансовой деятельности корпорации за третий квартал отмечалось, что 25 % ее корпоративных клиентов используют платформу Office 365. Если учесть, что в этот показатель включены и пробные подписки, можно утверждать, что фактическое число развернутых систем почти наверняка ниже. Среди малых предприятий количество развернутых комплектов Office 365, по-видимому, больше, поскольку данная служба представляет особый интерес для компаний, не обладающих развитой ИТ-инфраструктурой. Тем не менее, большое число компаний, что называется, заглядываются на эту платформу — и, вероятно, сталкиваются с необходимостью выполнения непростых требований в отношении организации процедуры однократной регистрации single sign-on (SSO). В предлагаемой статье я хочу рассмотреть проблемы, связанные с интеграцией Office 365 в вашу среду таким образом, чтобы пользователям не приходилось по нескольку раз вводить свои учетные данные; кроме того, я покажу, как можно облегчить решение этой задачи с помощью средств управления учетными данными от сторонних изготовителей.

Варианты интеграции Office 365

Существует пять способов интеграции комплекса Office 365 с имеющейся локальной средой — от практически полного отсутствия интеграции до реализации процедуры однократной регистрации на базе корпоративных учетных данных, как показано в таблице. При использовании трех из этих способов интеграции в качестве поставщика учетных данных используется лес вашей компании — как правило, это лес Active Directory (AD). В двух случаях для работы в Office 365 применяются те же идентификационные данные пользователей, что и в корпоративном каталоге. Но только один метод обеспечивает свободный доступ к Office 365, как если бы пользователь обращался к локальным ресурсам посредством SSO. Для средних и крупных предприятий этот метод чаще всего является оптимальным; всякий раз при необходимости ввести пароль пользователи начинают путаться, а затраты на поддержку возрастают.

 

Пять способов интеграции Office 365 с локальной сетью

Вне зависимости от того, к какой службе вы пытаетесь подключиться, к Office 365 или к другому поставщику «облачных» услуг cloud service provider (CSP), например к Google Apps, для осуществления по Интернету процедуры SSO необходимы два основных компонента. Прежде всего, пользователь не может обращаться к «облачной» службе, не имея в ней индивидуального имени. Следовательно, вы должны предусмотреть способ заполнения, а затем и синхронизации, ваших локальных имен с «облачной» службой. Для заполнения индивидуальными именами записей службы Office 365 специалисты Microsoft предложили утилиту Windows Azure Active Directory Synchronization Tool (известную как DirSync, technet.microsoft.com/en-us/library/jj151800.aspx). Средства управления идентификаторами от сторонних производителей тоже оснащены собственными механизмами заполнения учетных записей; о них я расскажу чуть позже.

Заполнение учетных записей с помощью DirSync

DirSync напрямую отслеживает и синхронизирует локальные объекты AD с AD Windows Azure. Это односторонняя синхронизация: локальные объекты AD всегда имеют приоритет перед синхронизируемыми объектами в Azure AD. Разумеется, если копнуть глубже, выясняется, что все не так просто. Утилита DirSync синхронизирует до 50000 объектов без вмешательства извне; если вам необходимо синхронизировать большее количество объектов, вам придется обратиться к службе поддержки Microsoft (насколько я понимаю, для того, чтобы пообещать: никакой атаки типа «отказ в обслуживании» — Denial of Service, или DoS — на Azure AD вы не планируете). Кроме того, если вам нужно выполнить синхронизацию более 50000 учетных записей, придется установить полнофункциональный экземпляр SQL Server 2008/SQL Server 2008 R2. Сервер DirSync должен быть членом леса, в котором он выполняет синхронизацию объектов; кроме того, этот сервер должен быть защищен так же надежно, как и контроллер домена (DC), но утилита не может быть установлена на DC. Если вы используете DirSync с функцией синхронизации паролей (этот вариант не является необходимым и даже не рекомендуется к применению, если вы используете механизм федерации), имейте в виду, что изменения паролей реплицируются раз в две минуты, тогда как на выполнение других изменений порой уходит несколько часов. Некоторые из упомянутых характеристик описываются в блоге обладателя звания Fellow Directory Services MVP Сандера Беркувера «Five Things you should know about using DirSync with Password Sync» (blogs.dirteam.com/blogs/sanderberkouwer/archive/2013/07/12/five-things-you-need-to-know-about-using-dirsync-with-password-sync.aspx).

 

Специализированный идентификационный мост поставщиков решений IDaaS
Рисунок. Специализированный идентификационный мост поставщиков решений IDaaS

Федерация со службами AD FS

Когда задача размещения учетных данных в Office 365 с целью организации SSO будет решена, потребуется продумать метод их аутентификации там, откуда они пришли — в вашей компании, выступающей в качестве поставщика учетных данных. В случае использования технологии федерации учетных данных аутентификация осуществляется с помощью компонента, известного как идентификационный мост, identity bridge. В продуктах Microsoft в роли универсального идентификационного моста выступают службы Active Directory Federation Services (AD FS). Специализированные идентификационные мосты выпускаются и сторонними производителями (в том числе поставщиками IDaaS).

Разработка и развертывание AD FS в производственной среде — задачи нетривиальные, хотя с выходом в свет каждой версии поиски решения несколько облегчаются. Раньше службы AD FS нельзя было устанавливать на контроллерах доменов, но в версии Windows Server 2012 R2 рекомендуемый вариант предусматривает их установку как раз на контроллере домена. Я рекомендую настраивать AD FS так, чтобы обеспечивалась их высокая доступность, иначе ваши пользователи не смогут получать доступ к критически важным офисным функциям. Так, вам нужно будет сформировать отказоустойчивый кластер Windows с установленной на нем ролью AD FS, развернуть в корпоративной димилитаризованной зоне прокси-сервер AD FS, а также получить и установить общие сертификаты. После установки и ввода в эксплуатацию служб AD FS необходимо осуществлять их мониторинг и обновление; кроме того, нельзя допускать истечения срока действия общих сертификатов — иначе доверительные отношения будут скомпрометированы. Далее, для функционирования решения, построенного исключительно на технологиях Microsoft, необходимо, чтобы федеративные отношения доверия с Office 365 были установлены в рамках одного леса, так что если у вас имеются учетные записи в нескольких лесах AD или источники учетных данных, не относящиеся к службе AD, вам нужно будет выполнить тот или иной вариант консолидации. В подготовленном Томасом Кемпом документе «Options for Federated Identity for Office 365, Part 2» (http://www.centrify.com/blogs/tomkemp/alternatives_to_active_directory_federation_services.asp) кратко описаны проблемы, возникающие в процессе развертывания служб AD FS в локальной сети.

Очистка данных каталога

Степень интеграции с Office 365 не имеет значения, если данные в вашем каталоге учетных записей не отражают реального положения дел. К примеру, широко распространены определенные соглашения, касающиеся имен пользователей и телефонных номеров, но хотя, воспользовавшись средством Office 365 Deployment Readiness Tool, вы сможете без труда уяснить, в чем состоят проблемы данных, на их исправление и на формирование политик, которые позволят сохранить данные достоверными, уйдет какое-то время. Отметим, кстати, что утилита Office 365 Deployment Readiness Tool, которую раньше можно было загрузить бесплатно и использовать в любом лесу AD с целью выявления проблем, затрудняющих миграцию Office 365, теперь доступна только для подписчиков Office 365. Чтобы ею воспользоваться, нужно будет оформить пробную подписку.

Это еще одна строчка в солидном списке проблем, препятствующих развертыванию службы Office 365. И дело здесь даже не в самой службе, а в архитектуре решения.

Решения от сторонних поставщиков

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

Если локальные источники учетных данных плохо взаимодействуют друг с другом, организуйте виртуальную службу каталогов virtual directory service (VDS), и все они будут представлены как элементы одного каталога. Вы также можете создать внутри VDS правила, по которым «грязные» данные будут переформатироваться, так что дистанционным веб-службам будут предъявляться «чистые» данные. Если же вы не хотите тратить время и силы на размещение высокодоступного кластера AD FS, то с легкостью найдете несколько локальных идентификационных мостов, специально спроектированных для того, чтобы обеспечить подключение к Office 365 с настройкой минимального числа параметров. А поставщики решений IDaaS (учетные данные как служба) помогут вам быстро решить проблему установления федеративных отношений с помощью легко развертываемого специализированного идентификационного моста, представленного на рисунке. Они обеспечивают функцию процедуры однократной регистрации для сотен поставщиков «облачных» услуг, включая Office 365. Они организуют и средства подготовки учетных записей, хотя функция подготовки учетных записей на платформе Office 365 у разных поставщиков имеет различное наполнение. Есть надежда, что именно в этой области развивающаяся система кросс-доменного управления учетными данными System for Cross-domain Identity Management (SCIM) станет хорошим подспорьем администраторов. Наконец, многие из поставщиков в своих комплектах продуктов предоставляют потребителям все три функции (федерация, подготовка и консолидация учетных данных).

Недавно я поймал себя на том, что повторяю слова Гила Киркпатрика, сказанные мне несколько лет назад в интервью (см. статью «Удостоверения как служба и будущее Active Directory», опубликованную в Windows IT Pro/RE № 5 за 2012 год): «Управление учетными данными интересует только тех, кто занимается непосредственно управлением учетными данными». Для всех остальных удостоверения — это всего лишь «лежачий полицейский», искусственное препятствие на пути. Таким ограничителем скорости и является подключение предприятия к службе Office 365: чем меньше ваши пользователи знают об этом подключении, тем лучше. А решения, предлагаемые сторонними производителями, могут заметно сократить время, которое вам придется потратить на развертывание.