Поднятие домена MS Windows 2003 Server

Как настроить домен Windows 2003?

Прежде всего, не удержусь от лингвистической ехидности – настроить домен, или поднять домен? Всё ж таки настройка и поднятие – создание с нуля – домена далеко не одно и то же. Настройка – доведение до ума уже существующего домена с целью заставить его соответствовать нуждам пользователей. А вот поднятие домена – занятие особенное. Можно сказать – целое приключение в духе исследователей неизведанных миров…

Что такое «домен»?

 

Чтобы понять, как поднять домен, следует – что вполне очевидно – представлять себе, что такое домен, с чем его едят (и едят ли) и нужен ли он вообще. Сие банальное рассуждение видится актуальным по той простой причине, что зачастую приходится сталкиваться с ситуациями, когда человек хочет сделать что-то, о чём не имеет представления, но о чём знает, что это – штука крутая и модная. Я лично однажды слышал утверждение в духе: «У нас же серьёзная компания! Нам просто необходим домен!». А между тем в этой компании, в серьёзности коей я ни мгновения не сомневаюсь, имелось всего десять компьютеров и задачи на них возложены максимально примитивные – печатная машинка и Интернет. Для такой сети домен – однозначно пятое колесо. Но что же такое домен?
Путём прочтения умных книг1 выясняется, что домен – это не самостоятельное понятие. Домен – есть одно из основных средств формирования пространства имён каталога Active Directory. Наряду с доменами таковыми средствами формирования являются административная иерархия и физическая структура сети. Причём все три средства могут использоваться как в самостоятельном виде, так и в комплексе. В уже упомянутой умной книжке читаем, что операционные системы Windows традиционно использовали понятие «домена» для логического объединения компьютеров, совместно использующих единую политику безопасности. И далее по тексту – домен традиционно выступает в качестве основного способа создания областей административной ответственности.
Чтобы двигаться дальше нелишним, я полагаю, будет привести и некое определение той самой Active Directory, в рамках коей живёт понятие «домена». Каталог (он же – Active Directory на чужеземном языке) есть глобальное унифицированное хранилище информации об элементах сетевой инфраструктуры. Элементами же сетевой инфраструктуры являются пользователи, ресурсы (общие папки, принтеры и т.п.), сетевые службы (почтовые сервисы, веб-сервисы, сервисы базы данных и т.п.), компьютеры и прочее. Собственно, назначение каталога – дать пользователю возможность использовать все эти элементы сетевой инфраструктуры без необходимости знать точное расположение каждого элемента и выстраивать политику взаимодействия с этим элементом индивидуально.

 

А теперь переведём это всё на русский язык.
Итак имеем сеть. Локальную, разумеется, хотя Интернет в этом случае мало чем отличается от локалки. В ней есть куча пользователей, какие-то сетевые папки (в разной степени закрытые для доступа), принтеры, факсы, сканеры, компьютеры (разные по предназначению). В этой сети крутится пара баз данных разного предназначения. Пользователи этой сети гуляют по Всемирной Паутине (опять же, с разной степенью ограничений). Ну и ещё куча всякого разного, что способствует плодотворной работе пользователей сети и их же не менее плодотворному отдыху. Вполне очевидно, что всё это сетевое разнообразие должно быть приведено к общему знаменателю. Хотя бы для удобства управления этим сетевым хозяйством. В конце концов, представьте себе необходимость держать на контроле взаимные связи всего перечисленного со всем перечисленным же. Представили? Вот и у меня не получилось.
Но такие взаимные связи и такой общий знаменатель обеспечивается как раз с помощью Active Directory (будем для краткости далее её обозначать буквами АД). Вся структура всех взаимных связей между элементами нашей сети и вообще вся сетевая инфраструктура и иерархия хранится и учитывается именно в АД. Перед тем, как пользователь (или сервис сети) обратится к какому-либо ресурсу сети он осведомится в АД, как именно ему с этим ресурсом положено взаимодействовать.

 

А нужен ли нам домен?

 

