В предыдущей статье мы начали обсуждать процесс миграции базовой инфраструктуры Microsoft, затронули тему интеграции двух инфраструктур, рассмотрели настройку разрешения имен между двумя инфраструктурами.
Первую часть можно найти здесь.
Аутентификация.
Следующим шагом сближения двух систем будет настройка аутентификации. Нам необходимо создать доверительные отношения между исходной инфраструктурой и целевой.
Для миграции из одного домена в другой, будет достаточно внешних односторонних доверительных отношений, так, чтобы исходный домен доверял целевому. Исходный -> целевой. В такой конфигурации смигрированные системы смогут получать доступ (аутентифицироваться) к еще несмигрированным системам. А если у нас есть системы, которые взаимодействуют друг с другом, то мы должны такие системы мигрировать как группу, одной порцией.
Использование односторонних доверительных отношений усложняет процесс миграции. Необходимо отслеживать, какие системы с какими взаимодействуют и в каких направлениях. В больших инфраструктурах отследить такие связи очень сложно. Поэтому, если есть такая возможность, создавайте внешние доверительные отношения в обе стороны. Исходный -> целевой и целевой -> исходный.
Помимо определения направления, вам необходимо определить тип доверительных отношений. Внешние доверительные отношения могут создаваться между лесами и доменами (non-Windows Kerberos-сферы - третий тип, но к нам он не относится).
Если уровни лесов Windows Server 2003 или выше, то мы можем создать доверительные отношения уровня леса. Такие доверительные отношения создаются в корневых доменах леса и являются транзитивными на уровне корневых доменов. Это означает, что все домены из одного леса, будут доверять доменам другого (доверяемого) леса. На уровне лесов, если брать их как единый объект, транзитивности нет.
Если уровень леса ниже Windows Server 2003 и повысить его нельзя ни при каких условиях, то придется создавать внешние доверительные отношения между доменами. Минус по сравнению с доверием между лесами очевиден - таких доверительных отношений необходимо создать больше.
Способов создания доверительных отношений достаточно много: оснастка Active Directory Domains and Trusts, скрипты, утилита netdom, использование различных API (Win32 API, классы .Net Framework) и т.д.
Стоит отметить, что утилита netdom не умеет создавать доверительные отношения между лесами, поэтому вам придется воспользоваться другими способами. Самый простой из них это оснастка Active Directory Domain and Trusts. Подробнее о создании доверительных отношений на уровне леса - http://technet.microsoft.com/en-us/library/cc780479%28WS.10%29.aspx.
А вот для создания доверительных отношений между доменами netdom подойдет.
Создаем односторонние доверительные отношения:
Netdom trust "source.com" /d:"target.com" /ud:"администратор target.com" /pd:"пароль администратора target.com" /uo:"администратор source.com" /po:"пароль администратора source.com" /add
Добавляем /twoway и получаем двухсторонние доверительные отношения:
Netdom trust "source.com" /d:"target.com" /ud:"администратор target.com" /pd:"пароль администратора target.com" /uo:"администратор source.com" /po:"пароль администратора source.com" /add /twoway
Основными структурами защиты доступа к данным, таким как файлы, принтеры, реестр, являются избирательные списки контроля доступа - DACL (Discretionary Access Control List). Элементы из DACL описывают уровень доступа, который будут иметь участники безопасности при обращении к защищенным данным. Участники безопасности представлены в виде идентификаторов безопасности- SID (Security Identifier). В Active Directory такие идентификаторы есть у объектов групп, пользователей, компьютеров. При миграции, в целевой инфраструктуре создаются новые учетные записи с новыми идентификаторами безопасности (далее основной SID). И получается, что доступ к данным у учетных записей с новыми SIDами должен пропасть. Но есть возможность перенести старые идентификаторы, сохранив их в атрибуте SIDHistory (назовем их вторичными SIDами). Контроль доступа к данным учитывает оба типа SIDов. Доступ к данным в этом случае должен сохраниться.
С одной стороны SIDHistory штука хорошая, с другой стороны создает определенные проблемы с безопасностью. Получается, что сисадмин из доверяемого домена может прописать в SIDHistory идентификатор полномочной учетной записи из доверяющего домена, и тем самым, получит доступ к каким-либо важным данным. Чтобы от этого защититься, придумали функционал фильтрации SIDов. Первый - фильтрация только SIDHistory, а второй, более строгий - фильтрация всех "инородных" SIDов. Инородными считаются идентификаторы, не относящиеся к доверяемому домену (или лесу, если это доверительные отношения на уровне лесов). Этот функционал определен на уровне доверительных отношений и включается для всех внешних доверительных отношений, создаваемых на контроллерах домена под управлением Windows Server 2000 SP4 или выше.
Подробнее о нецелевом использовании SIDHistory - http://gexeg.blogspot.com/2009/12/active-directory.html
ADMT позволяет переносить SID в SIDHistory. Но для того чтобы доступ к еще несмигрированным ресурсам сохранился, мы должны отключить фильтрацию SIDов.
Отключить фильтрацию SIDHistory можно с помощью утилиты netdom. Для этого введите следующую команду:
Netdom trust source.com /d:target.com /ud:"администратор target.com" /pd:"пароль администратора target.com" /uo:"администратор source.com" /po:"пароль администратора source.com" /EnableSidHistory:yes
Если необходимо проверить статус фильтрации SIDHistory введите туже самую команду, но без параметра yes:
Netdom trust source.com /d:target.com /ud:"администратор target.com" /pd:"пароль администратора target.com" /uo:"администратор source.com" /po:"пароль администратора source.com" /EnableSidHistory
Также необходимо отключить второй механизм - фильтрацию всех "неродных" SIDов:
Netdom trust source.com /d:target.com /ud:"администратор target.com" /pd:"пароль администратора target.com" /uo:"администратор source.com" /po:"пароль администратора source.com" /Quarantine:no
Проверить статус можно с помощью параметра /Querantine без значения no:
Netdom trust source.com /d:target.com /ud:"администратор target.com" /pd:"пароль администратора target.com" /uo:"администратор source.com" /po:"пароль администратора source.com" /Quarantine
Перечисленные команды отключают фильтрацию SID на ресурсной стороне. То есть на той стороне, где находятся ресурсы, к которым необходимо получить доступ. Мы это сделали на стороне source.com.
Но у нас есть системы из source.com, которые могут обращаться к смигрированным ресурсам в домене target.com. Нужно ли отключать фильтрацию SID в этом случае? Скорее всего, да. Во-первых, исходный домен мог когда-то уже участвовать в процессе миграции. У учетных записей этого домена заполнен атрибут SIDHistory, SIDы которого участвуют в назначении прав на ресурсы. Во-вторых, пользователи (или компьютеры) могут быть членами универсальных групп своего леса. А универсальные группы могут являться объектами другого домена. SIDы этих групп будут отличны от SIDа домена пользователя и, при включенной фильтрации, будут отфильтрованы.
Если у нас первый случай, то мы должны выполнить команду netdom с параметрами /EnableSidHistory:yes и /Quarantine:no.
Если у нас доверительные отношения созданы на уровне лесов, то вторая описанная проблема не возникает. Если доверительные отношения построены на уровне отдельных доменов, то необходимо отключить карантин - /Quarantine:no.
А что если, по каким-то причинам, нам нельзя мигрировать вторичные SIDы или отключать фильтрацию (или и то и другое)? Решение этой задачи есть. Но при этом сам процесс миграции меняется, становится более сложным в реализации, по сравнению с традиционным. Если всё-таки есть возможность отключить фильтрацию на время миграции и переносить SIDы, то лучше это сделать. Подробнее об особенностях миграции в такой конфигурации поговорим немного позже.
Подробнее о фильтрации SID:
http://technet.microsoft.com/en-us/library/cc772816%28WS.10%29.aspx (Disable SID filter quarantining)
http://technet.microsoft.com/ru-ru/library/cc772633%28WS.10%29.aspx (Configuring SID Filtering Settings)
О создании внешних доверительных отношений - http://technet.microsoft.com/en-us/library/cc738617%28WS.10%29.aspx
О синтаксисе netdom trust - http://technet.microsoft.com/en-us/library/cc835085%28WS.10%29.aspx.
Необходимые порты TCP/IP для создания доверительных отношений (а также их дальнейшей работы) - http://technet.microsoft.com/ru-ru/library/cc756944%28WS.10%29.aspx
Окружение пользователя.
С доверительными отношениями разобрались, переходим к виртуализации пользовательского окружения.
Перемещаемые профили (roaming profiles) пользуются большим спросом. Плюсов от их использования очень много, минусов практически нет. Но при миграции возникают определенные трудности использования этого функционала. Если конкретнее, то перемещаемые профили пользователей не загружаются между лесами. Это означает, что если пользователь из одного леса зайдет на рабочую станцию (или сервер) в другом лесу, то он получит пустой рабочий стол. Его перемещаемый профиль не загрузится. Более того, не отработают и групповые политики назначенные пользователю в его "родном" домене или лесу. Такое поведение наблюдается, начиная с Windows 2000 SP4.
Можно избежать этой проблемы, мигрируя пользователей и компьютеры, на которые заходят пользователи, одновременно. Перед началом миграции, как правило, составляются списки соответствия рабочих станций и пользователей, но эти списки далеки от идеала. Это и понятно, отследить такие связи при миграции больших инфраструктур очень сложно. Поэтому лучше исключить такие ошибки и не тратить на их исправление свое время и силы.
В случае с серверами, скорее всего, придется включить отработку групповых политик и загрузку перемещаемых профилей, поскольку серверы мигрируются после пользователей (как правило). Особенно актуально для терминальных серверов.
Чтобы включить обработку групповых политик пользователей и загрузку перемещаемых профилей между лесами, необходимо сделать следующее:
1) В домене исходного леса создайте групповую политику.
2) С помощью административных шаблонов установите значение параметра Computer Configuration\Administrative Templates\System\Group Policy\Allow Cross-Forest User Policy and Roaming Profiles в значение Enabled.
3) Полезно будет отключить конфигурацию пользователя, поскольку она не используется.
4) Необходимо продумать фильтрацию групповой политики. Будет это на основе иерархии, по группам безопасности или фильтрами WMI, решать вам. Но хотелось бы еще раз отметить, что данные настройки должны распространяться на компьютеры. Если будете использовать фильтрацию по группам, то делайте это универсальными или глобальными группами, поскольку в многодоменной среде есть особенности использования доменнолокальных групп при назначении прав на объекты каталога.
5) Если доменов в лесу несколько, то необходимо, либо создать несколько объектов групповых политик и повторить перечисленные выше действия, либо привязать существующую групповую политику. Лучше создавать дополнительные, иначе будет труднее отлавливать ошибки.
Те же действия, с 1 по 5, необходимо проделать в целевом лесу. Хотелось бы отметить, что в целевом домене это может не понадобиться, если у вас есть ограничения на создание доверительных отношений. Эти ограничения описаны в разделе аутентификация, выше.
В описании к административным шаблонам указано, что настройка Allow Cross- Forest User Policy and Roaming Profiles относится только к Windows Server 2003 и выше, но на самом деле, работает для Windows 2000 SP4 и выше. Для более низких версий, описанной проблемы не возникает - профили загружаются в любом случае.
Конечно же, для того, чтобы запускались хоть какие-то групповые политики из нового леса, необходимо перенести эти групповые политики. Но об этом поговорим в следующих статьях.