Для проведения реконфигурации и объединения доменной структуры Windows NT существует множество причин. Например, это может быть связано с выполнением рекомендаций Microsoft о переходе к плоской доменной структуре в рамках подготовки к Windows 2000. Возможно, реальная обстановка изменилась и первоначально выбранная концепция построения доменов NT уже не соответствует действительности. Или, может быть, планируется использовать новые средства администрирования, такие как Enterprise Administrator (EA) от компании Mission Critical Software или DM/Administrator от компании FastLane Technologies.

Независимо от причин объединения доменов, реконфигурация доменной структуры даст множество преимуществ. Например, она позволит уменьшить общую стоимость владения (total cost of ownership - TCO) сетью. Экономия средств достигается за счет сокращения числа доверительных отношений и контроллеров доменов, а также за счет возможности централизованного администрирования системы. Кроме того, реконфигурация сети открывает новые перспективы для ее расширения, для внедрения новых инструментов и проведения дальнейших модернизаций.

Конфигурации доменов в различных организациях отличаются друг от друга. Компания Microsoft рекомендует четыре основных модели доменной структуры: с одним доменом, с одним главным доменам, с несколькими главными доменами и домены, доверяющие друг другу. Чтобы решить, какая именно модель нужна, необходимо принять во внимание размещение пользователей, распределение ресурсов и физическое и географическое положение организации. При планировании перехода на Windows 2000, Microsoft рекомендует сократить доменную структуру до одного домена.

В этой статье рассматриваются методы реконфигурации существующей структуры доменов и подробно освещаются вопросы, связанные с выбором наилучшей доменной структуры.

Первым шагом на пути к объединению доменной структуры является выработка стратегии. Одна из главных преград здесь связана с тем, что необходимо преодолеть сопротивление к переменам внутри организации. Убедить пользователей пожертвовать имеющимися у них правами, либо возложить на себя большую ответственность - это непростая задача. Чтобы ускорить процесс, нужно тщательно обсудить планы и цели проекта с каждым из пользователей. Для определения целей и параметров проекта требуется разработать календарный план. Обсудите этот план со всеми, кто отвечает за конкретные участки работ. Эти сотрудники могут помочь в разработке календарного плана и определить временные рамки как для относящейся к их компетенции части проекта, так и для процесса объединения системы в целом.

На этом подготовительном этапе следует подумать о тех связанных с техническим обслуживанием серверов вопросах, которые можно решить в процессе изменения конфигурации доменной структуры. Это списание устаревших моделей серверов, объединение ресурсов, преобразование лишних контроллеров доменов в обычные (stand-alone) серверы. Этот подготовительный период хорошо также использовать для изучения различных утилит миграции от независимых компаний.

Внесение изменений в доменную структуру - комплексный процесс, включающий в себя такую неприятную задачу, как создание учетных записей для каждого пользователя и обновление списков управления доступом (Access Control List - ACL) на каждом сервере. Существует ряд превосходных утилит, которые могут помочь успешно реализовать проект. Я начал исследование утилит миграции с изучения инструментов, входящих в состав продукта Microsoft Windows NT Server 4.0 Resource Kit, таких как Subinacl и Xcacls. Мне удалось выяснить, что эти утилиты можно использовать при создании сценариев, выполняющих миграцию. Однако я быстро осознал, что подобный подход, состоящий в проведении деструктивных изменений, нереалистичен. Хотя эти утилиты и можно использовать для замены существующих списков управления доступом пользователей и групп, они не годятся, если требуется реализовать плавную миграцию, предварительно создав параллельную доменную структуру. Возникла необходимость в инструменте, который создавал бы параллельные списки управления доступом и выполнял бы необходимые для проведения миграции шаги, такие как создание учетных записей пользователей и обновление списков управления доступом на всех серверах предприятия. При выполнении этих задач могут оказаться полезными пакеты DM/Administrator, EA, или Unicenter TNG от Computer Associates. Мне показалось удобным использовать DM/Reconfigure (бывший Phoenix Domain Leveler) от FastLane Technologies, но я настоятельно рекомендую попробовать несколько продуктов, чтобы выбрать тот, который наилучшим образом соответствует условиям организации.