Итак, перед нами встаёт первый вопрос – а стоит ли огород городить? Скажем, в Государственной Публичной Научно-Технической Библиотеке (ГПНТБ) имеется весьма обширный каталог содержащихся в ней изданий с рубрикатором, системой поиска и чётко заданными правами доступа к изданиям – сюда всем, а сюда только от четвёртого курса и выше. Если принять фонд ГПНТБ за сетевые ресурсы, то её каталог вполне наглядно иллюстрирует АД. И необходимость этого каталога для ГПНТБ очевидна. Но вот нужен ли такой же каталог для книжной полки, на которой стоит всего пара десятков книг? Найти нужную публикацию в ГПНТБ и воспользоваться ей в обход каталога ГПНТБ вы не сможете – даже если вам удастся пробраться непосредственно в хранилище, скорее всего, вашу мумию найдут через пару тысячелетий в трёх тысячах полок от заветной публикации. Но если мы имеем дело с книжной полкой, то проще подойти к ней и найти нужную книгу, окинув всю полку взглядом и не мороча себе голову с каталогом. Отсюда и вытекает первый вопрос – нужна ли нашей сети АД?
Критериев несколько. Во-первых, полномочия доступа пользователей к сетевым ресурсам. Во-вторых, количество этих самых ресурсов и пользователей. В-третьих, наличие в сети таких сервисов, как базы данных, почтовые сервисы, службы документооборота и тому подобное.
Ели в вашей сети имеется с десяток пользователей, пара сетевых папок, в которые каждый сваливает всё, что наработал, не скрывая своих документов от коллег. Если у вас имеется всего один сетевой принтер, на котором все и печатают, и кроме общего доступа в Интернет ничего больше нет. Если каждый ваш пользователь вот уже вторую сотню лет работает на одной и той же машине, которую привык считать своей и расставаться с которой не собирается ещё триста лет – смело забрасывайте идею поднятия АД в самый пыльный угол. Просто потому, что такой сети АД не нужна – под АД требуется выделенный (и достаточно мощный) сервер, ставить который ради учёта двух сетевых папок и одного принтера просто экономически нецелесообразно.
Если же в вашей сети живёт триста пользователей, да ещё разбитых по разделам, для каждого из которых имеется свой набор сетевых папок. Если вы используете сетевую версию 1С и весь документооборот ведёте через неё. Если вы содержите веб-сайт на серверах вашей компании и каждый отдел имеет свою почту – вам без АД не обойтись никак. Вы, как админ, быстро сойдёте с ума, если попытаетесь администрировать такую сеть без использования АД. И никогда не добьётесь успеха в этом безумном начинании.

 

Сколько и каких доменов нам надо?

 

