Синхронизация локального каталога 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
