Поделиться через

Руководство по устранению неполадок: сбои авторизации DHCP

В этом руководстве представлен подробный пошаговый процесс диагностики и устранения сбоев авторизации протокола DHCP в среде Active Directory (AD).

Симптомы

На этапе после установки роли DHCP на сервере возникает следующее сообщение об ошибке:

Авторизация ..... DHCP-сервера Неудачно
Сбой авторизации DHCP-сервера с кодом ошибки: 20070. Служба DHCP не могла связаться с Active Directory.

В консоли DHCP отображается красная стрелка вниз в разделе IPv4, указывающая, что сервер не авторизован.

Снимок экрана: консоль DHCP с несанкционированным состоянием.

Идентификатор события 1046 регистрируется в журналах системных событий, указывая, что DHCP-сервер не авторизован для аренды IP-адресов:

Служба DHCP/BINL на локальном компьютере, принадлежащая домену административного домена <>Windows, определила, что она не авторизована на запуск. Она перестала обслуживать клиентов.

Снимок экрана: журнал событий, указывающий на несанкционированное состояние.

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

Указанный домен либо не существует, либо может быть контактирован.

Поток авторизации DHCP

Авторизация DHCP гарантирует, что только авторизованные серверы могут работать в домене AD. Этот механизм запрещает несанкционированным серверам распространять IP-адреса, что может вызвать проблемы с сетью и безопасностью.

Когда DHCP-сервер авторизован, запись создается в AD в списке авторизованных серверов. Это поведение выполняется с помощью протокола LDAP между контроллером домена (DC) и DHCP-сервером. Этот список находится в контейнере конфигурации схемы AD.

Снимок экрана: запись, созданная в AD.

DHCP-сервер проверяет состояние авторизации в службах домен Active Directory (AD DS) каждый час с помощью LDAP. Если IP-адрес сервера не найден в этом списке, сервер отменяет проверку подлинности.

Причины сбоев авторизации

  • Проблемы с разрешениями. Учетная запись, используемая для авторизации сервера, не имеет достаточных привилегий.
  • Отсутствующие записи в AD: запись для DHCP-сервера может быть удалена из контейнера конфигурации AD.
  • Проблемы с подключением: проблемы с сетью или брандмауэром препятствуют обмену данными между контроллером домена и DHCP-сервером.
  • Проблемы репликации AD: задержки или проблемы могут привести к несогласованным записям, что приводит к дублированию или конфликтующим записям (например, объектам conflict (CNF) в контейнере конфигурации AD. DHCP-сервер не может быть авторизован с этими записями.

Действия по устранению неполадок

Шаг 1. Проверка разрешений

Используйте учетную запись администратора предприятия для авторизации DHCP-сервера. Эта учетная запись имеет достаточные разрешения для внесения изменений в AD.

Шаг 2. Проверка состояния авторизации

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

Команда Powershell:

Get-DhcpServerInDC

Команда командной строки:

netsh dhcp show server

Кроме того, используйте команду ADSI Edit для подключения к секции конфигурации и проверьте, отображается ли сервер там:

  1. Откройте adsiedit.msc в контроллере домена.
  2. Подключитесь к контейнеру конфигурации .
  3. Перейдите к службам Configuration>Services>NetServices.
  4. Проверьте, отображается ли имя DHCP-сервера на правой панели.

Шаг 3. Попробуйте выполнить авторизацию вручную

Если для сервера нет существующей записи, выполните следующие действия.

  1. Откройте консоль управления DHCP.
  2. Щелкните правой кнопкой мыши имя DHCP-сервера.
  3. Выберите Разрешить.

Если это не удается, перейдите дальше.

Шаг 4. Проверка подключения

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

  • Команда Ping для основных проверок сетевого подключения между обоими серверами.

  • Команда Test-NetConnection для TCP-порта 389 через PowerShell. Например:

    Test-NetConnection -ComputerName <DC-IP> -Port 389

Убедитесь, что порты LDAP (TCP/UDP 389) открыты и функциональны. Проверьте параметры брандмауэра, чтобы убедиться, что эти порты не блокируются. Устраните обнаруженные проблемы с подключением соответствующим образом.

Кроме того, можно записать трассировки Wireshark, чтобы определить падение пакетов между контроллером домена и DHCP-сервером.

Шаг 5. Определение и разрешение конфликтующих записей

  1. Откройте adsiedit.msc и перейдите к службам Configuration>Services>NetServices.

  2. Найдите записи с тегом CNF, включающим имя сервера. Тег CNF добавляется в атрибут CN. Например:

    cn <fqdn>CNF:ca69f501234

В этом случае необходимо удалить объект CNF (конфликтующий объект). Рекомендуется создать резервную копию AD, а затем удалить этот объект. После удаления объекта можно повторно выполнить проверку подлинности DHCP-сервера.

Дополнительные действия по устранению неполадок

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

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

Включение аудита изменений AD

  1. Откройте консоль управления групповыми политиками на контроллере домена или запустите gpmc.msc.

  2. Перейдите к домену>Domain_Name>политике контроллеров>домена по умолчанию.

  3. Щелкните правой кнопкой мыши и измените политику контроллера домена по умолчанию.

  4. Перейдите к политикам конфигурации компьютера Windows Settings>Advanced Audit Policy Configuration>>Policies Audit Policies>>DS Access>Audit Service Changes. Включите попытки успешного и неудачного выполнения .

Настройка аудита в контейнере "Конфигурация"

  1. Откройте adsiedit.msc.

  2. Подключитесь к контейнеру конфигурации .

  3. Перейдите к службам>NetServices.

  4. Щелкните его правой кнопкой мыши и выберите Свойства.

  5. Перейдите на вкладку "Безопасность " и выберите "Дополнительно".

  6. На вкладке "Аудит" нажмите кнопку "Добавить".

  7. Добавьте группу "Все" и включите аудит для:

    • Запись всех свойств
    • Удаление
    • Удаление поддерев

  8. Примените изменения.

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

См. следующий пример удаления событий:

A directory service object was deleted.

Subject:
    Security ID: <domain>\administrator
    Account Name: Administrator
    Account Domain: <domain>
    Logon ID: 0x35D447

Directory Service:
    Name: <url>
    Type: Active Directory Domain Services

Object:
    DN: CN=<fqdn>,CN=NetServices,CN=Services,CN=Configuration,DC=<domain>,DC=com

Дополнительные сведения см. в разделе "Настройка аудита" в контейнере конфигурации.

Сбор данных

Перед обращением в службу поддержки Майкрософт вы можете собирать сведения о проблеме.

Выполните действия, описанные в статье "Введение в набор инструментов TSSotingScript" (TSS), чтобы скачать и собрать журналы с помощью средства TSS. Затем используйте эту команду, чтобы включить сбор журналов на затронутом компьютере.

.\TSS.ps1 -Scenario NET_DHCPsrv