Итак, у меня есть домен Windows Active Directory с двумя контроллерами домена, DC1 и DC2оба работают под управлением Windows Server 2008 R2. DC1 является основным DC, выполняющим все роли FSMO. Он работал нормально, как и ожидалось, пока однажды у нас не возникла потребность в некоторых (паршивых) приложениях, которые по какой-то причине давали определенным пользователям возможность изменять время и дату на своих машинах. Мы установили объект групповой политики для конкретных пользователей (OU1иOU2) позволяя им изменять системное время:
Computer Configurations
-> Windows Settings
-> Security Settings
-> Local Policies
-> User Rights Assignment
-> Change the system time
И добавил группы, которым хочу передать это право. Однако после установки этих настроек на DC1, Я сделал gpupdate и была возвращена ошибка:
C:\Users\myuser>gpupdate
Updating Policy...
User Policy update has completed successfully.
Computer policy could not be updated successfully. The following errors were encountered:
The processing of Group Policy failed. Windows could not authenticate to the Active Directory service on a domain controller. (LDAP Bind function call failed).
Look in the details tab for error code and description.
To diagnose the failure, review the event log or run GPRESULT /H GPReport.html from the command line to access information about Group Policy results.
Я проверил средство просмотра событий и показало ошибку: EventID 1006, ErrorCode 49, ErrorDescription: Invalid Credentials.
Эта статья предполагает, что эта ошибка вызвана тем, что некоторая системная служба работает как учетная запись пользователя, учетные данные которой были изменены, и после проверки служб выяснилось, что ни один из них не работает как пользователь (все работают как локальная система, локальная служба , или сетевой сервис, и отображается в журналах как пользователь SYSTEM).
Политика не применялась к пользователям, и в некоторых срочных случаях нам приходилось вручную обходиться. Бег gpupdate на DC2 не дает ошибок, поэтому мы подумали о передаче ролей FSMO в DC2 и удаление DC1 и переформатируйте его (или что-то вроде того, что отчаянные админы делают в наши дни: D) в крайнем случае. Прямо сейчас мы передали роли, и все еще работаем gpupdate (и gpupdate /force) приводит к той же ошибке в DC1 но плавно работает в DC2. Однако политика не применялась. В чем проблема и где мы ошибаемся? И как это исправить?
P.S. Я также дважды проверил DNS и использовал анализатор рекомендаций Active Directory Role, но он дал мне только пару предупреждений об отсутствии резервного копирования и ошибку о настройке синхронизации времени.
ОБНОВИТЬ: Кто-то опубликовал ответ (удален вскоре после этого), что он / она столкнулся с той же проблемой и нашли ли мы решение .. Нет, мы этого не сделали, мы просто заменили паршивое приложение, которому нужна была эта групповая политика ..
очистить кешированные учетные данные на машине
rundll32.exe keymgr.dll,KRShowKeyMgr
очистить учетные данные домена
запустить cmd как систему
c:\PSTools>psexec -i -s cmd.exe
PsExec v2.2 - Execute processes remotely
Copyright (C) 2001-2016 Mark Russinovich
Sysinternals - www.sysinternals.com
Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.
C:\Windows\system32>whoami
nt authority\system
Если вы запустите реестр Windows с привилегиями уровня SYSTEM и перейдете к «HKEY_LOCAL_MACHINE \ SECURITY \ CACHE», вы найдете в общей сложности 10 записей, начиная с NL1 и заканчивая NL10. Эти двоичные записи содержат кэшированные учетные данные пользователей на уровне домена. По умолчанию Windows позволяет кэшировать в общей сложности 10 учетных данных, и если все 10 записей заполнены, любые новые учетные данные, подлежащие кэшированию, будут перезаписаны датой валютирования в самой старой записи NL. Кроме того, чтобы узнать, сколько свободных записей осталось, просто подсчитайте количество записей, данные двоичного значения которых заполнены «0».