Удаление авторизованных DHCP серверов в среде Active Directory.

Начинаем

Вы установили Windows Server 2022 и (надеюсь) видите следующий экран:

Эта панель — основное (графическое) средство администрирования Windows Server 2022. Здесь вы можете управлять компонентами и сервисами на вашем сервере (проще говоря, настраивать то, что умеет делать сервер). Эту же панель можно использовать и для базовых сетевых настроек Windows Server, для чего есть вкладка “Локальный сервер”.

Первое, что нужно сделать — это поменять сетевое имя сервера.

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

Проблема в том, что по-умолчанию для Windows Server генерируется совершенно нечитаемое и неинформативное сетевое имя (я выделил его красным цветом на скриншоте).

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

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

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

Начинаем удалять авторизованные сервера

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

Что такое active directory

Active Directory — это службы каталогов от компании Microsoft, как подсказывает нам Википедия. За этим сухим и невзрачным определением скрывается одна из важнейших технологий в администрировании сетей. Благодаря Active Directory администратор сети получает очень удобное централизованное средство управления учетными записями пользователей, групповыми политиками (в т.ч. политиками безопасности) и объектами в сети (причём Active Directory без особых проблем справляется даже с гигантскими сетями).

А благодаря встроенному механизму репликации, “положить” правильно настроенные сервисы AD не так-то просто. Ну и напоследок, благодаря Windows настроить Active Directory можно буквально мышкой, так что даже совсем начинающие IT-шники смогут с этим справиться.

Несмотря на то, что технологией заведует Microsoft, она вовсе не ограничивается управлением Windows-машин — все известные Linux-дистрибутивы уже давным давно научились работать с этой технологией. Повстречаться с Active Directory не просто, а очень просто — практически каждый офис предполагает наличие этой технологии, поэтому даже самым заядлым линуксоидам было бы неплохо разбираться в азах работы Active Directory.

Что если сервер появился в сети после деавторизации?

Но что делать, если сервер появился в сети после того, как он был удален из конфигурации Active Directory? Например, если он был восстановлен из бекапа и мы планируем снова ввести его в эксплуатацию?

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

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

Удаление авторизованных DHCP серверов в среде Active Directory.
Выполняем деавторизацию через оснастку DHCP.

Похоже, что мы столкнулись с проблемой.

Удаление авторизованных DHCP серверов в среде Active Directory.
Возникает ошибка «The parameter is incorrect» при выполнении операции деавторизации сервера, сведения об авторизации которого уже были удалены.

Для решения проблемы нам потребуется ввести в командной строке:

NETSH DHCP add server <FQDN> <IP>
Удаление авторизованных DHCP серверов в среде Active Directory.
Теперь сведения об авторизованных серверах DHCP в Active Directory актуальны и только что добавленный хост появится в меню «Управление авторизованными серверами» оснастки DHCP.

Почему такой стенд?

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

Туториал предполагает подробный разбор всех шагов по настройке, с пояснениями “что, зачем и почему”. Туториал ориентирован на людей, не слишком знакомых с технологиями Active Directory, DNS и DHCP, которые хотели бы немного узнать о внутренней кухне администрирования сетей с Active Directory.

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

Что такое авторизация dhcp и зачем это нужно?

Перед тем, как перейти к конкретным действиям, предлагаю немного уделить время теории и проблематике. Начнем с того, что мы попробуем понять что это такое — Авторизация DHCP сервера. Для получения сведений по этому вопросу предлагаю, для начала, обратиться к документации Microsoft:

If you are installing DHCP in a domain environment, you must perform the following steps to authorize the DHCP server to operate in the domain.Unauthorized DHCP servers that are installed in Active Directory domains cannot function properly, and do not lease IP addresses to DHCP clients.

Dhcp сервер доступен

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

Dhcp сервер недоступен

В случае если хост недоступен, нам также доступны несколько вариантов:

