Как проверить доступность dhcp сервера

Устранение неисправностей с сервером DHCP

Самая частая проблема, связанная с DHCP, заключается в назначении неправильного IP адреса. Например, предположим, что ваш сервер DHCP был настроен на использования интервала IP адресов с 192.168.0.1 по 192.168.50. Вам следует ожидать, что сетевому компьютеру будет присвоен IP адрес из этого интервала. Теперь предположим, что рабочая станция в вашей сети начала испытывать проблемы при обращении к другим сетевым серверам. Вам необходимо использовать команду IPCONFIG /ALL для того, чтобы увидеть сетевую конфигурацию и IP адрес. Вместо адреса из ожидаемого интервала адресов мы видим, что рабочей станции был присвоен адрес, начинающийся с 169.254. Так что же произошло? Если компьютеру в вашей сети неожиданно был присвоен адрес, начинающийся с 169.254, то вы можете быть абсолютно уверены, что этот адрес был присвоен не вашим DHCP сервером. Случилось то, что ваша рабочая станция не смогла соединиться с сервером DHCP server. Если такое происходит, что рабочая станция сама назначает себе IP адрес, с помощью средства Windows под названием Automatic Private IP Addressing (APIPA или автоматическая адресация).

Microsoft встроил автоматическую адресацию в операционную систему Windows в качестве помощи тем, кто использует очень маленькие сети. Например, если вы создали небольшую сеть Windows, то вам не нужно вручную настраивать IP адреса, даже если нет сервера DHCP в сети. APIPA поможет вам автоматически присвоить уникальный адрес класса В каждой машине в сети. Это великолепно для небольших домашних сетей, но абсолютно неприменимо для больших сетей. Если рабочая станция воспользовалась услугами APIPA, то это означает, что на ее запрос на получение IP адреса не пришло ответа. Причин возникновения такой ситуации может быть несколько. Если вы знаете, что все остальные компьютеры в вашей сети нормально запрашивают IP адрес у вашего DHCP сервера, то вы можете заключить, что причиной проблемы является не DHCP server.

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

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

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

Если сервер DHCP может связаться с другими компьютерами в сети, то я рекомендую проверить, что серверу DHCP server присвоен IP адрес, и что этот адрес совместим с тем интервалом адресов, для которого этот сервер настроен присваивать адреса для рабочих станций. Например, если интервал адресов, которые сервер DHCP присваивает рабочим станциям, варьируется с 192.168.0.1 до 192.168.0.50, то сервер не сможет присваивать адреса рабочим станциям до тех пор, пока ему самому не будет присвоен статический адрес в том же самом сегменте подсети, например, 192.168.0.0 или 192.168.0.51.

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

Конфликты IP адресов

Другая проблема, которую я наблюдал, заключается в конфликте IP адресов среди динамически распределяемых адресов. Когда вы создаете интервал DHCP scope, то сервер DHCP отвечает за то, чтобы адреса внутри интервала были уникальны для каждой машины. Если это действительно так, то откуда же возникает конфликт динамически назначаемых адресов?

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

Вероятность возникновения такой ситуации в наши дни достаточно невелика. Когда возникла такая ситуация повсеместно использовалась операционная система Windows 98. В операционной системе Windows 98 не хватает много инструментов для безопасности, которые есть у нас на сегодняшний день. Правильно настроенная безопасность на рабочей станции с операционной системой Windows XP или Windows Vista позволит запретить все изменения конфигурации пользователю. Но, несмотря на это, я все же хотел упомянуть эту ситуацию, т.к. иногда она поможет вам решить проблему.

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

Операционные системы Windows 2000 Server и Windows Server 2003 спроектированы таким образом, чтобы избежать проблем с пиратскими (rogue) DHCP серверами. В них сервер DHCP может присваивать IP адреса лишь после того, как он был авторизован Active Directory. Но проблема заключается в том, что это применимо лишь для серверов DHCP, которые работают на платформе Windows. Сервера DHCP, работающие на других операционных системах могут присваивать IP адреса клиентам без необходимости быть авторизованными Active Directory.