Предположим, мы убедились, что АД нам нужна. Стало быть, необходимо её развернуть и настроить. Вот тут-то и приходит очередь домена.Дело в том, что АД не только содержит в себе информацию обо всех элементах сетевой инфраструктуры, но и описывает иерархию этой структуры. Вот с этой иерархией нам и надо определиться. В конце концов, чтобы совладать с сетью из трёхсот компьютеров и миллиона сетевых служб, её надо разбить на некие логически завершённые части и совладать с этими частями. Divida et impera!2 Таким образом, нам надо решить, как мы будем делить нашу сеть и будем ли мы её делить вообще.
Предположим, в нашей фирме имеется пять отделов, работающих в тесном контакте и содержащих не более четырёх сотрудников на отдел. Руководство, разумеется, считаем особняком. Сетевые папки, 1С, Exchange для документооборота и в качестве почтового сервиса, пара общих баз данных на SQL. АД нужна, но как её упорядочить? Вполне очевидно, что в данном случае делить сотрудников (и сетевые ресурсы) на группы внутри АД нелогично – их немного и они слишком тесно между собой контактируют.
Второй вариант – та же самая компания, но два из пяти отделов расположены в отдельном офисе на другом конце города. Связь – через Интернет (а как ещё?). Всё остальное – то же самое. Тут уже сложнее – нужно как-то сделать так, чтобы и сама АД была поделена на две части (по одной в каждом офисе), но объединена воедино.
Третий вариант – тридцать отделов в крупной фирме, каждый из которых в значительной мере независим от остальных. Вполне очевидно, что в данном случае каждому отделу компании должна соответствовать своя АД, полностью описывающая его сетевую инфраструктуру. Вместе с тем, все эти АД должны объединяться воедино в рамках предприятия.
Данные три примера несколько академичны, но хорошо описывают классические способы построения АД и создания доменов. Выше мы уже писали, что домен есть лишь средство формирования пространства имён АД – средство упорядочения АД. Как правило, домены создаются исходя из административной модели предприятия, которое обслуживается нашей сетью, или же по территориальному признаку – исходя из территориального упорядочения сети. И что же мы видим?
В первом варианте фирма представляет собой единое целое как с точки зрения административной, так и территориально. Кроме того, она не столь уж и велика. Для системного администратора это значит, что в ходе развёртывания АД будет создан один единственный домен, обслуживающий всю сеть фирмы в целом. Никакого деления в данном случае не будет – оно не нужно.
Во втором варианте фирма представляет в административном видении единое целое, но разнесена в пространстве географически. Имеет смысл разделить ЛВС этой фирмы по территориальному признаку – по количеству офисов. В этом случае в рамах развёртывания АД поднимается не один единственный домен, а лес доменов. Во-первых, свой домен у головного офиса. Во-вторых, свой домен у филиала. Ну и, наконец, корень леса – головной домен, которому будут принадлежать домены каждого из офисов. Соответственно, логично будет расположить корень леса и домен головного офиса в самом головном офисе, а домен филиала – в филиале (масло масляное, честное слово!). Соответственно, домен головного офиса будет согласовываться с корнем леса (его ещё принято называть Глобальным Каталогом – ГК сокращённо) по линиям ЛВС головного офиса, а домен филиала – через Интернет. Если же Интернет по разным причинам пропадёт, то домен филиала продолжит нормально функционировать и дождётся возобновления связи для согласования с ГК (такое согласование зачастую называют репликацией). Если бы у нас в данном случае был не лес, а отдельный домен (а такая схема тоже возможна), то обрыв Интернета парализовал бы начисто работу филиала, что не есть хорошо.
И, наконец, третий вариант. В этом случае территориально фирма едина, но административно – достаточно жёстко разделена. И по этому же самому признаку имеет смысл поделить ЛВС. Тогда в рамках развёртывания АД каждому отделу фирмы поднимается свой домен и, для объединения их всех в лес, создаётся ГК. В таком случае работы системного администратора над сегментом одного отдела фирмы никак не скажутся на работоспособности всех остальных отделов. Напротив, если бы у нас здесь был один самостоятельный домен, то падение какого-нибудь важного сервера могло парализовать работу всего предприятия, что едва ли приемлемо.
Разумеется, все описанные выше модели могут быть скомбинированы в зависимости от структуры конкретного предприятия и вам, как системному администратору, предстоит решить, какую именно схему АД строить и из каких частей она будет состоять. Тем не менее, практика показывает, что чаще всего ЛВС мелкого и среднего бизнеса построена по модели АД с одним самостоятельным доменом. И именно об этой модели мы и будем говорить в дальнейшем.

 

Контроллер домена.

 