В дополнение к упомянутым готовым коммерческим продуктам, потребовались некоторые доморощенные инструменты для решения задач, связанных с миграцией пользователей и рабочих станций. При написании сценариев я использовал программы из комплекта Windows NT Server 4.0 Resource Kit, создающие мощные средства для выполнения миграции рабочих станций. Вот небольшой перечень инструментов, с помощью которых можно автоматизировать процесс: пакет для создания сценариев на языке Perl, утилиты Netdom, Shutdown, Scanreg.

В процессе объединения доменной структуры придется иметь дело с различными типами систем. Это серверы DHCP и WINS, контроллеры доменов, серверы SQL, рабочие станции NT и Windows 9x. Каждая система требует своей стратегии реконфигурации и ставит собственный ряд вопросов, связанных с миграцией.

Перемещение серверов в новую доменную структуру подчас представляется сложной задачей, однако, этот шаг может оказаться одним из самых простых во всем процессе миграции. Серверы NT могут работать с учетными записями пользователей, используя доверительные отношения. Поэтому можно переместить сервер в другой домен, не оказывая влияния на доступ пользователей к этому серверу. Ключом к проведению такой аккуратной операции с серверами служит правильная установка доверительных отношений до переноса сервера. пример, домен Domain B "доверяет" домену Domain A. ресурсы из домена Domain A можно переместить в домен Domain B, никак не затрагивая доступ пользователей к этим ресурсам. Кроме того, домены Domain A и Domain B доверяют домену Master Account Domain. Поэтому можно перемещать серверы со списками управления доступом для новых учетных записей между доменами Domain A и Domain B, не оказывая влияния на существующие права пользователей при доступе к ресурсам.

Более всего вызывает затруднения перенос контроллеров доменов, так как они содержат базу данных системы безопасности. При установке сервера NT создается файл SAM, содержащий конфигурацию локальной системы безопасности данного компьютера. Если же данный сервер NT является контроллером домена, то файл SAM не создается, а копируется с сервера, являющегося основным контроллером домена. Этот файл содержит конфигурацию системы безопасности домена. После размещения базы данных системы безопасности нельзя переместить данный компьютер в другой домен без переустановки NT. Лучше всего решить проблему можно путем сокращения количества служб, работающих на контроллере домена. Перед проведением миграции пользователей следует перенести эти службы на обычные (stand-alone) серверы. Такой способ дает возможность устанавливать и переустанавливать контроллеры доменов, не беспокоясь о переназначении ресурсов. Однако при этом необходимо убедиться в том, что остается достаточное количество контроллеров доменов для выполнения задач регистрации пользователей, иначе могут возникнуть затруднения при входе в систему и осуществлении доступа к системным ресурсам.

Серверы DHCP, WINS и DNS также создают проблемы при миграции, в особенности, если эти службы установлены на контроллерах доменов. Данные службы не зависят от конфигурации системы безопасности на уровне домена, поэтому можно перенести их в другой домен, изменив имя домена в закладке Identification значка Network в Панели управления. Однако эти службы зависят от адреса TCP/IP. Поэтому их перемещение на сервер с другим IP-адресом требует тщательной подготовки. WINS-серверы помимо адреса IP зависят от атрибутов домена. Позаботьтесь о настройке структуры управления на WINS-сервере в самом начале процесса миграции. В этом случае можно будет администрировать сервер WINS после его перемещения в новый домен.

Наиболее сложным аспектом миграции сервера является обновление списков управления доступом разделяемых каталогов, файлов и принтеров для пользователей, имеющих доступ к ресурсам сервера. Конечно, для автоматизации обработки списков управления доступом можно использовать утилиты типа Subinacl из комплекта Resource Kit, однако применение утилит миграции, разработанных сторонними фирмами, таких как DM/Reconfigure, ускоряет этот процесс, делает его быстрее, проще и надежнее. Утилиты миграции создают учетные записи пользователей в новом домене и обновляют права доступа на каждом из серверов, добавляя права для новых пользователей. Для того чтобы произвести глобальные изменения списков управления доступом на сервере, необходимо иметь на этом сервере административные привилегии. Я написал сценарий, который одновременно обновляет локальную группу Administrators и перемещает сервер в новую доменную структуру. Когда я был готов задействовать утилиту миграции для обновления списков управления доступом на сервере, необходимые административные привилегии уже были присвоены.

