Для централизованного управления факультетской сетью необходимо создать домен на основе Microsoft Windows Server 2003.

Примечание . В процессе установки может потребоваться вставить в дисковод установочный компакт-диск Windows Server 2003. Можно использовать физический компакт-диск или iso -образ установочного диска операционной системы.

Задание 1. Установить на сервере службу каталога Active Directory, создать домен mydomain.ru.

Указания к выполнению

1. Запустите мастер установки Active Directory Start – Run – dcpromo.

2. Следуя шагам мастера установки, выберите следующие параметры установки:

В окне Domain Controller Type (Тип контроллера домена) – переключатель Domain controller for a new domain (Контроллер домена в новом домене);

В окне Create New Domain (Создать новый домен ) – переключатель Domain in a new forest (Домен в новом лесу );

В окне Install or Configure DNS (Установка или настройка DNS ) – переключатель No, just install and configure DNS on this computer (Нет, DNS уже установлена и настроена на этом компьютере ), если служба DNS уже установлена на сервере, или Yes, I will configure the DNS client (Да, я буду конфигурировать клиента DNS) ;

В окне New Domain Name (Новое доменное имя ) наберите mydomain.ru в строке Full DNS Name For New Domain (Полное DNS-имя нового домена );

В окне NetBIOS Domain Name (Доменное имя NetBIOS ) должна появиться запись MYDOMAIN ;

Убедиться, что для размещения базы данных и протокола выбран путь C:\WINDOWS\NTDS , а для размещения каталога SYSVOL указан путь C:\WINDOWS\SYSVOL ;

В окне Permissions (Разрешения ) выберите Permissions compatible only with Windows 2000 or Windows Server 2003 operating systems (Разрешения, совместимые только с операционными системами Windows 2000 или Windows Server 2003 );

В окне Directory Services Restore Mode Administrator Password (Пароль администратора для режима восстановления) введите пароль, который хотите присвоить этой учетной записи сервера Administrator в случае, если компьютер загрузится в режиме Directory Services Restore (Режим восстановления);

В окне Summary (Сводка) изучите список выбранных вами параметров установки и дождитесь завершения процесса установки Active Directory.

3. В окне Completing The Active Directory Installation Wizard (Завершение работы мастера установки Active Directory), щелкните кнопку Finish (Готово), а затем кнопку Restart Now (Перезагрузить компьютер сейчас).

Задание 2 . Просмотреть созданный домен одним из способов.

Указания к выполнению

1-й способ.

Откройте My Network Places – Entire Network – Microsoft Windows Network (Мое сетевое окружение – Вся сеть – сеть Microsoft Windows). Убедитесь, что появилась запись о домене mydomain, в котором содержится один компьютер – Server.

2-й способ.

1 В меню Start – Programs – Administrative Tools (Пуск – Программы – Администрирование) выберите Active Directory Users And Computers (Пользователи и компьютеры Active Directory). Откроется одноименная оснастка.

2 В дереве оснастки дважды щелкните на mydomain.ru (или на имени вашего домена), чтобы увидеть содержимое узла mydomain.ru.

3 В разделе Domain Controllers (Контроллеры домена) дерева оснастки просмотрите название контроллера домена и его полное имя DNS (например, если имя изолированного сервера было server, то после установки домена должно стать server.mydomain.ru).

4 В разделе Users (Пользователи) просмотрите список встроенных учетных записей пользователей и групп пользователей домена.

5 Активизируйте встроенную учетную запись Guest (Гость) и попробуйте войти в систему. Удалась ли попытка сделать это? На контроллеры домена разрешен вход только администраторам домена.

6 Закройте консоль Active Directory Users And Computers.

Задание 3. Проверить работу службы DNS с помощью оснастки DNS.

Указания к выполнению

1. Откройте консоль DNS командой Start – Programs – Administrative Tools – DNS (Пуск – Программы – Администрирование – DNS).

2. В дереве консоли DNS щелкните правой кнопкой по имени вашего сервера и выберите команду Properties (Свойства). Откроется окно свойств SERVER (если у сервера другое имя, то в заголовке окна будет значиться оно).

3. Перейдите на вкладку Monitoring (Наблюдение).

4. В списке Select A Test Type (Выберите тип теста) пометьте флажки A Simple Query Against This DNS Server (Простой запрос к этому DNS-серверу) и A Recursive Query To Other DNS Servers (Рекурсивный запрос к другим DNS-серверам) и щелкните Test Now (Протестировать). В окне свойств Server в списке результатов тестирования должна появиться надпись PASS (Пройден успешно) или FAIL (Не пройден) – в столбцах Simple Query (Простой запрос) и Recursive Query (Рекурсивный запрос). Объясните полученные результаты.

Задание 4. Удалить службу Active Directory.

Указания к выполнению

Запустите мастер установки и удаления Active Directory Start – Run – dcpromo.

Самостоятельная работа

Согласно заданию проекта установите домен с именем faculty.ru, где контроллером домена является server.faculty.ru, IP-адрес которого 192.168.1.1.

Вопросы для самоконтроля

1. Опишите различия между рабочей группой и доменом.

2. Каково основное различие между ОС Windows XP и Windows Server 2003?

3. Возможно ли создать домен в сети, где все компьютеры сети работают под управлением ОС Windows XP?

4. Дайте определение контроллера домена.

5. Перечислите известные Вам встроенные учетные записи пользователей и групп пользователей домена и опишите их назначение.

6. Что означает термин «изолированный» сервер?

7. Опишите различия между рабочей группой и доменом.

8. Почему встроенная учетная запись Guest (Гость), как правило, бывает отключена?

Литература

Лабораторная работа № 4

Тема: Создание и администрирование учетных записей пользователей и групп

Задание 1. Создайте доменную учетную запись декана:

– имеет доступ ко всем ресурсам сети,

– может осуществлять вход на любой компьютер.

Указания к выполнению

1. Выполните команду Start –All Programs –Administrative Tools –Active Directory Users and Computers (Пуск –Программы –Администрирование –Пользователи и компьютеры Active Directory) .

2. Раскройте папку faculty.ru Users (Пользователи) .

3. В меню Action (Действие ) выберите команду New –User (Создать –Пользователь) .

4. Введите необходимые сведения о пользователе. В разделе User logon name (Имя пользователя при входе в систему ) введите dean (декан) . Обратите внимание на то, что при создании доменной учетной записи, в отличие от локальной, после имени пользователя отображается имя домена, отделенное от последнего знаком @ . Таким образом, полное имя пользователя (User logon name) –[email protected] .

5. При определении пароля пользователя обязательно установите флажок User must change password at next logon (Пользователь должен сменить пароль при следующем входе в систему ).

6. Завершите создание учетной записи.

7. В правой панели найдите учетную запись. Дважды щелкните по ней, чтобы внести дополнительные сведения (адрес, организация и т. д.).

8. Убедитесь в том, что декан может входить в систему в любое время (вкладка Account –Logon Hours (Учетная запись –Часы входа) ).

9. Попробуйте войти в домен под учетной записью декана. Почему попытка не удалась?

10. Зарегистрируйтесь в системе как администратор.

11. Посмотрите свойство учетной записи декана, снова выполнив команду Start –All Programs –Administrative Tools –. В окне свойств учетной записи выберите вкладку Member of (Членство в группах ) и добавьте учетную запись декана в глобальную группу Администраторы домена с помощью следующих команд Add… –Advanced… –Find now… (Добавить… –Дополнительно… –Найти…) из полученного списка выберите Domain Admins (Администраторы домена ).

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

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

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

Указания к выполнению

1. Выполните команду Start –All Programs –Administrative Tools –Active Directory Users and Computers .

2. Раскройте папку faculty.ru в левой панели окна. Во вложенных папках выберите Users .

3. В правой панели найдите учетную запись. Дважды щелкните по ней, и перейдите на вкладку Member of (Членство в группах). Среди списка групп выберите Domain Admins и нажмите Remove .

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

Указания к выполнению

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

2. Войдите в домен под учетной записью декана

3. Предложите другой способ, разрешающий вход на контроллер домена.

Задание 4. Создайте глобальную группу Teachers (Преподаватели ):

– тип группы – группа безопасности;

– преподаватели могут осуществлять вход на любой компьютер сети, кроме сервера;

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

Указания к выполнению

1. Выполните команду Start –All Programs –Administrative Tools –Active Directory Users and Computers .

2. Раскройте папку faculty.ru в левой панели окна. Во вложенных папках выберите Users .

3. В меню Action выберите команду New –Group (Новое –Группа) .

4. В поле Group Name (Имя группы ) введите Teachers .

5. В области Group Scope (Область действия группы ) щелкните переключатель Global (Глобальная) , а в области Group Type (Тип группы ) – переключатель Security (Безопасность) .

6. Щелкните OK.

Задание 5. Добавьте в группу Teachers (Преподаватели ) члена группы – учетную запись декана.

Указания к выполнению

1. Убедитесь, что открыта оснастка Active Directory Users and Computers и выбран контейнер Users .

2. В окне свойств группы Teachers выберите вкладку Members (Члены группы ), а затем последовательно кнопки Add… –Advanced… –Find now… из полученного списка выберите учетную запись декана.

3. В окне свойств учетной записи декана найдите информацию о членстве в группе Teachers .

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

Задание 7. Заполните таблицы, содержащие сведения о членах домена. Таблицы должны помогать планировать и создавать учетные записи домена.

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

Таблица 8

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

Таблица 9

Расписание входа в систему

Таблица 10

Планирование паролей

@ Придумайте не менее трех пользователей из каждой группы и в соответствии с требованиями проекта заполните таблицы 8–10. Внесите таблицы в отчет.

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

Задание 9. Проведите тестирование учетных записей. Например, измените системное время на 6.00 и попытайтесь войти в домен под учетной записью студента. Попытайтесь сменить пароль данной учетной записи.

Вопросы для самоконтроля

1. Опишите различия между локальной и доменной учетными записями.

2. С какой целью создают группы пользователей?

3. Объясните назначение локальных, глобальных и универсальных групп.

4. Объясните назначение групп безопасности и групп распространения.

5. Дайте определение и приведите примеры для следующих терминов: «права пользователей», «привилегии пользователей», «разрешения доступа пользователей».

6. Перечислите известные Вам встроенные учетные записи пользователей и групп пользователей домена и опишите их назначение.

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

8. Как запретить вход в систему в выходные дни и нерабочее время?

9. Как ограничить срок действия учетной записи?

10. Как отключить учетную запись сотрудника, например, во время его болезни?

12. Как изменить пароль пользователя?

13. Как запретить изменение пароля пользователем?

14. Каковы последствия удаления группы?

Литература

Лабораторная работа №5

Иходная ситуация - существует домен, testcompany.local . Для упрощения в нем будет один контроллер домена под Windows Server 2003, с именем dc01 . DNS-сервер также на нем, основная зона интегрирована в Active Directory.

Сетевые настройки контроллера:

IP-адрес - 192.168.1.11
Маска - 255.255.255.0
Шлюз - 192.168.1.1
DNS-сервер - 192.168.1.11

Задача - установить контроллер домена на другом сервере, причем работающем под Windows Server 2008 R2, старый контроллер понизить до рядового сервера (а затем возможно, удалить вообще), а все функции старого контроллера передать новому.

Подготовительные работы

В качестве подготовительных работ следует запустить команды netdiag (эта команда существует только в 2003 Server, Support Tools) и dcdiag , убедиться в отсутствии ошибок, а при их наличии исправить эти ошибки.

В первую очередь определяем держателя FSMO-ролей в домене, командой:

Утилита netdom.exe в состав Windows Server 2003 по умолчанию не входит, поэтому нужно установить Support Tools (http://support.microsoft.com/kb/926027). В рассматриваемом случае от нее смысла никакого нет, так как контроллер домена всего один и роли FSMO все равно все на нем. Тем же, у кого контроллеров домена больше одного, это будет полезно, чтобы знать, какие именно роли и откуда переносить. Результат команды будет примерно таким:

IP-адрес - 192.168.1.12
Маска - 255.255.255.0
Шлюз - 192.168.1.1
DNS-сервер - 192.168.1.11

и вводим его в существующий домен, testcompany.local в нашем случае.

Обновление схемы леса и домена

Следующий этап - обновление схемы леса и домена до Windows Server 2008 R2, что мы будем делать с помощью утилиты adprep . Вставляем установочный диск с Windows Server 2008 R2 в сервер dc01 . На диске нас интересует папка X:\support\adprep (X: - буква диска DVD-ROM). Если windows Server 2003 у вас 32-х битная, следует запускать запускать adprep32.exe, в случае 64-х битной - adprep.exe .

Для выполнения команды никаких требований к функциональному режиму леса нет. Для выполнения команды adprep /domainprep требуется, чтобы в домене использовался функциональный уровень домена не ниже Windows 2000 native.

Вводим команду:

X:\support\adprep>adprep32.exe /forestprep

После предупреждения о том, что все контроллеры домена Windows 2000 должны быть минимум с SP4 вводим С и нажимаем Enter:

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

Adprep successfully updated the forest-wide information.

После этого вводим команду:

X:\support\adprep>adprep32.exe /domainprep /gpprep

Которая отработает не в пример быстрее:

Также стоит выполнить команду adprep /rodcprep . Даже если вы и не собираетесь использовать в вашей сети контроллеры домена только для чтения (Read Only Domain Controller - RODC), эта команда как минимум уберет ненужные сообщения об ошибках в журнале событий.

После завершения действия команд по обновлению схемы можно приступать к повышению роли нового сервера до контроллера домена.
На сервере dc02 заходим в Server Manager, добавляем роль Active Directory Domain Services . После установки роли, зайдя в Server Manager > Roles > Active Directory Domain Services, мы увидим желтую подсказку «Run the Active Directory Domain Services Installation Wizard (dcpromo.exe )». Ее и запускаем. Либо можно в командной строке набрать dcpromo , что будет равноценно вышеприведенному действию.

Так как освещение процесса установки контроллера домена в эту статью не входит, остановлюсь лишь на некоторых ключевых моментах. На шаге Additional Domain Controller Options поставьте обе галки, DNS Server и Global catalog .

Если галку Global Catalog и DNS Server не поставить, придется их переносить отдельно. А при миграции с 2003 на 2003 это придется делать в любом случае, так как в Windows 2003 такой возможности нет. О переносе глобального каталога и DNS-сервера будет немного ниже.

Завершаем установку контроллера домена, перезагружаем сервер. Теперь у нас есть два контроллера домена, работающих одновременно.

Передача ролей FSMO

Передачу ролей FSMO можно производить как через графический интерфейс, так и с помощью утилиты ntdsutil.exe . В этой статье будет описан способ с использованием графического интерфейса, как более наглядный, кого интересует другой способ, он по этой ссылке: http://support.microsoft.com/kb/255504 . Передача ролей FSMO будет состоять из следующих шагов:

Заходим на сервер dc02 , на тот, на который будем передавать роли. Для того, чтобы получить доступ к оснастке Active Directory Schema , сначала необходимо зарегистрировать библиотеку schmmgmt.dll . Это делается с помощью команды:

regsvr32 schmmgmt.dll

В дереве оснастки нужно щелкнуть правой кнопкой мыши элемент Active Directory Schema и выбрать пункт Change Domain Controller . Там меняем контроллер на dc02 .
Далее опять нажимаем правой кнопкой мыши элемент Active Directory Schema и выбираем пункт Operations Master . Появляется вот такое окно:

Нажимаем Change > Yes > OK и закрываем все эти окна.

Открываем оснастку , щелкаем правой кнопкой мыши элемент Active Directory Domains and Trusts и выбираем команду Change Active Directory Domain Controller . Это действие необходимо, если работа ведется не с контроллера домена, которому передается роль. Пропустите его, если подключение к контроллеру домена, чья роль передается, уже установлено. В открывшемся окне выбираем контроллер домена, которому присваивается роль (dc02 в нашем случае), в списке и нажимаем кнопку ОК .
В оснастке щелкаем правой кнопкой мыши элемент Active Directory Domains and Trusts и выбираем пункт Operations Master . В появившемся окне нажимаем кнопку Change .

Чтобы подтвердить передачу роли, нажимаем кнопку ОК , а затем - Close .

Открываем оснастку . Щелкаем правой кнопкой мыши элемент Active Directory Users and Computers и выбираем команду Change Domain Controller . Пропустите его, если подключение к контроллеру домена, чья роль передается, уже установлено. В открывшемся окне выбираем контроллер домена, которому присваивается роль (dc02 в нашем случае), в списке и нажимаем кнопку ОК.

В оснастке щелкаем правой кнопкой мыши элемент Active Directory Users and Computers , выбираем пункт All Tasks , а затем Operations Master .

Выбираем вкладку, соответствующую передаваемой роли (RID , PDC или Infrastructure Master ), и нажимаем кнопку Change .
Чтобы подтвердить передачу роли, нажимаем кнопку ОК , а затем - Close .

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

Если мы делаем миграцию не на 2008, а на 2003, в котором при добавлении добавочного контроллера домена глобальный каталог не ставиться, либо вы не поставили галку Global Catalog в шаге 2, тогда нужно назначить роль глобального каталога новому контроллеру домена вручную. Для этого, заходим в оснастку Active Directory Sites and Services , ракрываем Sites > сайт Default-First-Site-Name > Servers > DC02 > щелкаем правой кнопкой мыши по NTDS Settings > Properties. В открывшемся окне ставим галку Global Catalog > OK.

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

Event Type: Information
Event Source: NTDS General
Event Category: (18)
Event ID: 1110
Date: 12.07.2011
Time: 22:49:31
User: TESTCOMPANY\Administrator

Description:
Promotion of this domain controller to a global catalog will be delayed for the following interval.

Interval (minutes):
5

This delay is necessary so that the required directory partitions can be prepared before the global catalog is advertised. In the registry, you can specify the number of seconds that the directory system agent will wait before promoting the local domain controller to a global catalog. For more information about the Global Catalog Delay Advertisement registry value, see the Resource Kit Distributed Systems Guide.

http://go.microsoft.com/fwlink/events.asp .

Ждем пять минут и дожидаемся события 1119 о том, что этот контроллер стал глобальным каталогом.

Event Type: Information
Event Source: NTDS General
Event Category: (18)
Event ID: 1119
Date: 12.07.2011
Time: 22:54:31
User: NT AUTHORITY\ANONYMOUS LOGON
Computer: dc02.testcompany.local
Description:
This domain controller is now a global catalog.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp .

Перенастройка интерфейсов, DNS и другие послеустановочные задачи

Далее, так как DNS-сервер на dc02 мы установили, теперь нужно в свойствах сетевого интерфейса первичным DNS-сервером указать самого себя, т.е. адрес 192.168.1.12. И на dc01 соответственно поменять на 192.168.1.12.

В свойствах DNS-сервера на dc02 проверьте вкладку Forwarders , на 2003, в отличие от 2008, она не реплицируется. После этого можно понижать контроллер домена dc01 до рядового сервера.

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

После смены IP-адреса выполните команды ipconfig /registerdns и dcdiag /fix .

Лабораторная работа

Информатика, кибернетика и программирование

Лабораторная работа № 6. Создание домена Windows Server 2003 Цели работы: научиться создавать домен Windows Server 2003; научиться устанавливать службу каталога Active Directory; изучить структуру службы каталога Active Directory. Задание 1. Установить на сервере службу катало...

Лабораторная работа № 6 .

« Создание домена Windows Server 2003 »

Цели работы:

1. научиться создавать домен Windows Server 2003;
2. научиться устанавливать службу каталога Active Directory ;
3. изучить структуру службы каталога Active Directory .

Задание 1. Установить на сервере службу каталога Active Directory , создать домен mydomain. ru.

Задание 2 . Просмотреть созданный домен одним из способов.

Задание 3. Проверить работу службы DNS с помощью оснастки DNS.

Задание 4. Удалить службу Active Directory .

А также другие работы, которые могут Вас заинтересовать
71939.		Декабризм, и его значение в истории России	365 KB
	Движение декабристов является событием, длительное время приковывающим внимание историков. Это связано с тем, что события более чем 170-летней давности оказали значительное влияние на последующее развитие России; декабристы были первыми русскими революционерами, которые организовали открытое восстание против царизма.
71940.		ЗАКОНОДАТЕЛЬНЫЕ И ИНЫЕ НОРМАТИВНЫЕ ПРАВОВЫЕ АКТЫ, УСТАНАВЛИВАЮЩИЕ ПОРЯДОК РАССЛЕДОВАНИЯ И УЧЕТА НЕСЧАСТНЫХ СЛУЧАЕВ НА ПРОИЗВОДСТВЕ	91 KB
	Формы документов необходимых для расследования и учета несчастных случаев на производстве утвержденные Минтрудом России следующие: извещение о групповом несчастном случае тяжелом несчастном случае несчастном случае со смертельным исходом; акт о несчастном случае...
71941.		Пыль. Средства индивидуальной защиты от пыли	179.5 KB
	Для этой цели используется классификация пыли по ее дисперсности и способу образования. Характер действия пыли на организм зависит от физико-химических свойств пылевых частиц. Ядовитые пыли свинца ртути мышьяка и т. растворяясь в биологических средах действуют как введенный в организм...
71942.		Пенсии по случаю потери кормильца	24.33 KB
	Пенсии по случаю потери кормильца - это ежемесячные денежные выплаты алиментарного характера из фонда социальной защиты населения или государственного бюджета назначаемые нетрудоспособным членам семьи умершего кормильца состоявшим на его иждивении в размерах соизмеримых с заработком кормильца.
71943.		Альберт Великий	41.55 KB
	После распада Римской Империи, сельское хозяйство на её западных территориях, занятых варварами пришло в упадок. Были утрачены знания и технологии Империи, площадь пахотных земель значительно сократилась.
71944.		Александр Васильевич Советов	149.42 KB
	Александр Васильевич Советов возглавлял Вольное Экономическое общество (ВЭО), в котором его первый отдел объединял агрономов, экономистов и естествоиспытателей, таких как Д.И. Менделеев, К.А. Тимирязев, а с 1875 года - Докучаев.
71945.		ДЕМОГРАФИЧЕСКАЯ ПОЛИТИКА	111.5 KB
	Она призвана воздействовать на формирование желательного для общества режима воспроизводства населения сохранения или изменения тенденций в области динамики численности и структуры населения темпов их изменений динамики рождаемости смертности семейного состава расселения внутренней...
71947.		Понятие сети ССП и ее базовые принципы	180.57 KB
	Пользователи получили доступ к услугам, о которых 10–15 лет назад и не задумывались. E-mail, Интернет, сотовый телефон стали обычными атрибутами повседневной жизни. За короткое время мы так привыкли к практически ежедневному появлению всевозможных новинок, что сами начали выдвигать требования по предоставлению новых услуг и приложений.

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

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

Внедрение и интеграция

В данной главе мы рассмотрим новые возможности Active Directory с нескольких точек зрения: внедрения этой службы, ее интеграции с другими каталогами, перехода с предыдущей версии (либо обновление с Windows NT 4.0, либо просто установка Active Directory с нуля). Прежде всего, необходимо отметить, что новые возможности Active Directory на базе Windows 2003 по большей части не совместимы с Active Directory на базе Windows 2000. Например, возможности переименовать домен или восстановить ранее деактивированный объект в схеме могут быть использованы только тогда, когда каталог находится на максимально возможном функциональном уровне: уровень домена - Windows Server 2003 и уровень леса - Windows Server 2003. Чтобы получить доступ к этим и другим возможностям, следует перевести лес на максимально функциональный уровень. Рассмотрим, что собой представляют эти самые функциональные уровни.

Функциональные уровни

Администратор вручную повышает функциональный уровень

Замечу, что такая классификация была специально введена для обеспечения совместимости на уровне обратно-несовместимых возможностей. Даже если установить Active Directory с нуля, не выполняя никаких обновлений и не заботясь об интеграции, то есть просто установить новый сервер, а на него - первый контроллер в лесе, то получится система, которая изначально попадает на самый низкий уровень. Другими словами, уровень домена - Windows 2000 Mixed (смешанный) и уровень леса - Windows 2000. Таким образом, в этом режиме установленная система полностью соответствует всем тем возможностям, которые есть в Windows 2000 Active Directory. Чтобы перейти на более высокий уровень, необходимо выполнение определенных условий, например, домен может быть переведен на уровень Windows Server 2003 только после того, как все контроллеры этого домена будут переведены на эту операционную систему. Если говорить о переходе с Windows 2000, то, естественно, процесс перехода заключается в поэтапном обновлении существующих контроллеров. Невозможно все контроллеры разом перевести с Windows 2000 на Windows 2003, это можно делать только по очереди. Пока процесс перевода контроллеров не завершен, функциональный уровень домена остается на уровне Windows 2000 Mixed. Как только будут переведены все контролеры, можно перейти на следующий уровень. Администратор переключает функциональный уровень с помощью специальной консоли Active Directory Domains Trusts. Администратор не в состоянии понизить уровень, он может только перевести его на более высокую ступень, на котором система останется. После того, как администратор перевел домен на новый функциональный уровень, в Active Directory появляются определенные новые возможности.

Рассмотрим эти возможности для простоты изложения в режиме чистый лес - Windows 2003 и все домены - Windows 2003. Другими словами, максимально возможные уровни и, соответственно, максимальный спектр новых возможностей. Первое, на чем стоит остановиться - это функция, которая называется Application Partitions (по-русски - Разделы Приложений).

Разделы для приложений

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

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

Следующей возможностью является поддержка класса объектов InetOrgPerson (RFC 2798). Она появилась только в Windows 2003, а Windows 2000 этот класс объектов не поддерживает. InetOrgPerson нужен для интеграции с другими LDAP-каталогами (Novell, Netscape). Active Directory умеет работать с этим классом, создавать объекты этого класса, возможна также прозрачная и плавная миграция объектов типа InetOrgPerson из других каталогов Active Directory. Соответственно, становится возможным перенос приложений, написанных для других LDAP-каталогов. Если приложения используют данный класс, то их можно безболезненно, прозрачно портировать на Active Directory, сохраняя всю функциональность.

Далее, появилась возможность переименования доменов. В данном случае, следует четко понимать, что под переименованием домена имеется в виду не просто смена названия домена (назывался раньше домен "abcd", а теперь называется "xyz"). На самом деле, структура каталога является деревом, в нем много доменов, а сами домены объединены в иерархию. Переименование домена, это, на самом деле, реструктуризация леса. Можно переименовать домен таким образом, что он окажется в другом дереве.

Переименование домена. Утилита rendom.exe

Рассмотрим домен Contoso, подчиненный домену Sales в дереве WorldWideImporters.com. Его можно переименовать и назвать Contoso.Fabrikam.com. Это не просто переименование, это перенесение домена из одного дерева в другое, то есть достаточно нетривиальная процедура. Логично предположить, что переименование домена может привести к созданию нового дерева. Можно переименовать домен Contoso, который был подчинен домену Sales, и назвать его Contoso.com. Тогда домен станет родоначальником другого дерева в этом же лесе. Именно поэтому процесс переименования домена можно считать весьма сложной и нетривиальной процедурой.

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

Вместе с Windows 2003 поставляется утилита, которая называется Rendom, буквально от слов Rename Domain. Утилита Rendom.exe - это утилита командной строки, которая может использоваться для переименования домена. Правда, этот процесс состоит из шести этапов. Подробную информацию о нем можно отыскать в службе справки Windows 2003, специальных технических документах для Microsoft .NET, на сайте MSDN. Там подробно описано, как моделировать, проектировать и проводить процесс переименования домена, с использованием утилиты rendom. В любом случае, это сложный, многоэтапный процесс, требующий тщательной подготовки: слишком много связок и указателей, имен и прочих взаимозависимостей, которые формируются при создании доменов. Просто взять и одним махом все это перенести - невозможно.

В плане внедрения Active Directory появился режим установки контроллера домена со съемного носителя. Что имеется в виду? Очень часто встречается ситуация, когда предприятие внедряет Active Directory в удаленных офисах: связь с удаленным офисом слабая, плохие линии связи между головными офисами и филиалами. Тем не менее нужно в филиале установить новый контроллер доменов. Когда создается новый контроллер в уже существующем домене, утилита DCPromo связывается с существующими, работающими контроллерами и перекачивает себе всю базу данных и реплики, которые можно собрать с контроллера её домена. Если эта база занимает несколько десятков или сотен килобайт, то есть пустая (она по-умолчанию занимает несколько сот килобайт), то проблем нет. Но если говорить о работающей системе, в которой база может занимать десятки или сотни мегабайт, то её перекачка может оказаться просто невыполнимой задачей. Поэтому в этой ситуации можно решить проблему очень простым способом. С помощью Windows NT Back-up сделать архив в режиме "system state", то есть выбрать в консоли Windows NT Back-up опцию Back-up->SystemState. После этого весь созданный Back-up записать на носитель, например, на CD или DVD, взять этот диск и приехать с ним в удаленный офис, там восстановить всю информацию из архива с помощью той же самой Windows NT Back-up. Только нужно сделать восстановление не по умолчанию, а в другой каталог, чтобы сами файлы были просто выложены на диск. Естественно, не нужно заменять ту системную информацию, которая есть на существующем компьютере. Далее следует запустить утилиту DCPromo с ключом "/adv" и указать путь к тому хранилищу, где находится распакованный файл. После этого процесс инсталляции нового контроллера будет создавать свою реплику на основании информации со съемного носителя. При этом все равно потребуется связь с головным офисом, потому что помимо перекачки реплики, требуется еще установление определенных отношений с существующим доменом. Поэтому связь должна быть, но требования к ней существенно снижены: подойдет даже очень слабая линия. В приведенном сценарии 95% информации, которые нужно было перекачивать на новый контроллер, были перенесены на системный носитель, а линию связи между головным офисом и филиалом не пришлось перегружать.

Важно отметить, что у заказчиков по-прежнему очень часто используется Windows NT 4.0. Windows 2003 позволяет перейти с существующих каталогов (с NT 4 или с Windows 2000) быстрее, более безболезненно и эффективно. Этой цели служит утилита Active Directory Migration Tool (ADMT) . ADMT поможет с миграцией с Windows NT на Windows 2003, а также с Windows 2000 на Windows 2003 в том случае, если потребуется какая-то реструктуризация доменов, перенесение учетных записей и т.д.

Мастера Active Directory Migration Tool (ADMT) v.2

Active Directory Migration Tool представляет собой набор программ-мастеров. Каждый мастер выполняет определенную задачу (см. картинку выше). Важно, что большинство программ-мастеров имеет режим, который называется "Test migration settings and migrate later" - моделирование процесса без реального выполнения операций. Другими словами, процесс миграции эмулируется, и администратор может посмотреть, каков будет результат и как все будет происходить. Реальные действия в этом режиме не выполняются. В случае, когда результаты работы тестового режима удовлетворительны, можно попросить Active Directory Migration Tool выполнить полноценную миграцию.

Администрирование

Данная глава посвящена инструментальному администрированию. В принципе, нельзя сказать, что здесь появилось много новых очень полезных возможностей. Однако кое-что все-таки есть. Например, поддержка Drag&Drop: до выхода Windows 2003 поддержки Drag&Drop не было. Теперь можно кликнуть на объект "пользователь" и перетащить его мышкой в новый контейнер. Это очень удобно. Жаль, что такого механизма в предыдущих версиях не было.

Появилась дополнительная консоль для хранения запросов к каталогу. Известно, что Active Directory - это LDAP-каталог. Значит, к LDAP-каталогам можно делать запросы на стандартном языке запросов. Если эти запросы делать и не запоминать, то это является дополнительной нагрузкой на администратора: каждый раз ему нужно запрос писать заново или копировать его из какого-то документа. Для упрощения данного процесса предлагается раздел, который называется Saved Queries. В нем собственно и сохраняются те запросы, которые администратор или пользователь ввели в консоли.

Консоль сохраненных запросов к каталогу

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

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

Утилиты командной строки

В этом нет, на самом деле, никакого противоречия. Дело в том, что очень много операций, которые приходится выполнять администратору, удобнее делать в виде командных файлов. Например, когда речь идет о модификации у одинаковых или похожих объектов какого-то атрибута, это часто удобнее сделать в командной строке, написав соответствующий скрипт. Если необходимо изменить какой-то параметр, например, телефоны пользователей, которые прописаны в учетной записи (у всех в подразделении может поменяться телефон), можно зайти в каждую учетную запись и изменить телефон. Если это делать через графический интерфейс, то придется произвести как минимум сто операций по изменению объекта "Учетная запись". Можно же взять одну простую команду, которая называется DSMod (модификация объекта), сформировать строчку для записи новой информации, после чего написать скрипт с условиями поиска и выполнить всё в виде одной команды. Для таких операций (а в повседневной работе администратора их множество) следует использовать утилиты командной строки и скрипты.

Репликация

Вопросы репликации очень актуальны при внедрении Active Directory, проектировании и планировании инфраструктуры.

В Windows 2000 есть определенные ограничения по количеству сайтов, в которых можно было бы автоматически сгенерировать топологию. Существует служба, которая называется Inter-Site Topology Generator (ISTG) . Когда создаются два или три, а лучше пять или даже десять сайтов, служба ISTG автоматически генерирует топологию репликаций между сайтами, сама выбирает узловые серверы, сама определяет, как будет выполняться сценарий этой репликации. Всё хорошо, но если сайтов порядка двухсот, то служба ISTG не справляется с объемом информации и зацикливается. Поэтому для Windows 2000 есть совершенно четкая рекомендация - количество сайтов не должно быть более двухсот, если необходимо, чтобы топология репликации между сайтами генерировалась автоматически. Если же сайтов больше - автоматическую генерацию надо отключить и настраивать все это вручную.

Проблема, казалось бы, не очевидна, но с ней люди реально сталкиваются, когда доходит до внедрения Active Directory на многосайтные системы. Windows Server 2003 снимает этот вопрос. В этой системе реализован абсолютно новый Inter-Site Topology Generator, который работает принципиально по-другому и генерирует топологию, используя новый алгоритм. Количество сайтов, которое может теперь автоматически генерироваться (топология которых может генерироваться автоматически с помощью службы ISTG), только на тестах было несколько тысяч. Неизвестно, кому может потребоваться столько сайтов, но, тем не менее, можно забыть о каком-либо ограничении только за счет модификации механизма ISTG.

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

Есть еще одно ограничение в том, как Active Directory в Windows 2000 реплицирует группы. Речь идет о группе безопасности. Когда дело касается назначения прав для доступа к каким-то объектам, обычно правильная практика администрирования подразумевает, что права назначаются группам. Пользователи либо включаются в группу, либо исключаются. Группа - это точно такой же объект в Active Directory, как и все остальные объекты. Объект же имеет атрибуты. Особенность группы заключается в том, что список членов группы - это не несколько атрибутов, это один атрибут с большим количеством значений, так называемый "Multi Value Attribute" (на самом деле, это один атрибут, у которого много значений). Механизм репликации Active Directory детализирован до уровня атрибута. Если объект модифицируется, то система будет реплицировать эти изменения ровно для тех атрибутов, которые изменились, а не для всего объекта целиком. Теперь вернемся к группе, у которой есть атрибут, состоящий, например, из ста значений. Если в группу входит сто человек, значит у этого атрибута сто значений. А если 5 тысяч? Ограничение заключается в следующем: если членство в группе составляет 5 тысяч объектов, то репликация такого объекта становилась невозможна. Как только появится 5001 член группы, сразу же разрушается процесс репликации этой группы на Windows 2000. Есть даже документированный способ атаки, когда администратор, обиженный на кого-то, может разрушить процесс репликации в системе, просто написав скрипт, который циклическим образом поместит в какую-то группу 5 тыс. членов. После чего возникают проблемы с репликацией каталога. Windows Server 2003 Active Directory вводит дополнительный механизм, который называется "Репликация присоединенных значений" ("Linked Value Replication").

В этом случае механизм предназначен исключительно для репликации атрибутов, у которых есть много значений. То есть теперь, при использовании этого механизма членство в группе реплицируется на уровне отдельных членов. Если включить нового человека в группу, то репликация будет вестись не всего списка, как атрибут, а только значения за счет механизма Linked Value Replication.

Еще одна проблема, связанная с репликацией, имела отношение к глобальному каталогу. Трудность заключалась в том, как ведет себя глобальный каталог, когда администратор модифицирует, так называемый, Partial Attribute Set (PAS) - список атрибутов, которые должны быть помещены в глобальный каталог.

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

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

Windows Server 2003 снимает эту проблему. Репликация и синхронизация глобального каталога будет проводиться исключительно в объеме добавленного атрибута. То есть когда проводится операция добавления атрибута к PAS, происходит просто сбор информации у тех объектов, у которых этот атрибут есть. А затем он [атрибут] добавляется к глобальному каталогу. Полной синхронизации не происходит.

Еще одна дополнительная функция, касающаяся глобального каталога - это механизм кэширования универсальных групп. Напомню, группы в Active Directory бывают трех типов: локальные, глобальные и универсальные. Локальные и глобальные хранятся вместе с репликой на контроллере, универсальные группы хранятся в глобальном каталоге. Когда сотрудник удаленного офиса хочет войти в сеть, система провести регистрацию пользователя в сети и создать его контекст безопасности. Для этого ей необходимо узнать, в какие группы входит пользователь. Узнать о локальных и глобальных группах Windows 2000 может на своем ближайшем контроллере, но по устройству сети, глобальный каталог находится в головном офисе. Проверить членство пользователя в универсальных группах можно только, сделав запрос к глобальному каталогу. Поэтому на момент регистрации необходимо послать запрос в головной офис. Если связь оборвана и глобальный каталог не доступен, то пользователю будет отказано в регистрации (по умолчанию в этой ситуации). Если в реестре поставить значение "игнорировать ошибки, связанные с членством в универсальных группах", в системе безопасности образуется дыра.

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

Доверие между лесами

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

Доверие между лесами

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

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

Можно сделать цепочку, например, из трех лесов A, B, C. A доверяет В, а В доверяет С. Из этого не следует, что между лесом А и С тоже установились доверительные отношения. Это как в Windows NT 4: не транзитивные отношения в том смысле, что они не транзитивны между лесами. Но между доменами, которые связывают два леса, отношения являются транзитивными.

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

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

Механизм групповых политик позволяет назначать политики контейнерам, то есть организационным подразделениям, сайтам и доменам. Групповую политику нельзя назначить конкретному пользователю. При этом, поскольку структура контейнеров в Active Directory иерархична, можно на разных уровнях назначать разные групповые политики. Следовательно, работают механизмы наследования. У администратора есть определенные функции по блокировке наследования или, наоборот, по принудительному применению политики наследования. Администратор имеет возможность фильтровать применение групповых политик через права доступа. В любом случае, большое количество задач решается с помощью не меньшего количества инструментов. Для каждой задачи есть определенный инструмент. Таким образом, чтобы управлять групповыми политиками в Windows 2000, требуется знать порядка шести инструментов и использовать их для различных задач.

Windows Server 2003 позволяет существенно упростить жизнь администратору за счет появления специального инструмента, который называется Group Policy Management Console. Это интегрированная или консолидированная консоль, которая включает в себя интерфейс для выполнения абсолютно всех задач, связанных с групповыми политиками. Больше не нужно ломать голову, где делается данная операция - все в Group Policy Management Console, при этом консоль группирует информацию очень логично, интуитивно понятно.

Помимо того, что Group Policy Management Console является консолидированным графическим инструментарием, она еще и добавляет ряд новых функций к управлению групповыми политиками. Например, функции архивирования и восстановления групповых политик, функции копирования групповых политик между доменами одного леса и импорт/экспорт групповых политик.

Group Policy Management Console, как составная часть Windows Server 2003, отсутствует. Ее нужно скачивать с web-сервера Microsoft (http://www.microsoft.com/downloads ). Установить консоль можно либо на Windows Server 2003, либо на Windows XP при наличии Service Pack 1 и.NET Framework. Таким образом, с помощью Group Policy Management Console можно управлять групповыми политиками, даже не находясь непосредственно на контроллере домена. Можно установить консоль прямо на рабочую станцию Windows XP и с этой рабочей станции централизованно управлять всеми групповыми политиками леса. Кроме того, в составе Group Policy Management Console есть два мастера, которые позволяют анализировать и моделировать процесс применения групповых политик. Первый называется "Мастер результатов применения групповых политик" и он показывает, какие политики применялись к данному конкретному компьютеру, какие значения изменились и с каких политик эти значения были получены. Если что-то не применилось, мастер показывает, почему это не применилось.

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

Процесс такого моделирования выполняется с помощью консоли, которая расположена в Group Policy Management Console и называется Process Modeling. Моделирование не требует подключения к исследуемому компьютеру. Оно работает только с информацией, которая хранится в Active Directory. Достаточно просто иметь доступ к контроллеру Windows Server 2003 Active Directory. Можно, например, представить, что случится, если пользователь войдет в какую-то группу безопасности, можно условно поместить пользователя в какой-то контейнер и посмотреть, что произойдет.

Есть еще некоторые новые возможности Group Policy Management Console - это архивирование и восстановление групповых политик. Сами объекты можно сохранить в виде файла в определенном каталоге. Потом их можно восстановить обратно в случае какой-то проблемы или при экспериментах с доменом, Active Directory или групповыми политиками. Важно, что восстановить групповую политику можно только в том же домене, в котором она была заархивирована. Восстанавливается только объект групповой политики сам по себе: то, что было к нему дополнительно привязано, нельзя поместить в архив, соответственно, восстановить тоже.

Перейдем теперь к Windows Management Instrumentations (WMI). Это технология, которая сейчас является основной в управлении системами. WMI используется практически везде: любая служба так или иначе задействует WMI.

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

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

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

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

Правила могут быть четырех типов (ранжированы по приоритету): Certificate (максимальный приоритет), Hash, Path и Zone. Приоритет актуален, когда есть несколько политик, определяющих одно и то же приложение разными правилами. Например, одна политика разрешает запускать все программы, которые расположены в каталоге "ABCD", а другая политика запрещает запускать программы, имеющие такой-то хэш. Если окажется, что эта программа, которую запрещено запускать, находится в разрешенном каталоге ABCD, то сильнее окажется правило запрета, потому что правило по хэшу "побеждает" правило по пути. Именно для этого используется приоритет.

Заключение

Можно резюмировать, что с появлением Windows Server 2003 добавилось не так уж и много полезных возможностей для работы с Active Directory. Тем не менее, некоторые из них очень полезны и могут сэкономить время и нервы системному администратору. Это, прежде всего, Group Policy Management Console и утилиты командной строки. Остальные изменения зачастую устраняют недоработки предыдущих версий системы (обновленные механизмы и алгоритмы), однако все равно необходимо знать, где именно возможности Active Directory расширены и как ими пользоваться...

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

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

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