Итак, у нас имеется локальная вычислительная сеть (ЛВС) с каким-то количеством серверов, но не объединённая АД. Мы решили развернуть в этой сети АД и поднять один самостоятельный домен. Стало быть, нам понадобится некий сервер, который будет содержать в своих железных недрах копию АД и станет всему головой. Это – контроллер домена. Так какой же он – контроллер домена?
Прежде всего, это должен быть именно сервер. То есть, на нём должна быть установлена серверная операционная система. Замечание кажется излишним, но… Напомним, что в сети на основе рабочих групп каждый компьютер – сам себе голова. Как правило, выделенных серверов в такой сети нет и понятие «сервера» там – исключительно номинальное. То есть, вполне возможно, что за нашим предполагаемым сервером сидит какой-то сотрудник и увлечённо строчит свои отчёты. При этом в качестве ОС у него, скорее всего, стоит Windows 2000 Professional или Windows XP Home Edition. На такой ОС домен не поднять. Нам нужен именно сервер с серверной ОС. Поскольку мы говорим о доменах Windows, то в качестве серверной ОС мы можем рассматривать MS Windows NT, MS Windows 2000 Server и MS Windows 2003 Server. При этом есть подозрение, что ОС MS Windows NT несколько устарела. Я бы даже сказал – тотально устарела, так что домены на её основании здесь рассматриваться не будут.
Второе замечание касается мощности той машины, которая станет контроллером домена (КД). Аппаратное обеспечение следует подбирать, исходя из основных соображений по серверам. К примеру, файловый сервер должен обладать объёмистыми дисками, хорошо защищёнными и достаточно быстрыми, чтобы быть в состоянии с приемлемой скоростью отдавать всем желающим в любой момент любые файлы любого объёма. Зато, к примеру, мощный процессор (и высокая вычислительная мощность, соответственно) ему без нужности – он же ничего не считает. А вот сервер базы данных, напротив, к объёму диска и его скорости не очень чувствителен. Объём передаваемой информации при работе с базой данных, как правило, не так уж и велик. Объём самой базы может быть огромен, спору нет, но в каждый момент времени из этой базы требуется лишь маленькая её часть. А вот задача найти эту часть и соответствующим образом её обработать и отдать клиенту (провести транзакцию) возложена как раз на вычислительные мощности сервера. Причём таких транзакций может в каждый момент времени потребоваться много и одновременно. Таким образом, на роль сервера базы данных требуется машинка с могучим процессором (и лучше не с одним) и приличным объёмом оперативной памяти. Сервер печати принимает по сети задание печати (которое, заметим, может значительно превышать объём печатаемого файла) и отдаёт это задание принтеру. Определённая вычислительная мощность на это уходит, но не столь большая, как у сервера баз данных. Иными словами, сервер печати стоит где-то между сервером базы данных и файловым сервером.
Короче, совсем коротко – аппаратное обеспечение каждого сервера выбирается на основании задач, какие будут возложены на этот сервер. Но какие же задачи будут возложены на наш КД? Как уже говорилось, на КД хранится копия АД. И эта копия АД описывает всю нашу сетку и все взаимодействия между её элементами. А это значит, что данная копия АД – едва ли не самое ценное в нашей сети. Собственно, для системного администратора это и есть самое ценное. Если вы обрушите файловый сервер, ваш админ вас отругает, если вы обрушите КД – он вас убьёт с особой жестокостью и цинизмом. Таким образом, наш КД должен быть надёжно защищён от всего, включая прямое попадание атомной бомбы. Прежде всего, речь идёт о дисках КД. Разумеется, даже самый крутой современный диск тут не годится (хотя можно, очень даже можно). Для КД подходит только и исключительно RAID. Самый лучший, разумеется, но рассматривать разные модели RAID нам тут не с руки – не наша тема.
Далее, оперативка и процессор. Коль скоро наш КД содержит в себе всю инфраструктуру нашей сети, то эта инфраструктура (наша АД) представляет собой базу данных. Несколько специфическую, но тем не менее. А это значит, что КД должен уметь обработать данные этой базы и предоставить их клиенту в любой момент времени. То есть, провести транзакцию. Причём следует помнить, что клиенты трясут КД на предмет этих самых данных ежесекундно. Таким образом, на КД ложится функция сервера базы данных, да ещё и интенсивно использующегося всеми членами сети. Отсюда повышенные требования к процессору и памяти. Конкретные рекомендации предлагать не буду, но отмечу, что лично я в настоящий момент ищу возможности приобрести на сеть из 30 машин КД с двумя процессорами на 3ГГц и с не менее 4Гб оперативной памяти. И опасаюсь, что это будет впритык…
Далее, сетевое оборудование. Собственно, сетевая карточка. Пропускная её способность должна быть велика и с лихвой перекрывать потребности сети. С другой стороны, ставить гигабитную карточку в КД при наличии сети на витой паре категории 5 со скоростью 100 мегабит едва ли будет разумно – КД станет отдавать информацию настолько быстро, что клиенты просто не справятся с ним. Или же, напротив, сетевой адаптер приспособится к скорости ЛВС и станет работать на 100 мегабитах, так что всё преимущество гигабитной сети пропадёт. А вот поставить две сетевые карты, к примеру, и настроить их на параллельную работу, может оказаться вполне разумным шагом.
Материнская плата должна быть самой надёжной. Достаточно порыться в Интернете и выяснить, чьи изделия этого класса сейчас пользуются признанием, и принять решение. Видеокарта и звуковая карта для сервера, вполне очевидно, без надобности.
Блок питания. Одна из самых важных частей любого вообще компьютера. От его мощности зависит, насколько сильно он будет греться при работе (а ведь сервер включён круглосуточно семь дней в неделю!) и насколько стабильным он будет при возможных экивоках нашей электрической сети. Сильно сомневаюсь, что стандартный блок на 250 ватт пригоден для сервера. Но даже и при мощном блоке питания присутствие ИБП обязательно. В конце концов, наши энергетики способны на всё и было бы просто обидно из-за их экспериментов потерять самое ценное в сети – её голову.
Про такие мелочи, как отдельное помещение с кондиционированием и ключик, не позволяющий непосвящённым прикоснуться к этой святыне ЛВС, я не говорю – настолько очевидны эти вещи.

 