Так существует ли какая-нибудь сложность установки пиратского сервера DHCP, который работает на платформе Linux? Вероятно, нет. Гораздо более вероятное объяснение заключается в том, что вашей проблемой является беспроводная точка доступа, или маршрутизатор. Такие устройства практически всегда имеют встроенный DHCP сервер. Эти устройства обычно используют интервал адресов с 192.168.0.x или 192.168.1.x. Если так случилось, что этот же самый интервал IP адресов используется на вашем основном DHCP сервере, что тогда вы столкнетесь с ситуацией, когда оба сервера DHCP присваивают адреса из одного и того же интервала, что приводит к конфликту.

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

Оцените статью: Голосов

Первичная диагностика:

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

Проверка DHCP сервера

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

По логам возможно обнаружить три основные проблемы:

• Отсутствует Discover.
• Присутствует Discover, но отсутствует Offer.
• Присутствуют Discover и Offer, но отсутствует Request.

1. В логах отсутствует Discover от клиентского устройства.

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

• Если Discover отсутствует в дампе, то нужно перейти к проверке настроек в сети, DHCP-relay и связи с ним.
• Если Discover присутствует в дампе, но не попал в логи, то необходимо проверить настройки сервера (пункт 1.1).

1.1 Discover присутствует в дампе, но не попал в логи.

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

В файле /etc/default/isc—dhcp—server должны быть прописаны названия всех прослушиваемых интерфейсов, например:

INTERFACES="eth0 eth1"

2. В логах DHCP сервера присутствует Discover, но отсутствует Offer.

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

• не прописана одна из используемых подсетей
• неправильно прописаны классы
• в пулах закончились свободные адреса
• проблемы с файловером

2.1 не прописана одна из используемых подсетей

В файле /etc/dhcp/dhcpd.conf должны быть прописаны подсети, содержащие адреса прослушиваемых интерфейсов, а также адрес DHCP-relay (если он используется). Даже если адреса из этих подсетей не раздаются сервером, например:

subnet 192.168.1.0 netmask 255.255.255.0 <>

2.2 в пулах закончились свободные адреса

Одна из распространенных причин состоит в том, что сервер раздал все свободные адреса, для проверки этого следует использовать руководство: Мониторинг использования пулов в ISC-DHCP-server

3 В логах DHCP сервера присутствуют Discover и Offer, но не приходит Request.

Необходимо снять tcpdump на интерфейсе, на который приходит Discover и проверить, есть ли в этом же дампе Offer.

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

4 Проверка связи между dhcp-сервером и dhcp-relay

Проверить пинг до dhcp-relay с сервера. Пинг должен выполняться с правильного интерфейса.

Проверка DHCP-relay

Отладка в Схеме с GRE

1. Проверка статуса GRE туннелей.

Для этого необходимо:

• Через cистему управления (СУ) EMS узнать «первичный» IP адрес ТД. Первичный адрес указан на вкладке «Доступ» и на вкладке «Мониторинг» в разделе «Общее».
• На ESR посмотреть список GRE туннелей принадлежащий данной ТД. Это можно выполнить командой:

show tunnels status | include

, где XXX.XXX.XXX.XXX – первичный IP ТД

Команда вернет список туннелей, построенных этой точкой доступа.

• Если туннелей нет, то необходимо проверить IP связность между ТД и ESR, а так же конфигурацию DHCP сервера
• Если туннель 1 – то проверятся конфигурация DHCP сервера и конфигурация ESR
• Если 2 туннеля, то проверяется что для второго туннеля подняты SUB-туннели с, соответствующими конфигурации ТД VLAN.

2. Снятие дампа трафика на SUB-GRE туннеле проблемной точки доступа.

Для получения дампа нужно выполнить подключение под учетной записью techsupport, перейти в режим su и запустить команду:

tcpdump -i dygreХХХ.УУУ -evn -c100

, где ХХХ номер GRE туннеля найденный в пп выше, УУУ – номер VLAN ID

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

• Если Discover отсутствует в дампе — это означает, что возможно точка доступа не смогла корректно построить туннель. Необходимо выполнить проверку настройки DHCP сервера (43 опция , 12 подопция), а также проверить настройки ТД.
• Если Discover присутствует в дампе, но отсутствует Offer — следует перейти к проверке обмена с DHCP сервером (пункт 3).

3. Снятие дампа трафика при обмене пакетами с DHCP сервером.

Для получения дампа нужно выполнить подключение под учетной записью techsupport, перейти в режим su и запустить команду:

tcpdump -i te1_YYY.ZZZ -evn -c100

, где YYY – номер порта ESR, ZZZ – номер VLAN.

• Если Discover отсутствует в дампе – проблема в настройках ESR.
• Если Discover передается на DHCP сервер, но отсутствует Offer – проблема в связи между DHCP сервером и ESR.
• Если Discover и Offer присутствуют, но в обмене отсутствует Request – проблема в настройках ESR.

Отладка в Схеме без GRE

1. Снятие дампа трафика на интерфейсе в сторону клиента. При анализе дампа необходимо найти Discover от клиента.

• Если Discover отсутствует – необходимо проверить:

1. настройки файрвола на DHCP-relay,
2. настройки сети для связи с точкой доступа
3. настройки точки доступа,

• Discover присутствует, но отсутствует Offer – следует перейти к проверке обмена с DHCP сервером.

2. Снятие tcdump обмена с DHCP сервером.

• Если Discover отсутствует в дампе – проблема в настройках DHCP-relay. Необходимо проверить firewall и настройку маршрутизации на DHCP-relay.
• Если Discover передается на DHCP сервер, но отсутствует Offer – проблема в связи между DHCP сервером и DHCP-relay.
• Если Discover и Offer присутствуют, но в обмене отсутствует Request – проблема в настройках firewall на DHCP-relay.

Проверка точки доступа

На точке доступа необходимо настроить открытый SSID без авторизации, в том же VLAN, что и проблемный SSID. По инструкции о снятии дампа (pcap) с точки доступа, нужно снять дамп на радио интерфейсе, к которому подключается пользователь, а также на интерфейсе eth. Результаты следует интерпретировать в зависимости от используемой схемы подключения:

Для любой схемы:

• Если в дампе с радио интерфейсе Discover от пользователя отсутствует, то это означает, что есть проблема с клиентским устройством. Возможно оно не подключилось к сети, либо по каким-то причинам не запрашивает адрес.

Для схемы с GRE:

• Если на радио интерфейсе Discover от пользователя есть, а на eth его нет, то это означает, что GRE туннель для пользовательского трафика не построился из-за того, что при получении первичного адреса, точка получила неправильную 12 подопцию. Необходимо выполнить проверку настройки DHCP сервера (43 опция , 12 подопция)
• Если Discover есть в обоих дампах, то это означает, что пакет передается с ТД, нужно убедиться в получении .пакетов на ESR.

Для схемы без GRE:

• Если Discover зафиксирован в дампе с радио интерфейса и eth, но отсутствует на DHCP-relay, то это говорит о том, что на оконечном оборудовании не настроен пользовательский VLAN, либо он не прокинут до DHCP-relay.

• Нет меток

Протокол динамического выделения адресов (DHCP)

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

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

IP адрес и сетевую маску
IP адрес шлюза по умолчанию
IP адрес DNS серверов

Однако DHCP сервер может также предоставить такие параметры настройки, как:

Имя домена
Адрес сервера времени
Адрес сервера печати

Преимущество использования DHCP заключается в изменчивости сети, например, изменение адреса DNS сервера потребует изменений только на DHCP сервере, а все сетевые хосты будут перенастроены в момент следующего запроса их DHCP клиента к DHCP серверу. Дополнительное преимущество заключается в простом подключении новых компьютеров к сети, поскольку не требуется проверять доступность IP адресов. Конфликты по выделенным IP адресам также минимальны.

DHCP сервер может предоставлять настройки, используя следующие методы:

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

Динамическое выделение (пул адресов)
При этом методе, DHCP сервер будет выделять IP адрес из пула адресов (иногда называемым диапазоном или областью) на период времени (или в аренду), который настраивается на сервере, или пока клиент не проинформирует сервер, что больше вообще не нуждается в адресе. Таким образом, клиенты получают свои настройки динамически по принципу «первый пришел — первый обслужился». Когда DHCP клиент отсутствует в сети определенное время, настройка считается просроченной и возвращается в пул адресов для использования другими DHCP клиентами. Это означает, что адрес арендуется или выдается на определенный период времени. По истечении этого периода клиент должен повторно договариваться об использовании адреса с сервером.

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

Два последних метода можно рассматривать, как автоматические, поскольку DHCP сервер выдает адреса без дополнительного вмешательства. Единственная разница заключается в том, насколько арендуется адрес, другими словами, когда истечет время использования адреса клиентом. Ubuntu поставляется вместе с DHCP сервером и клиентом. Сервером является dhcpd (сервис протокола динамического выделения адресов). Клиент, поставляемый с Ubuntu, — это dhclient и он может быть установлен на все компьютеры, требующие автоматических настроек. Обе программы просты в установке и настройке и автоматически стартуют при загрузке системы.

Установка

В терминале введите следующую команду для установки dhcpd:

sudo apt-get install isc-dhcp-server

Возможно вам потребуется изменить настройку по умолчанию редактированием /etc/dhcp/dhcpd.conf для удовлетворения вашим потребностям и специфическим настройкам.

Вы также можете исправить /etc/default/isc-dhcp-server для определения интерфейсов, которые должен слушать dhcpd.

Обратите внимание, что сообщения dhcpd будут посылаться в syslog. Смотрите его для диагностики.

Настройка

Сообщение об ошибке в конце установки может немного смущать, но следующие шаги помогут вам настроить сервис:

В большинстве случаев, все что вам нужно сделать, это выделять случайный IP адрес. Это можно сделать следующими настройками:

# minimal sample /etc/dhcp/dhcpd.conf default-lease-time 600; max-lease-time 7200; subnet 192.168.1.0 netmask 255.255.255.0

В результате DHCP сервер будет выдавать клиентам IP адреса из диапазона 192.168.1.150-192.168.1.200. адреса будут предоставляться на 600 секунд, если клиенты не запросят специфический промежуток времени. При этом максимально разрешенное время аренды будет 7200 секунд. Сервер будет также «рекомендовать» клиентам использовать адрес 192.168.1.254 в качестве шлюза и 192.168.1.1 и 192.168.1.2 как DNS сервера.

После изменения настройки вам потребуется перзапустить dhcpd:

sudo /etc/init.d/isc-dhcp-server restart

Авторизация DHCP сервера и устранение проблем

Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org. Ранее мы с вами говорили про принципы работы DHCP протокола и разбирали его поэтапно. В сегодняшней заметке, мне бы хотелось осветить вопрос по защите и безопасности DHCP сервера, и речь пойдет, о авторизации и решения проблем с ней. Ситуаций в жизни бывает много, так что как говорится прокачаем свой навык траблшутинга. Уверен, что мой скромный опыт будет кому-то полезен.

Что такое авторизованный DHCP

Когда вы устанавливаете Active Directory в своей компании, то у вас появляется тройка ролей, которые очень часто идут вместе, я говорю про AD, DNS и DHCP. Эта тройка позволяет системному администратору получить все прелести и преимущества доменной структуры. Очень важным аспектом любой современной IT инфраструктуры, является аспекты безопасности и в случае DHCP, это очень актуально. Небольшое воспоминание из практики. Когда я еще только начинал свой путь инженера, то я плохо разбирался в сетевых протоколах и технологиях, знал так сказать азы. Я знал, что у нас в окружении установлен Windows DHCP сервер и, что он сам раздает ip-адреса. В один из рабочих дней мне позвонил менеджер и сказал, что у него пропал интернет и доступ к сетевым шарам.

Когда я к нему подошел, то стал проводить сетевую диагностику, где одним из этапов было вычисление полученного ip-адреса. Какого же было мое удивление, когда я за место диапазона 192.168.100.0 увидел диапазон адресов 192.168.1.0. Я точно знал, что на моем DHCP сервере такой области нет. В итоге оказалось, что один из программистов принес WIFI роутер в то время, это было диковинкой, а так как мозги данного устройства работали на Linux платформе, то его DHCP сервер отрабатывал быстрее, чем в Windows сервере, что в итоге вело к выдаче адресов из другой области. Вот для предотвращения таких вещей и есть авторизация DHCP сервера.

Требования к серверу перед авторизацией

Авторизация DHCP сервера является обязательной процедурой и требует соблюдения некоторых вещей:

• Ваш сервер DHCP должен быть членом Active Directory
• У вас должны быть права на авторизацию его в AD, администратор предприятия или делегированная группа.
• Не должно быть проблем с созданием и редактированием атрибутов и классов в схеме Active Directory

Интересные моменты

• Сервер DHCP проверяет свою авторизацию в AD DS каждый час. Он использует протокол LDAP [MS-ADTS] для связи с Active Directory и проверки, авторизован ли он для обслуживания IP-адресов.
• При установке в среде с несколькими лесами DHCP-серверы запрашивают авторизацию изнутри. После авторизации серверы DHCP в среде с несколькими лесами сдают в аренду IP-адреса всем доступным клиентам.
• Если вы устанавливаете роль DHCP на контроллере домена, сервер автоматически авторизуется. Если вы устанавливаете его на рядовой сервер, вам нужно будет вручную выполнить процесс авторизации одним из следующих способов.
• Если в сети появится DHCP сервер, отличный от Windows платформы, то он сможет раздавать IP-адреса и авторизация ему не потребуется. Чтобы этого избежать нужны технологии на подобии DHCP snooping и системы анализа трафика.

Методы авторизации DHCP в Active Directory

• Авторизация после установки из оснастки в мастере
• Из оснастки, после всех настроек
• Авторизация после установки роли, через PowerShell
• Авторизация сервиса после установки роли через командную строку и утилиту netsh

Первый метод авторизации DHCP

Я покажу его на примере Windows Server 2019, когда вы установили роль DHCP, вас попросят закончить настройку. В итоге у вас откроется окно мастера, где вас попросят авторизовать в Active Directory, обращаю внимание, что вы на этом этапе можете ее пропустить. Напоминаю, что права должны быть минимум администратора домена или аналогично делегированные.

Второй метод авторизации DHCP

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

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

В окне «Список авторизованных серверов» нажмите кнопку «Авторизовать». У вас откроется дополнительное окно, где можно указать DNS имя или IP-адрес. Я впишу мой второй дополнительный сервер с ip-адресом 192.168.31.3.

Произойдет поиск роли DHCP на данном сервере. Если она там есть то появится дополнительное окно, где нужно нажать «ОК».

Все сервер у вас должен появится в списке авторизованных.

Авторизовать DHCP-сервер с помощью Netsh

Откройте командную строку с правами администратора и введите следующую команду для авторизации DHCP-сервера.

netsh dhcp show server

Команда показывает мои текущие авторизованные серверы в домене, как видим у меня он один dc01/root/pyatilistnik.org. В окне «Управление авторизованными серверами» его видно. Далее авторизуем новый сервер svt2019s01.root.pyatilistnik.org с ip-адресом 192.168.31.3