Dhcp-сервер

Протокол DHCP (Dynamic Host Configuration Protocol) нужен для автоматической выдачи сетевых настроек узлам в сети. Под сетевыми настройками понимается IP-адрес, адрес шлюза по-умолчанию, адрес DNS-сервера, и ещё ряд других настроек. Этот протокол чрезвычайно удобен при администрировании сетей, особенно больших.

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

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

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

Что ж, довольно теории, давайте лучше перейдём к включению этих самых ролей.

Dns-сервер

Обычно протокол DNS (Domain Name System) используется для обращения к узлам в сети не по их IP-адресу, а по доменному имени (строковый идентификатор), что, конечно, гораздо удобнее. Другими словами, DNS чаще всего используется для разрешения доменных имен.

Похожее:  Установка и настройка FreeIPA - IT Pro Blog

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

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

Все DNS-записи (в том числе с информацией о сервисах Active Directory) хранятся на DNS-сервере, а это значит, что нам нужно заиметь свой собственный DNS-сервер! Вот только вопрос, откуда его взять? Есть два варианта:

  1. Использовать отдельную машину в роли DNS-сервера;
  2. Использовать саму машину windows_server в роли DNS-сервера.

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

Именно поэтому эту роль (DNS-сервера) тоже нужно добавить к ролям машины windows_server.

Кстати, если не добавить роль “DNS-сервер” сейчас, то в будущем у вас ещё будет такая возможность при конфигурировании контроллера домена AD.

Автоматизируем

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

Так почему бы не автоматизировать все действия с клавиатурой и мышкой, которые мы предпринимали? И нет, я говорю не об AutoIT, я говорю о платформе Testo, создателем которой я являюсь. Эта платформа позволяет фиксировать все действия, проводимые с виртуальными машинами, в виде скриптов на специальном языке Testo-lang. Ну а Testo затем превратит эти скрипты обратно в действия.

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

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

Всё, что Вам потребуется для создания собственного стенда с настроенной Active Directory — это:

  1. Установочный iso-образ Windows Server 2022 русской версии;
  2. Установочный iso-образ Windows 7 (придётся поискать самим);
  3. Скрипты на языке Testo-lang;
  4. Установленная платформа Testo (бесплатно);
  5. Выполнить команду.
sudo testo run ./tests.testo --param ISO_DIR /path/to/your/iso/dir

И всё. Как и я обещал — всего одна команда. Через пол часа — час (зависит от шустрости вашего компьютера) вы сможете наслаждаться своим готовым стендом.

Ввод рабочей станции в домен

Переключаемся на вторую машину workstation под управлением Windows 7 и заходим в свойства системы. Сейчас видно, что рабочая станция находится в рабочей группе (не в домене). Кстати говоря, WORKGROUP — это тоже NetBIOS-имя. Только в отличии от имени домена оно имеет суффикс 1E.

Щелкаем на кнопку “Изменить параметры”, затем в появившемся окне ещё раз “Изменить…”.

Включаем нужные компоненты

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

Пройдемся вкратце по каждому из них.

Где содержится информация об авторизованных серверах?

Как мы уже могли увидеть, оснастка в DHCP уже владеет информацией об авторизованных серверах. Возникает вопрос — Откуда?

При подключении к меню Управление авторизованными серверами в оснастке DHCP, происходит обращение к разделу конфигурации Active Directory, который реплицируется между другими контроллерами во всем домене.Давайте посмотрим где конкретно хранятся объекты серверов DHCP. Для этого откроем оснастку Редактирование ADSI:

Удаление авторизованных DHCP серверов в среде Active Directory.
Указываем настройки в соответствии с иллюстрацией.

Доменные службы active directory

Эта роль фактически “включает” технологию Active Directory на сервере и делает его контроллером домена (под доменом в технологии AD понимается группа логически связанных объектов в сети). Благодаря этой роли администратор получает возможность управлять объектами в сети, а также хранить информацию о них в специальной распределенной базе данных.

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

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

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

