Главная > Office 365 > Слияние объектов между Office 365 и Active Directory | Merge from Office 365 to AD

Слияние объектов между 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.

Кратко обозначим пункты, которые необходимо выполнить для решения задачи:

  1. В случае если планируется сменить политики именования или политики заполнения атрибутов я считаю, что проще это сделать первоначальным этапом в Office 365.
  2. Экспортируем всех пользователей у которых подключен Exchange Online.
  3. Импортируем пользователей в локальный каталог Active Directory.
  4. Выпполняем синхронизацию акаунтов.
  5. Проверяем результат.

Остановлюсь более подробно на 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…».

 

 

Рубрики:Office 365
  1. Комментариев нет.
  1. No trackbacks yet.

Оставьте комментарий