Таким образом, у меня есть Windows Active Directory Domain с двумя контроллерами домена, 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
, Я сделал a 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.
Я проверил Event Viewer, и он показал ошибку, EventID 1006, ErrorCode 49, ErrorDescription: Недопустимые Учетные данные.
Эта статья предполагает, что эта ошибка вызывается, потому что некоторая системная служба работает как учетная запись пользователя, учетные данные которой были изменены, и после проверки сервисов, оказалось, что ни один из них не работает как пользователь (все работают как локальная система, локальная служба или сетевая служба, и появляется в журналах как ПОЛЬЗОВАТЕЛЬ СИСТЕМЫ).
Политика не была применена к пользователям, и мы должны были сделать некоторое ручное обходное решение для некоторых экстренных случаев. Выполнение gpupdate
на DC2
урожаи никакие ошибки, таким образом, мы думали о передаче ролей FSMO к DC2
и удаление DC1
и переформатируйте его (или независимо от того, что отчаянные администраторы делают в эти дни :D), как последнее прибежище. Прямо сейчас мы передали роли и все еще выполнение gpupdate
(и gpupdate /force
) результаты по той же ошибке в DC1
но выполнения гладко в DC2
. Однако политика не была применена. Какова проблема и где мы идем не так, как надо? И как мы можем зафиксировать это?
P.S. Я также проверил DNS дважды и использовал Ролевую лучшую практику Active Directory анализатор, но это только дало мне несколько предупреждений о не резервном копировании и ошибку об установке синхронизации времени.
ОБНОВЛЕНИЕ: Кто-то отправил ответ (удаленный вскоре после), что он или она перенес ту же проблему и нашли ли мы решение.. Нет мы не сделали, мы просто заменили паршивое приложение, для которого была нужна та групповая политика..
очистить кэшированные учетные данные на машине
rundll32.exe keymgr.dll,KRShowKeyMgr
очистить учетные данные домена
запустить cmd как систему
c : \ PSTools> psexec -i -s cmd.exe
PsExec v2.2 - удаленное выполнение процессов
Copyright (C) 2001-2016 Марк Руссинович
Sysinternals - www.sysinternals.com
Microsoft Windows [Версия 10.0.14393]
(c) Корпорация Microsoft, 2016 г. Все права защищены.
C: \ Windows \ system32> whoami
nt власть \ система
Если вы запустите реестр Windows с правами уровня SYSTEM и перейдете к «HKEY_LOCAL_MACHINE \ SECURITY \ CACHE», вы найдете всего 10 записей, начиная с NL1 и заканчивая NL10. Эти двоичные записи содержат кэшированные учетные данные пользователей на уровне домена. По умолчанию Windows позволяет кэшировать в общей сложности 10 учетных данных, и если все 10 записей заполнены, любые новые учетные данные, подлежащие кэшированию, будут перезаписаны датой валютирования в самой старой записи NL. Кроме того, чтобы узнать, сколько свободных записей осталось, просто подсчитайте количество записей, данные двоичного значения которых заполнены "0".