Сайт о телевидении

Сайт о телевидении

» » Серверы - плацдармы. Указания к выполнению

Серверы - плацдармы. Указания к выполнению

Итак мы будем считать что у нас установлен Windows 2003 Server и на нем развернута Active Directory (Далее AD). AD позволяет нам управлять компьютерами и пользователями: устанавливать ограничения или наоборот задавать различные благоприятные условия работы. Теперь самое время перейти к созданию пользователей и компьютеров. В первую очередь необходимо создать пользователя и делать мы это будем в специальной консоли, доступ к которой можно получить так:

  • "ПУСК" ? "Насройка" ? "Панель управления" ? "Администрирование" ? "Active Directory - пользователи и компьютеры";
  • Или в меню: "ПУСК" ? "Выпонить" введите команду dsa.msc .

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

Вам откроется программа "Active Directory - пользователи и компьютеры", состоящая из двух окон. Слева мы видим папки с параметрами, а справа сами параметры находящиеся в этих папках.

На данном этапе нас интересует папка "Users" (Пользователи). Нажимаем на ней правой кнопкой мышки и выбираем "Создать" ? "Пользователь"

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

Если все было сделано правильно, то программа выдаст сообщение о создании нового пользователя.

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

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

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

Вкладка "Член групп": тут можно включить нашего пользователя в различные группы.

Вкладка "Удаленное управление" позволяет разрешить/запретить пользователю подключаться к домену через удаленное соединение.

Еще одна интереная вкладка "Учетная запись", тут можно поменять имя пользователя и задать различные параметры для пароля.

Добавление компьютера в домен

Для подключения компьютера к домену все готово. Компьютеры, работающие под управлением Windows 2000/XP, при подключении к серверу будут добавляться автоматически в группу Computers. Для этого на каждом клиенте нужно выбрать «Мой Компьютер» ? «Свойства» ? «Имя компьютера .

После этого у нас есть два пути: либо вызвать мастера сетевой идентификации, нажав кнопку «Идентификация», либо сразу ввести необходимые параметры, нажав кнопку «Изменить» .

Если в вашей сети есть ПК, работающие под Windows 98, то они подключаются как клиенты Active Directory; в этом случае учетные записи компьютера не создаются. Для их работы необходимо установить программу dsclient.exe, которая имеется на установочном диске Win2k3.

Итак задаем имя домена и нажимаем ОК.

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

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

Если все хорошо, то мы увидим окно об успешном подключению к домену.

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

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

На этом пока все, продолжение в следующих статьях...{odnaknopka}

После перезагрузки сервера необходимо убедиться, что Основной режим разрешений (режим Windows Server 2003) установился. Для этого необходимо открыть оснастку « Active Directory – домены и доверие», «встать» мышкой на название своего домена и из меню выбрать «Изменение режима работы домена».

Если Основной режим разрешений не установлен, его необходимо установить.


Настройка DNS

Для настройки автоматически созданного при установке контроллера домена DNS следует загрузить оснастку DNS , нажать правой кнопкой мыши на вкладке «Зоны обратного просмотра» и из предложенного меню выбрать пункт «Создать новую зону».


Будет выполнен запуск Мастера создания новой зоны.


В окне «Тип зоны» нужно указать, какая зона будет создана. Поскольку производится настройка первого сервера DNS в домене, требуется выбрать пункт «Основная зона», и рекомендуется выбрать параметр «Хранить зону в Active Directory ».


Выбор в окне «Область репликации зоны, интегрированной в Active Directory » рекомендуется остановить на пункте «На все DNS -серверы в домене имя_созданного_домена . local ». Это позволит передавать зоны только в пределах конкретного домена в случае наличия леса.


Окно «Имя зоны обратного просмотра» задает описание, для каких IP -адресов будет вестись накопление информации и предоставление имен по запросу клиентов. Рекомендуется для простоты вводить именно код сети, представляющий собой количество значащих октетов в адресах локальной сети (Например: 192.168.1).

В форме «Динамическое обновление» требуется выбрать, каким образом может быть изменена информация, хранимая DNS -сервером. Для сетей, в состав которых входят клиенты Windows 2000 и старше, можно разрешать только безопасные динамические обновления. В общем же случае рекомендуется выбирать параметр «Разрешать любые динамические обновления».

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


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


Затем нужно произвести настройку зоны прямого просмотра. Для этого, «встав» в ветви «Зоны прямого просмотра» на зону с именем созданного домена, требуется правой кнопкой мыши вызвать меню и выбрать пункт «Свойства».


На вкладке «Общие», как было проделано при создании ветви обратного просмотра, так же рекомендуется задать параметр «Динамическое обновление» в значение «Небезопасные и безопасные».

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

Создание записи выполняется следующим образом: на зоне с именем домена следует нажать правую кнопку мыши, и выбрать в меню пункт «Создать узел». В форме ввода информации о создаваемом узленужно ввести имя узла (полное доменное имя заполняется автоматически) и его IP -адрес, после чего проставить галочку на пункте «Создать соответствующую PTR -запись».


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

Настоятельно не рекомендуется создавать записи для компьютеров и серверов домена в DNS вручную. Для корректного создания записи в меню «Пуск - Выполнить» лучше выполнить команду ipconfig / registerdns , которая выполнит регистрацию на DNS -сервере.

Все операционные системы, подключенные к домену должны быть настроены на использование локальных DNS-серверов (обычно ими являются доменные контроллеры) в качестве предпочитаемых и альтернативных. Если конфигурация протокола TCP/IP настроена верно, операционные системы выполняют создание записей в доменных зонах в автоматическом режиме (за исключением Windows 9X).

Установка и настройка DHCP

Применение службы DHCP упрощает администрирование сети и позволяет обеспечить уникальность используемых в домене IP -адресов. Для установки службы DHCP достаточно зайти в«Панель управления», запустить «Установка и удаление программ», и выбрать вкладку «Установка компонентов Windows », «встать» на строку «Сетевые службы», и нажать «Состав».


Нужно установить компонент « DHCP ».


(Компонент « DNS » был добавлен автоматически в ходе установки AD и снимать с него галочку нельзя).

По завершению установки компонента DHCP нужно загрузить оснастку « DHCP », встать на запись, содержащую имя установленного сервера, и, развернув правой кнопкой мыши меню, выбрать пункт «Создать область». Будет запущен Мастер создания области.


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


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


В диалоговом окне задан диапазон, включающий в себя все возможные значения адресов в сети. Для того, чтобы не происходила выдача используемых адресов (IP -адреса серверов, активного сетевого оборудования и другие устройства со статическими адресами) необходимо на форме «Добавление исключений» указать исключаемый из распределения диапазон адресов. Можно перечислить адреса, исключаемые из распределения, по одному вводя их в графу «Начальный IP -адрес».


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

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

Для уменьшения общего времени создания домена, рекомендуется ответить согласием на предложение мастера создания области произвести настройку параметров DHCP .


Окно «Маршрутизатор (основной шлюз)» заполняется при наличии такового в составе сети.

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

Окно «Имя домена и DNS -серверы» требует особого внимания. В графу «Родительский домен» требуется ввести без каких-либо сокращений полное имя созданного домена (например: « domain 1. local »). Ошибка или неполный ввод имени домена повлечет за собой проблемы в работе сети, например, сложности с подключением компьютера к домену.


Тут же вводятся адреса DNS -серверов сети. Рекомендуется вводить не адрес DNS -сервера, а его имя, при нажатии на кнопку «Сопоставить» адрес сервера будет проставлен автоматически, после чего так же необходимо нажать на кнопку «Добавить». Если не произошло сопоставление имени DNS -сервера либо был возвращен неверный IP -адрес, это может означать наличие проблем либо в службе DNS , либо в настройке сетевого соединения.

Можно вводить адреса нескольких DNS -серверов, если в сети используется одновременно несколько DNS -серверов.

Если в сети нет серверов WINS , то окно « WINS -серверы» следует оставить пустым.

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

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

После завершения работы мастера создания зоны требуется авторизовать DHCP в AD . Если этого не проделать, адреса клиентам выдаваться не будут.

Для этого в оснастке DHCP нужно «встать» на имя настраиваемого сервера, развернуть правой кнопкой мыши меню, и выбрать пункт «Авторизовать».


Для того, чтобы выданные сервером адреса автоматически передавались в DNS , следует произвести дополнительную настройку сервера DHCP . Для этого в оснастке DHCP нужно «встать» на имя настраиваемого сервера, развернуть правой кнопкой мыши меню, и выбрать пункт «Свойства».

На вкладке «Служба DNS » рекомендуется выставить те же параметры, что использовались ранее. Данная настройка обеспечит одновременно и передачу информации в DNS обо всех выданных адресах, вне зависимости от типа клиента, и будет выполнять автоматическое удаление устаревшей информации при истечении срока аренды адреса.

Работа клиентов Windows 9х в домене Windows Server 2003

В домене Windows Server 2003 был повышен уровень безопасности по умолчанию, что привело к появлению определенных сложностей в работе устаревших клиентских систем, таких как Windows 95, 98, NT 4.0.

Для того, чтобы позволить данным операционным системам производить работу в домене, рекомендуется выполнить установку на машины клиента Active Directory DSCLIENT.EXE (располагается на дистрибутивах Windows 2000 Server в папке CLIENTS\WIN9X), и произвести ряд модификаций политик безопасности.

Для выполнения модификаций следует запустить оснастки «Политика безопасности контроллера домена»,


затем «Политика безопасности домена», и отключить показанные параметры безопасности.



По информации Microsoft , достаточным является отключение параметра "Сервер сети Microsoft : использовать цифровую подпись (всегда)" в политике безопасности домена Windows 2003.

После завершения редактирования данных политик безопасности рекомендуется произвести перезагрузку сервера.

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

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

Впрочем, цветастая оболочка Windows не всегда столь проста в настройке, как может показаться вначале. Как только вы переходите от простого использования каких-либо функций к их предложению по сети, возникает множество "подводных камней", о которых просто необходимо знать. Сегодня самым эффективным серверным инструментом в мире Microsoft является Windows Server 2003, который выпускается в трёх вариантах (Web, Standard и Enterprise).

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

На чём делать сервер? Серверное "железо"

Сервер не всегда должен иметь два процессора Xeon с дорогой памятью ECC и 64-битными слотами PCI-X, как показано на иллюстрации. Для дома или небольшого офиса вполне достаточно сервера на Pentium 4 или Athlon с достаточным объёмом памяти и массивом RAID для защиты от краха жёсткого диска.

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

Если некоторые пользователи не жалеют денег и могут позволить себе машины с четырьмя процессорами Itanium, Opteron или Xeon из-за требований каких-то специфических приложений, то на серверном рынке наиболее распространены системы с одним и двумя процессорами . Сегодня постепенно набирают популярность процессоры AMD Opteron, хотя самым распространённым выбором для малых серверов является Intel Xeon.

В качестве шлюза (default gateway) мы указали IP-адрес нашего DSL-маршрутизатора, поскольку сервер должен иметь доступ в Интернет. В качестве DNS-сервера мы тоже указали маршрутизатор.

Развёртывание Active Directory

Служба каталога 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-серверы не запущены. Поэтому необходимо установить и его.

Установка DNS-сервера

Система DNS (Domain Name Service) является ахиллесовой пятой структуры Active Directory. Поскольку сетевые коммуникации в целях доступности осуществляются по именам (скажем, www.thg.ru), должна существовать система преобразования имён в IP-адреса - и наоборот. Прямые запросы преобразовывают имя в IP-адрес , а обратные - IP-адрес в имя.

Установка сервера DNS происходит быстро (иллюстрация выше), правда сразу он обычно не работает.

Так работает обратный запрос. Источник: Microsoft.

Довольно важно добавить зону обратного преобразования (Reverse Lookup Zone). Тогда DNS-сервер сможет выдавать имена на основе IP-адресов.

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

Конечно же, нам нужно ввести адресное пространство для локальной сети . В данном случае идентификатор сети будет 192.168.1.x. В качестве маски подсети выбрана 255.255.255.0, при этом сеть может содержать 254 компьютера. Этого количества будет достаточно для дома или малого офиса. Переход на маску 255.255.0.0 увеличит количество компьютеров до 64 516.

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

После подтверждения будет создана зона обратного преобразования.

Наконец, нам понадобится запись PTR на нашу подсеть 192.168.1.0.

Здесь необходимо задать полное доменное имя сервера. В нашем случае это будет testserver.testdomain.com.

Лучшим способом проверки правильной настройки DNS являются утилиты nslookup и ping. Поскольку мы планируем выходить и в Интернет, необходимо проинформировать DNS-сервер, как разрешать запросы на другие имена.

Для простоты мы просто ввели IP-адрес нашего DSL-маршрутизатора в качестве DNS forwarder. Наш сервер будет автоматически перенаправлять запросы к серверу DNS провайдера.

10 советов по обеспечению безопасности Active Directory

Сразу скажу, что служба Брандмауэр Windows/Общий доступ к Интернету (ICS) должна быть отключена.

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

Пуск – Программы – Администрирование – Маршрутизация и удаленный доступ (Routing and Remote Access). В контекстном меню выбираем пункт Настроить и включить маршрутизацию и удаленный доступ (Configure and Enable Routing and Remote Access)

Появляется Мастер настройки сервера маршрутизации и удаленного доступа. Этот мастер позволяет вам выбрать различные конфигурации для Routing and Remote Access (RRAS). RRAS может быть настроен как вы захотите, но Microsoft включил несколько шаблонов, чтобы сделать процесс настройки для основных типов установки проще. Но мы выберем Особая конфигурация (Custom configuration)

Выбираем NAT и основной брандмауэр и Маршрутизация ЛВС (NAT and basic firewall и LAN routing)

В конце нажимаем Готово (Finish) на вопрос Хотите запустить службу? (Do you want to start the service?) Нажимаем Да (Yes)

Далее переходим к пункту меню NAT/Простой брандмауэр (NAT/Basic Firewall). Для работы NAT необходимо добавить публичный (подключенный к Интернет) и приватный (локальный) интерфейс. В контекстном меню выбираем Новый интерфейс (New Interface)

В списке интерфейсов выбираем интерфейс, подключенный к Интернету в нашем случае это LAN_1

В появившимся окне, выбираем пункт Общий интерфейс подключен к Интернету (Public interface connected to the Internet) и ставим галочку Включить NAT на данном интерфейсе (Enable NAT on this interface)

Снова идем к пункту меню NAT/Простой брандмауэр (NAT/Basic Firewall), в контекстном меню выберите Новый интерфейс (New Interface). В появившимся окне выберите интерфейс локальной или публичной сети

Оставляем это окно без изменений (по умолчанию выбрано Частный интерфейс подключен к частной сети (Private interface connected to private network)).

Нажимаем OK.

Настройка NAT

Итак, сетевые интерфейсы мы установили, теперь настроим их.

Первым делом давайте настроим Внешний интерфейс (LAN_1):
Нам необходимо настроить адреса и маску. Переходим к пункту меню NAT/Простой брандмауэр (NAT/Basic Firewall). Выбираем контекстное меню LAN_1, идем в Свойства (Prefences). Появится окно с вкладками, выбираем Пул адресов (Address Pool). Далее нужно добавить внешний IP-адрес и маску.


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

Настраиваем клиентскую машину

Производительность Remote Desktop Connection можно регулировать, изменяя опции.

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

Пользователей можно создавать через пункт меню - - . Убедитесь, что вы также добавили права на dial-in для VPN или терминальных служб (или не добавили), а также вписали пользователей в нужные группы.

Создаём общие каталоги

Администраторы всегда могут получить полный доступ к логическим дискам сервера Windows. Обратившись, к примеру, по имени \\testserver\c$ вы получите диск C. Для других же пользователей необходимо создать общие папки с разными разрешениями.

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

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

Доступ к ресурсам сервера

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

Путь вводится как в Windows Explorer.

Готово! Первый сетевой диск успешно привязан к общему каталогу.

Подготовка к установке сервера Exchange 2003

До установки сервера Exchange 2003 должны быть выполнены несколько задач:

1. Необходимо убедиться в доступности сервера глобального каталога (GC). Если сервер Exchange устанавливается в домене с несколькими сайтами AD, то 2. необходимо удостоверится, что у него будет постоянный доступ к GC.
Убедиться, что на сервере, на котором планируется развернуть Exchange, установлены все необходимые компоненты:

.NET Framework
ASP.NET
Internet Information Services (IIS)
World Wide Web Publishing Service
Simple Mail Transfer Protocol (SMTP) service
Network News Transfer Protocol (NNTP) service



Компоненты, необходимые для установки Exchange

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

Используйте локальные учётные записи для запуска служб

Скачайте и прочитайте Руководство по безопасности Windows Server 2003

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

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

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

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