Подробности о новом DirectorySync

Продолжим разговор об использовании функционала синхронизации паролей между on-prem и Облаком.

Важно понимать, что синхронизация пароля происходит не по расписанию синхронизации (которое по умолчанию раз в 3 часа), а per-user, только при смене пароля на стороне on-prem.

Задачка. Скажите, может ли быть так, что у пользователя два разных пароля – в Облаке и в домене? Да, может. Так как пользователь не федеративный, система позволяет сменить ему облачный пароль. Правда в нашем случае, обнаружив что это пользователь, чей пароль синхронизуется из on-prem, Портал не разрешит делать это самому пользователю, но администратору разрешит сделать reset.

То есть, при смене пароля в Облаке, до момента последующего изменения пароля учётки в on-prem пользователь должен будет подключаться к облачным сервисам с этим “облачным” паролем. Как только на стороне on-prem пароль доменной учётной записи будет сменён, будет проведена синхронизация, и облачный пароль затрётся новым on-prem-значением.

Сколько времени проходит от момента ресета пароля в AD до его синхронизации с Облаком? Пара минут.

Конечно, выставлять отдельный пароль облачной учётке при включённой синхронизации паролей незачем, и описанный выше пример вряд-ли будет использоваться в реальной жизни. Но в следующем примере мы видим, что тем не менее нюансы могут возникать.

Пример 2. У всех пользователей в соответствующих Облачных учётках устанавливается значение “Password never expires”. И может так сложиться, что пароль в локальной AD уже отэкспайрился, а в Облако пользователь может продолжать под ним заходить.

Следующая тема:

Как быть, если вы уже настроили ADFS и пометили свой домен как федеративный? Чтобы начать использовать синхронизацию паролей, потребуется сконвертировать домен в обычный командой  convert-msoldomaintostandard –domainname domain.name –skipuserconversion $false –passwordfile c:\password.txt

Обратите внимание, что файл с временными паролями для всех синхронизируемых пользователей будет создан при преобразовании. Но использовать его пользователям не придётся.

Проверьте, что служебная учётка, под которой стартуют службы Forefront Identity Manager Synchronization Service и Windows Azure Active Directory Sync Service (например, на моём тестовом ПК это некая учётка AAD_946f477892ae), входит в группу локальных администраторов сервера DirSync.

Сразу после этой команды проведите полную синхронизацию паролей из on-prem в Облако, запустив визард нового Дирсинка в первый раз.

Форсировать синхронизацию всех сразу паролей onprem > online можно следующим образом:

• Создайте ключ реестра и в нём DWORD value:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSOLCoExistence\PasswordSync\ FullSyncRequired="1"

• В ACL ключа пропишите сервисный аккаунт, под которым стартуют службы Forefront Identity Manager Synchronization Service и Windows Azure Active Directory Sync Service, и задайте ему права:

           

• Перезапустите службу Forefront Identity Manager Synchronization Service. После полной синхронизации паролей значение FullSyncRequired в реестре изменится на “0” автоматически.

Переключение на новые правила аутентификации провести незаметно (прозрачно) для пользователей трудно. Поэтому сразу выберите для этих работ правильное время и уведомите всех заранее о кратковременных возможных затруднениях входа в Облако в этот временной промежуток.