Однако этот туториал рассчитан на простое ознакомление с технологией AD “на виртуалках”, поэтому здесь не будет рассматриваться вопрос создания нескольких контроллеров AD в одном домене.

С этим пунктом все более менее понятно, а зачем же нам включать дополнительно ещё DNS-сервер?

Дополнительные решения

  1. Попробуйте отключить на сервере DCHP если это Windows встроенный брандмауэр
  2. Если на сервере есть антивирус, то так же на время выключите его

Надеюсь, что вам удалось решить проблему с авторизацией DHCP сервера, на этом у меня все. С вами был Иван Семин, автор и создатель IT портала vhod-v-lichnyj-kabinet.ru.

Зачем может понадобиться деавторизовывать сервера?

Для чего нужна процедура авторизации теперь понятно, но зачем нужна обратная процедура — деавторизация?

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

Похожее:  МОУ ИИФ личный кабинет

Один из очень частых сценариев, при котором может возникнуть вышеуказанная проблема — вывод из эксплуатации сервера или серверов. Например, больше нет необходимости держать сервер DHCP в удаленном филиале (сайте), т.к сайт будет полностью удален по причине переезда.

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

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

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

Возвращаемся на панель мониторинга (самый первый скриншот) и щелкаем на пункт “Добавить роли и компоненты”. Вас поприветствует мастер добавления ролей и компонентов. Первый экран (“Перед началом работы”) пропускаем, он совсем неинтересный, а вот дальше идёт экран “Выбор типа установки”

Нас устраивает значение по-умолчанию (Установка ролей или компонентов”), но интересен и второй пункт — он позволяет задействовать ещё одну возможность Windows Server — инфраструктуру виртуальных рабочих мест (Virtual Desktop Environment — VDI). Эта интереснейшая технология позволяет, буквально, виртуализировать рабочее место.

Впрочем, технология VDI это отдельная большая тема, а в этом туториале надо сосредоточиться на контроллере AD, так что кликаем “Далее” и видим экран выбора целевого сервера.

Мастер добавления ролей позволяет устанавливать роль не только на текущую машину, но вообще на любой добавленный сервер, и даже на виртуальный жёсткий диск. Да, если ваша Windows Server развернута на виртуальной машине (а это довольно частое явление), то вы можете администрировать эту виртуальную машину даже не запуская её! Понаблюдать за этим процессом можно, например, здесь

Нам же такая экзотика ни к чему, так что просто выбираем единственный возможный сервер (обратите внимание, что он теперь называется ADController место непонятной абракадабры), жмём “Далее” и, наконец, попадаем на экран выбора ролей, которые нужно добавить.

Выбираем три роли, о которых уже говорили ранее, и продолжаем.

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

Согласно идеологии Microsoft, роль — это набор программ, которые позволяют компьютеру предоставлять некоторые функции для пользователей в сети. Например, DNS, DHCP, контроллер домена AD — это всё роли. А вот компоненты — это набор программ, которые улучшают либо возможности ролей сервера, либо самого сервера.

При этом глядя на список “Компонентов” так сходу и не скажешь, что какие-то вещи в списке лишь “вспомогательные”. Вот например, DHCP-сервер расценивается как роль, а WINS-сервер — уже как компонент. А чем SMTP-сервер хуже DNS?

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

В любом случае, дополнительные компоненты нам не нужны, так что кликаем “Далее”.

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

На экране подтверждения ещё раз видим все устанавливаемые роли и компоненты, после чего жмём “Установить”.

Остаётся лишь дождаться, когда заполнится progress-bar, и перейти к следующему пункту туториала — настройке контроллера домена AD.

Настраиваем контроллер домена active directory

Все роли и компоненты успешно добавлены, о чём свидетельствует следующий экран:

