Изменение контроллера домена Active Directory. советов по обеспечению безопасности Active Directory

Active Directory - служба каталогов корпорации Microsoft для ОС семейства Windows NT.

Данная служба позволяет администраторам использование групповых политик для обеспечения единообразия настроек пользовательской рабочей среды, установки ПО , обновлений и пр.

В чем суть работы Active Directory и какие задачи она решает? Читайте дальше.

Принципы организации одноранговых и многоранговых сетей

Но возникает другая проблема, что если пользователь user2 на РС2 решит изменить свой пароль? Тогда если пользователь user1 сменит пароль учетной записи, доступ user2 на РС1 к ресурсу будет невозможен.

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

А если их будет не 20 а 200?

Как вы понимаете администрирование сети при таком подходе превращается в кромешный ад.

Поэтому подход с использованием рабочих групп подходит для небольших офисных сетей с количеством ПК не более 10 единиц.

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

Этим узлом и выступает контролер домена - Active Directory.

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

Контролер хранит базу данных учетных записей, т.е. он хранит учетку и для РС1 и для РС2.

Теперь все учетные записи прописываются один раз на контролере, а необходимость в локальных учетных записях теряет смысл.

Теперь, когда пользователь заходит на ПК, вводя свой логин и пароль , эти данные передаются в закрытом виде на контролер домена, который выполняет процедуры аутентификации и авторизации.

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

Важно! Контролер домена - это компьютер с поднятой службой Active Directory, который управляет доступом пользователей к ресурсам сети. Он хранит ресурсы (например, принтеры , папки с общим доступом), службы (например, электронная почта), людей (учетные записи пользователей и групп пользователей), компьютеры (учетные записи компьютеров).

Число таких сохраненных ресурсов может достигать миллионов объектов.

В качестве контролера домена могут выступать следующие версии MS Windows : Windows Server 2000/2003/2008/2012 кроме редакций Web-Edition.

Контролер домена помимо того, что является центром аутентификации сети, также является центром управления всеми компьютерами.

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

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

Установка Active Directory

Рассмотрим пример установки Active Directory на Windows Server 2008 R2. Итак для установки роли Active Directory, заходим в «Server Manager»:

Добавляем роль «Add Roles»:

Выбираем роль Active Directory Domain Services:

И приступаем к установке:

После чего получаем окно уведомления, об установленной роли:

После установки роли контролера домена, приступим к установке самого контролера.

Нажимаем «Пуск» в поле поиска программ вводим название мастера DCPromo, запускаем его и ставим галочку для расширенных настроек установки:

Жмем «Next» из предложенных вариантов выбираем создание нового домена и леса.

Вводим имя домена, например, example.net.

Пишем NetBIOS имя домена, без зоны:

Выбираем функциональный уровень нашего домена:

Ввиду особенностей функционирования контролера домена, устанавливаем также DNS-сервер .

Функциональный обзор Active Directory в Windows 2000 Server и Windows Server 2003. Источник: Microsoft.

Служба каталога Active Directory (AD) в Windows 2000 Server и Windows Server 2003 содержит информацию обо всех ресурсах, необходимых для работы в сети. Она включает соединения, приложения, базы данных, принтеры, пользователей и группы. Microsoft вполне конкретно указывает, что Active Directory обеспечивает стандартный путь для указания, описания, управления и доступа к ресурсам.

Active Directory по умолчанию не устанавливается, поскольку она не является обязательной для простых серверных задач. Но, по мере того, как сервер начинает заниматься всё большим количеством задач, AD становится всё более и более важной. Дополнительные компоненты, типа почтового сервера Exchange Server от Microsoft, к примеру, требуют полнофункциональной Active Directory.

Команда dcpromo позволяет превратить обычный сервер в контроллер Active Directory. Процесс отнимает около десяти минут, и здесь мы вкратце его опишем.

Мы предполагаем, что других серверов в вашей сети нет, и поэтому нам нужен контроллер для новой инфраструктуры Active Directory.

После этого мы должны определить, будет ли новый домен AD интегрирован в существующую систему.

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

Папка SYSVOL является ещё одной особенностью Active Directory, поскольку её содержимое дублируется всеми контроллерами Active Directory в домене. Она содержит скрипты входа в систему, групповые политики и другие опции, которые должны быть доступны на всех серверах. Конечно же, расположение этой папки можно менять.

Эта опция будет важна, только если у вас есть компьютеры Windows NT с доменной структурой.

Во время установки мастер AD будет жаловаться, что DNS-серверы не запущены. Поэтому необходимо установить и его.

СОДЕРЖАНИЕ

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

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

Чтобы понять, как поднять домен, следует – что вполне очевидно – представлять себе, что такое домен, с чем его едят (и едят ли) и нужен ли он вообще. Сие банальное рассуждение видится актуальным по той простой причине, что зачастую приходится сталкиваться с ситуациями, когда человек хочет сделать что-то, о чём не имеет представления, но о чём знает, что это – штука крутая и модная. Я лично однажды слышал утверждение в духе: «У нас же серьёзная компания! Нам просто необходим домен!». А между тем в этой компании, в серьёзности коей я ни мгновения не сомневаюсь, имелось всего десять компьютеров и задачи на них возложены максимально примитивные – печатная машинка и Интернет. Для такой сети домен – однозначно пятое колесо. Но что же такое домен?
Путём прочтения умных книг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 . Группа АД, члены которой имеют право изменять схему каталога.

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

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

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

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

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

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

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

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

Active Directory и DNS тесно интегрируются и даже используют общее пространство имен. А значит, важно, чтобы вы понимали, как устроена каждая из этих систем и как они работают совместно.

DNS - это служба локатора (locator service), используемая Active Directory (и многими другими компонентами Windows). Active Directory делает свои службы доступными в сети, публикуя их в DNS . Когда устанавливается контроллер домена (или к нему добавляются службы), он использует динамические обновления для регистрации своих служб в DNS как записей SRV. После этого клиенты могут находить службы через простые DNS -запросы. По умолчанию служба Microsoft DNS работает на каждом контроллере домена под управлением Windows Server 2003.

Пространство имен DNS в сети отражает пространство имен Active Directory. DNS разделяется на домены. Каждый домен отвечает за записи, хранящиеся в этом домене, и за сопоставление хост-имен и служб с IP-адресами в своих границах. Пространство имен DNS также разделяется на зоны - неразрывные части пространства имен, за управление которыми отвечают определенные серверы. Зона охватывает минимум один домен и может включать другие домены.

Анализ существующей инфраструктуры

Определение географической модели организации

• Локальная модель

  Региональная модель

  Национальная модель

  Международная модель

• Дочерние компании

Создание карты территориального размещения организации

Сбор сведений о информационных потоках в организации

Анализ текущей модели администрирования

Анализ топологии существующей сети

Планирование структуры AD

Первый шаг в проектировании структуры AD - определение лесов и доменов.

Применение одного домена

• Упрощение управления пользователями и группами

  Нет необходимости планировать доверительные отношения

  Для делегирования прав применяются OU

Применение нескольких доменов

• Возможность реализации разных политик безопасности

  Децентрализованное управление

  Оптимизация трафика

  Разные пространства имен

  Размещение хозяина схемы в отдельный домен

Применение одного домена

Простейшая модель Active Directory - единственный домен. Подавляющее большинство сетей во всем мире позволяет использовать единственный домен, поэтому такая модель, хотя и может показаться не столь гибкой, как другие, обычно заслуживает самого тщательного рассмотрения. В сущности, при планировании структуры Active Directory полезно всегда исходить из предположения, что будет использоваться один домен, и пытаться остаться в рамках этой модели.

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

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

Домены Active Directory масштабируемы в гораздо большей мере, чем домены Windows NT. Поэтому исчезает существенное препятствие, не позволявшее применять однодоменные сети на основе Windows NT, в которых диспетчер учетных записей безопасности (Security Accounts Manager, SAM) поддерживал только до 40 000 объектов в домене. В отличие от Windows NT в домен Active Directory может входить более миллиона объектов.

Использование нескольких доменов

В каждом домене требуется хотя бы один контроллер

Групповая политика и управление доступом действует на уровне домена

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

Административные права, действующие между доменами, выдаются только для Администраторов предприятия

Необходимо создавать доверяемые каналы

Хотя однодоменная модель дает существенное преимущество - простоту, иногда приходится использовать несколько доменов. Старайтесь планировать домены так, чтобы все они входили в одно дерево доменов. Так как все домены в одном дереве делят одно пространство имен, административные издержки будут значительно ниже, чем при использовании нескольких деревьев. При создании нескольких доменов определять их границы лучше в соответствии с теми разграничениями внутри компании, вероятность изменения которых меньше всего. Например, создание доменов по территориальному принципу, как правило, надежнее, чем создание доменов в соответствии с иерархией подразделений компании, поскольку изменение организационной структуры более вероятно, чем изменение территориальной.

Применение нескольких деревьев в лесу

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

Два дерева, представляющие собой два пространства имен

Недостатки:

Разное пространство имен, поддержка больше DNS -имен

Проблемы связанные с применением нескольких доменов

Возможности LDAP клиентов

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

Недостатки такого варианта:

Поскольку у каждого дерева должно быть отдельное пространство имен DNS , ИТ-отделу придется поддерживать больше DNS -имен, чем в случае однодоменной модели.

Чем больше деревьев, тем больше доменов, поскольку каждое дерево должно содержать минимум один домен. Следовательно, возникнут все проблемы, связанные с применением нескольких доменов.

Возможно, что LDAP -клиенты (Lightweight Directory Access Protocol), разработанные не Microsoft, не смогут выполнять поиск по глобальному каталогу и вместо этого им придется вести LDAP -поиск по каждому дереву отдельно. В результате увеличится время отклика для таких клиентов.

С учетом этих недостатков имеет смысл подумать об альтернативном решении: объединить пространства имен и использовать одно дерево с разными доменами вместо нескольких деревьев.

Отдельные пространства имен, в одном дереве

Применение нескольких лесов

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

Леса представляют собой крайние границы зон безопасности. Между лесами невозможно административное управление или пользовательский доступ, если на то нет явного разрешения в конфигурации. Для этого предназначен новый тип доверия, введенный в Windows Server 2003, - доверие к лесу (forest trust), применяемое при управлении отношениями между двумя лесами.

Доверие к лесу не является транзитивным на уровне лесов. Другими словами, если первый лес доверяет второму, а второй -третьему, это еще не означает, что первый автоматически доверяет третьему. Также учтите, что для использования доверия к лесу нужно, чтобы оба леса находились на функциональном уровне Windows 2003, т. е. чтобы все контроллеры доменов в обоих лесах работали под управлением Windows Server 2003.

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

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

Создание автономного подразделения. Поскольку леса являются крайними зонами безопасности, отдельный лес можно использовать для того, чтобы создать сеть, в которой администрирование в значительной мере независимо от основного леса. В таком случае ИТ-персонал отдельного леса может поддерживать и изменять схему, не оказывая влияния на другие леса.

Создание изолированного подразделения. Изолированный лес отличается от автономного в первую очередь уровнем полномочий по управлению, доступных администраторам вне леса. В изолированном лесу гарантируется, что администратор вне леса не сможет повлиять на управление им.

Недостатки структуры из нескольких лесов

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

Архитектура с несколькими лесами имеет следующие недостатки.

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

Сотрудникам, которым требуется входить на компьютеры, включенные во внешние леса, должны указывать при входе основное имя пользователя (user principal name, UPN) по умолчанию. От таких сотрудников требуется более высокий уровень подготовки.

Часто для наблюдения за отдельными лесами и управления ими нужен дополнительный ИТ-персонал, а значит, расходуются средства на подготовку большего штата ИТ-сотрудников и на оплату их труда.

Администраторам приходится хранить несколько схем.

Для каждого леса используются отдельные контейнеры конфигурации. Изменения в топологии необходимо реплицировать в другие леса.

Любую репликацию информации между лесами приходится настраивать вручную. Администраторы должны конфигурировать разрешение DNS -имен между лесами, чтобы обеспечить функционирование контроллеров доменов и поддержку поиска ресурсов.

Администраторам приходится настраивать списки управления доступом (ACL) к ресурсам, чтобы соответствующие группы из разных лесов могли обращаться к этим ресурсам, а также создавать новые группы, чтобы можно было использовать роли одних лесов в других лесах.

Соглашение о именовании

Чтобы найти сетевой ресурс, необходимо знать имя объекта или его одно из его свойств. Active Directory поддерживает несколько типов имен:

Относительные составные имена

Составные имена

Основные имена пользователей

Канонические имена

Решив, какую структуру доменов и лесов нужно создать, переключите свое внимание на именование элементов, входящих в эту структуру.

LDAP - стандартный протокол, используемый клиентами для поиска информации в каталоге. Служба каталогов, поддерживающая LDAP (например Active Directory), индексирует все атрибуты всех объектов, хранящихся в каталоге, и публикует их. Клиенты, поддерживающие LDAP , могут выполнять всевозможные запросы к серверу.

Каждый объект в Active Directory является экземпляром класса, определенного в схеме Active Directory. У каждого класса имеются атрибуты, обеспечивающие уникальную идентификацию каждого объекта каталога. Чтобы это реализовать, в Active Directory действует соглашение об именовании, позволяющее логически упорядочить хранение объектов и предоставить клиентам стандартизированные методы доступа к объектам. И пользователи, и приложения должны соблюдать соглашение об именовании, используемое каталогом. Чтобы найти сетевой ресурс, вы должны знать его имя или одно из его свойств. Active Directory поддерживает несколько типов имен, поэтому при работе с Active Directory можно использовать разные форматы имен.

Относительные составные имена

Относительное составное имя (RDN) объекта уникально идентифицирует объект, но только в его родительском контейнере. Таким образом, оно уникально идентифицирует объект относительно других объектов в том же самом контейнере. Например, здесь:

CN=wjglenn,CN=Users,OC=kd,DC=ru относительным составным именем объекта является CN=wjglenn . RDN родительской организационной единицы (OU) - Users. У большинства объектов RDN - то же, что и атрибут Common Name.

Active Directory автоматически создает RDN по информации, указываемой при создании объекта, и не допускает, чтобы в одном и том же родительском контейнере существовали два объекта с одинаковыми RDN.

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

DC - тэг Domain Component, который идентифицирует часть DNS -имени домена вроде СОМ или ORG.

OU - тэг Organizational Unit, который идентифицирует организационную единицу, являющуюся контейнером.

CN - тэг Common Name, который идентифицирует простое имя, присвоенное объекту Active Directory.

Составные имена

У каждого объекта в каталоге имеется составное имя (DN), которое уникально на глобальном уровне и идентифицирует не только сам объект, но и место, занимаемое объектом в общей иерархии объектов. DN можно рассматривать как относительное DN объекта, объединенное с относительными DN всех родительских контейнеров, образующих путь к объекту.

Вот типичный пример составного имени: CN=wjglenn,CN=Users,DC=kd,DC=ru

Это DN означает, что объект пользователя wjglenn содержится в контейнере Users, в свою очередь содержащемся в домене kd.ru. Если объект wjglenn переместят в другой контейнер, его DN изменится и будет отражать новое местоположение в иерархии. DN гарантированно уникальны в лесу - по аналогии с тем, как полное доменное имя (fully qualified domain name, FQDN) уникально идентифицирует местонахождение объекта в иерархии DNS . Существование двух объектов с одинаковыми DN невозможно.

Канонические имена

Каноническое имя объекта используется во многом также, как и составное. Просто у него другой синтаксис. Составному имени, приведенному в предыдущем разделе, соответствовало бы следующее каноническое имя: kd.ru/Users/wjglenn

Как видите, в синтаксисе составных и канонических имен два основных отличия. Первое - каноническое имя формируется от корня к объекту, а второе - в каноническом имени не используются тэги LDAP -атрибутов (например CN и DC).

Основные имена пользователей

Основное имя пользователя (UPN), генерируемое для каждого объекта пользователя, имеет вид имя_пользователя@имя_домена . Пользователи могут входить в сеть под своими основными именами, а администратор при желании может определить для этих имен суффиксы. Основные имена пользователей должны быть уникальными, но Active Directory не проверяет соблюдение этого требования. Лучше всего принять соглашение об именовании, не допускающее дублирования основных имен пользователей.

Идентификаторы защиты

При выработке стратегии именования две роли хозяев операций представляют интерес:

Хозяин именования доменов

• Один домен в каждом лесу, обрабатывает добавление и удаление доменов и генерирует уникальный идентификатор защиты (SID)

Хозяин RID

• Генерирует последовательности для каждого из контроллеров домена. Действует в пределах домена. Генерирует для каждого контроллера домена пул по 500 RID.

Active Directory используется модель репликации с несколькими хозяевами, при которой на каждом контроллере домена хранится своя копия раздела Active Directory; контроллеры домена являются равноправными хозяевами. Можно внести изменения в объекты, хранящиеся на любом контроллере домена, и эти изменения реплицируются на другие контроллеры.

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

Однако при выработке стратегии именования представляют интерес две роли хозяев операций: именования доменов (domain naming master) и RID (relative ID master). Два сервера, выполняющих эти роли, должны быть доступны, когда создаются и именуются новые участники системы безопасности (security principals).

Определение стратегии именования

Следует учитывать требования и DNS и AD

Поддерживается иерархия, длина имени до 64 символов

Подключение к внешним сетям

Совместимость с NetBios-именами

Плоская модель, длина имени не более 16 символов

Существует возможность назначать разные NetBios и DNS имена, но такой подход не допустим.

При выработке стратегии именования необходимо учитывать требования к именованию, предъявляемые как Active Directory, так и DNS . Клиенты используют DNS для разрешения IP-адресов серверов, на которых выполняются важные сетевые сервисы Active Directory. Следовательно, Active Directory и DNS неразрывно связаны.

В DNS имена образуют иерархию и формируются путем «движения» от родительских доменов к дочерним. Так, у домена kd.ru может быть дочерний домен sales.kd.com, у того в свою очередь - дочерний домен europe.sales.kd.ru. Имя каждого домена соответствует пути, идентифицирующему домен в иерархии DNS , т. е. пути к корневому домену (корневой домен обозначается точкой).

Active Directory следует соглашению об именовании, принятому в DNS . Когда вы создаете первый домен Active Directory, он становится корневым для леса и первого дерева доменов в этом лесу. С этого корневого домена начинается пространство имен. Каждый добавляемый домен получает имя от родительского домена и иерархии, в которую входит родительский домен.

Все имена доменов Active Directory идентифицируются по DNS , но можно использовать и NetBIOS-имена (Network Basic Input/Output System) - унаследованную систему именования, которая применялась в старых версиях Windows и по-прежнему поддерживается в Windows Server 2003. Windows автоматически генерирует NetBIOS-имена для каждой службы, выполняемой на компьютере, добавляя к имени компьютера дополнительный символ. Доменам также присваиваются NetBIOS-имена.

Правила именования доменов

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

Используйте только символы, разрешенные стандартами Интернета: а-z, 0-9 и дефис (-). Хотя реализация DNS в Windows Server 2003 поддерживает и другие символы, применение стандартных символов гарантирует возможность взаимодействия с другими реализациями DNS .

Используйте короткие доменные имена, которые легко идентифицировать и которые соответствуют соглашению об именовании в NetBIOS.

В качестве основы имени корневого домена берите только зарегистрированные доменные имена. Даже если вы не используете в качестве имени корня леса зарегистрированное DNS -имя, это поможет избежать путаницы. Например, у компании может быть зарегистрирован домен kd.ru. Если вы не используете kd.ru в качестве имени корневого домена вашего леса, все равно формируйте имя, производное от kd.ru (скажем, sales.kd.ru).

Не используйте дважды одно и то же доменное имя. Иное возможно только в сетях, которые не взаимодействуют между собой (например, вы можете создать домен microsoft.com в частной сети, не подключенной к Интернету), но это плохой подход. Когда-нибудь он обязательно приведет к путанице.

Для большей безопасности создайте отдельные внутреннее и внешнее пространства имен, чтобы предотвратить несанкционированный доступ к закрытым ресурсам. И создавайте внутреннее имя на основе внешнего (например kd.ru и local.kd.ru).

Имена участников системы безопасности

Объекты участников системы безопасности - это объекты AD, которым назначены идентификаторы защиты и которые указываются при входе в сеть (учетные записи пользователей, компьютеров и групп)

При добавлении учетной записи администратор задает:

Имя используемое для входа в сеть

Имя домена, содержащего учетную запись

Прочие атрибуты (имя, фамилия, телефон..)

Имена могут содержать любые символы Unicode, за исключением следующих: #, +, «, \, <, >

Объекты участников системы безопасности (security principal objects) - это объекты Active Directory, которым назначены идентификаторы защиты и которые указываются при входе в сеть и предоставлении доступа к ресурсам домена. Администратор должен давать объектам участников системы безопасности (учетным записям пользователей, компьютеров и групп) имена, уникальные в рамках домена. Следовательно, вы должны выработать стратегию именования, которая позволит это делать.

Добавляя в каталог учетную запись нового пользователя, администратор должен задать следующую информацию:

имя, которое пользователь должен указывать при входе в сеть;

имя домена, содержащего учетную запись пользователя;

прочие атрибуты, такие как имя, фамилия, номер телефона и т. д.

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

Правила имен участников системы безопасности

Длина имен учетных записей пользователей не более 20 символов

Имена учетных записей компьютеров не более 15 символов

Длина имен учетных записей групп не более 63 символов

Нельзя использовать только точки, пробелы и знак @

Имена участников системы безопасности не могут состоять только из точек, пробелов и знаков @. Любые точки или пробелы в начале имени пользователя отбрасываются.

Допускается применение одного и того же имени участника системы безопасности в разных доменах. Так, можно создать пользователя wjglenn в доменах hr.kd.ru и sales.kd.ru. Это не приведет к проблемам, поскольку составное, относительное составное и каноническое имена каждого объекта автоматически генерируются Active Directory и все равно позволяют глобально идентифицировать этот объект.

Проектирование структуры OU

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

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

OU служит контейнером, в который можно поместить ресурсы и учетные записи домена. Затем можно назначить OU административные разрешения и позволить содержащимся в нем объектам наследовать эти разрешения. OU могут содержать любые объекты следующих типов: пользователи; компьютеры; группы; принтеры; приложения; политики безопасности; общие папки; другие OU.

Не следует создавать структуру OU исключительно ради того, чтобы иметь какую-то структуру, - OU используются в определенных целях. К этим целям относятся: делегирование административного управления объектами; ограничение видимости объектов; управление применением групповой политики.

Цели создания OU

Делегирование прав администрирования - Существует чтобы облегчить жизнь администраторам

Ограничение видимости объектов

Управление применением групповой политикой

Есть две основные архитектуры OU, применяемые для делегирования административных полномочий: на основе объектов и на основе задач. Эти две архитектуры рассматриваются в следующих разделах.

Архитектура основанная на объектах

Архитектура основанная на объектах

В структуре OU, основанной на объектах, делегирование полномочий выполняется в зависимости от типа объектов, которые хранятся в OU. Вы можете выбрать структуру OU, в которой объекты группируются по принадлежности к одному из следующих типов: пользователям; компьютерам; сайтам; доменам; OU.

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

Служба каталогов Active Directory позволяет весьма точно управлять делегированием административных полномочий. Например, можно предоставить одной группе полный доступ ко всем объектам OU, второй - права на создание, удаление и изменение объектов OU определенного типа, а третьей - право управлять определенным атрибутом объектов конкретного типа (скажем, возможностью сбрасывать срок действия паролей учетных записей пользователей). Кроме того, можно сделать эти разрешения наследуемыми, чтобы они применялись не только к данному OU, но и ко всем создаваемым OU более низкого уровня. Такое тонкое управление обеспечивает огромную гибкость.

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

Архитектура основанная на задачах

В архитектуре, основанной на задачах, делегирование управления осуществляется в зависимости от административных задач, которые требуется решать, а не от типа объектов, подлежащих администрированию. К этим задачам относятся: создание, удаление и изменение учетных записей пользователей; сброс сроков действия паролей; определение групповой политики; управление членством в группах и разрешениями.

Верхний уровень структуры OU

Верхний уровень структуры OU

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

Физические участки. В филиалах, физически расположенных в разных местах (особенно, когда компания действует на обширной территории, например в нескольких странах), часто имеются свои ИТ-отделы, поэтому у филиалов разные требования к администрированию. Создание отдельного OU верхнего уровня для каждого филиала - один из вариантов архитектуры, основанной на задачах; в зависимости от местонахождения определяются разные административные задачи.

Типы административных задач. Структура верхнего уровня, основанная на административных задачах, относительно постоянна. Какие бы реорганизации не происходили в компании, основные типы административных задач вряд ли сильно изменятся.

Типы объектов. Как и структура, основанная на задачах, структура, в которой OU верхнего уровня соответствуют типам объектов, обеспечивает устойчивость архитектуры к изменениям.

При планировании структуры OU верхнего уровня для среды с несколькими доменами, есть смысл подумать о создании структуры верхнего уровня, которая будет одной и той же для каждого домена сети. В этом случае особенно эффективна архитектура, основанная на объектах или на задачах (об этих архитектурах рассказывается далее). Создание структуры OU, одинаковой для различных доменов, позволяет реализовать единый подход к администрированию и поддержке сети.

Нижний уровень OU

OU нижних уровней (создаваемые в OU верхнего уровня) должны использоваться для более тонкого управления административными полномочиями или в других целях, например для применения групповой политики. Запомните: по умолчанию OU нижних уровней наследуют разрешения от родительских OU. При планировании архитектуры вы должны определить и то, когда наследуются разрешения и когда они не наследуются.

При проектировании OU нижних уровней легко переусердствовать. Помните: ваша основная задача - получить структуру, максимально облегчающую администрирова-ние учетных записей и ресурсов. Поэтому ваша архитектура должна быть как можно проще. Если вы создадите слишком глубоко вложенную структуру OU, то не только будете иметь дело с более запутанной структурой, но и можете столкнуться со снижением производительности. Групповая политика может применяться к OU на разных уровнях - на уровне домена, сайта и каждого из родительских OU. Чем больше политик нужно применить, тем больше время ответа и тем ниже производительность.

Задачи решаемые с помощью OU

Применение OU для ограничения видимости объектов

В некоторых организациях определенные объекты должны быть скрыты от определенных администраторов или пользователей. Даже если вы запретите изменение атрибутов объекта, пользователи, имеющие доступ к контейнеру с таким объектом, все равно смогут видеть, существует ли этот объект. Однако вы можете скрыть объекты, поместив их в OU и ограничив круг пользователей, которые имеют разрешение Список содержимого (List Contents) для этой OU. Тогда объекты, помещенные в контейнер, будут невидимы пользователям, не имеющим этого разрешения.

Применение OU для управления групповой политикой

Групповая политика позволяет применять одни и те же параметры конфигурации сразу к нескольким объектам. С ее помощью можно определять параметры пользователей (например ограничения, налагаемые на пароли) или компьютеров. При использовании групповой политики вы создаете объект групповой политики (Group Policy Object, GPO) - объект, содержащий параметры конфигурации, которые вам нужно применить. Создав GPO, вы связываете его с доменом, сайтом или OU.

Проектируя структуру OU, управляющую применением групповой политики, старайтесь соблюдать следующие принципы.

Планируйте структуру OU так, чтобы использовать как можно меньше GPO. Чем больше GPO связано с каким-либо объектом, тем больше времени потребуется пользователям, чтобы войти в сеть.

Создавайте OU верхнего уровня, основанные на объектах или задачах, а затем создавайте OU более низких уровней, управляющие групповой политикой.

Создавайте дополнительные OU, чтобы обойтись без фильтрации для изъятия группы пользователей из OU, связанной с GPO.

Контейнеры и OU по умолчанию

При установке Active Directory создается несколько контейнеров и OU, используемых по умолчанию.

Контейнер Домен (Domain). Корневой контейнер в иерархии Active Directory. Административные разрешения, применяемые к этому контейнеру, могут влиять на дочерние контейнеры и объекты всего домена. Не делегируйте полномочия на управление этим контейнером - им должны управлять администраторы служб.

Контейнер Встроенный (Built-in). Содержит учетные записи администраторов служб, используемые по умолчанию.

Контейнер Пользователи (Users). Применяемое по умолчанию хранилище учетных записей новых пользователей и групп, создаваемых в домене. Также не следует изменять разрешения на доступ к этому контейнеру, действующие по умолчанию. Если требуется делегировать управление определенными пользователями, создайте новые OU и перенесите в них объекты пользователей. Кроме того, с контейнером Пользователи (Users) нельзя связать GPO. Чтобы применить групповую политику к пользователям, вы также должны создать OU и перенести в них пользователей.

Контейнер Компьютеры (Computers). Применяемое по умолчанию хранилище новых учетных записей компьютеров, создаваемых в домене. Как и в случае контейнера Пользователи (Users), чтобы назначить разрешения или GPO компьютерам, следует создать OU.

OU Контроллеры домена (Domain Controllers). Здесь по умолчанию хранятся учетные записи компьютеров - контроллеров домена. К этому OU по умолчанию применяется ряд политик. Чтобы обеспечить единообразие применения этих политик ко всем контроллерам домена, рекомендуется не переносить объекты-компьютеры, являющиеся контроллерами домена, из этого OU. По умолчанию этим OU управляют администраторы служб. Не делегируйте управление этим OU пользователям, которые не являются администраторами служб.

Стандартные модели структуры OU

Существует пять базовых моделей структуры OU:

На основе местоположения

На основе структуры организации

На основе функций

Смешанная - сначала по местоположению, затем по структуре организации

Смешанная - сначала по структуре, затем по местоположению

Каждый OU по умолчанию наследует разрешения, заданные для родительского OU. Ана-логично объекты, содержащиеся в OU, наследуют разрешения, заданные для этого OU (и для каждого из его родителей). Наследование - эффективный способ предоставить или делегировать разрешения на доступ к объектам. Преимущество наследования в том, что администратор может управлять разрешениями на доступ ко всем объектам в OU, задавая разрешения для самого OU, а не конфигурируя все дочерние объекты по отдельности.

Бывают ситуации, где наследование препятствует решению нужных задач. Вам может потребоваться, чтобы некоторые разрешения на доступ к объекту переопределяли разрешения, наследуемые объектом от родителей. В таком случае заблокируйте наследование разрешений, применяемых к родительской OU, чтобы они не распространялись на дочернюю OU.

Модель по месту положения

Модель по месту положения

Преимущества:

OU Устойчивы к изменениям

Для центрального 1Т-отдела легко реализовать общедоменные политики

Легко определять положение ресурсов

Легко создавать новые OU при расширении компании

Недостатки:

Предполагает наличие в каждом филиале администратора

Архитектура не соответствует бизнес-структуре или административной структуре

В модели OU на основе местонахождения административные полномочия распределены между несколькими филиалами, расположенными в разных местах. Эта модель полезна, когда у каждого филиала свои требования к администрированию, отличные от требований других филиалов.

Назначение объектов групповой политики сайтам (обычно выполняемое по территориальному признаку) обеспечивает во многом такие же преимущества, что и модель OU на основе местонахождения, но лишено ее недостатков.

Модель на основе структуры организации

Модель на основе структуры организации

Преимущества:

Обеспечивает определенный уровень автономии для каждого отдела

Поддерживает слияния и расширения

Удобна администраторам

Недостатки:

Уязвима при реорганизации, т.к. может потребоваться изменение верхнего уровня структуры ОU

В модели OU на основе структуры организации административные полномочия распределены между отделами или подразделениями, в каждом из которых имеется собственный администратор. Эта модель полезна, когда у компании есть четкая структура отделов.

Модель на основе функций

Модель на основе функций

Преимущества:

Устойчивость при реорганизациях

Недостаток:

Создание дополнительных OU для делегирования административного управления пользователями, компьютерами, принтерами.

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

Смешанная модель - по положению

Смешанная модель - по положению

Преимущества:

Поддерживает рост числа подразделений

Позволяет создавать зоны безопасности

Недостатки:

При реорганизации административного персонала, необходимо пересмотреть структуру

Необходимо взаимодействие между администраторами, работающими в разных отделах одного филиала

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

Смешанная модель - по структуре

Смешанная модель - по структуре

Преимущества:

Надежная защита на уровне отделов и подразделений

И в тоже время возможность делегировать административные полномочия в зависимости от местоположения

Недостатки:

Уязвимость при реорганизациях

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

Планирование стратегии управления учетными записями

Типы учетных записей

Учетная запись в Active Directory - это список атрибутов, определяющих участника системы безопасности (security principal), например пользователя или группу пользователей. В Active Directory можно создать пять типов учетных записей, перечисленных ниже.

Компьютер. Всякий раз, когда в домен добавляется компьютер под управлением Microsoft Windows NT, Windows 2000, Windows XP или Windows Server 2003, для него создается учетная запись компьютера. Учетные записи компьютеров служат для аутентификации компьютеров, которые обращаются к сети и ресурсам домена.

Пользователь. Учетная запись пользователя - это набор атрибутов для пользователя. Объект-пользователь хранится в Active Directory и позволяет пользователю входить в сеть. Пользователь должен указать удостоверения (имя и пароль) только один раз, затем ему предоставляются соответствующие разрешения на доступ к сетевым ресурсам.

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

InetOrgPerson. Учетная запись InetOrgPerson работает во многом аналогично учетной записи пользователя за исключением того, что учетные записи InetOrgPerson совместимы с другими службами каталогов, основанными на LDAP (Lightweight Directory Access Protocol). Это обеспечивает совместимость между Active Directory и другими системами.

Контакт. Объект, который хранится в Active Directory, но для которого не задаются разрешения. То есть контакт нельзя использовать для входа в сеть или доступа к ресурсам. Часто контакты связывают с пользователями, работающими вне сети, которым отправляет сообщения почтовая система.

Планирование учетных записей компьютеров

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

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

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

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

Планирование учетных записей пользователей

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

Учетные записи пользователей предоставляют пользователям возможность входить в домен или на локальный компьютер и обращаться к ресурсам. Объекты учетных записей пользователей содержат информацию о пользователях и связывают с ними определенные привилегии или ограничения. Каждый объект Active Directory связан со списком управления доступом (Access Control List, ACL), который представляет собой список разрешений на доступ к объекту, заданных для пользователей и групп.

Типы учетных записей пользователей

В Windows Server 2003 существует два основных типа учетных записей пользователей.

Локальные учетные записи пользователей. Создаются в базе данных защиты локального компьютера и управляют доступом к ресурсам этого компьютера. Локальные учетные записи пользователей предназначены для управления доступом к изолированным компьютерам или к компьютерам, входящим в рабочую группу. Когда вы только что установили операционную систему на сервер, используются локальные учетные записи, управление которыми осуществляется через консоль Управление компьютером (Computer Management) в узле Локальные пользователи и группы (Local Users and Groups). Если вы сделаете сервер контроллером домена, инструмент Управление компьютером запретит доступ к этому узлу, и вместо него будет использоваться инструмент Active Directory - пользователи и компьютеры (Active Directory Users and Computers) (учетные записи пользователей на контроллерах домена хранятся в Active Directory).

Доменные учетные записи пользователей. Создаются в Active Directory и дают возможность пользователям входить в домен и обращаться к любым ресурсам сети. Вы можете создать доменную учетную запись пользователя с помощью Active Directory - пользователи и компьютеры (Active Directory Users and Computers). Такие учетные записи пользователей реплицируются на все контроллеры в домене, поэтому после репликации любой контроллер домена сможет аутентифицировать пользователя.

Встроенные учетные записи пользователей.

Windows автоматически создает несколько учетных записей пользователей, называемых встроенными. И на локальных компьютерах, и в доменах создается две ключевых учетных записи: и Гость (Guest) .

Учетная запись Администратор обладает наибольшими возможностями, поскольку она автоматически включается в группу Администраторы (Administrators) . Члены этой группы имеют высший уровень прав по управлению компьютером, им предоставляются почти все пользовательские права. Учетная запись Администратор уровня домена дает максимум возможностей по управлению доменом в целом; по умолчанию она включается в группу Администраторы домена (Domain Admins) [а администратор корневого домена леса, кроме того, входит в группы и ]. Учетную запись Администратор нельзя удалить, но ее можно переименовать (и это следует сделать для большей безопасности). Также следует задать для этой учетной записи непустой пароль и не передавать его другим пользователям.

Учетная запись Гость (Guest) - еще одна базовая встроенная учетная запись пользователя. Она предназначена для того, чтобы администратор мог задать единый набор разрешений для любых пользователей, которые иногда входят в сеть, но не имеют обычной учетной записи. Учетная запись Гость позволяет это сделать, так как автоматически включается в локальную группу Гости (Guests) . В среде, где есть домен, эта учетная запись также включается в группу Гости домена (Domain Guests) . По умолчанию учетная запись Гость отключена. И действительно, ее следует использовать только в сетях, не требующих особой защиты. Эту учетную запись нельзя удалить, но можно отключить и/или переименовать.

Правила именования учетных записей

Каждый пользователь должен иметь уникальное имя (логин) в домене

Длина имени не должна превышать 20 символов (из-за совместимости с предыдущими версиями Windows)

Имена не чувствительны к регистру букв

Имена не должны содержать символов: »/\:; = , + *?< >

Должна поддерживаться гибкая система именования

Учитывайте совместимость именования для других приложений (например для электронной почты)

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

Есть несколько правил, которые нужно соблюдать при планировании стратегии именования пользователей.

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

Планирование политики управления паролями

Смена пароля не чаще чем 1 раз сутки

Длина пароля на должна быть короче 7 символов

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

Пароли - один из наиболее важных аспектов сетевой безопасности, поэтому политику определения паролей пользователей необходимо тщательно продумать. В Windows Server 2003 по умолчанию действуют более строгие ограничения на пароли, чем в предыдущих версиях. Например, в Windows Server 2003 имеется новое средство, проверяющее сложность пароля учетной записи Администратор (Administrator) . Если пароль пустой или недостаточно сложный, Windows предупреждает, что использовать нестойкий пароль опасно. Оставив пароль пустым, вы не сможете обращаться к учетной записи через сеть.

Надежная политика управления паролями гарантирует, что пользователи в полной мере соблюдают принципы задания паролей, установленные компанией. При планировании политики управления паролями следует соблюдать ряд правил.

Стратегия аутентификации

Планирование групп

Типы групп

Группы безопасности

Используются для объединения в одну административную единицу

Используются ОС

Группы распространения

Используются приложениями (не ОС) для задач не связанных с защитой

Области действия групп

Глобальные группы

Можно назначать разрешения или добавлять в локальные группы любого домена в данном лесу

Локальные группы домена

Существуют на контроллерах домена и используются для управления доступом к ресурсам локального домена

Могут включать пользователей и глобальные группы в пределах леса

Универсальные группы

Используются для назначение разрешений доступа к ресурсам нескольких доменов

Существуют вне границ доменов

Могут включать пользователей, глобальные группы и другие универсальные группы в пределах леса

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

Как и в случае учетных записей пользователей, группы бывают локальные и уровня домена. Локальные группы хранятся в базе данных защиты локального компьютера и предназначены для управления доступом к ресурсам этого компьютера. Группы уровня домена хранятся в Active Directory и позволяют помещать в них пользователей и управлять доступом к ресурсам домена и его контроллеров.

Вложение групп и их именование

Способ упорядочить пользователей

Глубина вложений должна быть минимальной (желательно 1 уровень вложенности)

Требования при именовании такие схожи с требованиями для пользователей, но длина до 64 символов

Active Directory позволяет вкладывать группы (т. е. помещать одни группы в другие). Вложение групп - эффективный способ упорядочения пользователей. При вложении групп стремитесь к тому, чтобы уровень вложения был минимальным. В сущности, лучше ограничиться одним уровнем вложения. Чем глубже вложение, тем сложнее поддерживать структуру разрешений.

Взаимодействие групп и пользователей

Избегайте выдачи разрешений учетным записям

Создавайте локальные группы домена

Для упорядочивания пользователей используйте глобальные группы

Помещайте глобальные группы в локальные группы домена

Не включайте пользователей в универсальные группы

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

Планирование групповой политики

Групповая политика - набор параметров конфигурации пользователей и компьютеров. Называется объектом групповой политики (GPO)

Существует два типа параметров групповой политики:

Конфигурация компьютера

• Используется для задания групповых политик, применяемых к определенным компьютерам

Конфигурация пользователя

• Используется для задания групповых политик, применяемых к определенным к определенным пользователям

Не зависимо от типа есть три категории:

Параметры программ

Параметры Windows

Административные шаблоны

Групповая политика - мощное и эффективное средство, позволяющее задать параметры сразу для нескольких пользователей и компьютеров. Кроме того, групповая политика применяется для распространения и обновления ПО в организации.

Групповая политика - набор параметров конфигурации пользователей и компьютеров, который можно связать с компьютерами, сайтами, доменами и OU в Active Directory. Такой набор параметров групповой политики называется объектом групповой политики (Group Policy Object, GPO).

Любой компьютер под управлением Windows 2000, Windows ХР или Windows Server 2003 (независимо от того, входит он в Active Directory или нет) содержит один локальный GPO, в котором заданы политики, применяемые к этому компьютеру. Если компьютер входит в Active Directory, к нему можно применить несколько дополнительных GPO, не являющихся локальными.

Существует два основных типа параметров групповой политики.

Параметры программ

Параметры применяемые для установки ПО на клиентских ПК (поддерживаются ОС Windows 2000 и более новые)

Используются два компонента:

Служба установки Windows

• Установка и обновление ПО в соответствии с инструкциями в установочных пакетах

Установочные пакеты Windows

• Исполняемые файлы сценариев со всеми инструкциями (msi)

Узел Параметры программ (Software Settings) содержит параметры, которые можно использовать для развертывания ПО на клиентских компьютерах, к которым применяется групповая политика. Для этого клиентские компьютеры должны работать под управлением Windows 2000 Professional, Windows 2000 Server, Windows XP Professional, Windows XP 64-Bit Edition или Windows Server 2003 и быть членами домена. Вы можете задать, для каких пользователей или на какие компьютеры будет установлено ПО, при необходимости указать обновления и даже удалить ПО. Для поддержки этой функции нужны два взаимодействующих компонента.

Служба установки Windows (Windows Installer service) - служба, которая развертывает и обновляет ПО в соответствии с инструкциями в установочных пакетах Windows (Windows Installer packages)

Установочные пакеты Windows (Windows Installer Packages) - исполняемые файлы сценариев со всеми инструкциями, нужными Windows Installer для установки, обновления или восстановления ПО. Файлы Windows Installer Package имеют расширение msi.

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

Существует два способа развертывания ПО с помощью групповой политики: публикация (publishing) и назначение (assigning) . Когда приложение назначается пользователю, создается ярлык, доступный пользователю и показываемый в меню Пуск (Start) или на рабочем столе этого пользователя. Это называется предложением (advertising) приложения пользователю. Когда пользователь щелкает ярлык (или открывает файл, связанный с программой), запускается программа установки. Когда приложение назначается компьютеру, приложение устанавливается при первом запуске компьютера после назначения.

Если вы публикуете приложение, оно становится доступным пользователям, которые могут установить его, когда пожелают. Приложения можно публиковать только для пользователей - сделать это для компьютера нельзя. Приложение становится доступным в апплете Установка и удаление программ (Add/Remove Programs) панели управления (Control Panel) и устанавливается по запросу пользователя, если тот откроет файл, связанный с программой.

Параметры Windows

Сценарии (Scripts). При настройке конфигурации компьютера можно задать сценарии, которые выполняются при его включении или выключении. При настройке конфигурации для пользователя можно задать сценарии, выполняемые при входе или выходе пользователя. Сценарии можно писать на любое языке сценариев с поддержкой ActiveX, в том числе на VBScript, JScript, Perl , языке командных файлов MS -DOS и др.

Параметры безопасности (Security Settings). Это параметры безопасности, задаваемые для компьютеров и пользователей.

Настройка Internet Explorer (Internet Explorer Maintenance). Этот узел доступен только для пользователей. Он служит для управления работой Internet Explorer на клиентских компьютерах.

Службы удаленной установки (Remote Installation Services, RIS). RIS позволяет автоматически выполнять удаленную установку операционной системы на новые клиентские компьютеры. Эти параметры тоже доступны только для конфигураций пользователей. Они управляют удаленной установкой операционных систем.

Перенаправление папок (Folder Redirection). И эти параметры доступны только для конфигураций пользователей. Они позволяют переопределить специальные папки Windows [такие как Мои документы (My Documents), Главное меню (Start Menu) и Application Data], изменив их местонахождение по умолчанию на сетевой каталог. Благодаря этому можно централизованно управлять папками пользователей.

Административные шаблоны

Административные шаблоны

Узел	Конфигурация компьютера	Конфигурация пользователя	Описание
Панель управления	Неприменимы	X	Определяет средства панели управления, доступные пользователю
Рабочий стол	Неприменимы	X	Задает внешний вид рабочего стола пользователя
Сеть	X	X	Управляет параметрами Автономные файлы и Сеть и удаленный доступ к сети
Принтеры	X	Неприменимы	Параметры принтеров
Панель задач и меню «Пуск»	Неприменимы	X	Параметры конфигурации для меню пуск и панели задач пользователя
Система	X	X	Управление входом/выходом, запуск/остановка
Компоненты Windows	X	X	Управление встроенными компонентами Windows

Поскольку GPO, применяемые к пользователю или компьютеру, могут поступать из нескольких источников, нужен способ определения того, как эти GPO сочетаются друг с другом. GPO обрабатываются в следующем порядке.

Локальный GPO - обрабатывается локальный GPO компьютера и применяются все параметры защиты, заданные в этом GPO.

GPO сайта - обрабатываются GPO, связанные с сайтом, к которому относится компьютер. Параметры, заданные на этом уровне, переопределяют любые параметры, заданные на предыдущем уровне, с которыми они конфликтуют. Если с сайтом связано несколько GPO, администратор сайта может задать, в каком порядке обрабатываются эти GPO.

GPO домена - обрабатываются GPO, связанные с доменом, к которому относится компьютер, и применяются содержащиеся в них параметры. Параметры, заданные на уровне домена, переопределяют параметры, примененные на локальном уровне или на уровне сайта, с которыми они конфликтуют. Если с доменом связано несколько GPO, администратор, как и в предыдущем случае, может задать порядок их обработки.

GPO OU - обрабатываются GPO, связанные с любыми OU, содержащими пользователя или компьютер. Параметры, заданные на уровне OU, переопределяют параметры, примененные на локальном уровне или уровне домена/сайта, с которыми они конфликтуют. Один и тот же объект может входить в несколько OU. В этом случае сначала обрабатываются GPO, связанные с OU, находящимся на самом высоком уровне иерархии Active Directory, затем - с OU, находящимся на следующем уровне и т.д. Если с одной OU связано несколько GPO, администратор, как и в предыдущих случаях, может задать порядок их обработки.

Наследование групповой политики

Дочерние контейнеры наследуют групповую политику от родительских контейнеров

Есть возможность переопределить унаследованные параметры

В GPO можно задавать активность/неактивность и не определенность параметров

Не противоречивые политики верхнего и нижнего уровней комбинируются, а для несовместимых значений используются значения родительских контейнеров

Дополнительные механизмы наследования:

• Не перекрывать

  Блокировать наследование политик

Если необходимо не применять политику к пользователю или группе, можно запретить чтение или применение этой политики для данного пользователя или группы

По умолчанию дочерние контейнеры наследуют групповую политику от родительских контейнеров. Однако можно переопределить унаследованные параметры, задав для дочернего объекта другие значения параметров. Кроме того, в GPO можно задать, что тот или иной параметр активен, неактивен или не определен. Параметры, которые не определены для родительского контейнера, вообще не наследуются дочерними контейнерами, а параметры, которые активны или неактивны, наследуются.

Если GPO определены и для родителя, и для потомка и если заданные в них параметры совместимы, эти параметры комбинируются. Например, если в родительской OU задана определенная длина пароля, а в дочерней OU - некая политика блокировки учетных записей, будут использоваться оба этих параметра. Если параметры несовместимы, то по умолчанию с дочерним контейнером связывается значение параметра, переопределяющее значение параметра, который связан с родительским контейнером.

Совет: На вкладке Общие (General) окна свойств GPO можно отключить неиспользуемые параметры конфигурации компьютера или пользователя, содержащиеся в GPO. В большинстве политик задействована лишь часть доступных параметров. Если неиспользуемые параметры включены, они все равно обрабатываются, что приводит к лишнему расходу системных ресурсов. Отключив неиспользуемые параметры, вы снизите нагрузку на клиентские компьютеры, обрабатывающие политику.

Конечно, описанное выше наследование применяется только по умолчанию. Имеется еще два механизма, применяемых при управлении наследованием групповых политик.

Не перекрывать (No Override). Когда вы связываете GPO с контейнером, можно выбрать Не перекрывать, чтобы параметры, заданные в этом GPO, не переопределялись параметрами в GPO, связанных с дочерними контейнерами. Это гарантирует, что для дочерних контейнеров будет применяться заданная вами политика.

Блокировать наследование политики (Block Policy Inheritance). При выборе этого параметра контейнер не наследует параметры GPO, заданные для родительского контейнера. Однако, если для родительского контейнера указан параметр Не перекрывать, дочерний контейнер не может заблокировать наследование от своего родителя.

Планирование структуры GPO

При реализации групповой политики сначала создают GPO, затем связывают их с сайтами, доменами и OU. Может потребоваться применение некоторых GPO на уровне доменов или сайтов, но в большинстве случаев следует применять GPO на уровне OU.

Связывание GPO с доменом

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

Связывание GPO с сайтом

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

Связывание GPO с OU

В большинстве случаев лучше связывать GPO с хорошо продуманной структурой OU, чем с сайтами или доменами. OU обеспечивают наибольшую гибкость, поскольку позволяют спроектировать структуру, хотя бы отчасти упрощающую применение групповой политики. Кроме того, OU гибче в администрировании. Вы можете без проблем перемещать пользователей и компьютеры между OU, изменять структуру OU и даже переименовывать сами OU.

Для принятия параметров групповой политики клиентские компьютеры должны быть членами Active Directory. Основные операционные системы обладают следующими возможностями по поддержке групповой политики.

Windows 95/98/Ме не поддерживают групповую политику.

Windows NT 4.0 и более ранних версий не поддерживает групповую политику.

Windows 2000 Professional и Server поддерживают многие параметры групповой политики, доступные в Windows Server 2003, но не все. Неподдерживаемые параметры игнорируются.

Windows XP Professional, Windows XP 64-bit Edition и Windows Server 2003 полностью поддерживают групповую политику.

Планирование сайтов

Планирование сайтов

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

Сайты Active Directory позволяют отделить логическую организацию структуры каталогов (структуры лесов, доменов и OU) от физической структуры сети. Сайты представляют физическую структуру сети на основе Active Directory. Поскольку сайты не зависят от структуры доменов, в один домен может входить несколько сайтов или, наоборот, один сайт может содержать несколько доменов.

Сайты не входят в пространство имен Active Directory- Пользователь, просматривающий логическое пространство имен, видит компьютеры и пользователей, сгруппированных в домены и OU, но сайты при этом не показываются. Однако имена сайтов используются в записях DNS (Domain Name System), поэтому у сайтов должны быть допустимые DNS -имена.

Если вы не конфигурируете в Active Directory собственные сайты, все контроллеры доменов автоматически входят в один сайт по умолчанию с именем Default-First-Site-Name, который создается при создании первого домена.

В целом, сайты служат для управления трафиком по WAN -каналам. А конкретнее, сайты используются для управления: трафиком входа на рабочие станции; трафиком репликации; распределенной файловой системой (Distributed File System, DPS) ; Сведения о TCP/IP-подсетях филиалов

Наблюдает за сетевыми соединениями и задает цены связей между сайтами.

Планирование контроллеров доменов

После того как вы определили структуру сайтов сети, наступает следующий этап планирования сайтов - определение количества и размещения контроллеров доменов в этих сайтах.

Как определить, нужен ли контроллер домена для данного участка

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

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

Если сайт охватывает много пользователей, помещение контроллера домена в сайт обеспечивает, что при аутентификации пользователей, входящих в сеть, не генерируется сетевой трафик, который нужно передавать на удаленный контроллер домена по WAN -каналу.

Если пользователям нужна возможность входить в домен, даже когда WAN -канал не работает, следует установить контроллер домена в локальном сайте. Если WAN -канал недоступен и нет локальных контроллеров домена, способных обработать запросы на вход в систему, пользователи регистрируются с кэшированными удостоверениями и не могут обращаться к ресурсам других компьютеров.

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

Если сайт является узловым (hub site), т. е. связывает друг с другом остальные сайты меньшего размера, и если у этих сайтов меньшего размера нет своих контроллеров доменов, имеет смысл поместить контроллер домена в узловой сайт, чтобы уменьшить время отклика при входе.

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

Контроллерами доменов нужно управлять. Устанавливайте контроллеры только там, где есть администраторы, достаточно квалифицированные для того, чтобы управлять контроллерами домена. Если таких администраторов нет, вы должны обеспечить сотрудникам ИТ-отдела уровень доступа, позволяющий удаленно управлять контроллером домена.

Контроллеры домена должны быть защищены. Устанавливайте контроллеры домена только в тех сайтах, в которых можно гарантировать физическую безопасность контроллера.

Как определить количество необходимых контроллеров доменов

Следующий этап - определить, сколько контроллеров доменов требуется на сайте для обслуживания каждого из его доменов.

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

Если данный домен сайта охватывает менее 1000 пользователей, в нем достаточно установить всего один контроллер.

Если данный домен сайта охватывает от 1000 до 10 000 пользователей, в нем требуется установить не менее двух контроллеров.

Для каждых дополнительных 5000 пользователей следует добавлять по одному контроллеру. Например, если на сайт входят 20 000 пользователей домена, в этом домене следует установить четыре контроллера.

Как разместить контроллеры корневого домена леса

Первый домен, создаваемый в новом лесу, называется корневым доменом леса и занимает особое место среди доменов леса. Корневой домен леса закладывает основу структуры леса и пространства имен. Кроме того, данные о группах Администраторы предприятия (Enterprise Admins) и Администраторы схемы (Schema Admins) уровня леса так-же хранятся в корневом домене леса.

Доверительные отношения между доменами являются транзитивными, и вся аутентификация между разными доменами леса выполняется или через корневой домен леса (т. е. контроллер корневого домена леса), или через специально сконфигурированное доверие к сокращению (shortcut trusts) между региональными доменами. Если один сайт содержит несколько доменов, но корневой домен леса находится в другом сайте, можно определить доверие к сокращению или добавить контроллер корневого домена леса в локальный сайт. Это позволит аутентифицировать пользователей между доменами локального сайта, даже если WAN -канал неработоспособен.

Планирование серверов - хозяев операций

Существуют задачи, которые в отличие от модели репликации с несколькими хозяевами решаются только определенными контроллерами домена. Эти контроллеры выполняют так называемые роли хозяев операций. Хозяева операций (operations masters) - контроллеры домена, которым назначены определенные роли, связанные с обслуживанием домена или леса, и они всегда выполняют функции, специфичные для домена или леса, - никакой другой компьютер не вправе брать на себя эти функции. Такие функции разделены на категории для лучшей управляемости.

В Windows Server 2003 две роли хозяев операций уровня леса.

Хозяин схемы (Schema Master). Первый контроллер домена в лесу принимает роль хозяина схемы и отвечает за поддержку и распространение схемы на остальную часть леса. Он поддерживает список всех возможных классов объектов и атрибутов, определяющих объекты, которые находятся в Active Directory- Если схему нужно обновлять или изменять, - как, например, в случае установки приложения, которое должно модифицировать классы или атрибуты схемы, - то делать это следует на хозяине схемы [т. е. должен быть доступен контроллер домена (DC), имеющий роль хозяина схемы] одному из членов группы Администраторы схемы (Schema Admins) . Если DC, являющийся хозяином схемы, недоступен, а вы должны внести изменения в схему, можно передать эту роль другому DC.

Хозяин именования доменов (Domain Naming Master). Протоколирует добавление и удаление доменов в лесу и жизненно необходим для поддержания целостности доменов. Хозяин именования доменов запрашивается при добавлении к лесу новых доменов. Если хозяин именования доменов недоступен, добавление новых доменов невозможно; однако при необходимости эта роль может быть передана другому контроллеру. Здесь есть одна тонкость, о которой важно помнить в среде с несколькими доменами: хозяин именования доменов должен быть еще и сервером глобального каталога. Дело вот в чем. Чтобы проверить, является ли уникальным домен, создаваемый в лесу, хозяин именования доменов запрашивает глобальный каталог. Эти две роли автоматически назначаются первому контроллеру домена в лесу. В однодоменной среде (или в лесу с нескольким доменами, в котором все контролле-ры корневого домена леса хранят глобальный каталог) вы должны оставить обе роли хозяев операций уровня леса первому контроллеру, созданному в корневом домене леса.

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

Роли хозяев операций уровня домена

В Windows Server 2003 три роли хозяев операций уровня домена.

Эмулятор основного контроллера домена отвечает за эмуляцию Windows NT 4.0 PDC для клиентских машин, которые еще не переведены на Windows Server 2003. Одна из основных задач эмулятора PDC - регистрировать устаревшие клиенты. Кроме того, к эмулятору PDC происходит обращение, если аутентификация клиента оказалась неудачной.

Хозяин RID отвечает за выделение диапазонов относительных идентификаторов (RID) всем контроллерам в домене. Идентификатор защиты (security identifier, SID) - уникальный идентификатор каждого объекта в домене. SID в Windows Server 2003 состоит из двух частей. Первая часть общая для всех объектов в домене; для создания уникального SID к этой части добавляется уникальный RID. Вместе они уникально идентифицируют объект в домене и указывают, где он был создан.

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

Планирование серверов глобального каталога

Сервер глобального каталога - это контроллер домена, поддерживающий подмножество атрибутов объектов Active Directory, к которым чаще всего обращаются пользователи или клиентские компьютеры, например регистрационное имя пользователя. Серверы глобального каталога выполняют две важные функции. Они дают возможность пользователям входить в сеть и находить объекты в любой части леса, не обращаясь к конкретным контроллерам доменов, на которых хранятся эти объекты. Active Directory состоит из трех разделов.

Раздел схемы. Хранит определения всех объектов, которые можно создать в лесу, а также их атрибутов. В лесу существует только один раздел схемы. Его копия реплицируется на все контроллеры доменов, входящие в лес.

Раздел конфигурации. Определяет структура доменов, сайтов и объектов-серверов Active Directory. В лесу существует только один раздел конфигурации. Его копия реплицируется на все контроллеры доменов, входящие в лес.

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

Другая функция глобального каталога, полезная независимо от того, сколько доме-нов в вашей сети, - участие в процессе аутентификации при входе пользователя в сеть. Когда пользователь входит в сеть, указывая имя участника системы безопасности (user principal name, UPN) вида [email protected] , оно сначала сверяется с содержимым глобального каталога. Это позволяет входить в сеть с компьютеров в доменах, отличных от того, где хранится нужная пользовательская учетная запись. Кроме того, это позволяет входить в сеть, когда контроллер домена недоступен, например из-за того, что не работает WAN -канал.

Планирование числа пользователей контроллеров доменов

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

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

Определение требований к процессорам

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

Если пользователей меньше 500, контроллеру домена под управлением Windows Server 2003 достаточно одного процессора с тактовой частотой 850 МГц или выше.

Если количество пользователей находится в пределах от 500 до 1500, контроллеру домена под управлением Windows Server 2003 требуется два процессора с тактовой частотой 850 МГц или выше.

Если пользователей больше 1500, контроллеру домена под управлением Windows Server 2003 нужно четыре процессора с тактовой частотой 850 МГц или выше.

Определение требований к дисковому пространству

Как и требования к процессорам, требования к дисковому пространству в первую очередь зависят от числа пользователей в домене. Чтобы определить требования к дисковому пространству, руководствуйтесь следующими правилами.

На диске, на который устанавливается ОС Windows Server 2003, должно быть примерно 2 Гб свободного дискового пространства.

Определив минимальный объем дискового пространства, необходимый контроллерам доменов, вы должны выделить дополнительное дисковое пространство на тех контроллерах домена, на которых будет храниться глобальный каталог. Если в лесу только один домен, назначение контроллеру домена роли сервера глобального каталога не приведет к увеличению размера БД. Однако, если в лесу более одного домена, для каждого дополнительного домена размер глобального каталога увеличивается приблизительно на 50% от размера базы данных этого домена.

Определение требований к памяти

И вновь основным фактором, влияющим на требования к объему памяти контроллера домена, является количество пользователей. Чтобы определить требования к памяти контроллера домена, руководствуйтесь следующими правилами.

Если пользователей меньше 500, контроллеру домена требуется 512 Мб памяти.

Если количество пользователей находится в пределах от 500 до 1000, контроллеру домена требуется 1 Гб памяти.

Если пользователей больше 1000, контроллеру домена требуется 2 Гб памяти.

Планирование стратегии репликации

Репликация Active Directory - жизненно важная операция, которую необходимо тщательно планировать. Правильно спланированная репликация ускоряет ответ каталога, уменьшает сетевой трафик по WAN -каналам и сокращает административные издержки.

Процесс репликации

Как вы уже знаете, в Windows Server 2003 используется модель репликации с несколькими хозяевами, при которой на всех контроллерах домена хранятся равноправные копии БД Active Directory. Когда вы создаете, удаляете или переносите объект либо изменяете его атрибуты на любом контроллере домена, эти изменения реплицируются на остальные контроллеры домена.

Внутрисайтовая и межсайтовая репликация

Внутрисайтовая (между контроллерами домена одного сайта) и межсайтовая репликация (между контроллерами домена, относящимися к разным сайтам) выполняется по-разному.

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

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

Удаленные вызовы процедур выполняются при отправке сообщений репликации внутри сайта и между сайтами. Протокол RPC используется по умолчанию при всех операциях репликации Active Directory, поскольку является отраслевым стандартом и совместим с большинством типов сетей.

SMTP применяется при репликации между сайтами, не связанными постоянными соединениями (необходимыми для работы RPC). Одно из ограничений при использовании SMTP - он не позволяет реплицировать информацию раздела домена (domain partition information) на DC, входящие в домен. Поскольку SMTP применяется только при репликации между сайтами, проблем с репликацией информации раздела домена внутри домена не возникает (в этом случае автоматически используется RPC). То есть SMTP полезен лишь при репликации схемы и глобального каталога.

Как выполняется репликация

Каждый контроллер домена в сайте представляется объектом-сервером. У каждого объекта-сервера есть дочерний объект NTDS Settings, управляющий репликацией данных контроллера домена внутри сайта, а у каждого объекта NTDS Settings - объект-соединение, в котором хранятся атрибуты соединения и который представляет коммуникационный канал, применяемый при репликации данных с одного контроллера домена на другой. Для репликации нужно, чтобы на обеих сторонах было по объекту-соединению.

Сервис Knowledge Consistency Checker (КСС) автоматически создает набор объек-тов-соединений для репликации с одного контроллера домена на другой. Однако при необходимости можно создать объекты-соединения вручную.

КСС создает различные топологии (т. е. задает местонахождение объектов-соедине-ний и их конфигурацию) для внутрисайтовой и межсайтовой репликации. Кроме того, КСС изменяет созданные им топологии всякий раз, когда вы добавляете и удаляете контроллеры домена или перемещаете их из одного сайта в другой.

Отключение транзитивности связей сайтов для транспорта влияет на все связи, использующие этот транспорт, - они станут нетранзитивными. Тогда, чтобы поддерживать транзитивные соединения, вам придется создать мосты связей сайтов.

Мосты связей сайтов (site-link bridges) - логические соединения, использующие связи сайтов в качестве транспорта. Когда транзитивность связей включена, между всеми сайтами автоматически создаются логические мосты связей сайтов. А когда транзитивность связей отключена, вы должны создавать такие мосты вручную. На рис. показана простая группа из четырех сайтов, соединенных связями по принципу карусели. Если транзитивность связей для этих сайтов отключена, вам придется вручную создать мосты связей сайтов, чтобы сделать возможной репликацию между всеми сайтами. В основном такие мосты служат для того, чтобы при отключенной транзитивности связей у каждого сайта был путь репликации к другим сайтам. Рассуждайте следующим образом. Когда транзитивность связей включена, между всеми связями сайтов имеются мосты, поэтому все сайты могут обмениваться данными репликации друг с другом. А когда транзитивность отключена, вы должны самостоятельно создать мосты, поскольку связаны только те сайты, между которыми вручную сконфигурированы связи. Мосты связей сайтов передают трафик репликации между соответствующими сайтами по цепочке из нескольких связей.

Назначение цен связям сайтов

Всем связям сайтов назначается цена, которая определяет, насколько данный путь лучше или хуже других связей. По умолчанию все связи имеют цену 100. Если одну связь сделать дороже другой, то при репликации (и при работе других приложений и служб, например Domain Controller Locator ) предпочтение будет отдаваться связи с меньшей ценой.

Серверы - плацдармы

Серверы - плацдармы

После создания связей сайтов КСС автоматически назначает один или несколько контроллеров в каждом домене на роль серверов-плацдармов (bridgehead servers) , или серверов репликации между сайтами.

Данные репликации передаются между этими серверами, а не напрямую между всеми контроллерами домена. Запомните, что внутри сайта контроллеры домена (в том числе и серверы репликации между сайтами) выполняют репликацию, как только в ней возникает необходимость. Затем, когда согласно расписанию связи доступны, серверы-плацдармы инициируют репликацию с аналогичными серверами других сайтов через заданный интервал.

Соединения репликации, создаваемые КСС, случайным образом распределяются между всеми серверами сайта, которые могут быть плацдармами репликации между сайтами, - это делается для распределения нагрузки по поддержке репликации. Обычно КСС распределяет соединения, только когда создаются новые объекты-соединения. Однако в Windows Server 2003 Resource Kit имеется утилита Active Directory Load Balancing (ADLB) , которую можно использовать для перераспределения ролей серверов-плацдармов в любое другое время (например, при добавлении новых контроллеров домена).

