Прошло более года с момента публикации моей первой статьи посвященной интеграции Office 365 с локальной доменной инфраструктурой, и за этот год статью не только достаточно много читали, но и несколько раз вполне успешно публиковали от своего имени — видимо такова цена популярности 🙂

Как бы там ни было, облачные сервисы Microsoft развиваются, и в новой статье я расскажу и покажу, как быстро, просто и гарантированно построить интеграцию существующей доменной инфраструктуры с Windows Azure Active Directory. В примерах, я буду использовать новейшую версию Windows Server — 2012 R2, кроме того я расскажу о тонкостях DirSync.  Все действия, которые я опишу обратимы, кстати говоря.

Перед тем как начинать, хочу предупредить читателя о том, что настраивать интеграцию ради интеграции и SSO ради SSO не стоит, т.к. интеграция с Active Directory приносит как преимущества, так и риски: а именно зависимость от Вашей площадки , LAN и WAN сетей, оборудования, программного обеспечения и т.д. и т.п. В связи с этим, использование исключительно Windows Azure Active Directory может быть хорошим вариантом. Но если без интеграции не обойтись, приступим к настройке.

Итак, первым делом нам необходимо установить и настроить Active Directory Federation Services и Web Application Proxy. Кроме того, нам потребуется сервер для DirSync, хотя часто его размещают на сервере AD FS, что является нежелательным, но тем не менее рабочим сценарием.

Для всех серверов необходимо иметь план аварийного восстановления (DLP) т.к. отказоустойчивость достигается достаточно просто для AD FS, не совсем просто для WAP и невозможна для DirSync. Исходя из этого,  я не буду кривляться с настройкой отказоустойчивости на уровне гостевых ОС и датацентра (сайта), но размещу сервера в кластере, который отказоустойчив на уровне сети, хранилища и вычислительных ресурсов — тем более что такой сценарий является наиболее распространенным в реальности.

Для реализации такого сценария, нам потребуется всего 3 vCPU, 3Gb vRAM и около 50Gb vHDD — как видите, требования к производительности минимальные. Важнее то, что необходимо минимум 3 лицензии на Windows Server (дополнительные лицензии клиентского доступа не требуется), а в случае использования полноценной версии SQL для DirSync лицензии и CAL’ы для SQL. Хорошо, если у Вас уже есть лицензии на SQL, в котором размещаются базы данных инфраструктурных сервисов, таких как AD FS, AD RMS, WSUS и т.д., а также хосты, на которых установлен Windows Server Datacenter (напомню, лицензия Datacenter дает право на использование неограниченного количества виртуальных машин, а в случае 2012 R2 AVMA дополнительно упрощает лицензирование).

В любом случае, после подготовки сслылка https://sso.mars.biz.ua/adfs/ls/IdpInitiatedSignon.aspx должна отдавать интерфейс AD FS (разумеется, вместо sso.mars.biz.ua должно быть ваше имя):

Вопросы относительно сертификатов поступают постоянно, поэтому уточняю:

1. Да, с «самоподписанным» сертификатом работать будет;
2. Да, сертификат выданный корпоративным ЦС работать будет (я использую этот вариант в лабе);
3. Да, в продуктивной среде нужно использовать сертификат выданный коммерческим ЦС. Идеально не Winldard и без Subject Alternative Name. В таком случае, AD FS и WAP должны использоваться исключительно для Windows Azure Active Directory.

Со стороны локального домена Active Directory необходимо обеспечить маршрутизируемые UserPrincipalName. Для этого, добавим маршрутизируемый домен (у меня это mars.biz.ua) используя mmc:

Для всех пользователей и групп, которые будут использовать Windows Azure Active Directory нужно включить UPN, сделать это можно вручную, используя mmc:

.. но если объектов много, просмотрим какие UPN заданы сейчас для всех пользователей в определенном OU (аналогично делаем для групп):

Get-ADUser -Filter * -SearchBase ‘OU=MARS Users,DC=lab,DC=local’ -Properties userPrincipalName

Установим добавленный ранее UPN для всех пользователей OU:

Get-ADUser -Filter * -SearchBase ‘OU=MARS Users,DC=lab,DC=local’ -Properties userPrincipalName | foreach { Set-ADUser $_ -UserPrincipalName «$($_.samaccountname)@mars.biz.ua»}

Проверим результат:

Отвечаю на вопрос «К чему приводит смена UPN?»:

1. Пользователи смогут входить на ПК, вводя в качестве логина свой email — это удобно и чем-то похоже на Windows 8 и Live ID;
2. Пользователи по-прежнему будут иметь возможность использовать логин в форме domainlogin
3. SID и т.п. не меняются.

Теперь, перейдем к подготовке доменов и Office 365. Для этого, у вас должен быть доступ к управлению интернет-доменами, которые вы будете использовать и учетная запись Office 365 с правами Global Administrator.

Теперь, на машине с которой мы будем настраивать и администрировать облачные службы (разумеется, таких машин может быть сколько угодно) установим Microsoft Online Services Sign-In Assistant и Windows Azure Active Directory PowerShell Module

На этом сервере, нужен .NET 3.5, установить можно так (разумеется вместо fssxs тут и далее по тексту  — Ваше расположение):

Add-WindowsFeature NET-Framework-Features -Sourcefssxs

Подключимся к Office 365 используя PowerShell:

$cred=Get-Credential
Connect-MsolService –Credential $cred

Укажем расположение нашего сервера AD FS:

Set-MsolADFSContext –Computer sso.lab.local

В случае ошибки Set-MsolADFSContext : The connection to Active Directory Federation Services 2.0 server failed due to i nvalid credentials. выполнить:

Enable-PSRemoting –force

Добавим в Office 365 наш федеративный домен (если домен уже подключен в Office 365, используйте Convert вместо Add):

New-MsolDomain -Authentication Federated -Name mars.biz.ua

Для проверки владения доменом, запросим TXT запись и добавим ее в панели управления доменом:

Get-MsolDomainVerificationDns -DomainName mars.biz.ua

Проверим результат используя nslookup:

Когда все готово, запустим:

New-MsolFederatedDomain -DomainName mars.biz.ua

Проверим результат:

Get-MsolFederationProperty -DomainName mars.biz.ua

Нужно понимать, что эта настройка выполнена разово, и изменения как на Вашей стороне, так и на стороне Office 365 потребуют ручного пинка (Update-MsolFederatedDomain). Но эта проблема решается с помощью Microsoft Office 365 Federation Metadata Update Automation Tool , которую мы установим на сервер AD FS (запустив от имени администратора):

Включим синхронизацию каталогов:

Set-MsolDirSyncEnabled -EnableDirSync $true

.. и проверим результат:

Get-MsolCompanyInformation

Приступим к установке DirSync, для которого уже подготовлен сервер и учетная запись с правами Domain Admins & Enterprise Admins (после установки, права можно убрать, оставив только Local Admin на сервере). Предварительно на сервере нужно установить .NET 3.5 ( Add-WindowsFeature NET-Framework-Features -Sourcefssxs ),  Microsoft SQL Server 2012 Native Client и Windows Azure Active Directory PowerShell Module

На SQL сервере добавим новый Instance c Database Engine Feature.

.dirsync-ru.exe /fullSQL

Перейдем к настройке:

cd ‘c:program filesWindows Azure Active Directory Sync’

.DirSyncInstallShell.psc1

Install-OnlineCoexistenceTool -UseSQLServer -SqlServer db.lab.local -SqlServerInstance dirsync -Verbose -ServiceCredential (Get-Credential)

Разумеется, вместо db.lab.local Вы должны указать свой SQL сервер, а вместо dirsync свой Instance. Результат:

Перезагрузим сервер dirsync и запустим Directory Sync Configuration Wizard, в котором введем учетные данные Windows Azure Active Directory Administrator (Office 365 Global Admin) и Active Directory Enterprise Administrator , включим Hybrid Deployment и Password Sync, а вот запускать синхронизацию каталогов не будем т.к. синхронизировать мы будем не все объекты (об этом чуть ниже).

Обратите внимание, права Enterprise Admin нужны были в т.ч. для создания новой учетной записи, которая будет использоваться процессами синхронизации:

Теперь, определимся какие объекты (пользователи и группы) мы будем синхронизировать с Azure Active Directory. Для этого будем использовать консоль Forefront Identity Manager, которая находится тут:

C:Program FilesWindows Azure Active Directory SyncSYNCBUSSynchronization ServiceUIShellmiisclient.exe

Перейдем на вкладку Management Agents, откроем свойства Active Directory Connector, перейдем в раздел Configure Directory Partitions и нажмем Containers (на запрос учетных данных введем учетные данные доменного администратора, а не MSOL_<id>), укажем какие OU будем синхронизировать:

Запустим синхронизацию:

cd ‘C:Program FilesWindows Azure Active Directory Sync’

.DirSyncConfigShell.psc1

Start-OnlineCoexistenceSync -FullSync

По-умолчанию, DirSync выполняет синхронизацию каждые 3 часа, но это не всегда уместное значение можно изменить отредактировав:

C:Program FilesWindows Azure Active Directory SyncMicrosoft.Online.DirSync.Scheduler.exe.config

Логи операции можно просматривать в разделе Operations консоли FIM:

.. или используя командлет:

Get-MsolCompanyInformation | fl LastDirSyncTime

Обратите внимание, по-умолчанию будут добавлены в т.ч. те пользователи, у которых отсутствует маршрутизируемый UPN — им будет назначен адрес .onmicrosoft.com:

Очевидно, такая ситуация нас не устраивает, поэтому я создам фильтр, который будет синхронизировать пользователей только с маршрутизируемыми UPN:

Для проверки, я создал двух пользователей, с разными UPN:

..и запустил синхронизацию:

Как видите, test4 был синхронизирован, а test и test3 отфильтрованы:

Похожая ситуация с электронной почтой, те пользователи, у которых нету почтового ящика в on-premise, но есть лицензия в Exchange Online, автоматически получат почтовые ящики с default SMTP в домене onmicrosoft.com:

Такая ситуация нас не слишком устраивает, поэтому я сделаю правило, которое запретит синхронизацию пользователей без email в федеративном домене:

Теперь, когда пользователи синхронизированы активируем их, сделать это достаточно просто из веб-интерфейса.

Обратите внимание, если сервер DirSync будет недоступен, алерты будут приходить НЕ на email в Office 365, а на внешний email администратора, что весьма разумно:

В результате, при попытке входа на https://portal.microsoftonline.com , пользователи после ввода логина будут перенаправлены на веб-интерфейс AD FS, где будут вводить пароли. После успешного ввода пароля, соединение с https://portal.microsoftonline.com будет установлено. Разумеется, если пользователь работает с ПК, котрый находится в домене пароль вводить не будет нужно, а если при логине установить галку в чекбоксе «Оставаться в системе», то не нужно будет вводить и логин. Проверенно на IE 11, Google Chrome 32 и Mozilla Firefox 26.

На этом настройку синхронизации и единого входа можно считать успешно законченной.

Дополнительно хочу сказать что относительно недавно Microsoft выпустил OnRamp — https://onramp.office365.com/onramp/, штука полезная, можете попробовать.