Итак, сервер куплен, подключён, настроен, находится в сети (в рабочей группе – другого пока нет) и видит прочие машины. Установлена ОС, всё готово. Или не всё?
Домен есть одно из средств формирования пространства имён в АД. И в локальной сети каждая машина задаётся своим именем и своим IP-адресом. Нетрудно сообразить, что именно об этих именах и идёт речь. И тогда встречный вопрос – как имя машины относится к её IP-адресу? Ответ известен любому системному администратору – как в базе DNS написано, так и относится. Соответственно, в нашей сети должна быть такая база и должна быть запущена служба, способная с этой базой работать. Проще говоря, в нашей сети должен быть DNS-сервер. И на этом сервере должен быть зарегистрирован наш будущий КД. Причём, что важно, все сетевые интерфейсы нашего будущего КД должны иметь статические IP-адреса. При этом на самом КД должен быть прописан адрес предпочитаемого DNS-сервера, т.к. в процессе развёртывания АД пространство имён будет создано на основе базы DNS этого сервера и сам наш КД будет зарегистрирован на этом сервере. Надеюсь, не требует специального уточнения, что этот DNS-сервер должен реально присутствовать в сети и работать.
Если же DNS-сервера в сети ещё нет, имеет смысл организовать его на нашем будущем КД, совместив, таким образом, эти две функции в одном сервере. В принципе, на стадии установки контроллера домена Windows способна проверить наличие и работоспособность существующих в сети DNS-серверов. Если указанный в параметрах сетевого подключения DNS-сервер будет работоспособен и сможет доказать своё соответствие требованиям АД к DNS-серверам, то Windows начнёт построение домена с использованием этого сервера. Если же удовлетворяющего требованиям АД сервера обнаружено не будет, Windows способна автоматически создать и настроить с нуля новый DNS-сервер, который будет физически совмещён с вновь создаваемым контроллером домена.

 

Этапы установки контроллера домена

 

Для создания контроллера домена необходимо иметь готовый сервер с установленной и настроенной ОС MS Windows 2003 Server. В меню Administrative Tools (Администрирование) находим пункт Configure Your Server (Управление данным сервером). Из открывшегося окна можно легко и просто запустить Мастер Установки Active Directory (Active Directory Installation Wizard).
Работа мастера установки АД осуществляется по четырём сценариям:

 

1.     Создание нового леса доменов;

 

2.     Создание нового дерева доменов в рамках существующего леса доменов;

 

3.     Создание нового домена в рамках существующего дерева доменов;

 

4.     Установка дополнительного контроллера домена в уже существующем домене.

 

Вторая и третья схемы используются в случаях, когда сеть организационно имеет более одного домена. Как мы договорились выше, мы рассматриваем случай установки самого первого домена и, поэтому, вторая и третья схемы нам не подходят. Четвёртая схема применяется при установке резервного контроллера домена и о ней мы здесь говорить не будем. Таким образом, на этой стадии поднятия домена следует выбирать первый сценарий. При этом словосочетание «лес доменов» не должно никого пугать. В конце концов, любой лес начинается с одного – самого первого – дерева, и только от нас зависит, разрастётся ли это дерево до леса, или же так и останется стоять в одиночестве.
Итак, выбираем первый сценарий установки. После этого мастер потребует от нас ввести доменное имя и NetBIOS-имя будущего контроллера домена. Что это за имена?

 

Собственно, все знают о существовании домена microsoft.com. То есть, где-то имеется сервер, содержащий копию АД и являющийся контроллером домена microsoft.com. Доменным именем, в данном случае, является сочетание символов «microsoft.com».
При создании своего нового домена мы вольны выбрать ему любое доменное имя, но... Необходимо, всё же, учитывать некоторые тонкости. Во-первых, доменное имя пишется латинскими буквами и только ими. Допускаются некоторые специальные символы (тире, знак подчёркивания и, кажется, всё). Во-вторых, необходимо избежать пересечения с уже существующими доменными именами. К примеру, компания, для которой мы создаём домен, носит гордое название РОГА. Совершенно очевидно, что присутствие этого слова в доменном имени более, чем оправдано. Кроме того, фирма-то наша, русская. Казалось бы, доменное имя напрашивается само собой – roga.ru. Ан нет!
Как только мы зададим такое доменное имя, в нашем локальном DNS-сервере появится запись о домене roga.ru и его содержимом. А где физически находится это содержимое? В нашей ЛВС, ибо где же ещё ему быть? И если пользователь нашего домена в своём веб-браузере наберёт http://www.roga.ru с целью ознакомиться с содержимым корпоративного веб-сайта, то попадёт ли он на этот сайт? Отнюдь нет! Ведь нашего пользователя обслуживает наш локальный DNS-сервер, а в нём нет записи об IP-адресе хоста, содержащего веб-сайт компании. И не может быть, потому что хост этот находится за пределами нашей ЛВС3. Таким образом, DNS-сервер даст ответ о невозможности разрешить имя данного хоста и браузер пользователя сообщит о невозможности открыть страницу – хост не найден. Сайт не найден в нашей ЛВС потому, что искать его следует в глобальной сети, а источником проблемы является тот факт, что доменное имя нашей ЛВС совпадает с доменным именем, зарегистрированным в глобальной сети интернет.
Конечно, можно осведомиться на соответствующих интернет-сервисах, не занято ли столь подходящее нам доменное имя roga.ru, но есть гораздо более простой и, одновременно, изящный вариант. В интернете имеется зона RU для регистрации доменов рунета – русскоязычной части интернета. Но в интернете нет зоны LOCAL. Вместе с тем суффикс LOCAL указывает на то, что речь ведётся о локальной сети. Соответственно, для компании с гордым названием РОГА имеет смысл зарегистрировать в интернете домен roga.ru и создать локальный домен roga.local для обслуживания ЛВС. Такой подход снимет все проблемы пересекающихся доменных имён и, одновременно, выглядит вполне логичным.

 

Далее следует NetBIOS-имя будущего контроллера домена. Это – то самое имя, которое выводится в Сетевом Окружении. Проще говоря, это – имя компьютера. Как назвать свой КД – дело каждого админа. Можно обозвать его PDC (Primary Domain Cotroller – Первый Контроллер Домена). Я, например, в своё время слышал такую схему: домен назвать universe.local (universe – вселенная). Каждому серверу в этом домене присвоить имя какой-нибудь звезды. Обозвать, к примеру, КД именем sun (Солнце). А каждую клиентскую машину назвать именем планеты или её спутника – к примеру, Pluto (Плутон). Здесь нет никаких чётких рекомендаций кроме правил для NetBIOS-имён. Более того, если не полениться и приложить к имени компьютера его краткое описание (для этого предусмотрена отдельная строка при именовании компьютера ещё на стадии установки ОС), то пользователь, вошедший в Сетевое Окружение, и без необходимости запоминать имена компьютеров легко и мгновенно в нём сориентируется.
Заметим в скобках, что кроме NetBIOS-имени компьютера имеется и его полное имя. Оно складывается из NetBIOS-имени компьютера и имени домена, которому этот компьютер принадлежит. К примеру если КД домена universe.local называется pluto, то полное имя этого КД будет pluto.univere.local. Если же компьютер pluto никакому домену не принадлежит, то его полное имя будет выглядеть как pluto. (именно так, с точкой на конце).
Таким образом, будем считать, что доменное имя и имя будущего КД выбраны и введены.

 