Дополнительные задачи при проектировании домена

Планирование DNS

Планирование WINS

Планирование инфраструктуры сети и маршрутизации

Планирование подключения к Интернету

Планирование стратегии удаленного доступа

Итоги

Были рассмотрены вопросы связанные с технологией построение службы каталогов на базе AD реализованной в ОС Windows Server 2003

Данная статья посвящена основам операционной системы . Здесь мы рассмотрим:

• Отличие от предыдущих версий;
• Редакции данной ОС;
• Установка Windows Server 2003;
• Роли сервера;
• Основы Active Directory;
• Функции командной строки;
• Настройка удаленного рабочего стола;
• Настройка DHCP сервера.

Microsoft Windows Server 2003 – одна из самых мощных серверных операционных систем для ПК. На сегодняшний день имеются уже более новые версии серверных операционных систем, например: Windows Server 2008, Windows Server 2008 R2, но сегодня мы поговорим именно об этой операционной системе т.к. она за это время стало настолько популярной среди системных администраторов, и многие из них до сих пор не хотят переходить на более новые версии ОС. В данной ОС реализованы совершенно новые средства управления системой и администрирования, впервые появившиеся в Windows 2000. Вот некоторые из них:

• Active Directory - расширяемая и масштабируемая служба каталогов, в которой используется пространство имен, основанное на стандартной Интернет-службе именования доменов (Domain Name System, DNS );
• InteiUMirror - среда конфигурирования, поддерживающие зеркальное отображение пользовательских данных и параметров среды, а также центральное администрирование установки и обслуживания программного обеспечения;
• Terminal Services - службы терминалов, обеспечивающие удаленный вход в систему и управление другими системами Windows Server 2003;
• Windows Script Host - сервер сценариев Windows для автоматизации таких распространенных задач администрирования, как создание учетных записей пользователей и отчетов по журналам событий.

Хотя у Windows Server 2003 масса других возможностей, именно эти четыре наиболее важны для выполнения задач администрирования. В максимальной степени это относится к Active Directory, поэтому для успешной работы системному администратору Windows Server 2003 необходимо четко понимать структуру и процедуры этой службы.

Если у Вас уже есть опыт работы с серверами Windows 2000, переход на Windows Server 2003 будет относительно прост, поскольку она является следующим шагом в обновлении платформы и технологий Windows 2000.

Обширный список новых функций вы сможете найти во множестве книг по новым системам. На самом деле список изменений Windows Server 2003 по сравнению с предыдущей версией достаточно велик, и в нем есть функции, которые заинтересуют практически каждого администратора.

Помимо обширного списка новых возможностей, Windows Server 2003 интересна еще и потому, что предлагается в 32-разрядном, 64-разрядном и встроенном (embedded ) вариантах. Тем не менее, наиболее важные отличия касаются четырех редакций ОС, которые перечислены ниже в порядке функциональности и, соответственно, цены:

• Windows Server 2003 Web Edition;
• Windows Server 2003 Standard Edition;
• Windows Server 2003 Enterprise Edition;
• Windows Server 2003 Datacenter Edition.

Редакция Web Edition

Чтобы Windows Server 2003 могла конкурировать с другими Web-серверами, Microsoft выпустила усеченную, но вполне функциональную редакцию специально для Web-служб. Набор функций и лицензирование упрощают развертывание Web-страниц, Web-узлов, Web-приложений и Web-служб.

Windows Server 2003 Web Edition поддерживает 2 Гб ОЗУ и двухпроцессорную симметричную обработку (symmetric multiprocessor, SMP ). Эта редакция поддерживает неограниченное количество анонимных Web-соединений, но только 10 входящих соединений блока серверных сообщений (server message block, SMB ), и этого более чем достаточно для публикации содержимого. Такой сервер не может выступать в роли интернет-шлюза, DHCP- или факс-сервера. Несмотря на возможность удаленного управления сервером с помощью ПО Remote Desktop, он не может играть роль сервера терминалов в традиционном понимании: он может принадлежать домену, но не может быть его контроллером.

Редакция Standard Edition

Данная редакция - надежный, многофункциональный сервер, предоставляющий службы каталогов, файлов, печати, приложений, мультимедийные и Web-службы для небольших и средних предприятий. Обширный (по сравнению с Windows 2000 ) набор функций дополнен рядом компонентов: MSDE (Microsoft SQL Server Database Engine ) - версией сервера SQL Server, поддерживающего пять параллельных соединений к БД размером до 2 Гб; бесплатной преднастроенной службой РОРЗ (Post Office Protocol v3 ), которая совместно со службой SMTP (Simple Mail Transfer Protocol ) позволяет узлу играть роль небольшого автономного почтового сервера; полезным инструментом NLB (Network Load Balancing ), который присутствовал только в Windows 2000 Advanced Server.

Редакция Standard Edition поддерживает до 4 Гб ОЗУ и четырехпроцессорную SMP-обработку.

Редакция Enterprise Edition

Windows Server 2003 Enterprise Edition нацелена стать мощной серверной платформой для средних и крупных предприятий. К ее корпоративным функциям относятся поддержка восьми процессоров, 32 Гб ОЗУ, восьмиузловая кластеризация включая кластеризацию на основе сетей хранения данных (Storage Area Network, SAN ) и территориально распределенную кластеризацию, плюс совместимость с 64-разрядными компьютерами на базе Intel Itanium, что позволяет поддерживать уже 64 Гб ОЗУ и восьмипроцессорную SMP-обработку.
Ниже перечислены другие отличия Enterprise Edition от Standard Edition:

• Поддержка служб MMS (Microsoft Metadirectory Services ), позволяющих объединять каталоги, БД и файлы со службой каталогов Active Directory;
• «Горячее » добавление памяти (Hot Add Memory ) - вы можете добавлять память в поддерживаемые аппаратные системы без выключения или перезагрузки;
• Диспетчер системных ресурсов Windows (Windows System Resource Manager, WSRM ), поддерживающий распределение ресурсов процессора и памяти между отдельными приложениями.

Редакция Datacenter Edition

Редакция Datacenter Edition доступна только в качестве OEM-версии, предлагаемой в комплекте с серверами класса high-end, и поддерживает практически неограниченную масштабируемость: для 32-разрядных платформ - 32-процессорная SMP-обработка и 64 Гб ОЗУ, для 64-разрядных - 64-процессорная SMP-обработка и 512 Гб ОЗУ. Существует также версия, поддерживающая 128-процессорную SMP-обработку на базе двух 64-процессорных секций.

64-разрядные редакции

По сравнению с 32-разрядными, 64-разрядные редакции Windows Server 2003, работающие на компьютерах Intel Itanium, эффективнее используют скорость процессора и быстрее выполняют операции с плавающей точкой. Улучшения в коде и обработке существенно ускорили вычислительные операции. Возросшая скорость доступа к огромному адресному пространству памяти позволяет улучшить работу сложных, требовательных к ресурсам приложений, например приложений для работы с большими БД, научно-исследовательских приложений и подверженных высоким нагрузкам Web-серверов.

Однако некоторые функции в 64-разрядных редакциях недоступны. Например, 64-разрядные редакции не поддерживают 16-разрядные Windows-приложения, приложения реального режима, приложения POSIX и службы печати для клиентов Apple Macintosh.

Установка и настройка Windows Server 2003

При установке Windows Server2003 система конфигурируется согласно ее роли в сети. Серверы обычно становятся частью рабочей группы или домена.

Рабочие группы - это свободные объединения компьютеров, в которых каждый компьютер управляется независимо.
Как администратор, Вы, несомненно, потратили много времени на установку платформ Windows. Ниже перечислены важные особенности, которые следует учитывать при установке Windows Server 2003.

• Установка с загрузочного компакт-диска. Windows Server 2003 продолжает традицию установки с компакт-диска. Однако есть и нововведение: установка с дискет больше не поддерживается;
• Улучшенный графический пользовательский интерфейс во время установки. Во время установки Windows Server 2003 использует графический пользовательский интерфейс (GUI ), похожий на интерфейс Windows XP. Он более точно описывает текущее состояние установки и время, оставшееся до ее завершения;
• Активация продукта. Розничная и пробная версии Windows Server 2003 требуют активации. Такие массовые программы лицензирования, как Open License, Select License или Enterprise Agreement не требуют активации.

После установки и активации Windows можно настроить сервер, используя хорошо продуманную страницу Управление данным сервером (Manage Your Server ), которая автоматически открывается при входе в систему. Эта страница упрощает установку некоторых служб, инструментов и конфигураций в зависимости от роли сервера. Щелкните кнопку Добавить или удалить роль (Add Or Remove A Role ), появится окно Мастера настройки сервера (Configure Your Server Wizard ).
Если установить переключатель Типовая настройка для первого сервера (Typical Configuration For A First Server ), мастер сделает сервер контроллером нового домена, установит службы Active Directory и при необходимости службы DNS (Domain Name Service ), DHCP (Dynamic Host Configuration Protocol ) и RRAS (Routing And Remote Access ).

Если установить переключатель Особая конфигурация (Custom Configuration ), мастер может настроить следующие роли.

• Файловый сервер (File Server ). Обеспечивает централизованный доступ к файлам и каталогам для пользователей, отделов и организации в целом. Выбор этого варианта позволяет управлять пользовательским дисковым пространством путем включения и настройки средств управления дисковыми квотами и ускорить поиск в файловой системе за счет активизации Службы индексирования (Indexing Service ).
• Сервер печати (Print Server ). Обеспечивает централизованное управление печатающими устройствами, предоставляя клиентским компьютерам доступ к общим принтерам и их драйверам. Если выбрать этот вариант, запустится Мастер установки принтеров (Add Printer ), позволяющий установить принтеры и соответствующие драйверы. Кроме того, мастер устанавливает службы IIS 6.0 (Internet Information Services ), настраивает протокол печати IPP (Internet Printing Protocol ) и Web-средства управления принтерами;
• Application Server IIS, ASP.NET (Сервер приложений IIS, ASP.NET ). Предоставляет компоненты инфраструктуры, которые требуются для поддержки размещения Web-приложений. Эта роль устанавливает и настраивает IIS 6.0, ASP.NET и СОМ+;
• Mail Server РОРЗ, SMTP (почтовый сервер РОРЗ, SMTP ). Устанавливает РОРЗ и SMTP, чтобы сервер мог выступать в роли почтового сервера для клиентов РОРЗ;
• Сервер терминалов (Terminal Server ). Позволяет множеству пользователей с помощью клиентского ПО Службы терминалов (Terminal Services ) или Дистанционное управление рабочим столом (Remote Desktop ) подключаться к приложениям и ресурсам сервера, например принтерам или дисковому пространству, как если бы эти ресурсы были установлены на их компьютерах. В отличие от Windows 2000, Windows Server 2003 предоставляет Дистанционное управление рабочим столом автоматически. Роли сервера терминалов требуются, только когда нужно размещать приложения для пользователей на сервере терминалов;
• Сервер удаленного доступа или VPN-сервер (Remote Access/VPN Server ). Обеспечивает маршрутизацию по нескольким протоколам и службы удаленного доступа для коммутируемых, локальных (LAN) и глобальных (WAN) вычислительных сетей. Виртуальная частная сеть (virtual private network, VPN ) обеспечивает безопасное соединение пользователя с удаленными узлами через стандартные Интернет-соединения;
• Контроллер домена Active Directory (Domain Controller Active Directory ). Предоставляет службы каталогов клиентам сети. Этот вариант позволяет создать контроллер нового или существующего домена и установить DNS. Если выбрать эту роль, запускается Мастер установки Active Directory (Active Directory Installation Wizard );
• DNS Server (DNS-сервер ). Обеспечивает разрешение имен узлов: DNS-имена преобразуются в IP-адреса (прямой поиск ) и обратно (обратный поиск ). Если выбрать этот вариант, устанавливается служба DNS и запускается Мастер настройки DNS- сервера (Configure A DNS Server Wizard );
• DHCP-сервер (DHCP Server ). Предоставляет службы автоматического выделения IP-адресов клиентам, настроенным на динамическое получение IP-адресов. Если вы¬брать этот вариант, устанавливаются службы DHCP и запускается Мастер создания области (New Scope Wizard ), позволяющий определить один или несколько диапазонов IP-адресов в сети;
• Сервер потоков мультимедиа (Streaming Media Server ). Предоставляет службы WMS (Windows Media Services ), которые позволяют серверу передавать потоки мультимедийных данных через Интернет. Содержимое может храниться и предоставляться по запросу или в реальном времени. Если выбрать этот вариант, устанавливается сервер WMS;
• WINS-сервер (WINS Server ). Обеспечивает разрешение имен компьютеров путем преобразования имен NetBIOS в IP-адреса. Устанавливать службу WINS (Windows Internet Name Service ) не требуется, если вы не поддерживаете старые ОС, например Windows 95 или NT. Такие ОС, как Windows 2000 и XP не требуют WINS, хотя старым приложениям, работающим на этих платформах, может понадобиться разрешать имена NetBIOS. Если выбрать этот вариант, устанавливается сервер WINS.

Контроллеры домена и рядовые серверы

При установке Windows Server 2003 систему можно конфигурировать как рядовой сервер, контроллер домена или изолированный сервер. Различия между этими типами серверов чрезвычайно важны. Рядовые серверы являются частью домена, но не хранят информацию каталога. Контроллеры домена хранят данные каталога и выполняют службы аутентификации и каталога в рамках домена. Изолированные серверы не являются частью домена и имеют собственную БД пользователей, поэтому изолированный сервер также аутентифицирует запросы на вход.

Windows Server 2003 не различает основные и резервные контроллеры домена, так как поддерживает модель репликации с несколькими хозяевами. В этой модели любой контроллер домена может обрабатывать изменения каталога и затем автоматически реплицирует их на другие контроллеры домема. В модели репликации с одним хозяином в Windows NT все происходит не так: основной контроллер домена хранит главную копию каталога, а резервные - ее копии. Кроме того, Windows NT распространяет только БД диспетчера учетных записей безопасности (security access manager, SAM ), a Windows Server 2003 - весь каталог информации, называемый хранилищем данных (datastore ). В нем есть наборы объектов, представляющие учетные записи пользователей, групп и компьютеров, а также общие ресурсы, например серверы, файлы и принтеры.

Домены, в которых применяются службы Active Directory, называют доменами Active Directory, чтобы отличать их от доменов Windows NT. Хотя Active Directory работает только с одним контроллером домена, в домене можно и нужно создать дополнительные контроллеры. Если ОДИН контроллер выходит из строя, для выполнения аутентификации и других важных задач можно задействовать другие.

В домене Active Directory любой рядовой сервер разрешается повысить до уровня контроллера домена без переустановки ОС, как того требовала Windows NT. Для превращения рядового сервера в контроллер следует лишь установить на него компонент Active Directory. Возможно и обратное действие: понижение контроллера домена до рядового сервера, если он не является последним контроллером домена в сети. Вот как повысить или понизить уровень сервера посредством мастера установки Active Directory.

Функции командной строки

В Windows Server 2003 масса утилит командной строки. Многие из них используют протокол TCP/IP, поэтому его следует предварительно установить.
Как администратору, Вам следует знать следующие утилиты командной строки.

• ARP - отображает и управляет программно-аппаратной привязкой адресов, используемой Windows Server 2003 для отправки данных по сети TCP/IP;
• FTP - запускает встроенный FTP-клиент;
• HOSTNAME - отображает имя локального компьютера;
• IPCONFIG - отображает свойства TCP/IP для сетевых адаптеров, установленных в системе. Также используется для обновления и освобождения выданных службой DHCP адресов;
• NBTSTAT - отображает статистику и текущее соединение для протокола NetBIOS поверх TCP/IP;
• NET - отображает список подкоманд команды NET;
• NETSH - отображает и управляет сетевой конфигурацией локального и удаленных компьютеров;
• NETSTAT - отображает текущие TCP/Ip соединения и статистику протокола;
• NSLOOKUP - проверяет статус узла или IP-адреса при использовании с DNS;
• PATHPING - проверяет сетевые пути и отображает информацию о потерянных пакетах;
• PING - тестирует соединение с удаленным узлом;
• ROUTE - управляет таблицами маршрутизации в системе;
• TRACERT - во время цитирован и я определяет сетевой путь к удаленному узлу.

Чтобы научиться применять эти средства, наберите имя команды в командной строке без параметров: в большинстве случаев Windows Server 2003 выведет справку по ее использованию.

Использование команды NET

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

• NET SEND - отправляет сообщения пользователям, зарегистрированным в указанной системе;
• NET START - запускает службу в системе;
• NET STOP - останавливает службу в системе;
• NET TIME - отображает текущее системное время или синхронизирует системное время с другим компьютером;
• NET USE - подключает и отключает от общего ресурса;
• NET VIEW - выводит список доступных сетевых ресурсов.

Чтобы научиться использовать команду NЕТ, введите NET HELP и имя подкоманды, например NET HELP SEND. Windows Server 2003 выведет необходимые справочные сведения

Создание соединения удаленного рабочего стола

Как администратор Вы можете создавать соединения удаленного рабочего стола с серверами и рабочими станциями Windows. В Windows 2003 Server для этого необходимо установить службы терминалов (Terminal Services ) и настроить их на использование в режиме удаленного доступа. В Windows XP соединения удаленного рабочего стола разрешены по умолчанию и все администраторы автоматически имеют право доступа. В Windows Server 2003 удаленный рабочий стол устанавливается автоматически, но по умолчанию отключен, и Вам вручную следует разрешить эту функцию.
Вот один из способов создать соединение удаленного рабочего стола с сервером или с рабочей станицей.

1. Щелкните Пуск (Start ), затем Программы (Programs ) или Все программы (All Programs ), затем Стандартные (Accessories ), затем Связь (Communications ), затем Подключение к удаленному рабочему столу (Remote Desktop Connection). Откроется одноименное диалоговое окно;
2. В поле Компьютер (Computer ) введите имя компьютера, с которым хотите установить соединение. Если вы не знаете имени, воспользуйтесь предлагаемым раскрывающимся списком или укажите в списке вариант Поиск других (Browse For More), чтобы открыть список доменом и компьютеров в этих доменах;
3. По умолчанию Windows Server 2003 берет для регистрации на удаленном текущее имя пользователя, домен и пароль. Если нужна информация другой учетной записи, щелкните Параметры (Options) и зашагайте поля. Имя пользователя (User Name ), Пароль (Password ) и Домен (Domain );
4. Щелкните Подключиться (Connect ). При необходимости ведите пароль и щелкните ОК. Если соединение создано успешно, вы увидите окно удаленного рабочего стола выбранного компьютера и получите возможность работать с ресурсами этого компьютера. Если соединение создать не удалось, проверьте введенную вами информацию и повторите попытку

С командой Подключение к удаленному рабочему столу (Remote Desktop Connection ) работать просто, но она неудобна, если вам приходится создавать удаленные соединения с компьютерами достаточно часто. Вместо нее рекомендуется обращаться к консоли Удаленные рабочие столы (Remote Desktops ). В ней можно настраивать соединения с несколькими системами и затем легко переключаться с одного соединения на другое.

Знакомство с DHCP

DHCP - средство централизованного управления выделением IP-адресов, но этим его функции не ограничиваются. DHCP-сервер выдает клиентам основную информацию, необходимую для работы сети TCP/IP: IP-адрес, маску подсети, сведения о шлюзе по умолчанию, о первичных и вторичных DNS- и WINS - серверах, а также имя домена DNS.

Клиент DHCP и IP-адрес

Компьютер с динамическим IP-адресом называют клиентом DHCP. При загрузке компьютера DHCP-клиент запрашивает IP-адрес из пула адресов, выделенных данному DHCP-серверу, и использует адрес определенное время, называемое сроком аренды (lease ). Спустя примерно половину этого срока клиент пытается возобновить аренду и повторяет эти попытки до успешного возобновления или до окончания срока аренды. Если возобновить аренду не удастся, клиент обращается к другому DHCP-серверу. Если клиент успешно связался с сервером, но его текущий IP-адрес не может быть возобновлен, DHCP-сервер присваивает клиенту новый IP-адрес.

DHCP-сервер обычно не влияет на процедуру загрузки или входа в сеть. Загрузка DHCP-клиента и регистрация пользователя в локальной системе возможна даже при неработающем DHCP-сервере.

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

Установка сервера DHCP

Динамическое выделение IP-адресов возможно только при наличии в сети DHCP-сервера. Компоненты DHCP устанавливаются при помощи мастера установки компонентов Windows, а запуск и авторизация сервера осуществляются из консоли DHCP Предоставлять клиентам динамические IP-адреса вправе только авторизованные серверы DHCP.

Установка компонентов DHCP

Чтобы сервер с Microsoft Windows Server 2003 мог работать в качестве DHCP-сервера, выполните следующие действия.

1. В меню Пуск (Start ) выберите Программы (Programs ) или Все программы (All Programs ), затем щелкните Администрирование (Administrative Tools ) и Мастер настройки сервера.
2. Дважды щелкните Далее (Next ). Появятся текущие роли сервера. Выделите роль DHCP - сервер и дважды щелкните Далее. Мастер установит DHCP и запустит Мастер создания области;
3. Если вы хотите сразу же создать начальную область для DHCP-сервера, щелкните Далее (Next ) и выполните действия, вписанные в разделе «Управление областями DHCP ». В противном случае щелкните Отмена (Cancel ) и создайте необходимые области позднее.
4. Щелкните Готово (Finish ). Чтобы использовать сервер, Вы должны авторизовать его в домене, как описало в разделе Авторизация сервера DHCP в Active Directory. Далее Вам необходимо создать и активизировать все необходимые области DHCP.

После установки DHCP-сервера настройка и управление динамической IP-адресацией осуществляется из консоли DHCP. Команда для ее запуска располагается в меню Администрирование (Administrative Tools ). В главном окне консоли DHCP две панели. Слева перечислены все DHCP-серверы домена, по IP-адресам, включая локальный компьютер, если окно открыто на DHCP-сервере. Справа приведены подробные сведения о выбранном объекте.

Вот, пожалуй, и все что я хотел Вам рассказать об основах операционной системы Microsoft Windows Server 2003.

Желаю удачи в освоение данной ОС.