Как сделать сервер основным контроллером домена. Повышение сервера до контроллера домена

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

Итак, поднимаем домен на Windows Server 2008 r2 sp1. Всё standalone, новый лес. Заодно и DNS прикрутим.

Исходная позиция - установленный Windows Server 2008 r2 Standart with sp1. Втыкаем все необходимые обновления.

Пуск - Командная строка (win+r => cmd), запуск от имени администратора.
Вбиваем dcpromo.exe.
Запускается утилита dcpromo.
Поехали.

Нас приветствует мастер установки доменных служб AD и бла-бла-бла.

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

Вводим полное доменное имя.
Обычно стандартно оно будет вида DOMENNAME.local или DOMENNAME.lan, но в зависимости от вашей фантазии можете хоть DOMENNAME.mur. Единственное что не рекомендуется использовать имена типа DOMENNAME.com (т.е. игнорируем приведённый пример с com), так как имена вроде com, ru, org и т.п. реально существующие в интернете домены первого уровня. Если, конечно, вы не их владелец. Хотя если вы читаете этот текст. вы явно не владелец домена первого уровня.
Также учтите, что даже если вы создаете новый лес, а имя совпадает с именем чего-то уже существующего в вашей инфраструктуре, волшебства не получится. Имена должны быть уникальными.
Далее.

Выбираем режим работы леса. Для данной задачи это будет windows server 2008 r2.
Если вам необходимо в дальнейшем добавлять в свежесозданный лес контроллеры домена ниже 2008 r2, режим работы леса надо выбирать соответствующее. Короче говоря, будущие контроллеры домена должны быть не ниже режима работы леса.
Далее.

Выбираем дополнительные параметры контроллера домена. Я выбираю DNS, т.к. вся новая структура будет отдельно стоящая.
Далее.

Выбираем расположение для баз данных. Это уже по своему усмотрению и религиозным соображениям.
Далее.

Задаём пароль для учетной записи администратора домена. После этого действия учетная запись локального администратора больше не действует.
Далее.

Смотрим сводку. Убеждаемся, что всё в порядке.
Далее.

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

Куищще (reboot).

Домен создан, остаётся только настроить.

Настраиваем DNS (при условии, что мы проигнорировали эту возможность в dcpromo).

Пуск - администрирование - диспетчер DNS.

В открывшемся окне кликаем правой мышкой по имени нашего сервера и выбираем пункт "Настроить DNS-сервер".

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

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

Создать зону прямого просмотра сейчас? Да, создаём.
Далее.

Выбираем тип зоны. Так как мы уже определились с тем, что мы standalone, выбираем создание основной зоны. Мы контроллер домена, в связи с этим оставляем галку на сохранение зоны в AD.
Далее.

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

Динамические обновления. Я выставляю "разрешать только безопасные динамические обновления".
Далее.

Имя зоны обратного просмотра. Я старательно уверяю себя, что ipv6 не существует и выбираю ipv4.
Далее.

Мастер создания новой зоны. Выбираем идентификатор сети, логично что это первые три октета.
Далее.

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

серверы пересылки. Мы standalone, не знаем ничего и никого, посему - "Нет, не пересылать запросы".
Далее.

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

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

Они подразделяются по области действия:

  • универсальные группы могут включать в себя пользователей в рамках леса, а также другие универсальные группы или глобальные группы любого домена в лесу;
  • глобальные группы домена могут включать в себя пользователей домена и другие глобальные группы этого же домена;
  • локальные группы домена используются для разграничения прав доступа, могут включать в себя пользователей домена, а также универсальные группы и глобальные группы любого домена в лесу;
  • локальные группы компьютеров – группы, которые содержит SAM (security account manager) локальной машины. Область их распространения ограничивается только данной машиной, но они могут включать в себя локальные группы домена, в котором находится компьютер, а также универсальные и глобальные группы своего домена или другого, которому они доверяют. Например, вы можете включить пользователя из доменной локальной группы Users в группу Administrators локальной машины, тем самым дав ему права администратора, но только для этого компьютера.

Сайты

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

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

Такое разбиение AD не влияет на принципы логического построения, поэтому как сайт может содержать в себе несколько доменов, так и наоборот, домен может содержать несколько сайтов. Но такая топология службы каталогов таит в себе подвох. Как правило, для связи с филиалами используется Интернет – очень небезопасная среда. Многие компании используют средства защиты, например, брандмауэры. Служба каталогов в своей работе использует около полутора десятков портов и служб, открытие которых для прохождения трафика AD через брандмауэр, фактически выставит ее «наружу». Решением проблемы является использование технологии туннелирования, а также наличие в каждом сайте контроллера домена для ускорения обработки запросов клиентов AD.

Сущность службы каталогов

Чтобы обеспечить некоторый уровень безопасности, любая операционная система должна иметь файлы, содержащие базу данных пользователей. В ранних версиях Windows NT для этого использовался файл SAM (Security Accounts Manager – менеджер учетных записей). Он содержал учетные данные пользователей и был зашифрован. Сегодня SAM также используется в операционных системах семейства NT 5 (Windows 2000 и выше).

Когда вы повышаете роль рядового сервера до контроллера домена с помощью команды DCPROMO (фактически она запускает мастер установки службы каталогов), подсистема безопасности Windows Server 2000/2003 начинает использовать централизованную базу данных AD. Это можно легко проверить – попробуйте после создания домена открыть на контроллере оснастку Computer Management и найти там «Локальные пользователи и группы». Более того, попробуйте войти на этот сервер под локальной учетной записью. Вряд ли у вас получится.

Большинство данных пользователей сохраняются в файле NTDS.DIT (Directory Information Tree – дерево информации каталога). NTDS.DIT – это модифицированная база данных. Она создана с использованием той же технологии, что и база данных Microsoft Access. Алгоритмы работы контроллеров домена содержат вариант движка JET базы данных Access, который был назван ESE (Extensible Storage Engine – расширяемый движок хранения информации). NTDS.DIT и службы, обеспечивающие взаимодействие с этим файлом, фактически и есть служба каталогов.

Структура взаимодействия клиентов AD и основного хранилища данных, аналогично как и пространство имен службы каталогов, представлены в статье . Для полноты описания нужно упомянуть об использовании глобальных идентификаторов. Глобальный уникальный идентификатор (Global Unique Identifier, GUID) – это 128-разрядное число, сопоставляемое каждому объекту при его создании для обеспечения уникальности. Имя объекта AD можно изменить, а вот GUID останется неизменным.

Глобальный каталог

Наверняка вы успели заметить, что структура AD может быть весьма сложной и вмещать в себя большое количество объектов. Чего стоит только тот факт, что домен AD может включать в себя до 1,5 млн. объектов. Но из-за этого могут возникнуть проблемы с производительностью при выполнении операций. Эта проблема решается с помощью Глобального каталога ( , ). Он содержит сокращенную версию всего леса AD, что помогает ускорять поиск объектов. Владельцем глобального каталога могут выступать специально назначенные для этого контроллеры домена.

Роли

В AD существует определенный перечень операций, выполнение которых можно возложить только на один контроллер. Они называются ролями FSMO (Flexible Single-Master Operations – операции с одним хозяином) . Всего в AD 5 ролей FSMO. Рассмотрим их более подробно.

В рамках леса обязательно должна существовать гарантия уникальности доменных имен при добавлении нового домена к лесу доменов. Такая гарантия осуществляется исполнителем роли владельца операции именования доменов (Domain Naming Master ) Исполнитель роли владельца схемы (Schema Master ) осуществляет все изменения в схеме каталога. Исполнители ролей владельца доменных имен и владельца схемы должны быть уникальны в рамках леса доменов.

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

В отличие от доменов NT в AD нет понятия PDC и BDC (основной и резервный контроллеры домена). Одной из ролей FSMO является PDC Emulator (эмулятор основного контроллера домена). Сервер под управлением Windows NT Server может выступать в роли резервного контроллера домена в AD. Но известно, что в доменах NT может использоваться только один основной контроллер. Именно поэтому Microsoft сделала так, что в рамках одного домена AD мы можем назначить единственный сервер – носитель роли PDC Emulator. Таким образом, отступая от терминологии, можно говорить о наличии главного и резервных контроллеров домена, имея в виду обладателя роли FSMO.

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

Последние три роли требуют уникальности исполнителя в рамках домена. Все роли возлагаются на первый контроллер, созданный в лесу. При создании разветвленной инфраструктуры AD вы можете передавать эти роли другим контроллерам. Могут возникать также ситуации, когда владелец одной из ролей недоступен (вышел из строя сервер). В этом случае необходимо выполнить операцию захвата роли FSMO с помощью утилиты NTDSUTIL (о ее использовании мы поговорим в следующих статьях). Но стоит быть осторожным, так как при захвате роли служба каталогов полагает, что предыдущего владельца нет, и не обращается к нему вовсе. Возвращение в сеть прежнего исполнителя роли может привести к нарушению ее функционирования. Особенно это критично для владельца схемы, владельца доменных имен и владельца идентификаторов.

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

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

Как руководство по установке AD могу посоветовать использовать статьи и , а также базу знаний Microsoft.


Напоследок несколько советов:

  • Постарайтесь по возможности не совмещать роли PDC Emulator и прокси-сервера на одной машине. Во-первых, при большом количестве машин в сети и пользователей Интернет возрастает нагрузка на сервер, а во-вторых, при удачной атаке на ваш прокси «упадет» не только Интернет, но и основной контроллер домена, а это чревато некорректной работой всей сети.
  • Если вы постоянно администрируете локальную сеть, а не собираетесь заняться внедрением Active Directory для заказчиков, вносите машины в домен постепенно, скажем, по четыре-пять в день. Поскольку если у вас в сети большое количество машин (50 и больше) и вы управляете ею один, то вряд ли вы управитесь даже за выходные, а если и управитесь, то насколько все будет корректно, неизвестно. К тому же для обмена документацией внутри сети вы можете использовать файловый или внутренний почтовый сервер (такой был описан мной в №11 за 2006 г.). Единственное, в этом случае стоит корректно разобраться в настройке прав пользователей для доступа к файловому серверу. Потому что, если, например, он не будет включен в домен, аутентификация пользователей будет осуществляться, основываясь на записях локальной базы SAM. Там нет данных о доменных пользователях. Однако если ваш файловый сервер будет в числе первых машин, включенных в AD, и не будет контроллером домена, то будет существовать возможность аутентификации посредством как локальной базы SAM, так и учетной базы AD. Но для последнего варианта вам нужно будет в локальных настройках безопасности разрешить (если это еще не сделано) доступ к файловому серверу по сети как участникам домена, так и локальным учетным записям.

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

Приложение

Новшества Active Directory в Windows Server 2003

С выходом Windows Server 2003 в Active Directory появились следующие изменения:

  • Стало возможным переименование домена после его создания.
  • Улучшился пользовательский интерфейс управления. Например, можно изменить атрибуты сразу нескольких объектов.
  • Появилось хорошее средство управления групповыми политиками – Group Policy Management Console (gpmc.msc, ее нужно скачивать с сайта Microsoft).
  • Изменились функциональные уровни домена и леса.

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

  • Windows 2000 Mixed (смешанный Windows 2000). В нем допускается иметь контроллеры различных версий – как Windows NT, так и Windows 2000/2003. Причем если серверы Windows 2000/2003 равноправны, то сервер NT, как уже говорилось, может выступать только резервным контроллером домена.
  • Windows 2000 Native (естественный Windows 2000). Допускается иметь контроллеры под управлением Windows Server 2000/2003. Этот уровень более функционален, но имеет свои ограничения. Например, вы не сможете переименовывать контроллеры доменов.
  • Windows Server 2003 Interim (промежуточный Windows Server 2003). Допускается иметь контроллеры под управлением Windows NT, а также Windows Server 2003. Используется, например, когда главный контроллер домена под управлением сервера Windows NT обновляется до W2K3. Уровень имеет чуть большую функциональность, чем уровень Windows 2000 Native.
  • Windows Server 2003. Допускается наличие в домене контроллеров только под управлением Windows Server 2003. На этом уровне можно воспользоваться всеми возможностями службы каталогов Windows Server 2003.

Функциональные уровни леса доменов практически те же, что и для доменов. Единственное исключение – существует только один уровень Windows 2000, на котором возможно использование в лесу контроллеров под управлением Windows NT, а также Windows Server 2000/2003.

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


1. Коробко И. Active Directory – теория построения. //«Системный администратор», №1, 2004 г. – C. 90-94. (http://www.samag.ru/cgi-bin/go.pl?q=articles;n=01.2004;a=11).

2. Марков Р. Домены Windows 2000/2003 – отказываемся от рабочей группы. //«Системный администратор», №9, 2005 г. – C. 8-11. (http://www.samag.ru/cgi-bin/go.pl?q=articles;n=09.2005; a=01).

3. Марков Р. Установка и настройка Windows 2К Server. //«Системный администратор», №10, 2004 г. – C. 88-94. (http://www.samag.ru/cgi-bin/go.pl? q=articles;n=10.2004;a=12).

Александр Емельянов

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

Из этой статьи вы узнаете:

Планирование установки Active Directory в разных подсетях

Итак, у нас имеется две подсети 10.1.3.0/24 и 10.1.4.0/24 , в каждой из которых некоторое количество компьютеров и сетевых шар. Нужно объединить все это в один домен. Сети соединены между собой vpn тоннелем, компьютеры пингуют друг друга в обе стороны, проблем с сетевым доступом нет.

Для нормальной работы службы Active Directory установим в каждой подсети по контроллеру домена и настроим репликацию между ними. Использовать будем Windows Server 2012R2. Последовательность действий следующая:

  • Устанавливаем контроллер домена в одной подсети, поднимаем на нем новый домен в новом лесу
  • Устанавливаем контроллер домена во второй подсети и добавляем его в домен
  • Настраиваем между доменами репликацию

Первый контроллер домена будет называться xs-winsrv с адресом 10.1.3.4 , второй — xm-winsrv 10.1.4.6 . Домен, который мы будем создавать будет называться xs.local

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

Первым делом устанавливаем контроллер домена в новом лесу на первом сервере xs-winsrv . Подробно останавливаться на этом я не буду, в интернете много обучалок и инструкций на эту тему. Все делаем стандартно, ставим AD, DHCP и DNS службы. В качестве первого DNS сервера указываем локальный ip адрес, в качестве второго 127.0.0.1 :

Дальше устанавливаем Windows Server 2012R2 на второй сервер xm-winsrv . Теперь делаем несколько важных шагов, без которых добавить второй сервер в домен не получится. Оба сервера должны по имени пинговать друг друга. Для этого в файлы C:\Windows\System32\drivers\etc\host добавляем записи друг о друге.

В xs-winsrv добавляем строку:

10.1.4.6 xm-winsrv

В xm-winsrv добавляем:

10.1.3.4 xs-winsrv

Теперь второй важный момент. На сервере xm-winsrv указываем в качестве первого DNS сервера первый контроллер домена 10.1.3.4:

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

После этого сервер xs-winsrv нужно перенести из сайта Default-First-Site-Name в новый созданный для него сайт. Теперь все готово для добавления второго сервера в домен.

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

Идем на второй сервер xm-winsrv, запускаем мастер добавления ролей и добавляем так же как и на первом сервере 3 роли — AD, DNS, DHCP. Когда будет запущен Мастер настройки доменных служб Active Directory, выбираем там первый пункт — Добавить контроллер домена в существующий домен , указываем наш домен xs.local :

На следующем шаге в параметрах контроллера домена указываем имя сайта, к которому мы присоединим контроллер:

Напомню, что это должен быть сайт, к которому привязана подсеть 10.1.4.0/24. Первый и второй контроллеры оказываются в разных сайтах. Не забываем поставить галочку Глобальный каталог (GC) . Дальше все настройки оставляем по-умолчанию.

После перезагрузки сервера, он окажется в домене xs.local . Зайти под локальным администратором не получится, нужно использовать доменную учетную запись. Заходим, проверяем прошла ли репликация с основным контроллером домена, синхронизировались ли записи DNS. У меня все это прошло благополучно, всех пользователей и записи DNS второй контроллер домена забрал с первого. На обоих серверах в оснастке Active-Directory — сайты и службы отображаются оба контроллера, каждый в своем сайте:

На этом все. Можно добавлять компьютеры в обоих офисах в домен.

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

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

Онлайн курс "Администратор Linux"

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «Администратор Linux» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров. Проверьте себя на вступительном тесте и смотрите программу детальнее по.

Прошло много времени с того момента, когда я писал одну из статей «старой школы», которая начинается с самого начала и не предполагает, что вы уже являетесь профессионалами в области Windows Server. За последние несколько лет я написал сотни статей о тайнах компьютерных технологий Windows. В большинстве этих статей я многое принимал как должное относительно того, что, на мой взгляд, вы уже знали. Я писал эти статьи, потому что были определенные сложности, трудные в настройке функции и прочие проблемы, которые я хотел продемонстрировать вам. Хотя все это было интересно небольшому количеству людей, эти статьи как бы оставляли всех остальных за пределами своих границ.

Давным-давно этот сайт назывался «Мир сетей Windows» (‘World of Windows Networking’ или WOWN). В те времена сайт был наполнен множеством статей, которые повествовали о том, как выполнять общие сетевые задачи Windows. Тогда в этих статьях содержалось гораздо меньше информации о Active Directory, групповых политиках, установке и прочих не сетевых трудностях. И хотя на сегодняшний день сайт повзрослел и больше нацелен на опытных специалистов ИТ, есть определенная ценность в предоставлении контента для начинающих в этой области и для тех, кто хочет узнать некоторые основы.

Все это заставило меня задуматься о написании статьи или, возможно, цикла статей, которые бы содержали информацию с самого начала. И самым лучшим моментом написания этой статьи стал недавний выход Windows Server 2008 R2. Поэтому я решил написать базовую статью «Давайте установим Windows Server 2008 R2», но потом я подумал об этой статье, как «об отправной точке написания более широкого цикла статей». Чем больше я думал об этом, тем больше мне это нравилось. Поскольку в Windows Server 2008 R2 содержится масса новых функций и возможностей для работы с сетью и безопасностью, почему не начать с создания тестовой сети, затем провести вас через все эти удивительные функции? Таким образом, мы будем работать с основами сети и пройдем этот долгий путь вместе.

Итак, давайте начнем. Первым шагом будет выбор ПО виртуализации. Для данного типа тестовой сети я предпочел VMware Workstation. У меня нет серьезных технических причин в обосновании своего предпочтения в пользу VMware Workstation, я просто предпочитаю использовать эту программу, поскольку работал с ней на протяжении почти десяти лет, и отлично знаю принцип ее работы. Мне не нужно изучать новый язык, как пришлось в случае с Hyper-V, и это приложение, на мой взгляд, отлично работает. Однако если вы хотите использовать Hyper-V или ESX, это тоже хорошие варианты.

По мере написания цикла мы будем использовать до 8 виртуальных машин одновременно. По этой причине я рекомендую использовать компьютер как минимум с 8 ГБ оперативной памяти и с четырехядерным процессором. На протяжении всего цикла я буду использовать рабочую станцию с 12 ГБ памяти DDR3 с тройным каналом и четырехядерный процессор Core i7. Если вы используете любой четырехядерный процессор семейства Xeon или Core 2, этого будет вполне достаточно. Конечно, эквиваленты AMD тоже отлично подойдут.

Мы начнем с установки первой машины в нашей тестовой сети. Это будет машина Windows Server 2008 R2, использующая один виртуальный процессор и 512 МБ виртуальной памяти. Во время установки я собираюсь использовать сетевое подключение в режиме моста на своей виртуальной сетевой карте. Некоторые предпочитают использовать NAT, и это тоже нормально. Суть в том, что вам потребуется подключение к рабочей сети, чтобы иметь доступ к обновлениям во время изначальной установки. По завершении изначальной установки, мы переведем эту виртуальную машину в другую виртуальную сеть, поскольку нам нужно будет расположить ее за виртуальным брандмауэром TMG. Виртуальная машина брандмауэра TMG будет иметь подключение к физической сети, а все остальные виртуальные машины (VM) будут расположены за брандмауэром.

В VMware Workstation 6.5 я создам новую виртуальную машину и свяжу Windows Server 2008 R2 .iso файл с приводом CD, чтобы он загрузил этот образ.iso. Во время первого запуска машины вы увидите первую страницу мастера установки, на которой нужно будет определить языковые параметры , формат времени и валюты и способ ввода через клавиатуру или другое устройство .

Итак, вводная часть завершена! Установщик дает вам возможность Установить сейчас (Install now) . Давайте так и сделаем.

Файл.iso содержит все версии Windows Server 2008 R2, и здесь мы можем выбрать версию, которую хотим установить. Обратите внимание, что можно даже установить версии Server Core. Но мы не будем устанавливать версию ядра сервера. Давайте выберем опцию Windows Server 2008 R2 Enterprise (полная установка (Full Installation)) и нажмем Далее .

Ставим галочку напротив опции Я принимаю условия лицензионного соглашения на странице лицензионного соглашения и нажимаем Далее .

Какой тип установки вы предпочитаете? Честно говоря, я предпочитаю такой тип установки, который работает и делает то, что я ему говорю, но здесь нет такого варианта. Это чистая установка, поэтому опции обновления не имеют смысла. Нажимаем на опцию Выборочная (расширенная) - Custom (advanced) . Обратите внимание, что на этой странице нет кнопки ‘Далее’.

Здесь вы определяете, куда установить системные файлы (которые раньше назывались загрузочными файлами, но новая команда конструкторов Microsoft не проходила курсы по Windows NT 4 MCSE, поэтому они не знают, что в системах на базе Windows NT и более ранних версий вы загружаете системные файлы и «систематизируете» загрузочные файлы). Я создал динамический виртуальный жесткий диск размером 24 ГБ для ОС, и этого места будет более чем достаточно. Помните, что файлы динамических виртуальных жестких дисков занимают только нужное им место, они не занимают все место, выделенное под них, пока этого не требует конфигурация.

Ура! Установка началась, и она займет много времени. Вы можете оставить свой компьютер на час или два, а затем прийти и посмотреть, что получилось.

Во время первого входа в систему установщик попросит вас создать пароль. Нажмите OK , когда видите изображение, как показано ниже.

Рисунок 8

Введите пароль и подтверждение, но не нажимайте OK (поскольку здесь нет кнопки OK). Вместо этого нажмите на значок стрелки, который не имеет названия, и который расположен справа от текстового поля с подтверждением пароля.

Рисунок 9

Очень хорошо! Пароль был изменен. Нажмите OK .

Рисунок 10

Вы, возможно, помните страницы Задач первоначальной настройки (Initial Configuration Tasks) , если использовали Windows Server 2008. Если вы не использовали Windows Server 2008, и сразу перешли от использования Windows Server 2003, то страница задач первоначальной конфигурации предоставляет вам доступ ко многим вещам, которые нужно сделать после установки файлов операционной системы. После просмотра этой страницы вы заметите, что многие опции, которые настраивались во время процесса установки в предыдущих версиях, теперь настраиваются здесь. Целью было обеспечить минимум вводимых данных во время установки ОС, и оставить все настройки на самый конец. Очень удобно!

Рисунок 11

На странице Initial Configuration Tasks я установлю следующее:

    Часовой пояс

    Настройки сети

    Имя компьютера и домен

Остальные настройки я выполню после того, как определю IP адрес в сети для этой машины. Я назову этот компьютер FFWIN2008R2DC , поскольку это будет контроллер домена в моем домене FFLAB . FF – это сокращение от ‘Forefront’, поскольку мы будем выполнять множество тестов Forefront в этой тесовой сети. Информация IP адресации будет следующей:

    IP адрес ‘ 10.0.0.2

    Основной шлюз ‘ 10.0.0.1

    DNS ‘ 10.0.0.2

    WINS ‘ 10.0.0.2

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

Делаем виртуальную машину Windows Server 2008 R2 контроллером домена

Далее нам нужно сделать эту машину контроллером домена. Если вы пришли из мира Windows Server 2003, вы заметите значительную разницу в этом шаге. Да, нам все еще нужно запустить dcpromo из команды Выполнить , но здесь есть небольшое изменение ‘ вам также нужно установить роль Active Directory Domain Controller . Роли сервера являются довольно новым явлением в Windows Server 2008, где основные службы считаются «ролями». Роль контроллера домена Active Directory Domain Controller немного отличается, поскольку для установки этой роли требуется процесс из двух шагов: сначала вы устанавливаете роль, а затем запускаете dcpromo .

Входим в Диспетчер сервера (Server Manager) и переходим в узел Роли (Roles) в левой панели консоли. Затем нажимаем Добавить роли (Add Roles) в правой панели.

Рисунок 12

У нас откроется страница Before You Begin . Если вы впервые устанавливаете роли с помощью диспетчера сервера, то вам нужно прочитать информацию на этой странице. Если вы уже давно работаете с диспетчером сервера, то можете пропустить эту страницу и нажать Далее .

Рисунок 13

Здесь вы выбираете роли сервера для установки. Мы установим другие роли сервера позже, но сначала нам нужно установить роль контроллера домена (DC). Выбираем Active Directory Domain Services , отмечая соответствующую опцию. Обратите внимание, что мастер отобразит вам ряд функций, которые будут установлены наряду с ролью Active Directory Server Role. Нажмите кнопку Добавить нужные функции (Add Required Features) , чтобы установить эти функции во время установки роли Active Directory Server.

Рисунок 14

После выбора роли Active Directory DC Server, вы увидите информацию об этой роли сервера. Здесь есть некоторые интересные моменты:

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

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

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

    Обратите внимание, что во время установки роли Active Directory Domain Services также устанавливаются службы DFS пространства имен, DFS репликации и репликации файлов ‘ все эти службы используются службами Active Directory Domain Services, поэтому устанавливаются автоматически.

Рисунок 15

Нажмите Установить для установки файлов, необходимых для запуска dcpromo .

Рисунок 16

Ура! Установка прошла успешно. Нажимаем Закрыть .

Рисунок 17

Теперь переходим в меню Пуск и вводим dcpromo в текстовом поле Выполнить. Вы найдете его в списке, как показано на рисунке ниже. Нажимаем dcpromo .

Рисунок 18

В результате у нас запустится мастер Welcome to the Active Directory Domain Service Installation Wizard . Нам не нужны расширенные опции в этом сценарии, поэтому просто нажимаем Далее .

Рисунок 19

На странице Совместимость операционной системы (Operating System Compatibility) мастер предупреждает о том, что ваши NT и non-Microsoft SMB клиенты будут испытывать проблемы с некоторыми криптографическими алгоритмами, используемыми в Windows Server 2008 R2. У нас нет таких проблем в нашей тестовой среде, поэтому просто нажимаем Далее .

Рисунок 20

На странице Выбор конфигурации установки (Choose a Deployment Configuration) выбираем опцию Создание нового домена в лесу (Create a new domain in a new forest) . Мы делаем это по той простой причине, что это новый домен в новом лесу:)

Рисунок 21

На странице Имя корневого домена в лесу (Name the Forest Root Domain) мы вводим название домена в текстовое поле FQDN корневого домена в лесу . В этом примере мы назовем домен fflab.net . Это сокращенно от ‘Forefront Lab’. Вы можете назвать свой домен, как вам нравится, но если вы используете имя, которые уже используется в интернете (имя, которое уже было зарегистрировано), то у вас могут возникнуть проблемы раздвоения имен. Нажимаем Далее.

Рисунок 22

На странице Определение функционального уровня леса (Set Forest Functional Level) выбираем опцию Windows Server 2008 R2 (а не опцию Windows Server 2003, которая показана на рисунке ниже). Мы выбираем опцию Windows Server 2008 R2, чтобы воспользоваться всеми новыми удивительными возможностями, включенными в Windows Server 2008 R2. Нажимаем Далее .

Рисунок 23

На странице Дополнительные опции контроллера домена (Additional Domain Controller Options) у нас есть единственный выбор: DNS сервер . Опция глобального каталога выбрана и не является опцией по выбору, так как пока что это единственный DC в этом домене, поэтому он должен быть сервером глобального каталога. Опция контроллера домена с разрешением только чтения (Read-only domain controller - RODC) не отмечена, поскольку необходимо иметь другой не-RODC в сети, чтобы включить эту опцию. Выбираем опцию DNS сервер и нажимаем Далее .

Рисунок 24

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

Рисунок 25

Оставляем папки для Database, Log Files и SYSVOL на своих местах по умолчанию и нажимаем Далее .

Рисунок 26

На странице Directory Service Restore Mode Administrator Password вводим надежный пароль в текстовые поля Пароль (Password) и Подтверждение (Confirm password) .

Рисунок 27

Проверяем информацию на странице Summary и нажимаем Далее .

Рисунок 28

Установится Active Directory. Установка первого DC занимает немного времени. Отметьте опцию Перезагрузить по окончании (Reboot on completion) , чтобы машина автоматически перезагрузилась после установки DC.

Рисунок 29

Машина автоматически перезагрузится, поскольку мы выбрали эту опцию. Установка будет завершена после того, как вы войдете в систему. Если я правильно помню, в Windows Server 2008 были дополнительные настройки, которые нужно было сделать после перезагрузки и входа в систему, но в Windows Server 2008 R2 этого уже нет.

Служба DNS была установлена во время установки Active Directory, поэтому нам не нужно об этом беспокоиться. Есть еще несколько служб, которые нам нужно установить на этот контроллер домена. К ним относятся следующие:

  • Enterprise Certificate Services

К сожалению, только DHCP и Certificate Services считаются «ролями». Служба WINS считается функцией. Полагаю, у разработчиков были на то свои причины, но я не присутствовал на собрании и не знаю, почему это так.

сталь, норка, говядина, бумага 5 января 2011 в 01:22

Установка контроллера домена Active Directory в Windows Server 2008 R2 для начинающих

  • Чулан *

Я всех приветствую и предлагаю вашему вниманию эту статью. Надеюсь, что она будет полезна начинающим системным администраторам Windows. Мы познакомимся с основами Active Directory и поднимем контроллер домена.

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

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

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

После этого перейдем к назначению роли:

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

Поскольку это первый и единственный DNS-сервер у нас в сети, мы создадим основную зону.

Далее нам нужно указать имя зоны. Я использовал testnet.local, хотя сейчас рекомендуется не использовать несуществующих доменных имен первого уровня даже для приватных сетей. Но в нашем примере это несущественно.

Нам нужно разрешить динамические обновления для успешной работы домена.
Нажав далее и прочитав сообщение об успешном завершении мы продолжим настройку.
Впишем полное доменное имя для нашего сервера и почтовый адрес для связи с ответственным лицом (обратите внимание на важность наличия точки в конце – корня. Также вместо значка @ используется точка.)

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

И пропишем наш сервер:

Всё. Настройка зоны прямого просмотра завершена.

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

Укажем идентификатор сети:

Обратите внимание на имя зоны: октеты нашей сети записаны справа налево. Так и должно быть.
Создаем новый файл, разрешаем динамические обновления и жмем «Готово». Дальнейшая донастройка полностью идентична манипуляциям, проделанным для зоны прямого просмотра. Запись типа A в основной зоне для нашего сервера есть, так что воспользуемся этим для создания PTR-записи автоматически здесь:

Настройка нашего DNS-сервера завершена.

Установка контроллера домена

Теперь установим роль контроллера домена Active Directory. Для этого нужно выполнить команду dcpromo.

Последует запуск мастера:

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

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

У нас уже есть настроенный сервер DNS и мы создадим делегирование, указав логин и пароль администраторской учетной записи.

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

Теги: системное администрирование