Следующий этап поднятия домена состоит в том, что мастер предложит выбрать место под файлы хранилища АД и журналов, равно как и место системного тома. Проще говоря, вам предложат выбрать папки, в которые будет установлена АД. Как правило, едва ли имеет смысл менять предложенные мастером умолчания, но если на будущем КД имеется несколько локальных томов, у вас может возникнуть желание выбрать наиболее подходящий из них для этой цели. Собственно, требований тут несколько:

 

1.     Хранилище АД, журналы и системный том (SYSVOL) могут располагаться исключительно на томах, отформатированных в файловую систему NTFS.4

 

2.     Имеет смысл разместить хранилище АД, журналы и системный том на самом защищённом и надёжном жёстком диске или RAID, если в компьютере содержится несколько физических дисков.

 

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

 

Следующий этап – общение с DNS-сервером. В сетевых настройках вашего будущего КД должен быть прописан предпочитаемый DNS-сервер. Имея эту информацию, мастер установки АД способен послать этому серверу запрос и протестировать его на предмет пригодности для развёртывания АД. К этому серверу будут предъявлены следующие требования:

 

1.     Наличие в сети (реальное наличие и работоспособность).

 

2.     Поддержка ресурсных записей SRV-типа.

 

3.     Возможность динамической регистрации имён.

 

Если сервер удовлетворяет этим требованиям, он будет использован при построении АД. Иначе мастер предложит на выбор несколько вариантов:

 

·        Повторное тестирование DNS-сервера. Предполагается, что системный администратор понял намёк, вмешался и исправил все проблемы с существующим DNS-сервером. Он готов протестировать его ещё раз, чтобы убедиться в его пригодности.

 

·        Установка и конфигурирование нового DNS-сервера на данном компьютере. Самый удобный вариант – Windows не станет разбираться с имеющимися серверами и создаст себе новый, полностью удовлетворяющий её требованиям и настроенный должным образом, совместив его с будущим КД.5

 

·        Настройка DNS-сервера после установки АД. Предполагается, что системный администратор учёл наличие проблемы с DNS-сервером и исправит её по завершении установки АД.
При возникновении ошибки я советую воспользоваться вторым вариантом. Ну а если ошибки не возникло, то можно оставить всё, как есть, и использовать существующий DNS-сервер.

 

И, наконец, заключительный этап – определение уровня разрешений для системы безопасности. В вашей сети могут присутствовать другие сервера под управлением Windows, равно как и сервера под управлением других ОС. Возможны два варианта:

 

1.     В сети присутствуют только сервера под управлением MS Windows 2000 Server и MS Windows 2003 Server.

 

2.     В сети присутствуют сервера под управлением MS Windows NT и прочих серверных ОС (к примеру, семейства *nix), тогда как наш будущий КД управляется MS Windows 2003 Server.

 

