Office 365 hybrid configuration: Как “отвязать” пользователя от синхронизации и сделать его только облачным

Воистину, бесчисленны возможные варианты настройки инфраструктур! Недавно столкнулся с такой казалось бы редкой ситуацией. Пользователь имел учётку в ЕСК AD и почтовый ящик on-prem. Когда в Компании развернули гибридную конфигурацию с O365, его почтовый ящик переехал в Облако. Прошло ещё какое-то время, и по определенным причинам возникла необходимость удалить его неиспользуемую учётку в AD, но оставить ему облачный почтовый ящик. Как это сделать?

Ответ прост: созданием в Облаке новой учётки и прилинкованием к ней почтового ящика от доменной учётки.

При аутентификации в Облаке если пользователь использует федеративный домен, происходит безусловная попытка аутентификации через ADFS. Наша же задача – обеспечить аутентификацию в Облаке. Это значит, что пользователь, для которого мы решаем поставленную задачу, должен иметь UPN-имя, в котором не будет использоваться федеративный домен.

Таким образом, чтобы решить данную задачу, необходимо иметь в Облаке второй зарегистрированный домен, не являющийся федеративным. Можно использовать домен @orgname.onmicrosoft.com, либо создать/выбрать другой, более удобный. Это должен быть внешний домен. Этот домен не может быть поддоменом федеративного домена, так как если корневой домен федеративный, то и все дочерние являются тоже федеративными. Почтовые сообщения на данный домен должны доставляться напрямую в Облако.

Первым делом нужно удалить пользователя в AD, и провести DirSync. Пользователь удалится и в Облаке. Его учётная запись и почтовый ящик поместятся в облачную Корзину.

Посмотреть список пользователей в Корзине (используя шелл Microsoft Online Services Module for Windows PowerShell):  Get-Msoluser –Returndeletedusers   (список ПЯ в Корзине: Get-Mailbox –SoftDeletedMailbox)

Теперь нужно удалить пользователя из облачной Корзины (используя шелл Microsoft Online Services Module for Windows PowerShell):  remove-MsolUser –UserPrincipalName user@domain.ru –RemoveFromRecycleBin (domain.ru в нашем примере = это федеративный домен)

Учётка из корзины удалилась, но почтовый ящик остался, и его стало возможным прилинковать к другой учётной записи.

Посмотреть удалённые ПЯ можно так: Exchange Control Panel –> Manage My Organization –> Users & Groups –> Mailboxes –> кнопка Deleted Mailboxes  или командой get-removedmailbox

Далее в облачной Exchange PowerShell Console одной командой одновременно создаём нового, уже 100%-облачного пользователя, и пристёгиваем ему из корзины тот самый почтовый ящик: 

new-mailbox –RemovedMailbox user @domain.ru –MicrosoftOnlineServicesID user@domain.ru –Name <username> –Password (ConvertTo-SecureString –String <password> –AsPlainText –Force)

Теперь для новосозданного в Облаке пользователя следует добавить почтовый адрес, который являлся ранее его основным, как Primary SMTP Address (выполняется в Cloud EMS):

Set-Mailbox user@orgname.onmicrosoft.com -EmailAddresses @{add="user@domain.ru"}

Set-Mailbox user@orgname.onmicrosoft.com –PrimarySMTPAddress user@domain.ru

Наконец, из-за односторонней репликации АК созданный в Облаке пользователь с ПЯ не появится в On-prem-адресной книге без ручного добавления. Поэтому следует добавить его в качестве mail-контакта (On-Prem EMS):

New-MailContact -Name <username> -ExternalEmailAddress user@orgname.onmicrosoft.com

Чтобы этот контакт не синхронизировался с Облаком (этого нельзя делать из-за совпадений атрибутов Proxy address у контакта и соответствующей уч.записи пользователя в Облаке), необходимо переместить контакт в организационное подразделение, не синхронизируемое с Облаком (как это сделать – описано в этой статье). После нужно запустить синхронизацию Dirsync.

Также следует заново добавить пользователя во все списки рассылки, в которых он состоял до процедуры реинкарнации.

Чтобы начать работать с почтовым ящиком, нужно будет присвоить новосозданной облачной учётке лицензию и выждать минут 5-10. При первом входе через Портал система попросит пользователя сменить пароль на новый.

Если при попытке доступа к ПЯ система скажет «учётная запись отключена» – следует просто подождать подольше и обновить экран.

Какие неудобства несёт в себе предлагаемый метод?

• у пользователя отныне будет другой login name (UPN с другим именем домена);
• необходимо заново перепрописывать пользователя во всех списках рассылки / группах безопасности (если он, например, использовал общие почтовые ящики);
• при первом обращении к Порталу пользователь должен набрать временный пароль и изменить его на постоянный (это означает также, что пользователю необходимо будет как-то передать его временный пароль);
• процедура не проста: требует последовательного выполнения нескольких операций, в том числе удаления и последующего восстановления почтового ящика, что несёт в себе, хотя и только потенциально, определенные риски;
• процедура предусматривает определенный период простоя – когда пользователь не сможет отсылать и получать письма.

Каков полученный результат?

• пользовательская доменная учётная запись исчезает (т.е. пользователь больше никак с доменом AD не завязан);
• пользователь продолжает иметь свой почтовый ящик с привычным емейл-адресом;
• пользователь виден всем сотрудникам компании в Адресной Книге – и в onprem, и в облачной.

* * * * *

А вот ситуация более простая: удалять учётку в домене не требуется. Тогда и решение на порядок более простое и изящное. Рассмотрим его.

Итак, почтовый ящик доменного пользователя находится on- premise. 

Всё вышеописанное, касающееся нефедеративного домена и UPN-суффикса, остаётся в силе.

Дополнительный – нефедеративный - домен нужно зарегистрировать в Облаке и в on-prem-каталоге Active Directory как альтернативный UPN-суффикс.

Далее нужно изменить пользователю в AD его UPN-суффикс на нефедеративный, и провести DirSync.

Следующий шаг: изменить пароль пользователю в Облаке (через веб-портал). Эта операция станет доступна после смены login-имени на имя с нефедеративным доменом. Сообщить пользователю новый временный пароль.

Присвоить соответствующую лицензию облачному пользователю.

Переместить почтовый ящик пользователя в Облако стандартным образом.

После окончания перемещения почтового ящика пользователь должен зайти в него через веб-Портал, используя новый временный пароль – сменив его на постоянный, известный только ему. С этого момента пользователь может подключаться к своему уже Облачному почтовому ящику через веб или через Outlook (при наличии лицензии).

Какие неудобства несёт в себе предлагаемый метод?

• у пользователя отныне будет другой login name (UPN с другим именем домена);
• обязательна смена пароля.

Ещё раз подчеркнём: в вышеописанном решении учётная запись пользователя в домене – остаётся. Однако аутентификация в AD DS - не производится.

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