При проведении миграции следует помнить о том, что пользовательская учетная запись - это больше чем просто имя пользователя. Учетная запись включает в себя уникальный идентификатор защиты (SID - security ID), который напрямую или через членство в группе предоставляет пользователю права доступа к ресурсам сети организации. Используя этот идентификатор, администратор может назначать пользователю права на любом сервере или рабочей станции из любого домена, который имеет доверительные отношения с доменом, где находится учетная запись данного пользователя. Поэтому, чтобы случайно не отключить пользователя от какого-либо ресурса сети, доступ к которому был ему предоставлен, необходимо очень внимательно рассмотреть списки управления доступом каждого из пользователей.

Рабочие станции Windows9x создают меньше всего проблем. Произвести миграцию большого числа клиентов Windows9x можно посредством импорта простого файла в системный реестр.

Во время миграции пользователей Windows9x на некотором отрезке времени возникает ситуация, когда определенный пользователь имеет, по крайней мере, две учетные записи: одну в старой, а другую в новой доменной структуре. После создания записи в новом домене, но перед тем как пользователь зарегистрировался под этой новой учетной записью, пароли пользователя в старом и новом домене различаются. Архитектура систем Windows9x построена на базе рабочих групп, поэтому запрос станции Windows9x на доступ к сетевым ресурсам содержит только имя пользователя и пароль и не включает имя домена. Когда сервер NT получает запрос от станции Windows9x, он должен определить, к какому домену относится данный запрос. В начале сервер NT проверяет тот домен, к которому принадлежит сам. Если сервер не находит соответствующего пользователя Windows9x, то он продолжает поиск в других доменах. Если сервер NT осуществляет поиск в новой доменной структуре, то пароль пользователя не совпадет, и регистрация завершится неудачно. Для решения этой проблемы я блокировал учетные записи пользователей, создаваемые в новой доменной структуре, на то время, пока я не был готов их использовать. Затем, через неделю после миграции пользователя, я автоматически блокировал его старую учетную запись. Кроме того, я установил для новых учетных записей флажок "User Must Change Password at Next Logon" (означающий, что пользователь должен изменить пароль при следующем входе в систему) и проинструктировал пользователей о том, как использовать свои старые пароли для новых учетных записей.

Дополнительные трудности создают клиенты RAS. При регистрации пользователя на сервере RAS, ОС Windows9x кэширует имя домена для данного пользователя с тем, чтобы не было необходимости вводить эту информацию во время следующего сеанса. После помещения в кэш Windows9x не желает изменять атрибуты пользователя. Чтобы решить проблему, предложите пользователям стирать свои имена во время установления соединения с сервером RAS. В этом случае RAS-сервер запросит новые атрибуты для регистрации, включая информацию о домене. Можно применить другой способ: проанализировать раздел RAS в системных реестрах клиентов и заменить старую информацию о домене, поместив туда новое имя домена. Я выбрал второй вариант и использовал утилиту regedit и язык Perl для анализа раздел RAS пользовательских реестров. С помощью программы regedit я экспортировал ключ реестра, который содержит кэшируемые атрибуты пользователя, необходимые для регистрации на сервере RAS (т.е., HKEY_CURRENT_USERRemote AccessProfile). Затем при помощи сценария на языке Perl я анализировал полученный файл и модифицировал все ссылки на имя домена, заменяя в них старое имя на новое И, наконец, я импортировал файл с новыми настройками.

Еще одна проблема, возникающая при миграции Windows9x, связана с доменом, в котором располагается сервер RAS. Если сервер RAS остается в старой доменной структуре до тех пор, пока все пользователи не перемещены, могут возникнуть проблемы блокировки старых учетных записей пользователей в процессе миграции. Но они возникнут и в том случае, если сервер RAS переносится в новую доменную структуру, до того как были активизированы новые учетные записи пользователей. RAS-сервер проверяет права пользователей по отношению к RAS сначала в своем домене и лишь затем в доменах, с которыми установлены доверительные отношения. Если сервер встречает заблокированную учетную запись пользователя, то он запрещает данному пользователю доступ к RAS, не утруждая себя дальнейшей проверкой. Чтобы избежать этого конфликта, оставьте сервер RAS в старой доменной структуре до тех пор, пока не активизируете перемещенные учетные записи пользователей. После активизации учетных записей в новой доменной структуре, можно перенести сервер RAS. При этом будет выполнена проверка прав доступа к RAS и в старой, и в новой доменной структуре. Такой метод обеспечивает возможность удаленной миграции внешних пользователей.

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