netsh dhcp add server svt2019s01.root.pyatilistnik.org 192.168.31.3

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

Авторизовать DHCP-сервер с помощью PowerShell

Get-DhcpServerInDC

Вижу, что в данный момент он один.

Теперь, чтобы добавить второй сервер, выполните команду:

Add-DhcpServerInDC -DnsName «svt2019s01.root.pyatilistnik.org» -IPAddress 192.168.31.3

Как деактивировать DHCP сервер

Логично предположить, что методов деактивации тоже четыре.

• Из оснастки DHCP сервера, для этого правым кликом по названию сервера и из контекстного меню выбираем пункт «Запретить».

• Второй метод деактивации — это из окна «Управление авторизованными серверами», выбираем нужный и нажимаем кнопку «Запретить»

• Третий метод запретить конкретный сервис, это утилита командной строки netsh.

netsh dhcp delete server svt2019s01.root.pyatilistnik.org 192.168.31.3

• Последний метод деактивации, это в PowerShell

Remove-DhcpServerInDC -DnsName «svt2019s01.root.pyatilistnik.org -IPAddress 192.168.31.3

Где прописывается DHCP в конфигурации Active Directory

Теперь хочу вам показать, где в классах и с какими атрибутами прописываются записи авторизованных DHCP серверов. Откройте редактор атрибутов AD и зайдите в раздел конфигурации. Перейдите по пути: CN=Services,CN=Configuration,DC=root,DC=pyatilistnik,DC=org. В данном контейнере вы увидите записи ваших авторизованных DHCP сервисов и очень важную запись CN=DhcpRoot, если ее нет, то это плохо.

Когда вы пытаетесь авторизовать сервер, то первым делом проверяется наличие записи CN=DhcpRoot ,и если она не найдена, то вы не сможете завершить вашу операцию

В итоге у вас появится контейнер «Services», далее «NetServices», в котором вы увидите весь список.

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

Из-за не правильной деактивации DHCP или восстановлении сервера из резервной копии приличной давности, он у вас может не запускать и при попытке пройти авторизацию написать «Параметр задан неверно»

В таких случаях вам нужно проверять наличие CN=Services,CN=Configuration,DC=root,DC=pyatilistnik,DC=org записи вашего сервера. Если ее нет, то придется создать ее с нуля. Через правый клик создаем новый объект AD.

Выбираем класс объекта dhcpServer.

Прописываем Common-name вашего сервера.

dhcp-Unique-key ставим 0.

dhcp-type ставим 1.

В dhcp-identification прописываем distinguished name сервера.

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

Как дать права на авторизацию DHCP сервера

На сколько мне известно, чтобы у вас была возможность авторизовывать серверы DHCP, то вы должны быть администратором предприятия (Enterprise Admin). Понятно, что в данной группе должно быть минимум людей. Вы можете делегировать данные права, любой группе или пользователю. Для этого, в оснастке Active Directory — сайты и службы с включенной опцией «Показать узел служб» вы нажимаете правым кликом по контейнеру NetServices и выбираете пункт делегирование управления.

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

Выбираем создание особой задачи для делегирования.

Оставляем пункт «Этой папкой, существующими в ней объектами и созданием новых объектов в этой папке»

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

На этом я хочу закончить эту статью, она получилась и так очень длинной. Если у вас остались вопросы, то пишите их в комментариях, я на них постараюсь ответить. С вами был Иван Семин, автор и создатель IT блога Pyatilistnik.org,

Популярные Похожие записи:

• Ошибка DHCP, потеряна связь с партнером
• Поиск mac-адреса на DHCP с помощью PowerShell
• DHCP BAD_ADDRESS: This address is already in use
• Ошибка NETLOGON 5719: Перестал отвечать дочерний домен
• Ошибка активации 0xC004F034 на KMS сервере
• Ошибка 0xC000018C An Error occured during Logon