Соответственно, существуют две модели работы системы безопасности. Первая модель позволяет анонимный доступ к информации в доменном разделе каталога. Эта модель использовалась в доменах под управлением MS Windows NT. Таким образом, если в нашей сети будут присутствовать сервера (это могут быть любые сервера, не обязательно КД) под управлением MS Windows NT, нам необходимо в мастере установки АД отметить галку Permissions compatible with pre-Windows 2000 operating system (Разрешения, совместимые с более старыми, нежели Windows 2000, ОС). Точно так же следует поступить и в том случае, если в домене планируется использовать сервера под управлением ОС семейста Unix, т.к. они общаются с КД именно по этой схеме.
Если же в нашем новоиспечённом домене будут только сервера под управлением MS Windows 2000 Server и MS Windows 2003 Server, то выбирать уровень совместимости с более старыми ОС не стоит. И даже не рекомендуется, поскольку отключение анонимного доступа куда бы то ни было – один из главных элементов информационной безопасности.
Если же вы при установке домена совместимость разрешений с предыдущими версиями ОС не задали, а впоследствии сервер, требующий такой совместимости, в сети всё же появился, то этот уровень можно установить командой:

 

net localgroup «Pre-Windows 2000 Compatible Access» everyone /add

 

Заметим в скобках, что установка уровня совместимости разрешений имеет отношение только к серверам. Иными словами, наличие в домене клиентских станций под управлением сколь угодно древних версий любых ОС на выбор уровня совместимости не влияет. И наоборот – выбор уровня совместимости не влияет на поведение клиентских станций с любыми версиями ОС в домене.

 

Этап выбора уровня совместимости был последним. После его завершения потребуется перезагрузить систему. В процессе последующей загрузки в базе DNS будет зарегистрировано доменное имя и на нашем КД будет создана учётная запись администратора домена. Точнее, не создана.
Установку АД и поднятие КД следует производить от имени локального администратора нашего сервера – это очевидно. И именно его учётная запись будет преобразована в учётную запись Administrator и включена в следующие группы:

 

·        Administrators. Встроенная локальная группа.

 

·        Domain Admins. Группа АД, члены которой имеют право управлять доменом.

 

·        Domain Users. Группа АД, членами которой являются все создаваемые пользователи домена.

 

·        Enterprise Admins. Группа АД, члены которой имеют право управлять инфраструктурой каталога.

 

·        Group Policy Creator Owners. Группа АД, имеющие право редактировать параметры групповых политик в пределах данного домена.

 

·        Schema Admins. Группа АД, члены которой имеют право изменять схему каталога.

 

Соответственно, по окончании этого этапа вам останется вписать в ваш домен все компьютеры вашей ЛВС и создать учётные записи для пользователей вашей ЛВС. И домен готов.

 

Дополнительные соображения

 

Разумеется, простой установкой КД системный администратор не отделается. Ведь в каждой компании имеется своя политика использования ЛВС, её ресурсов. Как минимум, свой набор этих самых ресурсов и свои права пользователей на эти ресурсы. Соответственно, в круг обязанностей админа входит создание в домене групп пользователей, распределение ресурсов по этим группам. Внесение этих ресурсов в АД, ведь тот же сетевой принтер сам от себя в каталоге не пропишется. Но всё это – тема отдельного разговора.

 

А.Чекмарев, А.Вишневский, О.Кокарева. / Microsoft Windows Server 2003 в подлиннике. Наиболее полное руководство. // «БХВ-Петербург», С-Пб., 2003.

 

2  Разделяй и властвуй! (лат.)

 

Разумеется, существуют случаи, когда веб-сайт расположен на серверах корпоративной ЛВС. Но всё же гораздо чаще веб-сайт компании располагается на платном внешнем хостинге и никакого отношения к корпоративной ЛВС не имеет.

 

4  Строго говоря, данное требование может показаться избыточным, поелику серверные версии Windows по умолчанию форматирую свои тома в NTFS. Тем не менее, разные причины могут привести к тому, что на сервере появятся тома с файловой системой FAT32. Таким образом, отследить данное требование всё же надо, т.к. АД не может быть инсталлирована в отличную от NTFS файловую систему.

 

5  Я настоятельно рекомендую начинать установку АД, не имея в сети готового DNS-сервера или же не занимаясь конфигурированием имеющегося. Что бы ни говорили о творениях Microsoft, но пусть уж лучше Windows настроит необходимый ей DNS-сервер с нуля и автоматически. Она сделает это быстрее и лучше человека, да и с меньшими затратами.

 

Взято тут

Автор:  drblack

Поделиться в соц. сетях