При миграции рабочих станций NT можно использовать кое-что из тех инструментов, что применяли для миграции серверов. Возможности DM/Reconfigure позволяют перемещать рабочие станции NT в новую доменную структуру и конвертировать конфигурации пользователей. Однако применение этих инструментов требует, чтобы пользователи были подключены к сети во время процесса миграции. В системах, где имеется 400 - 500 портативных компьютеров, невозможно гарантировать, что все они будут подключены к сети. Поэтому может возникнуть необходимость проведения миграции рабочих станций NT из одного домена в другой, не применяя утилит независимых производителей.

Профиль пользователя представляет собой сложный комплект параметров реестра, переменных окружения, файлов и установок, которые определяют уникальную для данного пользователя рабочую среду. Несмотря на все усилия, мне не удалось придумать, как автоматизировать миграцию профилей пользователей. Ключи реестра определяются идентификаторами SID, что сильно усложняет процесс экспорта и импорта этих ключей. Чтобы экспортировать ключи реестра, нужно знать текущий SID пользователя, а чтобы их импортировать, надо знать его новый SID. Кроме того, просто копировать файлы с профилями пользователей нельзя, так как самый важный файл - ntuser.dat, содержащий всю необходимую информацию о профиле, остается открытым во время использования данного профиля.

Решение этой проблемы состоит в применении встроенного в NT инструмента для копирования профиля пользователя. Для этого нужно в Панели Управления,значок System, в закладке User Profiles выбрать Copy To. Данная утилита копирует настройки рабочего стола, параметры приложений, информацию о подключенных сетевых дисках. Однако эта утилита имеет некоторые недостатки. Например, она не позволяет копировать профили для пользователей, которые никогда не работали на данном компьютере. Это ограничение означает, что невозможно подготовить заранее профили для перемещаемых пользователей. Чтобы сформировать профиль пользователя, нужно подождать, когда этот пользователь зарегистрируется в системе. Такой метод задает пользователям массу работы: они должны зарегистрироваться в новом домене, выйти из системы, зарегистрироваться в старом домене, скопировать свои профили, выйти из системы и снова зарегистрироваться в новом домене. Трудно себе представить такого человека, который мог бы безропотно все это перенести. Лучшим решением, которое я нашел, было следующее: предложить пользователям копировать свои старые профили в профиль Default User, используемый по умолчанию на рабочей станции. В этом случае при следующей регистрации в системе они будут работать со своим старым профилем. Недостаток такого метода в том, что любой человек, регистрирующийся на рабочей станции, будет вынужден работать с использованием указанного профиля.

Еще одним недостатком утилиты копирования профилей является то, что эта утилита копирует информацию о подключенных сетевых дисках. Хотя это свойство поначалу может показаться ее достоинством. Дело в том, что при подключении сетевых дисков NT использует кэшируемые атрибуты пользователя (включая имя пользователя и имя домена). Когда пользователь регистрируется в новом домене, эти атрибуты отличаются от тех, которые сохранены в кэш-памяти для восстановления сетевых подключений. Поэтому попытка подсоединить сетевые диски завершится ошибкой. Чтобы исправить эту ситуацию пользователи могут отключить все сетевые диски, либо можно написать автоматическую процедуру, которая отсоединяла бы все их сетевые подключения. Я использовал сценарий, анализирующий в процессе миграции существующие сетевые подключения и восстанавливающий эти подключения после того, как пользователь зарегистрируется в новой доменной структуре. Запустив команду Net Use, я перенаправил вывод в файл журнала. Затем я использовал сценарий на языке Perl, который создает из файла журнала отдельный командный файл, отсоединяет пользовательские сетевые диски и планирует запуск командного файла для восстановления сетевых подключений при следующем входе пользователя в систему. Для получения информации из системного реестра в сценариях используются экспорт и импорт реестра. Можно задействовать и библиотеку расширений Win32 для языка Perl. Я не стал этого делать, потому что библиотека для работы с системным реестром в Perl очень большая по объему, и требуется много времени для ее копирования на пользовательскую рабочую станцию. Кроме того, экспортируемые ключи реестра оставляют след в журнале аудита, и при возникновении каких-либо проблем их можно вручную обновить и заново импортировать.

Дополнительные трудности при копировании профилей NT создает Microsoft Wallet - средство, которое Microsoft включила в состав продукта Internet Explorer (IE) 4.x. Данное средство обеспечивает возможность создания защищенной области данных в системном реестре, где пользователь может хранить информацию о кредитной карте для совершения покупок в Internet. Эта область защищена настолько, что даже сам пользователь не имеет к ней доступа. При наличии такой конфигурации работа утилиты копирования профиля завершается ошибкой. При этом пользователь получает необычное сообщение об ошибке: "The operation completed successfully" (операция выполнена успешно). Эту проблему можно решить двумя способами. Во-первых, можно, используя редактор regedt32, предоставить пользователю доступ к указанной области реестра, изменив права доступа для ключа реестра HKEY_CURRENT_USERSoftwareMicrosoftProtected Storage System Provider. И, во-вторых, можно связаться с Microsoft и получить обновленную версию файла sysdm.cpl, в которой данная ошибка исправлена. Я переписал на пользовательские рабочие станции файл sysdm.cpl и решил проблему, при этом перезагрузка системы не потребовалась.

Последняя трудность, с которой я столкнулся при использовании утилиты копирования профилей, состоит в том, что данная утилита не копирует пользовательские переменные окружения. Чтобы решить эту проблему, нужно модифицировать для данного пользователя ключ реестра HKEY_CURRENT_USEREnvironment. Экспорт этого ключа из старых профилей пользователей и импорт его в новые профили гарантирует, что переменные окружения перейдут вслед за самими пользователями в новую доменную структуру.

Для моей системы обеспечить сохранность прав пользователей на их рабочих станциях оказалось очень просто. При установке рабочих станций специалисты службы поддержки предоставляли всем пользователям административные права (права локальной группы Administrators) на их станциях. Чтобы гарантировать, что права пользователей сохраняются после миграции в новую доменную структуру, я использовал сценарий. Созданный сценарий добавлял идентификатор пользователя из нового домена в локальную группу Administrators. В моем случае написание такого сценария было достаточно для того, чтобы пользователи имели те же самые права на своих рабочих станциях, что были у них до проведения миграции. Для систем, где используются одноранговые сети, бывает необходимо конвертировать списки управления доступом для корректировки прав доступа на NTFS и на разделяемые каталоги. Для этого можно использовать такие утилиты как Subinacl из комплекта Resource Kit.

Когда новый пользователь регистрируется на рабочей станции, операционная система создает новый профиль, помещая в кэш-память атрибуты этого пользователя. Для того, чтобы создать новый профиль, удаленный пользователь должен в окне регистрации NT отметить Login Using Dial-up Networking (войти в систему, используя коммутируемое соединение). При использовании этой опции подключение к сети занимает очень много времени. Чтобы решить проблему, я модифицировал на пользовательских станциях ключ системного реестра HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon, включив в него параметр KeepRasConnections и присвоив ему значение 1. Установка этого параметра запрещает RAS разрывать соединение при выходе пользователя из системы. При этом пользователи получают возможность зарегистрироваться в системе со своей текущей учетной записи, выполнить миграцию и войти в систему с использованием учетной записи в новом домене, не разрывая соединения с RAS.

Последняя задача при выполнении миграции состоит в том, чтобы определить, как и когда заблокировать старые учетные записи пользователей и отключить старый домен. Я понял, что автоматическое блокирование старых учетных записей и одновременное обновление полей описания (description) позволяет легко определить, какие пользователи уже мигрировали. После этого я мог обратиться к тем пользователям, которые еще не мигрировали, и озадачить их необходимостью выполнить переход. Кроме того, я послал пользователям по электронной почте предупреждение о том, что дни старого домена сочтены. Таким образом, я был готов к тому, чтобы завершить процесс миграции и отключить старые домены. Я автоматизировал блокировку учетных записей в старой доменной структуре, подготовив командный файл на NT-сервере. Этот сервер, в свою очередь, передавал задания о блокировании учетных записей на контроллеры доменов в старой доменной структуре. Использование центрального сервера NT для распределения заданий дает возможность компьютерам NT и Windows9x автоматически формировать задания.

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