Вот только AD на сервере всё еще не работает — для этого его необходимо донастроить. Для этого нам настойчиво предлагают “Повысить роль этого сервера до уровня контроллера домена”.

Погодите-ка, ЧТО?!

А чем же я занимался последние 15 минут? Я же добавлял роли, и судя по сообщению, они успешно добавились! И тут меня снова хотят заставить добавлять какие-то новые роли? В чем-то тут подвох.

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

Видите разницу? В английской версии ни слова ни про какие роли! Про повышение есть, про роли — нет. Один из тех случаев, когда перевод вносит сумятицу на пустом месте. Согласно английской версии, никакими ролями мы дальше не занимаемся, что и логично, ведь мы их как раз только что добавили.

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

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

Настройка репликации между wins-серверами

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

Настройка статического отображения

Запись, отображающая имя в IP-адрес, может быть добавлена в базу данных WINS двумя способами.

  • Динамически. Этот тип записей создается в базе данных сервера WINS-клиентами в процессе регистрации локальных NetBIOS-имен.
  • Статически. Администратор создает записи вручную, определяя статическое отображение (static mapping) NetBIOS-имени на IP-адрес.

Статические отображения используются в ситуации, когда необходимо жестко прописать соответствие “имя-адрес” в базе данных WINS-сервера для хоста, который непосредственно не использует WINS. Например, в некоторых сетях серверы под управлением других операционных систем не могут регистрировать свои NetBIOS-имена непосредственно на WINS-сервере.

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

Переустановка роли из-за поврежденной базы

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

C:WindowsSystem32dhcpbackup

Пробуем удалить и заново установить роль DHCP. Проще всего, это сделать через PowerShell

Remove-WindowsFeature DHCP -IncludeManagementTools или Uninstall-WindowsFeature DHCP -IncludeManagementTools

Похожее:  GitHub - shanept/mediawiki-LdapAuth: New LdapAuthentication provider plugin for mediawiki

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

Install-WindowsFeature -Name DHCP -IncludeAllSubFeature

После переустановки DHCP я снова проверил с помощью BPA роль DHCP.На этот раз было опубликовано предупреждение о том, что группа безопасности DHCP будет отсутствовать. Я использовал команду netsh для добавления группы безопасности dhcp.

C:Windowssystem32 netsh dhcp add securitygroups

Затем остановка и повторный запуск службы DHCP и другое сканирование с помощью инструмента BPA больше не отображали никаких предупреждений или ошибок. И новый идентификатор 1035/1036 больше не виден в средстве просмотра событий.

Переход от wins к dns

В Windows Server 2003 система доменных имен (DNS) рассматривается как основной способ именования ресурсов. Служба WINS используется исключительно по соображениям сохранения совместимости. Со временем администратор может реализовать полный переход от WINS к DNS, оставив в сети только одну службу имен. Процесс удаления из сети функционирующего WINS-сервера называется отзывом (decommissioning).

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

  1. В пространстве имен оснастки WINS выберите WINS-сервер для отзыва. После этого перейдите к контейнеру Active Registrations (Активные регистрации).
  2. В меню Action (Действие) выполните команду Show records for the selected owner (Найти по владельцу).
  3. В открывшемся окне в списке only for selected owner (только для выбранного владельца) укажите WINS-сервер для отзыва и нажмите кнопку ОК.
  4. В окне подробного просмотра выделите все элементы.
  5. В меню Action (Действие) выберите команду Delete (Удалить).
  6. В диалоговом окне Confirm WINS Record Delete (Подтверждение удаления записей) установите переключатель Tombstone WINS records on all WINS servers (Реплицировать удаление записи на другие серверы) и нажмите кнопку ОК.
  7. Подтвердите удаление, нажав кнопку Yes (Да) в окне запроса.
  8. В дереве выберите элемент Replication Partners (Партнеры репликации).
  9. В меню Action (Действие) выполните команду Replicate Now (Запустить репликацию).
  10. После проверки репликации выбранных записей на другие серверы остановите и удалите службу WINS на отозванном сервере.

