Имея проблему, которую я видел раньше, но еще не нашел решения, у меня есть несколько сайтов AD в одном домене, физически разделенных и логически разделенных разными подсетями и сайтами AD.
Когда учетная запись пользователя активируется после того, как она находится в отключенном состоянии на одном сайте, а затем пытается войти в систему на рабочей станции (на этом сайте), они получают сообщение для входа в систему, что их учетная запись все еще отключена.
При проверке для всех контроллеров домена локальный контроллер домена указывает, что пользователь включен, но, поскольку репликация еще не произошла, все остальные по-прежнему отключены. Тестирование с активированным пользователем, вводящим неправильные пароли, показывает, что событие неправильного пароля попадает в локальный контроллер домена, а также на основной контроллер домена для домена (но не на сайте пользователей). Я еще не смог найти правильные идентификаторы события в Win2k8. для неправильных попыток ввода пароля, поэтому я пока не могу сообщить, с какого DC возник неправильный запрос pw.
Все подсети верны, и в% systemroot \ debug \ netlogon.log на локальном контроллере домена нет ошибок, сервер возвращает его на правильном сайте, рабочая станция возвращает его на правильном сайте, а его сервер входа в систему является локальным контроллером домена, все Пути DFS возвращаются к локальному узлу DFS, и после входа в систему я не вижу никакого трафика к другому DC. Пинг доменного имени также разрешается в локальный DC. Мы также установили DNS, чтобы он указывал только на локальный DC.
Кто-нибудь знает, почему для этой настройки потребуется DC, отличный от локального, для разблокировки учетной записи? Пользователи хотели бы немедленно использовать свои учетные записи, поэтому решение этой проблемы будет очень полезным.
Клиенты Win 7, серверы Win 2k8 r2, функциональный домен 2003 в конфигурации с несколькими сайтами AD
Итак, вопрос в том, что вы думаете, что процесс аутентификации сначала связывается с удаленным DC, даже если есть локальный DC, на котором включена учетная запись.
Я подозреваю, что здесь происходит нечто большее, чем наблюдается.
Вот несколько вещей, которые вы можете сделать, чтобы собрать больше информации:
-Включите ведение журнала отладки Netlogon на рабочей станции:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters]
"DBFlag"=dword:24401F04
"MaximumLogFileSize"=dword:3200000
Это создает очень подробный журнал в C: \ Windows \ debug \ netlogon.log с большинством действий и решений, которые происходят во время аутентификации, а также процесса локатора сайта / контроллера домена.
-Проведите тест на рабочей станции, на которой можно воспроизвести симптом, сразу после перезапуска рабочей станции.
-Настройте захват пакетов NetMon для запуска на компьютере при запуске рабочей станции с использованием запланированной задачи. Настройте задачу для запуска как СИСТЕМА с наивысшими привилегиями. Команды будут примерно такими:
cd /d "C:\Program Files\Microsoft Network Monitor 3"
nmcap /network * /capture /DisableConversations /file c:\temp\test.cap:20M /StopWhen /TimeAfter 5 min /MinDiskQuota 100M
Подождите, пока захват корректно завершится через пять минут, прежде чем пытаться его использовать. Тест входа в систему необходимо завершить в течение пяти минут после перезапуска.
Это должно позволить вам подтвердить, что с локальным DC вообще не связываются. Если есть ссылка на удаленный DC, может быть дополнительная информация, чтобы определить причину.
Если процесс аутентификации успешен на рабочей станции, которая недавно была перезапущена, но терпит неудачу на рабочей станции, на которой недавно произошла ошибка аутентификации, это будет полезной информацией.