Почему пониженный контроллер домена все еще аутентифицирует пользователей?
Всякий раз, когда пользователи входят на рабочие станции с учетными записями домена, этот пониженный DC проверяет их подлинность. Его журнал безопасности показывает их входы, выходы из системы и специальные входы в систему. Журналы безопасности наших новых контроллеров домена показывают некоторые входы и выходы из машины, но не имеют ничего общего с пользователями домена.
Задний план
- server1 (Windows Server 2008): недавно пониженный DC, файловый сервер
- server3 (Windows Server 2008 R2): новый DC
- server4 (Windows Server 2008 R2): новый DC
бревна
События журнала безопасности: http://imgur.com/a/6cklL .
Два примера событий от server1 :
Audit Success,3/31/2014 11:06:14 AM,Microsoft-Windows-Security-Auditing,4624,Logon,"An account was successfully logged on.
Subject:
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0
Logon Type: 3
New Logon:
Security ID: MYDOMAIN\auser
Account Name: auser
Account Domain: MYDOMAIN
Logon ID: 0x8b792ce
Logon GUID: {54063226-E9B7-D357-AD58-546793C9CA59}
Process Information:
Process ID: 0x0
Process Name: -
Network Information:
Workstation Name:
Source Network Address: 192.168.20.143
Source Port: 52834
Detailed Authentication Information:
Logon Process: Kerberos
Authentication Package: Kerberos
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
[ ... ]
Audit Success,3/31/2014 11:06:06 AM,Microsoft-Windows-Security-Auditing,4624,Logon,"An account was successfully logged on.
Subject:
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0
Logon Type: 3
New Logon:
Security ID: MYDOMAIN\anotheruser
Account Name: anotheruser
Account Domain: MYDOMAIN
Logon ID: 0x8b74ea5
Logon GUID: {7E74986A-7A4D-B6E0-5D6F-D8CF78E8C718}
Process Information:
Process ID: 0x0
Process Name: -
Network Information:
Workstation Name:
Source Network Address: 192.168.20.203
Source Port: 53027
Detailed Authentication Information:
Logon Process: Kerberos
Authentication Package: Kerberos
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
Пример события изменения политики аудита с сервера 3 (в журнале также есть события изменения политики аудита с изменениями, помеченными как «Успешно добавлено»):
System audit policy was changed.
Subject:
Security ID: SYSTEM
Account Name: SERVER3$
Account Domain: MYDOMAIN
Logon ID: 0x3e7
Audit Policy Change:
Category: Account Logon
Subcategory: Kerberos Authentication Service
Subcategory GUID: {0cce9242-69ae-11d9-bed3-505054503030}
Changes: Success removed
Попытки Решения
- Исправление DNS записей.
dcdiag /test:dnsсначала вернули ошибки после того, как сервер1 был понижен в должности. Например, в наших зонах прямого просмотра были устаревшие записи сервера имен. В итоге я открыл DNS Manager и удалил записи о проблемах вручную, а также убедился, что записи LDAP и Kerberos указывают на новые серверы. Например, __ldap.Default-First-Site .__ sites.dc .__ msdcs.mydomain.local_ указывает на server3.mydomain.local . - Проверка записей DNS с помощью
nslookup.nslookup -type=srv _kerberos._udp.mydomain.localвозвращает записи для server3 и server4 - ничего о server1 . - Очистка метаданных. После использования
ntdsutilдля очистки метаданных, как описано в этой статье TechNet ,ntdsutilкомандаlist servers in siteвозвращает только две записи, обе из которых выглядят нормально:- 0 - CN = SERVER4, CN = серверы, CN = первый сайт по умолчанию, CN = сайты, CN = конфигурация, DC = домен, DC = локальный
- 1 - CN = SERVER3, CN = серверы, CN = первый сайт по умолчанию, CN = сайты, CN = конфигурация, DC = mydomain, DC = локальный
- Удаление server1 из сайтов и служб Active Directory. После демонтажа server1 я заметил, что он остался в сайтах и службах Active Directory, хотя он больше не был указан в качестве глобального каталога. Я удалил его в соответствии с инструкциями в этой статье Microsoft KB .
- Перенос ролей хозяина операций на сервер3 . Роли хозяина операций немного за пределами моей компетенции, но я обычно
ntdsutilпередавал их все на сервер3 сегодня утром. Ошибок не было, но перезагрузки и тесты показали, что server1 все еще выполняет всю аутентификацию. - Перерегистрация с DNS и перезапуск netlogon . В сообщении на форуме предлагается запустить
ipconfig /registerdnsиnet stop netlogon && net start netlogonна новых серверах для решения связанной проблемы. Это не помогло. - Обеспечение того, чтобы победивший объект групповой политики на новых контроллерах домена включал аудит событий входа в систему и входа в учетную запись.
Другие потенциальные клиенты
- Та же проблема описана в этой серии сообщений на форуме . Там нет разрешения.
- Это также описано в этом вопросе на бирже экспертов . Комментарий, помеченный как ответ, гласит: «Если его [sic] больше не DC, то он никак не может обрабатывать какие-либо запросы на аутентификацию». Это было бы моей реакцией, но работа
dcdiagна сервере server1 подтверждает, что server1 не считает себя DC. И все же это единственный сервер, аутентифицирующий всех.
Что тут происходит?
auditpol /clearиgpupdate /forceна новых DC все работает. Я обязан @mfinni за то, что он указал мне направление настройки аудита GPO, когда я участвовал во всевозможных погонях за неисправностями!Пониженный DC ни в коем случае не будет продолжать аутентификацию входа в домен. То, что вы видите, это локальные события входа в систему. Когда вы входите на рядовой сервер с учетными данными домена, вы увидите локальные события входа в систему, а также соответствующие события проверки учетных данных на DC.
Когда вы входите на рядовой сервер с локальными учетными данными, вы по-прежнему видите локальные события входа в систему, но не видите никаких событий проверки учетных данных на DC.
источник