В процессе перехода может потребоваться настроить разрешение доменных имен DNS через службу WINS.

Процесс настройки

Запускаем «Диспетчер серверов». Находим пункт DHCP в открывающемся списке «Tools»:

DHCP

В нашем варианте мы рассматриваем выдачу IPv4 адресов, поэтому нужно создать новую область (Scope) — пул IP-адресов, выдаваемых клиентам. Нажимаем правой кнопкой мыши на IPv4 и выбираем «New Scope…»:

New Scope Wizard

Открывается Мастер создания области, где мы вводим имя пула. Если необходимо, то можно ввести описание:

New Scope Wizard

Определяем границы нашего пула, задав начальный и конечный IP-адрес. Также вводим маску подсети:

Определение границ нашего пула

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

Мастер создания области, где мы вводим имя пула

Далее можно указать время аренды IP-адреса. По умолчанию выставлено 8 дней:

New Scope Wizard

Теперь Мастер предложит указать сетевые параметры (Gateway, DNS, WINS), выдаваемые клиентам в сети:

Указание сетевых параметров (Gateway, DNS, WINS), выдаваемых клиентам в сети

Укажем адрес сетевого шлюза:

Маршрутизатор

Следующий этап позволяет добавить WINS-сервер:

New Scope Wizard

Выбираем «Активировать» заданную нами область сейчас:

New Scope Wizard

После настройки пула можно проверить работает ли сервер. Посмотреть подключенных клиентов можно перейдя в раздел «Address Leases». В нашем случае видим, что подключено одно устройство:

Раздел «Address Leases»

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

Правильные настройки DHCP-сервера в Windows Server

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

  • Запустим Диспетчер серверов и выберем «Add roles and features». Выберем первый пункт «Role — based or feature — based installation»:

Диспетчер серверов «Add roles and features»

  • Укажем сервер, на который будем устанавливать роль DHCP:

Указание сервера на который будет установлена роль DHCP

  • Мастер напомнит вам о то, что нужно заранее спланировать подсети, области и исключения:

Сервер DHCP

  • Проверяем устанавливаемые компоненты и нажимаем «Install»:

Подтверждение установки

  • После завершения установки можно начать первичную настройку DHCP. Переходим по ссылке «Complete DHCP configuration»:

Меню прогресса установки

Процесс первичной настройки проходит в два этапа:

1. Создание «Группы безопасности» для управления этим DHCP—сервером. Всего их две:

2. Авторизация DHCP-сервера в Active Directory (если он присоединен к домену). Данная настройка нужна, чтобы избежать появления в сети посторонних DHCP-серверов. Сервер должен пройти авторизацию чтобы служба DHCP запустилась:

Авторизация DHCP-сервера в Active Directory

  • Вписываем учетные данные администратора и жмем кнопку «Commit». Если сервер не присоединен к домену, то выбираем последний пункт:

Авторизация

  • Если всё сделано верно, мастер оповещает об успешном выполнении настройки:

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

Создаём нового пользователя в домене ad

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

Для этого возвращаемся на панель мониторинга, кликаем на “Средства” и затем на “Пользователи и Компьютеры Active Directory”

Создание области действия

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

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

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

Иллюстрированный самоучитель по Microsoft Windows 2003 › Серверы DHCP, DNS и WINS › Создание области действия
Рис. 13.16. Опция, позволяющая определить адреса шлюзов по умолчанию

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

Иллюстрированный самоучитель по Microsoft Windows 2003 › Серверы DHCP, DNS и WINS › Создание области действия
Рис. 13.17. Опция, позволяющая определить адреса DNS-серверов и DNS-имени домена

Итоги

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

До новых встреч! 🙂

1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (1 оценок, среднее: 4,00 из 5)
Загрузка...

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector