Слияние объектов между Office 365 и Active Directory | Merge from Office 365 to AD
Одним из важных этапов интеграции локальной инфраструктуры Active Directory и Office 365 является синхронизация пользователей, контактов и групп из Службы Каталогов Active Directory в Office 365.
Зачастую при внедрении Office 365 в ИТ инфраструктуре уже развернут каталог Active Directory. На последнем небольшом проекте я столкнулся с ситуацией, когда компания изначально использовала Office 365, но чтобы деятельность компании соответствовала Российскому законодательству (закон о персональных данных) пришлось использовать локальный каталог Active Directory.
Комментарии к Закону:
Федеральный закон № 242-ФЗ от 21 июля 2014г. (далее «Закон»), вносящий поправки в законодательство о персональных данных, вступившие в силу с 1 сентября 2015 года, накладывает на операторов персональных данных граждан Российской Федерации, осуществляющих сбор таких персональных данных, определенное требование о локализации указанной информации на территории России. При сборе персональных данных операторы обязаны обеспечить запись, систематизацию, накопление, хранение, уточнение (обновление, изменение) и извлечение персональных данных граждан Российской Федерации с использованием баз данных, находящихся на территории Российской Федерации.
Для того, чтобы связать пользователей из Office 365 с пользователями в Active Directory, необходимо создать в локальном каталоге AD идентичных пользователей и настроить синхронизацию через ADConnect. В этой схеме есть один существенный нюанс:
Исходя из следующией статьи: How to use SMTP matching to match on-premises user accounts to Office 365 user accounts for directory synchronization
Для того чтобы учетная запись пользователя в Office 365 была синхронизирована с локальной учетной записью, необходимо, чтобы атрибут E-mail в локальной учетной записи соответствовал атрибуту Primary E-mail Address для облачной.
Слияние возможно только когда у облачного пользователя включен почтовый ящик. Со всеми ограничениями можно ознакомиться из статьи выше.
В некоторых источниках в качестве атрибута на основе которого происходит слияние добавляют Primary E-mail Address в атрибут proxyAddress локального пользователя, но я в своем решении так же заполнял и атрибут E-mail.
В случае когда Active Directory не имеет ни одного пользователя, мы создаем их на основе пользователей из Office 365.
Кратко обозначим пункты, которые необходимо выполнить для решения задачи:
- В случае если планируется сменить политики именования или политики заполнения атрибутов я считаю, что проще это сделать первоначальным этапом в Office 365.
- Экспортируем всех пользователей у которых подключен Exchange Online.
- Импортируем пользователей в локальный каталог Active Directory.
- Выпполняем синхронизацию акаунтов.
- Проверяем результат.
Остановлюсь более подробно на 2 и 3 пункте
К сожалению у меня нет навыков в написании скриптов, тоесть совсем нет 🙂 поэтому простите меня за мою рукож..ть..
Задача скрипта — экспортировать пользователей со всеми их описательными параметрами, а так же для каждого пользователя из параметра Proxyaddress выделить основной адрес SMTP. Основной адрес отображается заглавными буквами «SMTP».
Экспорт пользователей Office 365
Get-MsolUser -all | Select-Object userprincipalname, displayName, FirstName, City, Country, Department, LastName, MobilePhone, Office, PhoneNumber, PostalCode, StreetAddress, State, Title, Fax, @{L = «ProxyAddresses»; E = { $_.ProxyAddresses -join «;»}}, @{e={$_.ProxyAddresses -cmatch ‘^SMTP\:.*’};name=’Primaryaddress’}|Export-Csv -Path c:\temp\users.csv -NoTypeInformation -Delimiter «;»
Скрипт создает пользователей в организационном подразделении «Not_sync_users» с одним и тем же паролем и добавляет Proxy адреса.
Import-Csv «C:\temp\script\users_test.csv» -Delimiter «;» | foreach-object {
New-ADUser -Name $_.DisplayName -SamAccountName $_.UserPrincipalName.Split(«@»)[0] -DisplayName $_.Displayname -UserPrincipalName $_.UserPrincipalName -GivenName $_.FirstName -SurName $_.LastName -City $_.City -Fax $_.Fax -Department $_.Department -MobilePhone $_.MobilePhone -Office $_.Office -OfficePhone $_.PhoneNumber -PostalCode $_.PostalCode -StreetAddress $_.StreetAddress -State $_.State -EmailAddress $_.Primaryaddress.Split(«:»)[1] -Title $_.Title -Path «OU=Not_sync_users,OU=CORP,DC=domain,DC=com» -AccountPassword (ConvertTo-SecureString «ВашПароль» -AsPlainText -force) -Enabled $False -PassThru
$proxy = $_.ProxyAddresses -split ‘;’
Set-ADUser -Identity $_.UserPrincipalName.Split(«@»)[0] -Add @{proxyAddresses= $proxy}
}
Так как у облачных пользователей нет SAM атрибута, но в On-prem AD это обязательный атрибут, в качестве SAM берется атрибут UserPrincipalname из таблицы и выбирается массив с названием пользователей
$_.UserPrincipalName.Split(«@»)[0]
Далее осталось включить пользователей, перенести их в OU, где происходит синхронизация с облаком и дождаться обновления пользователя на портале, его статус изменится на «Sync…».
Сервер времени в домене с помощью групповых политик | How to setup Time server in Domain through GPO
Настройку серверов времени удобно производить с помощью групповых политик. Преимущество в том, что в случае смены PDC роли, все настройки синхронизации с внешним NTP узлом будут применены автоматически.
Для настройки необходимо:
- Проверить доступность UDP 123 от PDC до источника времени
- Создать WMI фильтр:
Select * from Win32_ComputerSystem where DomainRole = 5
Параметр Domain Role назначается всем компьютерам домена, его можно посмотреть с помощью команды:
wmic computersystem get domainrole — локально на компьютере.
wmic /node:”M1” computersystem get domainrole — удаленно на компьютере.
Value | Meaning |
0 | Standalone Workstation |
1 | Member Workstation |
2 | Standalone Server |
3 | Member Server |
4 | Backup Domain Controller |
5 | Primary Domain Controller |
- Создать GPO TimeServices
И включить следующие параметры в разделе Сomputer Configuration/Policies/Administrative Templates/System/Windows Time Service/Time Providers
1. Enable Windows NTP Client: Enabled
2. Enable Windows NTP Server: Enabled
3. Configuring Windows NTP Client: Enabled
В разделе NTP Client значение Type — NTP означает синхронизацию с внешним источником.
NtpServer — через пробел перечисляются серверы «внешние» NTP, формат в котором нужно указывать:
ntpserver1,0x01 ntpserver2,0x01 ntpserver3,0x01
SpecialPollInterval — время в секундах через которое сервер PDC будет синхронизироваться с внешним сервером. Этот параметр работает в случае указания флага 0x01. По умолчанию сервер времени синхронизруется с источником без определенного интервала.
- Обновить групповую политику на PDC:
gpupdate /force
- Перезапустить сервис времени на PDC.
- Проверить настройки:
w32tm /query /status — текущий статус настройки времени на узле.
w32tm /query /source — отображает источники времени узла.
w32tm /resync — ручная синхронизация времени клиента с сервером.
Если для настройки времени используется GPO — настройки хранятся в разделе реестра:
HKLM\SOFTWARE\Policies\Microsoft\W32Time\Parameters
Если для настройки времени используется ручная настройка — настройки хранятся в разделе реестра:
HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters