Установка Active Directory

Едем дальше. Следующая остановка - Active Directory.

На данный момент имеем сервер с Windows 2008 с настроенным DNS сервером. Сейчас будем устанавливать туда же службу Active Directory, создадим домен и включим в него клиента и.

Для начала немного теории. Википедия расскажет любому желающему, что "Active Directory — LDAP-совместимая реализация службы каталогов корпорации Microsoft для операционных систем семейства Windows NT." Короче, всё просто: служба каталогов - собрание в кучу всех ресурсов сети (учётки юзеров, ПО, файловые ресурсы, etc) в единой базе, чтобы ими можно было централизованно управлять; доступ к этой самой службе каталогов происходит по протоколу LDAP (устройство которого нам сейчас не важно, так как это совсем другой уровень мастерства).

Добавляем роль серверу. Панель управления > Администрирование > Диспетчер сервера, жмём Добавить роли выбираем Доменные службы Active Directory (так как начинать будем с основ, то все остальные названия, содержащие AD, нам пока не нужны)

Далее, Далее, Установить.

Ну вот. Тут нам предлагают ещё мастер установки доменных служб запустить. Это можно сделать из консоли (dcpromo.exe) или прямо в этом окошке нажать на синюю строчку "Закройте этот мастер и запустите...". Результат один. Вот этот мастер, который должен создать домен и сделать из нашего сервера контроллер домена:

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

Итак, нас просят ввести DNS-имя для корневого домена. Казалось бы у нас уже есть DNS-зона stado.net, наверное надо просто ввести это имя (иначе зачем мы его вообще создавали?). Но нет. Не всё так просто. Домен AD и домен DNS - разные вещи, разницу между которыми надо понимать чётко и ясно.

Домен ДНС - поддерево в области имён ДНС, и как видно из структуры имени, отражает путь к ресурсу. Например, maps.google.ru - ресурс "Карты" в домене Google в зоне RU. Простая иерархия.

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

Домен stado.net, созданный нами ранее, - это домен ДНС. Представим, что мы расчитываем зарегистрировать его и позднее использовать это имя для публикации своих ресурсов (сайт, например) в интернете. С другой стороны домен АД, которым создаём сейчас, будет использоваться только для локальных целей - чтобы управлять нашей внутренней сетью. Понятно, что домен АД и домен ДНС выполняют разные роли, так что объединять всё в кучу не стоит. Опять же не будем забывать о безопасности - ДНС-сервер будет выдавать всю информацию о зоне stado.net всем желающим (чтобы все знали, как попасть на наш сайт). Соответственно ничего лишнего в этой зоне быть не должно, а если мы создадим АД-домен с таким же именем, то все адреса компьютеров нашего АД-домена автоматически будут занесены в зону ДНС и злоумышленник сможет узнать внутреннюю структуру нашей сети, что не есть хорошо. Поэтому настоятельно рекомендуется разделять пространства имён внутренних и имён внешних.

Надеюсь все осилили вышеописанное и поняли, что в Мастере установки доменных служб Active Directory надо задать имя домена отличное от stado.net. Пусть это будет stado.local. Далее. Режим работы - Windows Server 2008 (другие варианты нужны, если бы у нас в сети были серверы AD более ранних версий Винды). Затем нам сообщат, что служба DNS, которая нужна для функционирования AD, у нас-то уже и есть. Замечательно. Потом выскочит окошко, гласящее "Делегирование для этого DNS-сервера не будет создано поскольку полномочная родительская зона не найдена..."

Всё нормально, нет причин для паники. К нам это не относится. Если бы у нас был ДНС-домен domain.ru и мы бы создавали АД-домен с именем ad-domain.domain.ru, то нам бы тогда надо было создавать делегирование прав на этот домен (чтобы разделить имена из ad-domain.domain.ru и domain.ru). Но так как мы создали корневую зону stado.local, выше которой ничего нет, то можно забить на это окошко.

Расположение служебных папок менять не будем. Задаём пароль для восстановления (можно тот же пароль админа). Ребут. Смотрим на экран и видим:

Мы в домене! Запись вида user\domain при логине говорит нам об этом. Наш локальный пользователь Администратор стал теперь администратором домена. Снова стоит оговориться, что теперь на каждом компьютере будет использоваться две базы пользователей - локальная и доменная. Локальная будет храниться (что характерно) локально на компьютере, доменная будет храниться на сервере. На контроллере домена локальных пользователей быть не может. Убедиться можно так: Пуск > Выполнить > control userpasswords2 > OK > Дополнительно > Дополнительно, видим следующее:

Я же говорил.

Теперь заглянем в Свойства системы > Дополнительные параметры системы. Наблюдаем:

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

Ну и раз уж мы решили, что домен stado.net будет у нас только для глобальных ресурсов, то давайте возьмём его в ежовые рукавицы. Идём в настройки ДНС-сервера и в свойствах зоны stado.net (только зоны прямого просмотра) снимаем разрешение на динамические обновления:

Далее разберёмся с зоной обратного просмотра. Мы её создавали из соображений, что ДНС-зона stado.net будет использоваться для локальных нужд. Раз уж это оказалось не так, то и зона обратного просмотра подсети 192.168.100.0/24 должна обслуживать наш домен для локальных нужд stado.local, а не stado.net. Удаляем зону обратного просмотра и создаём заново. На этот раз у нас уже будет галочка "Сохранять зону в AD". Все настройки оставляем по умолчанию. Готово.

Зону stado.net мы пока оставим как есть. Пусть болтается.

Сервер настроен. Можно попробовать добавить клиента. Запускаем нашу машину с Windows XP и снова видим какую-то хрень - не удалось получить адрес от DHCP-сервера. Всё потому что наш свежеустановленный домен Active Directory наложил некоторые ограничения для безопасности. Возвращаемся на сервер в настройки DHCP, жмём на наш сервер (ad.stado.local) и выбираем Авторизовать. После этого всё должно снова заработать.

Но вернёмся к нашим баранам - мы хотели включить клиента в домен AD. Для этого нам нужно включить в домен компьютер и завести в домене пользователя. Заходим на клиенте в Свойства компьютера > Имя компьютера > Изменить, ставим переключатель на Является членом домена, вбиваем stado.local

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

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

Одна проблема - не будем же мы логиниться на клиентский комп под доменным админом. Нам нужен простой доменный пользователь. Создать его можно сервере. Администрирование > Active Directory - Пользователи и компьютеры. Сделаем сначала подразделение, в которое будем кидать наших пользователей. Назовём его СТАДО по имени нашей организации. А в нём уже можно создать и пользователя.

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

И блядский Виндовс снова выставил политики паролей... Меняем опять, хуле. Только теперь уже локальная политика безопасности, которую меняли раньше, не спасёт (собственно она и не активна - зайдите туда в политики учётных записей > политики паролей и попытайтесь что-то изменить, увидите сами, что все переключатели заморожены). Поскольку у нас домен, то и менять надо доменную политику безопасности. Администрирование > Управление групповой политикой, там выбираем наш домен stado.local, жмём на Default domain policy > Изменить

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

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

C:\Users\Администратор>gpupdate
Обновление политики...

Обновление политики пользователя завершено успешно.
Обновление политики для компьютера успешно завершено.

Теперь снова можно делать простые пароли.

После этого создадим ещё несколько пользователей, чтобы потом было с чем поиграться:

• бухгалтер маша (логин - buh-m)
• менеджер степан (man-s)
• менеджер даша (man-d)
• гендиректор (gendir)

Ну вот. Теперь мы можем зайти на клиентский компьютер под любой из этих учёток. Можете сами попробовать, если не верите. И напоследок:

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

Длинная получилась статья... Но надеюсь, что не бесполезная.

FIN