ГЛАВА 3
Планирование
системы
Говоря о планировании
системы, обычно подразумевают выбор крите-
риев используемой техники, определение
нагрузочной способности,
необходимых сервисов и протоколов и т. п. Если
обратиться к [I], то
там достаточно подробно освещены эти вопросы. И
хотя это описание
предыдущей версии Windows NT, во многом методики
расчета приме-
нимы и к новой версии 5.
Дополнительный фактор,
заставляющий воздержаться пока от разра-
ботки подробных рекомендаций, — то, что система
на момент написа-
ния книги находится на стадии первой бета-версии.
Многие функции
еще лишь намечены, некоторые — не реализованы
полностью, в коде
присутствует отладочная информация. Все это пока
не позволяет де-
лать какие-либо выводы о технических
характеристиках системы.
Тем не менее, уже сейчас
ясно, что появление в Windows NT 5.0 службы
каталогов Active Directory существенно изменяет подход
к построению
сетей на базе Windows NT. Вместо привычных одно- или
двухъярусных
объединений доменов предполагается строить
иерархии доменов, объ-
единять домены в деревья доменов, а деревья
доменов — в леса. Да и
внутри доменов стало возможным создавать
иерархичные структуры
организационных единиц. Изменились и роли
контроллеров доменов,
механизмы их взаимодействия друг с другом и с
клиентами.
Особого внимания
заслуживают такие вопросы, как планирование ар-
хитектуры DNS, а также планирование структуры
узлов. Именно о них
мы и поговорим в этой главе, а также рассмотрим
процесс установки
Windows NT, сделав при этом упор на особенностях
установки первой
бета-версии.
Планирование архитектуры DNS
Давайте начнем с
планирования интрасети Вашей организации. Учти-
те, что многие советы из этого раздела пригодятся
Вам и при подклю-
чении сети к Интернету.
Перед началом
планирования архитектуры DNS следует изучить или
повторить концепцию и терминологию DNS. Лучше
всего это делать по
специальной литературе. Например, рекомендую Вам
[4].
Пример организации DNS
Итак, Вы приступаете к
планированию интрасети. Первыми Вашими
шагами станут:
• разработка структуры имен доменов;
• определение количества доменов и поддоменов;
• определение нужного числа конфигурируемых зон;
• определение числа серверов;
• решение, будет ли сервис DNS интегрирован с Active Directory;
• определение количества клиентов DNS;
• планирование пространства имен.
При планировании сервера
DNS Вы можете избрать один из несколь-
ких возможных подходов. Например, решить, что для
всей организа-
ции будет создана одна зона, содержащая один
домен. Но на этом пути
Вас подстерегают две опасности. Первая — по мере
роста зоны ею ста-
нет сложно управлять централизованно. Для
решения этой проблемы
внутри зоны можно создать несколько поддоменов и
делегировать им
(разумеется, в разумных пределах) полномочия
администрирования.
Вторая опасность в том, что тиражирование зон DNS
по узкополосным
каналам — довольно дорогое удовольствие. Таким
образом, плоская
структура рациональна только для небольших
организаций с несколь-
кими узлами.
В большинстве же случаев
лучше создавать поддомены по организаци-
онному или территориальному признаку. В больших,
охватывающих
несколько узлов, сетях хороший эффект дает
разбивка на несколько
зон, каждая из которых управляется своей службой
DNS. При такой
структуре нужен один корневой (roof) домен с
одним первичным и
несколькими вторичными серверами DNS. В остальных
зонах (или
подзонах) также должно быть по одному первичному
и по несколько
вторичных серверов DNS.
В больших организациях
целесообразно комбинировать территориаль-
ный и производственный принципы деления на зоны.
При этом важно
учитывать как размер файла зон, так и потребности
выполняемого по
узкополосным каналам обмена информацией между
первичным и вто-
ричными серверами в зоне.
Замечание. Старайтесь
создавать домены так, чтобы они соответ-
ствовали доменам DNS, зонам и поддоменам.
Другой, не менее важный,
вопрос; какие имена давать доменам и хос-
там, какие символы допустимо в этих именах
использовать? Вообще-
то, сервер DNS Microsoft позволяет использовать любые
символы, вклю-
чая Unicode. Это означает, что в интрасети допустимы
даже русские
имена зон, доменов и хостов. Тем не менее, не
рекомендуется подда-
ваться такому соблазну. Лучше строго следовать
стандартам (RFC952 и
RFC1123): ведь неизбежно настанет день, когда Вы
подключите свою
сеть к Интернету. Тогда и поймете, что поступили
правильно.
Выбор поддерживаемой системы, наименований DNS
Согласно RFC952, в именах
допустимо использовать строчные и про-
писные латинские буквы (A-Z), цифры (0-9), дефис (-) и
точки. Обра-
тите внимание на то, что использование точек
допускается только в ка-
честве разделителей в имени DNS.
Кроме того, спецификации
RFC1123 дополнительно задают следующие
правила:
• в качестве первого
символа в имени допустимы как буквы, так и
числа;
• полное имя домена может
иметь длину до 63 октетов, а полностью
определенное имя (FQDN) — до 255 символов.
Планирование количества и типов серверов имен
В каждой зоне должно быть
как минимум два сервера DNS: первичный
и вторичный. Для надежности эти компьютеры
должны быть макси-
мально независимы друг от друга, например,
располагаться в различ-
ных подсетях.
Число серверов DNS и их
расположение определяются объемом сети,
связями между подсетями и требованиями
безопасности. Серверы имен
могут быть первичными, вторичными или просто
кэширующими.
Первичные серверы
следует располагать вблизи наиболее критичных и
часто используемых серверов, таких, как серверы
файлов, почтовые
серверы или серверы Web.
Вторичные серверы
нужны для избыточности и для разгрузки первич-
ных. Эффективность здесь достигается
ограничением числа серверов,
которым разрешается забирать обновления
непосредственно с первич-
ных. Если вторичных
серверов много, следует наладить между ними
отношения для управления тиражированием.
Для повышения
производительности разрешения имен (особенно на
низкоскоростных линиях) рекомендуются кэширующие
серверы имен.
В предыдущих версиях Windows NT
обязательным механизмом регис-
трации и разрешения имен в сети является NetBIOS, Для
динамичного
отслеживания соответствия NetBIOS-имен и IP-адресов
рекомендуется
использовать WINS. В Windows NT 5.0 на смену NetBIOS пришел
сер-
вер DNS, и серверы WINS больше не нужны.
Внимание! В Windows NT 5.0
оставлена поддержка WINS для унасле-
дованных систем. Допускается и интеграция DNS с WINS
таким же об-
разом, как в Windows NT 4.0.
Сервер DNS в Windows NT 5.0
поддерживает динамические обновления
в соответствии со спецификациями RFC 2136. Динамический
сервер
DNS позволяет клиентам и серверам
регистрировать доменные имена
и соответствующие IP-адреса без участия
администратора. Можно,
правда, отключить эту функцию, но при этом
существенно возрастет
нагрузка на администраторов, которым придется
вручную заниматься
обновлением базы.
Флажок Allow dynamic update,
разрешающий динамическое
обновление базы DNS
Интеграция DNS со службой каталогов
Так как каждому домену Windows
NT соответствует DNS-домен, можно
использовать DNS для общения со службой каталогов.
Для Windows NT
необходим сервер DNS,
поддерживающий записи SRV (локаторов сер-
висов) в соответствии со спецификацией RFC2052.
Записи SRV — обоб-
щение записей MX, когда несколько разных серверов
могут объявлять
об одном и том же сервисе. В случае Windows NT записи SRV
указыва-
ют на контроллер домена.
Формат записи следующий:
Service.Proto.Name TTL Class SRV Priority Weight Port Target,
где:
• Service — символическое имя сервиса (например, http или Idap);
• Proto — протокол (обычно TCP или UDP);
• Name — имя домена для этой записи;
• TTL — стандартное время жизни DNS;
• Class — стандартный класс DNS IN;
• Priority — приоритет хоста
назначения (клиент должен пытаться
подключиться к наименее приоритетному хосту
назначения);
• Weight (вес) — механизм
балансировки нагрузки при выборе среди
хостов с равным приоритетом (тогда хост должен
выбираться в пер-
вую очередь по своему весу); в случае отсутствия
балансировки на-
грузки вес равен 0;
• Port — порт, используемый сервисом на хосте назначения;
• Target — доменное имя хоста
назначения (для него должна быть, по
крайней мере, одна запись типа А).
Типичной записью SRV для домена fyodor.work будет:
ldap.tcp.fyodor.work О IN SRV 0 0 389 nts5fz.fyodor.work
Редактирование записи типа SRV
В соответствии со
спецификацией RFC2136, для обновления базы в
динамической реализации DNS используется модель
тиражирования с
одним мастером. Это означает, что первичный
сервер зоны должен
быть всегда доступен для клиентов.
Active Directory — отличное место
для хранения базы DNS и, кроме того,
эта служба каталогов предоставляет возможности
тиражирования с
несколькими мастерами. Эта возможность в Windows NT 5.0
позволяет
использовать механизмы тиражирования Active Directory
для обновле-
ния информации DNS. Для активации этой функции
необходимо выб-
рать соответствующую возможность при создании
зоны.
Создание первичной зоны,
база которой хранится в каталоге Active
Directory
Планирование структуры узлов
Объем данных, тиражируемых
между различными узлами, зависит от
того, принадлежат ли контроллеры доменов одному
домену, доступен
ли глобальный каталог, и есть ли таковой в узле
назначения.
Предположим, что
штаб-квартира некоей корпорации расположена в
Северной Америке, центральный филиал — в Европе,
а еще один фи-
лиал — в Юго-Восточной Азии. Все три точки
связаны между собой
каналами связи, причем между американским и
европейским подраз-
делениями проложена высокоскоростная линия Т1, а
азиатский филиал
связан с европейским медленным каналом б4К.
Допустим, что вся сеть
выполнена в виде одного домена (сценарий 1).
Каждый контроллер домена получает полную копию
данных. Для уско-
рения входа в сеть в каждом из трех узлов
располагаются контроллеры
домена. После создания
нового пользовательского объекта в американ-
ском отделении вся информация о нем тиражируется
в европейское, а
затем, оттуда — в азиатское. При изменении
свойств этого объекта ти-
ражируется только информация об изменениях.
Пример организации с тремя узлами
А теперь предположим, что
каждый узел содержит отдельный домен
(сценарий 2). В каждом узле — свои контроллеры
доменов. Локаль-
ные администраторы доменов создают новых
пользователей, инфор-
мация о которых не тиражируется между узлами.
Единственная инфор-
мация, тиражируемая между агентами DSA независимо
от принадлеж-
ности к домену — метаданные дерева.
Если Вас более всего
заботит трафик между узлами и в каждом отделе-
нии корпорации имеется квалифицированный
технический персонал,
то сценарий 2 — именно то, что нужно. А
возможность доступа пользо-
вателей к ресурсам всех доменов обеспечат
доверительные отношения
Kerberos.
Однако это решение удачно
только в том случае, если пользователи од-
ного домена никогда не запрашивают информацию из
каталога друго-
го. Например, если пользователь в азиатском
домене запросит инфор-
мацию о пользователе в американском домене, то
контроллер азиатс-
кого домена возвратит ссылку на контроллер
американского. Следуя
этой ссылке, пользователь обратится к
контроллеру американского
домена и получит по сети всю информацию об
объекте. Представьте
себе, что Вы используете в корпорации приложения,
активно работа-
ющие со службой каталогов, например программу по
учету кадров. В
таком случае все преимущества минимизации
графика за счет отсут-
ствия тиражирования между доменами будут
сведены на нет обраще-
ниями приложений к Active Directory.
Одним из решений этой
проблемы может служить установка в каждом
узле контроллеров всех доменов (сценарий 3).
Например, в европей-
ском узле представлены контроллеры как
европейского, так и амери-
канского и азиатского доменов. При таком подходе
опять же практи-
чески отсутствует тиражирование между доменами.
Все запросы к служ-
бе каталогов являются локальными и выполняются
быстрее, чем в сце-
нарии 2, но все же немного медленнее, чем при
использовании одного
большого домена, так как требуется некоторое
время на подключение
к другому контроллеру домена. К тому же, это
решение достаточно до-
рогостоящее, так как в каждом узле требуется по
два дополнительных
компьютера-контроллера других доменов.
Еще один выход из
положения — иметь в каждом узле серверы глобаль-
ного каталога (сценарий 4). Серверами
глобального каталога служат
те контроллеры домена, где хранится полная копия
базы данных свое-
го домена и частичная копия объектов всего
дерева доменов. Эта ко-
пия включает в себя информацию только о
некоторых (принимающих
участие в тиражировании) свойствах всех объектов
дерева. Для всех
предопределенных объектов в каталоге имеется
список таких свойств.
Если администратор создает новый объект, то по
умолчанию все свой-
ства этого объекта частично тиражируются. Этот
порядок можно из-
менить, выбрав только некоторые свойства
создаваемого объекта.
При выполнении запросов к
серверу глобального каталога (его имя
стандартное — дс. ms-dcs. <имя домена>) происходит
передача ограничен-
ного набора свойств об объекте. Если же запрос
относится к опреде-
ленным свойствам, то глобальный каталог
возвращает не ссылку на
другой агент DSA, а полностью определенное имя
объекта, что позво-
ляет напрямую обращаться к нужному контроллеру
домена.
Использование серверов глобального каталога
Этот вариант организации
наиболее эффективен, когда и трафик в
сети, и организация доступа к каталогу равно
важны.
Пример планирования структуры организации
Итак, при планировании
узлов лучше сочетать два подхода: географи-
ческий и производственный. Можно использовать
как каждый по от-
дельности, так и их комбинацию. Проиллюстрируем
эту мысль приме-
ром гипотетической организации, структура
которой изображена на
рисунке.
Пример структуры предприятия
Наше предприятие весьма
централизовано. В Москве располагается
руководство, а также отделы маркетинга, кадров,
производственный и
бухгалтерия. Отдел продаж распределенный: он
располагается частич-
но в Москве, а частично — в Санкт-Петербурге,
Екатеринбурге, Мурман-
ске, Новосибирске и Владивостоке. Руководство
Северо-Западного на-
правления находится в Санкт-Петербурге, а
Восточного — в Новоси-
бирске.
Планируя структуру, можно
предложить разбить организацию на не-
сколько крупных узлов, где целесообразно
поместить серверы глобаль-
ного каталога:
— Московский, в который
войдут все подразделения за исключением
региональных отделов продаж,
— Северо-Западный,
— Уральский,
— Восточный.
Над доменной структурой
стоит задуматься. С одной стороны, кажется
логичным поместить руководство, отдел кадров,
маркетинга, бухгалте-
рию и производственный в одном домене. Отдел
продаж (о нем мы
поговорим позднее)
выносится в отдельный домен, что с точки зрения
графика при тиражировании и выполнении запросов
не принципиаль-
но, так как все подразделения территориально
расположены в одном
месте и связаны между собой скоростными
каналами. База данных
службы каталогов поддерживает до 10 миллионов
объектов, поэтому
такой порядок не вызывает тревоги и с точки
зрения ее емкости.
Отделы внутри домена можно
оформить в виде организационных еди-
ниц, что обеспечит точность делегирования
административных полно-
мочий.
Правда, использование
организационных единиц в данном случае име-
ет и отрицательные стороны.
1. Сложности в управлении
политикой безопасности. По умол-
чанию все новые пользователи домена будут
наделяться одинаковы-
ми полномочиями. Это очевидно неприемлемо, и для
разграничения
доступа администратору придется создавать для
каждого отдела
группы с различными правами доступа или писать
разные сценарии
входа в систему. Согласитесь, это весьма сложно,
да и чревато мно-
жеством ошибок. Гораздо лучше использовать
разграничения, пред-
лагаемые доменной структурой.
2. Замедление операций
авторизации доступа и поиска в ка-
талоге. Служба каталогов позволяет хранить
огромное количество
объектов. Но чем больше объектов, тем медленнее
выполняются опе-
рации, то есть «раздутый» каталог нерационален.
Кроме того, неиз-
бежно избыточное тиражирование. Предположим, что
в домене де-
сять контроллеров. Тогда, создавая новый объект,
Вы будете порож-
дать его девять копий, а тиражирование будет
выполняться по сети
девять раз!
Доменная структура с
доменными границами, отражающая
производственную организацию
Все это приводит к выводу:
целесообразно отделы кадров, маркетинга,
производства и бухгалтерию разместить в
отдельных доменах, дочер-
них по отношению к домену руководства. Возможная
структура (без
отдела продаж) изображена на рисунке.
Подразделения
производственного отдела оформлены в виде
органи-
зационных единиц, а отдела маркетинга — в виде
доменов. Такое ре-
шение обусловлено предположением, что отдел
маркетинга больше
производственного и более распределен.
Политика безопасности
наследуется дочерними доменами от родитель-
ских. Таким образом, правила, установленные для
домена руководства,
будут распространяться на все нижележащие
отделы.
Отдел продаж хорошо
вписывается в эту схему. Для него также созда-
ется отдельный домен, дочерний по отношению к
домену руководства.
В свою очередь, у домена отдела продаж четыре
дочерних домена: Мос-
ковский, Уральский, Северо-Западный и Восточный.
Так как в Санкт-
Петербурге и Новосибирске располагается
региональное руководство,
которое должно выполнять операции на доменном
уровне, то отделе-
ния в этих городах оформляются в организационные
единицы Севе-
ро-Западного и Восточного доменов. Филиалы в
Мурманске и Влади-
востоке можно оформить либо в виде
организационных единиц, либо
в виде доменов. (Окончательный выбор зависит от
размера филиалов
и требований безопасности. В любом случае во всех
узлах должны быть
серверы глобального каталога.)
Как видите, создать
структуру организации не так уж и сложно. Важно
решить, по какому принципу будет выполняться
деление: географичес-
кому или производственному. А после этого можно
определять струк-
туру дерева доменов или леса деревьев в
зависимости от требуемой
свободы администрирования.
Переход с предыдущей версии
Windows NT
Рассмотренные элементы
планирования новой системы и установки «с
нуля» в настоящее время встречаются все реже, в
основном в случаях
создания новых сетей. Гораздо чаще встает вопрос
о модернизации и
расширении уже имеющейся сети или объединении
нескольких се-
тей. Несомненно, здесь применимы и уже
рассмотренные нами ре-
шения, однако ряд специфических особенностей
требует отдельно-
го обсуждения.
Те, кто уже хорошо знаком с
сетями на базе ранних версий Windov. s
NT, знают, что существует несколько моделей связи
между доменами.
Встречаются и простые сети, состоящие всего из
одного домена; и сети
из нескольких доменов, связанных между собой по
схеме с одним или
несколькими
мастер-доменами и полностью централизованным
управ-
лением; и сети, использующие модель полностью
доверительных отно-
шений, предлагающую полную децентрализацию; а
также смешанные
модели, созданные в соответствии со структурой
конкретной органи-
зации (подробнее см. [1]). Понятно, что для каждой из
этих моделей
оптимален свой способ миграции на новую систему,
обеспечивающий
эффективный и безопасный перенос учетной
информации и мини-
мально воздействующий на конфигурацию
клиентских рабочих мест.
Итак, поговорим о
различных вариантах перехода со старой системы
на новую, а также о способах обеспечения
нормального сосуществова-
ния в одной сети как старых, так и новых систем.
Если у Вас только один домен
Давайте сначала повторим
некоторые основы работы сервера Windows
NT 4.0 и доменов на его основе. Сервер может быть
либо PDC (первич-
ным контроллером домена), либо BDC (резервным
контроллером),
либо отдельно стоящим сервером. Роль, которую он
будет исполнять в
домене, определяется на этапе установки и не
может быть изменена в
дальнейшем. Так, в частности, контроллер домена
нельзя сделать от-
дельно стоящим сервером, а сервер — контроллером
домена, не пере-
установив их полностью. Единственное, что можно
сделать — повысить
статус резервного контроллера до первичного, а
статус первичного —
понизить до резервного. На резервном контроллере
можно остановить
сервис регистрации, но это приведет только к
тому, что он не будет
регистрировать входящих в домен, однако своей
роли контроллера не
изменит.
Так как в домене на базе
Windows NT 4.0 широко используются иден-
тификаторы безопасности компьютеров,
генерируемые при установке
системы, а также доверительные отношения старого
типа, основанные
на этих идентификаторах, то невозможно
переместить контроллер из
одного домена в другой, не прибегнув к полной
переустановке систе-
мы. Кроме того, без полной переустановки Вы не
можете произвольно
изменять имена контроллеров домена.
Вспомним также, что
учетную информацию в домене можно изменять
только на первичном контроллере, а резервные
контроллеры исполь-
зуются для регистрации пользователей. База
учетных записей на BDC —
точная копия базы PDC. Достигается это за счет
процесса, называемо-
го тиражированием с одним мастером (single master
replication),
Отличительная особенность
контроллера домена в Windows NT 5.0 —
выполнение на нем сервиса службы каталогов.
Достаточно запустить
на сервере агента службы каталогов DSA (directory service
agent), чтобы
обычный сервер превратился в контроллер домена.
версией). Если же первичный
контроллер домена с установленной Win-
dows NT 5.0 включен, то повысить статус BDC невозможно.
Что делать после того, как
на одном контроллере домена установлена
Windows NT 5.0? Можно обновить операционную систему на
всех ос-
тавшихся контроллерах, а можно удовлетвориться
сделанным и оста-
вить все как есть. Наилучший вариант, как всегда,
компромиссный: на
нескольких контроллерах домена установлена
новая система, а на не-
скольких — старая. С одной стороны, это позволит
оперативно восста-
навливать информацию из Active Directory в случае выхода
из строя
одного из контроллеров с Windows NT 5.0, а с другой
—несколько BDC
с Windows NT 4.0 обеспечат восстановление при
проблемах с тиражи-
рованием между машинами с Windows NT 5.0 и Windows NT 4.0.
Присоединение к дереву
После того, как на PDC
установлена основная операционная система,
можно установить службу каталогов Active Directory. В
процессе уста-
новки необходимо задать имя дерева, к которому
будет присоединен
данный домен, и ссылку на будущий родительский
домен, либо создать
новое дерево.
По мере обновления
системы, программа установки перенесет объек-
ты (учетные записи пользователей, локальных и
глобальных групп, а
также машин), расположенные в базе учетных
записей SAM, в каталог
Active Directory. Как уже упоминалось, в Windows NT 5.0 не
существует
разницы между локальными и глобальными группами
— все группы
равны между собой. Более того, можно создавать
вложенные группы,
что дает большую гибкость администрирования.
Однако для совмести-
мости с предыдущими версиями локальные и
глобальные группы пе-
реносятся в новую ОС в том виде, как они
существовали. При этом
допускается членство глобальных групп в
локальных.
Каждый объект
безопасности переносится в контейнер со своим
име-
нем. Контейнер, не будучи организационной
единицей, является объек-
том с общим именем (сп). В таблице 3-1 показано
соответствие учет-
ных записей контейнерам, в которые они
переносятся.
Таблица 3-1
| Учетные записи | Контейнер |
| Все пользователи Компьютеры Встроенные локальные группы Встроенные глобальные группы Все остальные группы |
Users Computers Builtin Users Users |
Присоединение к дереву
После установки протокола
Kerberos будут запущены службы аутенти-
фикации и выдачи начального билета TGT, а вслед за
этим — заданы
транзитивные двусторонние доверительные
отношения с родительс-
ким доменом.
Контроллер родительского
домена выполнит тиражирование инфор-
мации в новый дочерний домен, который, в свою
очередь, будет добав-
лен в доменную структуру узла. Все контроллеры
домена получат уве-
домление о том, что к дереву подключен новый
домен.
С этого момента новый
домен становится полноправной частью дере-
ва доменов. Клиенты, которые поддерживают работу
с Active Directory
(Windows NT Workstation 5.0, Windows 98 и Windows 95 с установлен-
ной клиентской поддержкой), будут пользоваться
всеми преимущества-
ми транзитивного доверия и доступом к ресурсам
всего дерева доме-
нов. Для них станет возможным поиск в каталоге
путем запросов кон-
троллеров доменов и серверов глобального
каталога. Для «старых» кли-
ентов, однако, новый домен
будет выглядеть так же, как и обычный
домен ранних версий Windows NT,
Обновление резервного контроллера домена
На следующей стадии можно
обновить операционную систему на дру-
гих контроллерах домена и установить на них
службу каталогов Active
Directory или добавить в домен новые контроллеры с
установленной
системой Windows NT 5.0.
Обновление дополнительных контроллеров домена
Так как контроллеры домена
старого типа используют в своей работе
последовательно возрастающие RID (относительные
идентификато-
ры) из ряда всех SID (идентификаторов
безопасности), то для созда-
ния объектов системы безопасности годится
только первичный кон-
троллер домена с установленной ОС Windows NT 5.0.
Объекты, не име-
ющие к ней отношения, например, организационные
единицы, могут
быть созданы на любом контроллере, где
установлена служба катало-
гов Active Directory.
На первичном контроллере
домена используется два протокола тира-
жирования: с одним мастером для систем на базе
Windows NT 4.0 и
более ранних версий, и с
несколькими мастерами — для партнеров на
базе Windows NT 5.0.
Завершение миграции
Когда все контроллеры
домена перешли на новую версию Windows NT,
домен может быть переведен из смешанного режима
работы в домен
Active Directory. (Подробнее об этом — в главе 2.) При этом
в домене
появятся следующие новшества:
• механизм тиражирования
каталога Active Directory с несколькими
мастерами, в том числе и для тиражирования
объектов безопасности;
• прекращение бывшим
первичным контроллером домена поддерж-
ки тиражирования с одним мастером, что сделает
невозможным
добавление в домен контроллеров под управлением
Windows NT 4.0;
• возможность для всех
клиентов пользоваться преимуществами тран-
зитивных доверительных отношений;
• возможность вложения групп.
Решение о переводе домена
в этот режим принимается администрато-
ром и не может быть выполнено автоматически.
Другими словами, ре-
шение, что в домене больше не будет контроллеров
на базе Windows
NT 4.0, может принять только человек.
Так же как и в предыдущих
версиях Windows NT, в новой версии и в
службе каталогов Active Directory для определения
объектов системы
безопасности используются идентификаторы
безопасности SID. Не-
смотря на то, что на уровне ОС нет разницы в
использовании этих
объектов, сами объекты создаются иначе. В
предыдущих версиях PDC
был единственным местом, где могли быть созданы
объекты безопас-
ности, а все BDC предполагали, что идентификаторы
являются после-
довательно возрастающими RID. В схеме
тиражирования с нескольки-
ми мастерами это в принципе невозможно, так как
объекты могут быть
созданы на различных контроллерах домена, каждый
из которых ис-
пользует свой диапазон RID.
После установки на PDC Windows NT
5.0 этот контроллер становится
единственным владельцем всех допустимых RID. По
мере добавления в
домен новых контроллеров на базе Windows NT 5.0,
текущий владелец
(информацию о котором можно получить, сделав
соответствующий
запрос в Active Directory) будет выдавать им
персональные пулы RID.
После того, как пул адресов
выдается запросившему об этом контрол-
леру, последний принимает на себя роль владельца,
что позволяет ему
вырезать блок идентификаторов RID (сейчас их 100
тысяч) из общего
количества доменных RID. Создавая новый объект
системы безопасно-
сти, контроллер домена выдает ему RID из пула,
после чего новый объ-
ект тиражируется для всех партнеров. Если
выделенный пул идентифи-
каторов заканчивается, контроллер запрашивает
еще один кусочек из
общего пула RID домена.
Использование блоков идентификаторов раз-
личными контроллерами домена приводит к тому,
что RID назначают-
ся в произвольном порядке, а не последовательно.
Перенос пула RID
Контроллеры домена с Active
Directory «воспринимают» такие непос-
ледовательные RID как должное, в то время как у
контроллеров с пре-
жними версиями это «вызывает замешательство».
Вот почему, до тех
пор, пока в домене имеются контроллеры с Windows NT
версии 4.0 и
более ранних, первичный контроллер домена должен
работать в сме-
шанном режиме и обслуживать два механизма
тиражирования. И лишь
только тогда, когда администратор решит, что в
домене больше не бу-
дет контроллеров с Windows NT прежних версий, следует
переключить
домен из смешанного в чистый режим Active Directory.
Для клиентов перевод
домена в «родной» режим означает, что они пол-
ностью получают предоставляемую доверительными
отношениями Кег-
beros возможность доступа ко всем ресурсам в дереве
доменов, даже
если сами клиенты и не поддерживают протокол
Kerberos. Сквозная
аутентификация позволяет опознавать клиента в
любом домене дерева.
Домен после полностью завершенной миграции
Обеспечение безопасной миграции
Администраторы сетей
всегда с опасением относятся к обновлению
операционных систем, постоянно откладывая это
мероприятие и оп-
равдываясь боязнью «будить лихо, пока тихо». А
когда, в конце концов,
жизнь заставляет их решиться на этот отчаянный
шаг, стараются мак-
симально обезопасить систему от возможных
непредвиденных послед-
ствий. Рекомендуются два способа миграции,
которые позволят Вам в
нештатной ситуации «отойти на исходные позиции».
Первый метод — предварительная установка и сохранение BDC.
Он основан на том, что для
восстановления может быть использована
копия информации первичного контроллера,
которая всегда хранится
в базе учетных записей резервного контроллера
домена.
Перед началом обновления
операционной системы на первичном кон-
троллере домена установите в домене (или
задействуйте существую-
щий) резервный контроллер с Windows NT версии 4.0. После
того, как
резервный контроллер
подготовлен (содержит свежую версию базы
SAM), выключите его или отключите от локальной
сети.
Теперь можно смело
приступать к обновлению системы на PDC так, как
описано выше. Если по каким-либо причинам
корректно выполнить
обновление системы не удалось, домен останется
без первичного кон-
троллера. Регистрация пользователей в нем будет
еще возможна (при
наличии резервных контроллеров), но модификация
— нет. Не отчаи-
вайтесь! Выключите компьютер, обновление
которого не состоялось,
включите «сохраненный» BDC и повысьте его статус
до PDC. После это-
го он выполнит тиражирование своей базы на все BDC
в домене и тем
самым восстановит исходное состояние.
Недостаток данного
способа в том, что все изменения, внесенные в
учетную информацию с момента «замораживания» BDC,
будут утеряны
после того, как он станет PDC. Поэтому либо
выполняйте обновление
сразу же после отключения BDC, либо обновите его
базу непосред-
ственно перед отключением. Можно
порекомендовать использовать два
BDC — один «замороженный», до которого «не
дотрагивался» Windows
NT 5.0 и второй, который был включен в момент
обновления PDC. В
этом случае на втором BDC останется самая
актуальная информация.
Второй метод —
исключение PDC из сети — прямо противополо-
жен первому и подразумевает физическое
отключение первичного
контроллера домена от сети на момент обновления.
Вместо этого сер-
вер подключается к лабораторной сети, после чего
и проводится мо-
дернизация ОС. В этой же сети можно сформировать
дерево доменов,
установив по контроллеру для каждого домена.
Далее следует подсое-
динить резервные контроллеры и выполнить их
обновление. Наконец,
в тестовую систему включаются несколько рабочих
станций, и произ-
водится их проверка. Убедившись, что созданный
домен нормально
функционирует, компьютеры переносят назад в
корпоративную сеть.
Преимущество такого
способа в том, что сеть организации не подвер-
гается никакому риску. Но есть и недостаток: до
тех пор, пока первич-
ные контроллеры не будут возвращены назад в сеть,
в ней невозможны
никакие изменения.
Политика безопасности
В предшествующих версиях
Windows NT политика безопасности делит-
ся на две части: доменную и локальную. Правила
доменной политики
безопасности хранятся в базе данных SAM и
охватывают такие вопро-
сы, как создание учетных записей, ограничения на
пароли пользовате-
лей, блокировки учетных записей. Правила
локальной политики хра-
нятся в базе LSA (локального уполномоченного
безопасности) и регла-
ментируют привилегии учетных записей и правила
аудита. Локальная
политика тиражируется между контроллерами
домена таким образом,
что все контроллеры следуют одним и тем же
правилам. Доменная
политика применяется ко всему домену в целом.
В Windows NT 5.0 политика
безопасности применяется по отношению
ко всему каталогу Active Directory. Отдельные
контроллеры доменов
могут следовать различным правилам
безопасности. Политика, опреде-
ленная в одном месте сети, может быть
распространена на все серве-
ры и рабочие станции. Детальное делегирование
административных
полномочий позволяет отказаться от
всемогущества одного админист-
ратора.
Составляющие политики безопасности хранятся в двух типах объектов:
доменной и локальной политики. К доменной политике относятся:
• правила использования паролей;
• правила блокировок;
• дескриптор безопасности доменных операций;
• политика регистрации Kerberos;
• политика файловой системы с шифрованием.
В домене может
существовать либо собственный объект политики,
либо
ссылка на такой объект, расположенный где-то в
дереве доменов, а
также соответствующая реплика. В последнем
случае сервер глобаль-
ного каталога управляет тиражированием.
Объекты локальной политики хранят следующую информацию:
• правила аудита;
• правила привилегий;
• локальные роли.
Так как различия между
моделями хранения и использования состав-
ляющих политики безопасности Windows NT 5.0 и
предыдущих версий
слишком велики, то перенос правил в процессе
миграции невозможен.
При подсоединении домена к существующему дереву
он наследует объ-
ект политики от родительского домена. При
обновлении отдельного
домена в нем по умолчанию формируется новая
политика и новые со-
ответствующие объекты в каталоге.
Если у Вас несколько доменов
Если в Вашей организации
существует несколько доменов, то они мо-
гут быть связаны друг с другом по одной из
следующих моделей: мо-
дель с одним мастер-доменом, модель с несколькими
мастер-домена-
ми, модель полностью доверительных отношений. В
ряде случаев
структуру организации лучше всего сможет
отразить комбинация этих
моделей.
Зачастую отделы
информационных технологий стремятся, насколько
возможно, централизовать доменную структуру,
даже если при этом она
не точно соответствует внутренней структуре
предприятия. В ряде
организаций, особенно
больших, с различными направлениями дея-
тельности, наоборот, наблюдается полная
децентрализация управления.
Переход на службу
каталогов Active Directory позволяет пересмотреть
используемую ранее модель и, в ряде случаев,
сократить количество
доменов путем иерархичной структуры внутри
одного домена. Кроме
того, деревья и леса доменов позволяют привести
структуру в полное
соответствие со структурой организации и
обеспечить наибольшую
эффективность управления.
Планируя большую
разветвленную, содержащую много низкоскорост-
ных участков, сеть стоит уделить особое внимание
ее пропускной спо-
собности. Иногда бывает полезно организовать
тиражирование не все-
го каталога, а только отдельной его части по
узкополосным каналам.
Это удобнее, если домены организованы по
географическому принци-
пу, а для международной корпорации, к тому же,
облегчает управление
отделениями на родном языке.
Давайте рассмотрим
некоторые общие вопросы перехода от различных
доменных моделей к Active Directory.
Модель с одним доменом
Миграцию одного домена мы
уже обсуждали, уделяя основное внима-
ние механическому обновлению контроллеров и
переносу существую-
щих объектов безопасности в Active Directory по
умолчанию.
Однако Вы можете улучшить
администрирование домена за счет более
широкого использования организационных единиц и
делегирования
полномочий. Организуя пользователей и доступные
им ресурсы в иерар-
хичном пространстве имен OU, Вы точнее отразите
реальную структу-
ру предприятия. Назначение детальных привилегий
тем или иным
пользователям позволит разгрузить технических
специалистов и ли-
шить их административной монополии.
Модель с одним мастер-доменом
Миграция доменов,
объединенных в модели с одним мастер-доменом,
выполняется, как правило, по нисходящей: сначала
мастер-домен, и
лишь потом, постепенно — ресурсные. Оценив
степень централизации
управления, Вы можете прийти к выводу, что Вашей
организации дос-
таточно всего одного домена. В этом случае вся
структура ресурсных
доменов будет отражена в организационной
структуре домена.
Ресурсы из доменов второго
яруса разумней переместить в новый до-
мен позже, без спешки. Вместо ресурсного домена
можно создать орга-
низационные единицы в мастер-домене и закрепить
за ними перено-
симые ресурсы. Такой подход, с одной стороны,
позволяет централи-
зовать управление, а с другой — более точно
наделять пользователей
полномочиями.
Другой метод основан на
том, что ресурсные домены остаются в дере-
ве доменов, но пользователи из мастер-домена
переносятся в те доме-
ны, где реально располагаются. Этим достигается
большая децентрали-
зация, а следовательно, большая
самостоятельность и независимость
групп пользователей.
Модель с несколькими мастер-доменами
Модель с несколькими
мастер-доменами оправданна, чаще всего, в
крупных организациях. Например, если
подразделения «разбросаны по
городам», то мастер-домены создаются в регионах;
а если в компании
несколько различных, слабо связанных между
собой, направлений де-
ятельности, то отдельный мастер-домен выделяется
каждому из них.
Для организаций такого
типа приемлемы два подхода. Первый осно-
вывается на построении одного дерева доменов.
Подразделения
должны договориться, какой домен станет корневым
(удобнее отдать
эту роль домену отдела информационных
технологий). Все домены,
бывшие ранее мастер-доменами, становятся
равноправными доменами
второго уровня в дереве доменов. Ресурсные
домены могут располагать-
ся уровнем ниже и иметь свои собственные
параметры политики безо-
пасности.
Корневой домен хорош для
размещения в нем общих ресурсов орга-
низации таких, как, например, Web-сервер или
информации отдела
кадров. Тогда с одной стороны, специалистам
отдела информационных
технологий обеспечена возможность
централизованно управлять об-
щими ресурсами, а с другой — индивидуальным
подразделениям пре-
доставлена самостоятельность в выборе политики
безопасности.
Большую децентрализацию
предлагает второй подход: каждый из
мастер-доменов с соответствующими ему
ресурсными домена-
ми объединяется в отдельное дерево, а все деревья
вместе со-
ставляют лес. Концепция леса позволяет
входящим в него деревьям
использовать общую схему, общий глобальный
каталог и транзитивные
доверительные отношения Kerberos таким образом, что
пользователи
получают доступ ко всем ресурсам дерева доменов.
Утомительное уп-
равление доверительными отношениями исчезает,
так как надо уста-
новить всего одно доверие с родительским
доменом.
Концепция леса позволяет
также производственным единицам созда-
вать поддеревья, имеющие собственную структуру и
политику безопас-
ности. Все, что объединяет их с другими деревьями,
— связь на уровне
леса. Никакой дополнительной административной
работы при этом нс
требуется. Такая схема идеально подходит для
компаний, занимающих-
ся покупкой и продажей производственных единиц и
склонных рас-
сматривать последние как независимые
организации.
Модель полностью доверительных отношений
Структура некоторых
организаций децентрализована до такой степе-
ни, что подразделениям трудно договориться даже
о том, чтобы сде-
лать корневым домен отдела информационных
технологий. Такие ком-
пании, ранее использовавшие модель полностью
доверительных от-
ношении, страдают от усилий, направленных на
поддержку этих от-
ношений.
Переход на Windows NT 5.0 и Active
Directory позволяет сохранить
независимость. Как и в случае с несколькими
мастер-доменами, мож-
но выбрать один из нескольких вариантов и
построить либо одно де-
рево с развитой структурой организационных
единиц, либо, полнос-
тью отказываясь от централизации, создать
несколько деревьев и объе-
динить их в лес. В любом случае, получится
достаточно плоская струк-
тура, однако управление доверительными
отношениями в ней значи-
тельно проще, чем ранее.
Еще одно возможное решение
— создание нескольких раздельных ле-
сов. При этом между некоторыми доменами одного
леса устанавлива-
ются доверительные отношения с некоторыми
доменами другого леса
для предоставления ограниченного доступа
избранным категориям
пользователей. Надо заметить, что подобная
структура больше подхо-
дит для связи различных организаций, чем для
подразделений внутри
одной компании.
Итак, подведем итоги: любая
модель доверительных отношений доста-
точно просто может мигрировать в Active Directory. В
зависимости от
структуры организации, можно создать либо
полностью централизо-
ванную, либо полностью децентрализованную
структуру, равно просто
управляемые. Иными словами, выполнив миграцию, Вы
сможете «на-
строить» систему на еще более точное
соответствие целям, задачам и
структуре Вашего предприятия.
Перенос доменов второго яруса в мастер-домен
При рассмотрении вопросов
миграции от модели с одним или несколь-
кими мастер-доменами к Active Directory, мы неоднократно
упоминали
о возможности превращения ресурсных доменов
(доменов второго яру-
са) в отдельные домены (домены первого яруса). В
свое время приво-
дилось много аргументов за использование
двухъярусной схемы. Од-
нако Active Directory делает большинство из них
бессмысленными.
Несмотря на то, что этот
процесс не автоматический (для его выпол-
нения не существует административного
интерфейса), он относитель-
но прост. Единственное, что требует некоторого
планирования — ис-
пользование локальных групп домена второго
яруса для предоставле-
ния доступа к ресурсам. Но есть такой процесс
миграции, при котором
сохраняется вся информация о доступе к ресурсам.
Исчезновение доменов второго яруса
Определение способа предоставления доступа
В модели мастер-доменов
Windows NT 4.0 для предоставления доступа
к ресурсам в доменах второго яруса применяются
три метода работы с
группами: использование глобальных групп
мастер-домена, локальных
доменных групп ресурсного домена, локальных
групп серверов — чле-
нов ресурсного домена.
Пример организации доступа к ресурсам в двухъярусной модели
На рисунке изображен
классический пример организации двухъярус-
ной модели. Мастер-домен Research связан
односторонними довери-
тельными отношениями с двумя ресурсными
доменами DB и OS таким
образом, что пользователи мастер-домена имеют
доступ к ресурсам
доменов второго яруса. Все
учетные записи пользователей располага-
ются в домене Research.
Пользователь AlbertE имеет
учетную запись в мастер-домене Research.
Он работает на принадлежащей домену DB рабочей
станции, где уста-
новлена Windows NT Workstation 4, и зарегистрирован под
своей до-
менной учетной записью.
На сервере OS1, входящем в
домен OS, в совместное использование
предоставлен каталог secret. Доступ к этому
каталогу ограничен в со-
ответствии со списком контроля доступа.
Пользователь AlbertE может
получить доступ к каталогу тремя способами,
используя:
• доверительные отношения и свою учетную запись в домене Research;
• доверительные отношения
и учетную запись локальной группы
OSDevs, членом которой он является, в домене Research;
• членство в локальной
группе, которая может принадлежать как все-
му домену OS, так и просто серверу — члену домена
OS.
В любом случае в список
контроля за доступом к каталогу будет внесен
уникальный идентификатор безопасности SID,
который, помимо про-
чей информации, содержит сведения о том домене
или компьютере, на
котором был создан. Напомним, что для доступа к
ресурсу необходима
аутентификация пользователя. В зависимости от
мандатов, переданных
для аутентификации, сервер использует либо
локальную базу данных,
либо передает мандаты службе NETLOGON, через которую
идет обра-
щение к базе учетных записей домена (см. главу 2).
Если пользователь
не может быть аутентифицирован в текущем домене,
то выполняется
его аутентификация в доверенных доменах. Этот
процесс называется
сквозной аутентификацией [I]. После
аутентификации создается мар-
кер доступа, используемый операционной системой
для доступа к ре-
сурсу от имени пользователя.
В рассматриваемом примере
маркер доступа содержит в себе SID учет-
ной записи Research/AlbertE, а также SID глобальной группы
Research/
OSDevs. В зависимости от того, является ли сервер OS1
контроллером
домена или просто сервером в домене, маркер
доступа будет включать
SID либо локальной группы домена OS/Researches, либо
локальной
группы сервера OS I/Researches.
При переносе домена
второго яруса в организационную единицу быв-
шего мастер-домена SID пользователей и групп
локального домена
перестают быть действительными, что может
впоследствии затруднить
доступ. Если же сервер — просто член домена, а не
его контроллер, SID
этого сервера переносятся без изменений.
Для разрешения этой
проблемы при миграции в Active Directory мож-
но копировать объекты безопасности из одного
домена в другой. Пос-
ле такого копирования для каждого объекта
безопасности будет суще-
ствовать по два SID: один — из старого домена и
один — из нового. При
формировании маркера
доступа в него будут записываться оба SID, что
снимет все проблемы доступа к ресурсам.
Как видим, миграция
доменов второго яруса в организационные еди-
ницы бывшего мастер-домена может выполняться без
потери инфор-
мации о правах доступа. Однако для этого
необходимо придерживать-
ся пошаговой процедуры миграции. Вот ее
подробное описание.
1. Миграция мастер-домена.
На первом шаге выполняется перевод
мастер-домена под управление ОС Windows NT 5.0, для чего
доста-
точно лишь обновить первичный контроллер домена.
После этого
можно присоединиться к существующему дереву
доменов.
Внимание! Даже если на
всех контроллерах мастер-домена будет
установлена служба каталогов Active Directory,
доверительные отно-
шения с ресурсными доменами останутся прежними,
не транзитив-
ными.
Шаг 1: миграция мастер-домена
2. Создание
организационных единиц. Так как цель миграции
—
исчезновение доменов второго яруса, необходимо
создать соответ-
ствующие им организационные единицы внутри
мастер-домена.
Вы можете создать
иерархичное пространство имен OU. В каждой
OU либо создают новые учетные записи
пользователей и групп, либо
их переносят из контейнера cn=users.
Организационные единицы
будут доступны только для тех клиен-
тов или серверов, где уже установлена поддержка
Active Directory. Для
всех остальных объекты безопасности будут
по-прежнему видны «в
одной плоскости».
Шаг 2: Создание организационных единиц
3. Миграция PDC в ресурсных
доменах. Следующий шаг — пере-
вод первичных контроллеров ресурсных доменов
под управление
Windows NT 5-0 и Active Directory.
После обновления
операционной системы на PDC между ресурсны-
ми доменами и мастер-доменом устанавливаются
транзитивные до-
верительные отношения. Ресурсные домены
подсоединяются к де-
реву доменов.
Внимание! Этот шаг
обязателен, если Вы планируете перевести
серверы или объекты безопасности из доменов
второго яруса в ма-
стер-домен. Перемещение объектов между доменами
не поддержи-
вается в Windows NT 4.0. Механизм отслеживания SID имеет
только
Active Directory.
А_
•Др Research\AlbertE
г- -п
Research И Reseaгch\osoevs
,_________К Ц AlbertE
/7\\
/ / \ \ 1. Перевод PDC в
ресурсных
ои - DB ou = os доменах на Windows NT 5
/ \
\YResearch-l\se'c.ret 2-
Подсоединение к дереву
/ OS-Researc\ers: Full Access доменов и установление
,/ ъ двусторонних транзитивных
АЛ доверительных отношений
/ 03\
_^ N,-I j^^^, OS-Reseaicheia
l==f'" l^J I———? Research\OSDevs
Jl¦lj¦¦^l.l \\OS1\secret
OS-Researchers:
d 11 Л Лг-соо о
ZZ/az 3: Обновление ОС на
первичных контроллерах ресурсных
доменов
4. Перевод серверов в
мастер-домен. Теперь все готово к переносу
ресурсов из ресурсных доменов в организационные
единицы мас-
тер-домена. Сделать это просто, ведь слепок
управления службой
каталогов Active Directory позволяет перетаскивать
объекты мышью'.
Для тех клиентов, которые
подключались к ресурсам, используя UNC
(универсальные соглашения об именовании), все
подключения ос-
таются действительными, так как для UNC не
существует доменных
границ. Клиенты, использовавшие для поиска
серверов NetBIOS, по-
прежнему могут применять этот механизм.
Если Вы администратор, то
должны принять решение: продолжать
ли использование NetBIOS, или публиковать ресурсы
только в Active
Directory. Критерий выбора прост: до тех пор, пока Вы
планируете
работать с клиентами, не поддерживающими Active
Directory, Вы
будете вынуждены применять и NetBIOS, и Active Directory. Как
толь-
ко последний «старый» клиент будет обновлен,
поддержку NetBIOS
можно выключать.
Стоит ли на этом этапе
выключить первичные контроллеры ресур-
сных доменов? Еще нет. Дело в том, что пока они еще
несут ответ-
ственность за все выданные ими идентификаторы SID,
Предполо-
жим, что при
аутентификации на одном из BDC, перенесенном в
мастер-домен, понадобится проверить SID. BDC
обратится к первич-
ному контроллеру. Двусторонние доверительные
отношения Кег-
beros и сквозная аутентификация позволят
авторизовать доступ.
5. Проверка списков
коитроля доступа. Вспомните, как был орга-
низован доступ к ресурсам: через глобальные
группы мастер-доме-
на, через локальные группы ресурсного домена или
через локальные
группы серверов домена.
Если использовались
глобальные группы домена, то они по-прежне-
му существуют, а значит, никаких изменений в
списках контроля за
доступом не требуется.
Если использовались
локальные группы серверов — членов домена,
то все эти группы были перемещены вместе с
серверами. Как и в
предыдущем случае, изменения в ACL не нужны.
Если использовались
локальные группы ресурсных доменов, то сле-
дует помнить, что очень скоро контроллеры
ресурсных доменов
прекратят свое существование. Поэтому
необходимо перенести
группы в мастер-домен, сделав их обычными. После
переноса не
требуется вносить изменения в ACL.
6. Перенос рабочих
станций в мастер-домен. Кроме серверов, из
ресурсных доменов в мастер-домен необходимо
переместить рабо-
чие станции. Для Windows 95 и Windows 98 это просто —
достаточ-
но изменить название рабочей группы в настройках
сети. Для Win-
dows NT Workstation нужно сначала выполнить удаление из
ресурс-
ного домена, а затем — подключение к новому
домену. При этом в
мастер-домене будет создана новая учетная запись
для этого компью-
тера. Этот шаг можно завершить установкой
сервисного пакета для
Windows 95, либо обновлением Windows NT Workstation до 5 вер-
сии. Обновление можно произвести с помощью SMS в
автоматичес-
ком режиме.
7. Выключение первичных контроллеров ресурсных доменов.
На этом этапе миграция
практически завершена. Все, что можно
было перенести в мастер-домен, уже перенесено.
Первичные кон-
троллеры ресурсных доменов можно либо выключить,
либо перене-
сти их в мастер-домен. В любом случае ресурсные
домены прекра-
тят свое существование.
Установка операционной системы
Пока еще (на стадии первой
бета-версии) довольно рискованно давать
какие-либо советы по установке операционной
системы. Очевидно, что
она еще находится на стадии разработки, а
особенности версии изло-
жены в соответствующих файлах, поставляемых на
компакт-диске. Тем
не менее, уже можно дать несколько практических
рекомендаций, вы-
явленных п ППОИРГГР пяботы
Если Вы устанавливаете рабочую станцию
Установка рабочей станции
не требует дополнительных знаний или
предварительной подготовки (также как и
предыдущая версия Win-
dows NT). Все что Вам нужно, это:
• компьютер с процессором
Intel (желательно Pentium, Pentium II или
Pentium Pro) или Alpha; процессоры MIPS и PowerPC больше не под-
держиваются Windows NT;
• оперативная память не менее 32 мегабайт (проверено на практике:
меньше для нормальной работы не годится);
• свободное пространство
на жестком диске не менее 200 Мб (при
условии, что Вы выполняете полную установку с
загрузочных
дискет программы установки; если же использовать
программу
Winnt32.exe, то объем требуемого свободного
пространства придет-
ся удвоить);
• проигрыватель
компакт-дисков (за неимением такового можно
обойтись подключением к сетевому ресурсу,
содержащему файлы
Windows NT 5.0);
• сетевая плата.
Внимательно просмотрите
список совместимого оборудования. Может
так случиться, что имеющаяся у Вас плата в нем
пока отсутствует. На-
пример, устанавливая систему на портативный
компьютер, обратите
внимание на PC-карточку. В первой бета-версии не
поддерживаются
комбинированные карты (например, модем + сетевая).
Драйвер от пре-
дыдущей версии не подойдет.
Уточните тип
видеоадаптера, используемого в компьютере. Не ис-
ключено, что если в стандартную поставку еще не
включена его под-
держка, то вполне можно использовать драйвер,
разработанный для
Windows NT 4.0 и поставляемый производителем.
Windows NT 5.0 может
устанавливаться как обновление одной из сле-
дующих версий Windows, а именно:
• Windows З.х;
• Windows 9x;
• Windows NT Workstation 4.0.
При обновлении сохранятся
настройки установленных приложений,
что выгодно отличает новую версию от предыдущей,
не позволявшей
выполнять обновление Windows 95.
Внимание! Если в
текущей версии ОС Вы используете Microsoft
Internet Explorer 4.0, то обновить систему будет
невозможно. Удалите
эту версию и установите Internet Explorer З.х.
Программа Winnt32.exe
Установка новой ОС
производится так же, как и ранее — либо с трех
загрузочных дискет, либо запуском программы
Winnt32.exe из преды-
дущей версии 32-разрядной ОС. Как командный, так и
пользователь-
ский интерфейсы последней изменились. Синтаксис
используемых па-
раметров следующий:
winnt32 [/s:sourcepath] [/tempdrive:drive_letter]
[/unattend[num]
[:unattend_file] [/соpydir:directory_name]
[/copy source:directory_name] [/cmd:command_line]
[/debug[level][:filename]] [/udf:id[,UDF_file],
где:
• /s : sou rcepath — указывает
положение файлов Windows NT; если ука-
зать несколько каталогов путем многократного
использования клю-
ча /s, то программа Setup будет одновременно
копировать файлы из
разных источников, что сократит общее время
загрузки;
• /tempdrive : drive_letter
—предписывает программе Setup размес-
тить временные файлы на указанном диске;
• /unattend — выполняет
обновление предыдущей версии Windows NT
в автоматическом режиме без вмешательства
пользователя; все ус-
тановки пользователей берутся из предыдущей
версии;
• /unattend[num]: unattend_file —
выполняет обновление предыдущей
версии Windows NT в автоматическом режиме, но для
пользователь-
ских установок указывает файл сценария (также
называемый фай-
лом ответов), а не использует имевшиеся ранее; при
этом
— n urn — число секунд, в
течение которых программа Setup будет
ожидать перезагрузки после копирования файлов
(появится диа-
логовое окно с отсчетом времени). Следует
отметить, что между
/unattend и num нельзя вставлять пробел (например,
можно ввес-
ти /unattend30 : my_answers. txt). Параметр num можно использо-
вать только в командной строке Windows NT;
— unattend_file — имя файла
сценария; пример этого файла на-
ходится в каталоге исходных файлов Windows NT и
называется
Unattend.txt;
• /copydir :directory_name — создает
дополнительный каталог внут-
ри того каталога, в который устанавливается Windows
NT; например,
если в каталоге, содержащем исходные файлы,
имеется подкаталог
Private_drivers, содержащий драйверы устройств,
используемых в
Вашем компьютере, то параметр /copydir:Private_drivers
предпишет
программе установки скопировать этот каталог в
каталог Windows NT
(например, C:\Winnt\Private_drivers), Многократно используя
па-
раметр /copydir можно создать дополнительные
подкаталоги;
• /copysou i-ce : di recto ry_name —
предписывает программе Setup ско-
пировать исходные файлы в каталог на жестком
диске, причем
— при установке с сетевого
ресурса такое копирование выполняет-
ся по умолчанию;
— при установке с
компакт-диска этот параметр целесообразно за-
дать в том случае, если после перезагрузки
компакт-диск будет
недоступен (не поддерживается системой) или
скорость его ра-
боты мала;
• /cmd ; cornmand_line —
предписывает программе Setup выполнить оп-
ределенную команду после завершения графической
части програм-
мы установки (после того, как компьютер
перегрузился два раза,
собрана вся информация о компьютере, но
установка еще не завер-
шилась);
• /debug[level][: filename] — создает
журнал отладки с указанным
уровнем; по умолчанию создается файл C:\Winnt32.1og с
уровнем от-
ладки 2 (предупреждение);
• /udf : id[, UDF_file] —указывает
идентификатор id, используемый
программой Setup для определения того, как UDF (файл
базы дан-
ных уникальности) изменяет файл сценария (см,
параметр /unattend);
при этом
— параметр UDF заменяет
значения в файле автоматической уста-
новки, и идентификатор определяет, какие
значения в файле UDF
используются; например, /udf;RAS_user,Our_company.udf заменяет
установки для идентификатора RAS_user в файле Our_company.
udf;
— если не указано имя
файла UDF_file, программа Setup напомнит
пользователю вставить диск с файлом $Unique$.udf.
Программа установки Windows NT 5-0
Пользовательский
интерфейс этой программы также изменился и на-
поминает интерфейс программы-мастера. Вам
необходимо последова-
тельно ответить на несколько простых вопросов и
программа установ-
ки начнет копирование установочных файлов на
жесткий диск (или
диски).
Программа Winnt.exe
Для обновления 16-разрядной
версии Windows или установки систе-
мы из MS-DOS, можно, как и раньше, воспользоваться
программой
Winnt.exe. Синтаксис ее параметров следующий:
WINNT [/S[:]sourcepath] [/Т[: jtempdr-ive] [/![:]inffile]
[/0[X]]
Е/Х I [/F] [/С]] [/В] [/U[:scnptfile]] [/R[X] :directory]
[/Е:command] [/A],
где:
• /S[: ]sou rcepath — указывает
положение исходных файлов Windows
NT; причем должен быть задан полный путь в виде
x:\[path] или
\\server\share[\path]; по умолчанию используется активный
каталог;
• /Т[: ]tempd rive — указывает
диск, на котором будут размещены вре-
менные файлы; если файл не указан, то программа
установки выбе-
рет диск сама;
• /I[:]inffile — указывает имя
(не путь) информационного файла
программы установки (по умолчанию DOSNET.INF);
• /OX — создает загрузочные дискеты для установки с компакт-диска;
• /X — не создает загрузочных дискет;
• /F — не проверяет файлы, копируемые на загрузочные дискеты;
• /С — не проверяет, есть
ли свободное место на загрузочных диске-
тах;
• /В — установка без дискет (требуется задать параметр /s);
• /U — автоматическая
установка и, возможно, имя файла сценария
(требуется задать параметр /s);
• /R — указывает
дополнительный создаваемый каталог (см. описание
параметров winnt32.exe);
• /RX — указывает
дополнительный каталог для копирования (см. опи-
сание параметров winnt32.exe);
• /Е — указывает команду,
исполняемую по завершении графической
части программы установки (см. описание
параметров winnt32.exe);
• /А — разрешает
использование дополнительных функций для лю-
дей с ограниченным зрением.
В процессе установки
внимательно отвечайте на все задаваемые про-
граммой вопросы. Если все параметры указаны
правильно, а в компью-
тере отсутствуют устройства, не поддерживаемые
операционной сис-
темой, установка пройдет гладко и без
особенностей. Все, что Вам ос-
танется — настроить
интерфейс так, как нравится, и установить при-
ложения, с которыми Вы будете работать.
Если Вы устанавливаете сервер
Установка сервера, в
отличие от установки рабочей станции, требует
тщательного планирования. В еще большей степени
это относится к
установке контроллера домена.
Для начала разберитесь с требованиями к технике. Вам необходимы:
• компьютер с процессором
Intel (желательно Pentium, Pentium II или
Pentium Pro) или Alpha;
• оперативная память не менее 48 мегабайт (проверено на практике:
меньше не годится, что
особенно заметно при работе со службой
каталогов Active Directory — поиск в базе тем быстрее,
чем больше
оперативной памяти);
• свободное пространство
на жестком диске не менее 250 Мб (при
условии, что Вы выполняете полную установку с
загрузочных дис-
кет; если же использовать программу Winnt32.exe, объем
требуемо-
го свободного пространства нужно удвоить);
• проигрыватель
компакт-дисков (если его у Вас нет, то можно обой-
тись подключением к сетевому ресурсу,
содержащему файлы Win-
dows NT 5.0);
• сетевая плата.
Внимательно просмотрите
список совместимого оборудования. Обра-
тите внимание на типы высокоскоростных
адаптеров, поддерживаемых
в новой версии. Для сервера это весьма актуально.
Уточните тип
видеоадаптера, используемого в компьютере. Не
исклю-
чено, что в стандартную поставку еще не включена
его поддержка, но
вполне подойдет драйвер, разработанный для Windows NT
4.0 и постав-
ляемый производителем.
Windows NT Server 5.0 может
устанавливаться как обновление Windows
NT Server 4.0. При обновлении сохранятся настройки
установленных
приложений.
Внимание! Если в
текущей версии ОС Вы используете Microsoft
Internet Explorer 4.0, то обновить систему будет
невозможно. Удалите
эту версию и установите Internet Explorer З.х.
Перед установкой контроллера домена
Перед установкой контроллера домена необходимо знать:
• это контроллер
вновь создаваемого домена или нет; если нет, то
выясните имя домена, имя сервера DNS, имя узла; если
да, то:
• определите, входит ли
этот домен в уже существующее дерево доме-
нов, или станет корневым доменом нового дерева;
если входит, то
выясните, какой домен станет родительским для
вновь создаваемо-
го; если нет, то:
• выясните, какие серверы
DNS существуют и, при необходимости,
спланируйте собственный сервер, который будет
располагаться на
устанавливаемом; выясните, к какому узлу будет
принадлежать дан-
ный домен; если узла нет, то спроектируйте его;
• если узел существует и в
нем имеются иные деревья доменов, то
определите нужен ли новый лес или новое дерево
доменов будет
включено в существующий.
Схематично эти шаги изображены на рисунке на следующей странице.
Дополнительно необходимо
выяснить, является ли этот контроллер
сервером глобального каталога.
Если сервер будет
исполнять роль сервера приложений, то необходи-
мо рассчитать требования к ресурсам,
воспользовавшись методикой,
приведенной в [I].
Процесс установки
выполняется, как и для предыдущих версий: либо
загрузкой с трех дискет, либо запуском программы
Winnt32.exe из пре-
дыдущей версии 32-разрядной ОС, либо программы
winnt.exe из MS-
DOS. Синтаксис параметров командной строки этих
программ приве-
ден выше.
Если используется техника,
соответствующая списку совместимого
оборудования, и отсутствуют конфликты
параметров, процесс установ-
ки в большинстве случаев протекает гладко и без
осложнений. Необ-
ходимо четко следовать указаниям программы
установки и своевремен-
но отвечать на вопросы.
Замечание. В процессе
установки сервера Вам будет предложено вве-
сти пароль администратора. На контроллере домена
во время установ-
ки службы каталогов Active Directory этот пароль будет
сброшен и за-
дан пустым. Поэтому сразу после установки
войдите в систему и изме-
ните пароль.
После завершения
установки сервера можете приступать к установке
на нем приложений.
Схема планирования установки контроллера домена
Заключение
Новая версия Windows NT
предоставляет много оригинальных и полез-
ных функций, среди которых можно выделить:
• службу каталогов Active Directory;
• транзитивные доверительные отношения Kerberos между доменами;
• деревья доменов;
• леса доменов;
• тиражирование каталога между узлами.
Все эти функции
значительно расширяют возможности
использования
Windows NT в крупных организациях, сохраняя гибкость
и простоту
работы в мелких и средних. Однако для правильного
планирования
сети необходимо глубокое знание службы
каталогов, принципов тира-
жирования данных, тонкостей настройки DNS и ряда
других важных
вещей. Возможно, что администраторы (в
особенности малых сетей)
еще не готовы к этому и ожидают от Windows NT 5.0 такой
же просто-
ты в планировании, как в предыдущих версиях.
Чтобы избежать разо-
чарований, стоит уже сейчас изучать и
прорабатывать пути миграции
на новую версию.