Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье устранена проблема, из-за которой приложение не может пройти проверку подлинности пользователей при завершении работы контроллера домена (DC).
Исходный номер базы знаний: 2683606
Симптомы
Приложения в домене используют NT Local Area Network Manager (NTLM) или Kerberos для проверки подлинности пользователей. Некоторые приложения имеют шаблон, в котором клиенты часто повторно подключаются к серверу приложений.
Приложения в основном затрагиваются при использовании NTLM. Приложения, использующие Kerberos, также могут быть затронуты, если проверка сертификата атрибута привилегий Kerberos (PAC) используется для проверки подлинности, принятой приложением. Невозможно отключить эти проверки во всех случаях.
В этом случае при завершении работы контроллера домена приложение может не проходить проверку подлинности пользователей, пока контроллер домена не отвечает в сети, а член домена выбрал другой контроллер домена для проверки подлинности.
В журналах диагностики и трассировках сети могут отображаться ошибки входа пользователя в систему или ошибка 0xc0000064 STATUS_NO_SUCH_USER, отображающая указанную учетную запись. Если вы используете Kerberos, вы можете увидеть ошибку 6, KDC_ERR_C_PRINCIPAL_UNKNOWN.
Причина
Существует две проблемы, которые могут произойти:
Когда контроллер домена находится на этапе завершения работы, он обычно сообщает текущим клиентам использовать другой контроллер домена для проверки подлинности с помощью кода ошибки 0xc00000dc (STATUS_INVALID_SERVER_STATE). Существует путь к коду, в котором эта проблема не происходит.
Сервер не будет отвечать на новые клиенты в запросах Протокола пользовательской диаграммы netlogon (UDP ). Кроме того, клиенты, получившие сообщение об ошибке завершения работы контроллера домена, не будут избегать выбора того же контроллера домена в последующем поиске контроллера домена.
Когда клиент выбирает контроллер домена во время завершения работы, запросы NTLM или Kerberos снова завершаются ошибкой. На этом этапе клиент перейдет в режим отрицательного кэша и завершится сбоем последующих запросов проверки подлинности.
В случае NTLM клиент является сервером приложений, поэтому он не может принимать новые клиенты до выбора рабочего контроллера домена.
Решение
Чтобы избежать проблемы, остановите службу Netlogon на контроллере домена перед началом завершения работы или перезапуска. Чтобы автоматизировать это действие, введите задачу остановки в локальном скрипте завершения работы для контроллера домена. Чтобы добраться до локальной групповой политики, выполните следующие действия.
Запуск Gpedit.msc
Откройте дерево параметров и перейдите к разделу": Завершение работы скриптов > параметров Windows конфигурации > > компьютера.
В командной строке нового скрипта введите
net stop netlogon && net stop kdc.
Хотя параметр реестра NegativeCachePeriod можно задать на низкое значение, это изменение не полностью избежать проблемы, так как клиент будет искать альтернативный контроллер домена чаще.
Дополнительная информация
В Netlogon.log клиента появится код ошибки STATUS_INVALID_SERVER_STATE из контроллера домена:
<Время> даты><[КРИТИЧЕСКОЕ] NlPrintRpcDebug: не удалось получить EEInfo для I_NetLogonSamLogonEx: 1761 (может быть законным для 0xc00000dc)
<><Домен> date Time> [CRITICAL]<: NlpUserValidateHigher: запрет доступа после состояния: 0xc00000dc 0
<><Домен> date Time> [SESSION]<: NlSetStatusClientSession: задайте состояние подключения для c00000dc
<Домен date Time> [SESSION]<: NlSetStatusClientSession: unbind from server \\<dc-name1>.<>><полное доменное имя> домена (TCP) 1.
Результаты, когда клиент пытается завершить работу контроллера домена в качестве одного из контроллеров домена:
<Домен> даты><и времени> [СЕАНС]<: NlSessionSetup: попробуйте настроить сеанс
<Домен> даты><и времени> [SESSION]<: NlDiscoverDc: запуск синхронного обнаружения
<Дата><> [MISC] NetpDcInitializeContext: DSGETDC_VALID_FLAGS — c01ffff1
<Дата><[>MAILSLOT] NetpDcPingListIp: домен>: <отправлен UDP ping до 10.10.103.87
<Дата><[> СЕАНС] NETLOGON_CONTROL_TC_QUERY функция, полученная.
<Время> даты><[MAILSLOT] NetpDcPingListIp: домен>: <отправлен UDP ping до 10.10.103.93
<Время> даты><[MAILSLOT] NetpDcPingListIp: <домен>: отправлен UDP ping до 10.10.103.92
Вторая связь отправляется в контроллер домена при завершении работы.
Контроллер домена ответит, хотя он уже вернул ошибку клиенту:
<Дата><> [ВХОД] HM-REBOOT: SamLogon: транзитивный сетевой <вход в домен>\test1 из HM-REBOOT-SRV1 (через HM-REBOOT-SRV1) ввели
<Время><> ДАТЫ [LOGON] HM-REBOOT: SamLogon: транзитивный вход <в сеть домена>\test1 из HM-REBOOT-SRV1 (через HM-REBOOT-SRV1) возвращает 0xC00000DC
...
<Дата><> [MAILSLOT] Получена связь из HM-REBOOT-SRV1 <\domain> (NULL) в UDP LDAP
<><Домен> Даты и времени> [MAILSLOT]<: ответ Ping Sam Logon Response Ex (null) на сайт \\<member server> Site: Default-First-Site-Name on UDP LDAP
<><Домен> Даты и времени> [MAILSLOT]<: ответ Ping Sam Logon Response Ex (null) на сайт \\<member server> Site: Default-First-Site-Name on UDP LDAP
Next Steps
Справочник по "NegativeCachePeriod":