Как выполнить перенос домена Active Directory для Dell Security Server

• Dell Security Management Server (ранее Dell Data Protection | Enterprise Edition) установлен и присоединен к домену.
• Существующий домен добавлен в раздел «domain» в консоли WebUI.
• Конечные точки активированы на сервере.
• Требуется перенос домена.
• Мы планируем также перенести историю SID для объектов AD.
• Конечные точки имеют полное подключение к серверу и могут извлекать политики в старом домене перед началом процесса переноса домена.
• Зашифрованные данные на конечных точках полностью доступны, конечные точки активированы и их можно деактивировать и повторно активировать. Мы можем подтвердить, что активации выполняются без каких-либо проблем, выполнив команду WSDeactivate на любой конечной точке.

Общие шаги довольно несложные, но необходимо понимать, что если весь процесс не будет выполнен должным образом, данные могут быть потеряны или потребуется восстановление машин. И наконец, хотя этот процесс может быть выполнен на любой версии сервера и клиента Dell Security Management Server, Dell Technologies рекомендует установить как минимум версию клиента 8.3.0 и версию сервера 8.5, поскольку с тех пор было внесено несколько улучшений, которые упрощают весь процесс переноса на стороне Dell Security Management Server. Ниже представлен общий обзор процесса и наиболее важных вопросов.

Первым шагом является понимание необходимости переноса домена. Существуют ситуации, когда компания переходит, например, на Office 365, где достаточно добавить псевдоним и установить его в качестве основного UPN для пользователей AD. Это не действительный перенос домена, и на сервере Dell Data Protection | Enterprise Edition не требуется никаких действий, кроме добавления нового псевдонима в список псевдонимов домена в разделе Settings, Domain Alias List. Если создан новый домен, а объекты AD необходимо переместить из старого выведенного из эксплуатации домена в новый, то в этом случае необходимо запланировать перенос домена.

Каждый раз, когда планируется перенос домена, первым шагом является перенос истории SID. Для успешного выполнения переноса домена на стороне Dell Security Management Server необходимо сохранить историю SID, иначе объекты AD будут считаться новыми для Dell Security Management Server и, следовательно, после повторной активации мы не сможем использовать те же ключи шифрования. Dell требует перенести историю SID. Мы не будем тратить время на выполнение переноса домена, так как это не задача Dell Data Protection | Encryption, но существует несколько инструментов, например ADMT от Microsoft, которые позволяют организации перенести домен A в домен B. Как указано выше, для сохранения сохранения ключей требуется перенос истории SID. Перенос истории SID означает, что мы добавляем к атрибуту истории SID в AD предыдущего переноса SID пользователя, гарантируя непрерывность перемещаемых объектов.

Как правило на стороне AD:

• При переименовании любого объекта значение атрибута objectSID (SID) не изменяется. При перемещении объекта из одного домена в другой objectSID должен измениться, поскольку его часть зависит от домена, а старый SID добавляется в атрибут SIDHistory (при условии, что он перенесен). Можно просмотреть SIDHistory с помощью ADSI Edit (можно просмотреть в шестнадцатеричном или десятичном формате). Если значения отсутствуют, история SID отсутствует или объект никогда не перемещался из другого домена.
• SIDhistory доступна только при переносе учетных записей между доменами или лесами.

Ниже приведен снимок экрана с инструкциями, чтобы определить, была ли SIDHistory перенесена с помощью редактора атрибутов:

Убедившись, что SIDHistory перемещенных пользователей и машин также была перемещена, мы можем продолжить конфигурацию Dell Security Management Server. Если требуются дополнительные сведения о выполнении переноса домена и сохранении истории SID, см. следующую документацию Microsoft:

• https://www.microsoft.com/en-us/download/details.aspx?id=19188
• https://technet.microsoft.com/en-us/library/cc974332(v=ws.10).aspx
• https://technet.microsoft.com/en-us/library/cc974384(v=ws.10).aspx

Ниже приведены действия, которые выполняются во время переноса домена на стороне Dell Security Management Server.

1. На стороне клиента:
   • Мы решаем UPN пользователей для SID. Мы ищем их SID в файле хранилища. Мы не находим его.
   • Мы решаем, что это новый пользователь, и связываемся с сервером безопасности, передавая пароль UPN в качестве типичного запроса на активацию.
2. На стороне сервера:
   • Мы получили запрос на активацию. Мы связываемся с Active Directory и ищем UPN. После этого в процессе сортировки пользователей мы заметили, что SID в таблице «Entity» не соответствует SID в AD. Мы исследуем SIDHistory , чтобы проверить SID в таблице «Entity». Если мы не нашли его, мы отмечаем исключение, и активация не будет выполнена, так как у нас уже есть этот SCID. Когда мы находим SID, мы добавляем в таблицу «Entity» новый SID (в части UID первая часть является доменом, и мы обновляем ее и обновляем часть домена конечной точки).
   • Затем мы передаем клиенту старые ключи, политику, DCID и т. д. (как в случае повторной активации).
3. Снова на клиенте:
   • Конечная точка получает эту информацию и добавляет запись в файл credsys.vlt, что пользователь активирован, а пользователь на этом этапе входит в систему в обычном режиме.

Ключевым пунктом на стороне Dell Security Management Server является понимание необходимости добавления нового домена в веб-интерфейс пользователя для работы с новыми и старыми пользователями во время активации или повторной активации.

При переносе домена мы не добавляем новый домен в консоль сервера Dell Security Management Server, ЕСЛИ там находится родительский объект корневого домена старого и нового перенесенных доменов. Достаточно добавить новый домен в виде псевдонима в разделе «Settings», «Domain Alias List». (И мы предполагаем, что между родительским и новым дочерним доменом существует двунаправленное доверие.) Сервисная учетная запись для корневого домена должна быть настроена, возможно, в родительском домене. Если вместо этого мы переносим домен A.local в B.local, и два домена не являются дочерними относительно одного корневого домена, или они принадлежат другому лесу, нам требуется новый домен, который добавляется в консоли, так как мы должны привязать существующие конечные точки к новому домену и новой служебной учетной записи.

Понимание вышеперечисленного делает правильную настройку Dell Security Management Server ключевым фактором, поскольку в противном случае после переноса мы сталкиваемся с несколькими проблемами. Понимание типа доверия между этими доменами и их корневыми доменами (если таковые имеются), а также списка их текущих доменов в консоли Dell Security Management Server также имеет большое значение. Правило очень простое: если между родительским и дочерним сервером есть определенный уровень доверия, то будет достаточно настроить корневой домен и псевдонимы на сервере Dell Data Protection | Enterprise Edition. В противном случае мы должны добавить в Dell Security Management Server столько дочерних доменов, сколько их реальных поддоменов, и это правило также относится к переносу домена.

И наконец, мы *никогда* не должны добавлять одновременно дочерний и родительский домен, поскольку потенциальная видимость одного пользователя на обоих уровнях создает для нас новые проблемы. И удаление домена не является (пока что) полностью поддерживаемой задачей на стороне Dell Security Management Server.

Если используется клиент версии 8.2.1 или более ранней и сервер версии 8.3.1 или более ранней, WSDeactivate является обязательным шагом, так как часть домена конечной точки не была автоматически переименована на стороне сервера. Это не относится к последним сборкам Dell Security Management Server или конечной точки.

Старые домены нельзя удалить из базы данных Dell Security Management Server вручную или с помощью консоли. Это связано с тем, что Dell Security Management Server выполняет поиск пользователя или группы, а затем определяет принадлежность к домену. Из-за этого при удалении домена все объекты, которые являются частью этого домена, также должны быть удалены. На этом этапе ни один из вариантов не поддерживается. Dell исследует изменение этого поведения в будущих сборках Dell Security Management Server, хотя на этом этапе это не поддерживается или не является нужной задачей. В качестве примечания, если мы хотим отметить (вручную) домен как удаленный в базе данных, то мы будем получать ошибку в журналах сервера каждые 15 минут для всех связанных пользователей и групп, оставшихся без домена.

Если Shield необходимо удалить на перенесенной конечной точке, необходимо выполнить те же действия, которые необходимы для принудительной обычной (не доменной) повторной активации с тем же идентификатором Shield. В общих зашифрованных файлах необходимо принудительно применить тот же DCID в реестре, прежде чем разрешить повторную активацию конечной точки в Dell Data Protection | Enterprise Edition Server или Dell Security Management Server. Если у вас возникли вопросы, обратитесь в службу технической поддержки.

Нет, новая лицензия домена не требуется начиная с Dell Data Protection | Enterprise Edition Server 8.x. В более старых версиях Dell Data Protection | Enterprise Edition Server по-прежнему требуется новая лицензия. Для получения дополнительной информации обратитесь в службу технической поддержки.