Синхронизация локального каталога Active Directory с Office 365 (Azure AD Connect)

Предыдущая статья про синхронизацию с помощью устаревшего коннектора Azure Active Directory Sync tool - в Архиве.

 Новый коннетор Azure AD Connector вовсе не новый. Он уже используется с лета 2015 года. Однако, когда я вперый раз настраивал синхронизацию локального каталога AD с облаком Office 365 его ещё не было и я использовал коннектор Azure Active Directory Sync Tool. Примерно через год MS уведомил, что старый коннектор через год-другой поддерживаться не будет. С одной стороны, можно подумать, что этот-другой год можно будет работать с устаревшим коннектором, как MS взяла и... "отключила" его. Однажды, зайдя в Панель Управления Office 365, я увидел, что синхронизация не работает, а в логах написано - несоответствие версии коннектора. Пришлось устанавливать Azure AD Connector.

 Изначально мне не понравился Azure AD Connector из-за того, что не было ясно где теперь управлять фильтрами синхронизации. С помощью ТП выяснилось, что фильтры управляются в отдельном приложении "Synchronization Rules Editor". Но настроив его однажды я просто перестал париться из-за какого-то "нового" коннетора...

 На днях руководство поставило задачу - резервное копирование Exchange Online, One Drive for business, SharePoint Online в локальное хранилище. С одной стороны, облачные сервисы подразумевают собственное резервное копирование. Для Exchange по умолчанию это 14 дней хранения удалённых писем, для SharePoint и OneDrive это до 500 копий, сделанных перед изменением файлов. Но есть одно "но" - пользователь может зайти в средства восстановления и удалить всё безвозвратно. По этому была поставлена задача реализовать резервное копирование в локальное хранилище. Погуглив, был найдет Layer2 Cloud Connector, который синхронизирует как в обе стороны, так и в одну. Есстествено, я не стал бы тестироваь его с рабочей инфраструктурой, а в тестовой среде. Так мы подошли к моменту, как создать тестовую среду локального AD и синхронизировать её в облако Office 365. Данной статье будет рассмотрена только подробная синхронизация каталога в облако. Настройка контроллера домена на базе Windows Server 2016 описана в этой статье. Необходимо добавить дополнительнй суффикс UPN (такой же как и почтовый домен) в оснастке "Active Directory Domain and Trusts". Для сервера синхронизации будет использоваться отдельный сервер. Для начала надо зарегистрировать пробную версию Office 365. Подключаем домен:

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

 Для того, чтобы отключить домен от этой учтёной записи Office 365, необходимо выполнить следующие действия (в веб-админке этого не получится, т.к. у меня остались там синхронизированные пользователи). Пропустите данный шаг, если выполняете настройку синхронизации впервые:
- установить Sing-In assistant.
- установить Windows Azure PowerShell cmdlets. x64.x32.
- подключится через PowerShell и выполнить следующие команды:

Set-ExecutionPolicy RemoteSigned 
$LiveCred = Get-Credential
Import-Module MSOnline -verbose
Connect-MSOLservice -Credential $LiveCred

Поиск всего, связаного с моим доменом:

Get-MsolGroup -All | where {$_.ProxyAddresses -match "@exonix.ru"} > C:\Get-MsolGroup.TXT
Get-MsolContact -All | where {$_.EmailAddress -match "@exonix.ru"} > C:\Get-MsolContact.TXT
Get-DistributionGroup | where {$_.EmailAddresses -match "@exonix.ru"} > C:\Get-DistributionGroup.TXT
Get-Mailbox -ResultSize unlimited | where {$_.EmailAddresses -match "@exonix.ru"} > C:\Get-Mailbox.TXT
Get-Mailbox -SoftDeletedMailbox | where {$_.EmailAddresses -match "@exonix.ru"} > C:\SoftDeletedMailbox.TXT
Get-Msoluser -All | where {$_.ProxyAddresses -match "@exonix.ru"} > C:\Get-Msoluser.TXT
Get-Msoluser -ReturnDeletedUsers -All | where {$_.ProxyAddresses -match "@exonix.ru"} > C:\Get-MsolDeletedUsers.TXT
Get-MailUser -ResultSize unlimited | where {$_.EmailAddresses -match "@exonix.ru"} > C:\Get-MailUser.TXT
Get-User -ResultSize unlimited | where {$_.UserPrincipalName -match "@exonix.ru"} > C:\Get-User.TXT
Get-User -ResultSize unlimited | where {$_.WindowsEmailAddress -match "@exonix.ru"} > C:\Get-UserWindowsEmailAddress.TXT
Get-MailContact -ResultSize Unlimited | where {$_.EmailAddresses -match "@exonix.ru"} > C:\Get-MailContact.TXT
Get-Recipient -ResultSize Unlimited | where {$_.EmailAddresses -match "@exonix.ru"} > C:\Get-Recipient.TXT
Get-MailPublicFolder -ResultSize unlimited | where {$_.EmailAddresses -match "@exonix.ru"} > C:\MailPublicFolder.TXT

 В текстовых файлах я нашёл своих двух пользователей, которых я не мог удалить в веб-интерфейсе (и не мог поменять им адрес электронной почты):

 Удаляем пользователя и домен:

Remove-MsolUser -Userprincipalname test3_m@exonix.ru -force
Remove-MsolDomain -DomainName exonix.ru -force

Возвращаемся к настройке Office 365. Добавление пользователей можно пропустить:

 Если домен уже имеет свои ДНС сервера, то стоит переключиться на самостоятельное управление. В противном случае, можно делегировать домен ДНС серверам от MS (у регистратора прописать предложенные MS сервера).

 В ДНС зону домена необходимо добавить все следующие записи. У каждого клиента MS записи будут одинаковыми, кроме MX записи.

 Всё!

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

 Далее, я переключаюсь в бразузер IE, т.к. Chrome не захотел запускать утилиту проверки локальной инфраструктуры:

 Возвращаемся в Chrome.

 Никакая очистка среды не нужна (если не будет настоятельно требоваться):

 Скачиваем Azure AD Connect:

 Запускаем, выбираем Настроить (Customize):

 И начинается самое интересное. Azure AD Connect в настоящее время предлагает больше способов синхронизации. Если в первый раз я использовал синхронизацию паролей в облако, то сейчас я решил попробовать "сквозную аутентификацию" (Pass-through authentication). В этом случае пользователь, который пробует войти в Office 365, авторизуется не Office 365, а локальным сервером через установленный агент. А это значит, что теперь не нужно запускать синхронизацию, после смены пароля (или ждать до 30 минут). К сожалению, пока не удалось найти хоть какие-то логи на локальных серверах об авторизации пользователей...

 Вводим учётные данные от Office 365:

 Вводим учётные данные от локального AD:

 Если нужного домена нет, значит его не добавили как дополнительный UPN.

 Выбираем только те организационные еденицы, ресурсы которых будут синхронизироваться с Office 365. Это второй большой плюс Azure AD Connect (после сквозной авторизации).

 Оставляем по умолчнию (для одного домена):

 Самый главный плюс (на мой взгляд) - синхронизация на основе членства у Группе! Просто напишите имя группы и нажмите Resolve:

 Выставляем нужные опции (хотя я не уверен, что синхронизация паролей теперь нужна). Запись пароля из Облака в локальную AD возможна только в том случае, если имеется подписка Azure AD.

 Собственно, итоговый лог и скажет о невозможности настроить обратную запись паролей (из Office 365 в локальный AD):

 У меня был один тестовый пользователь, который входит в группу для синхронизации AADC. Т.к. больше никаких настроек с ним не производилось, то он "синхронизировался" в таком виде (домен входа exonixgmbh.onmicrosoft.com). Такой пользователь не сможет войти в Office 365, т.к. его "не существует" в локальном AD.

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

 Включаем циклическую синхронизацию (каждые 30 минут):

set-ADSyncScheduler -SyncCycleEnabled $true

 А вот так можно запускать синхронизацию вручную:

Import-Module ADSync
Start-ADSyncSyncCycle

 Если нужно добавить ещё несколько OU для синхронизации, то это можно сделать в Synchronization Service. Фильтры синхронизации правятся в Synchronization Rules Editor. Оба приложения запускаются с повышенными правами!

 Ещё нужно добавить, что если пользователь имеет несколько почтовых псевдонимов (Alias), то он должен быть записан в атрибут proxyAddresses, где заглавные буквы SMTP означают главный почтовый адрес, от которого будет уходить почта:

 На этом настройка синхронизации локальный учётных записей пользователей завершена. Если сравнивать её с предыдущим коннектором, то это как настраивать DirectAccess на 2012 и 2012 R2 серверах. Т.к. в предыдущем коннекторе нужно было сделать много чего вручную, а в Azure AD Connect - практически всё делается автоматом + синхронизация на основе членства в группе. Мне определённо нравится этот коннектор )

16.02.2017