Чому контрольований доменний ідентифікатор все ще автентифікує користувачів?
Кожен раз, коли користувачі входять на робочі станції з обліковими записами домену, цей знижений постійний струм підтверджує їх автентичність. Її журнал безпеки показує їхні входи, виходи та спеціальні логотипи. У наших нових журналах безпеки постійних джерел безпеки відображаються деякі машинні входи та виходи, але нічого спільного з користувачами домену.
Фон
- server1 (Windows Server 2008): нещодавно демонтований DC, файловий сервер
- server3 (Windows Server 2008 R2): новий постійний струм
- server4 (Windows Server 2008 R2): новий постійний струм
Колода
Події журналу безпеки: http://imgur.com/a/6cklL .
Два зразкових події з сервера1 :
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
Зразок події зміни політики аудиту з server3 ( у журналі також є події зміни політики аудиту із змінами, позначеними "Успіх додано"):
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_ вказує на сервер3.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 = default-first-site, CN = Sites, CN = конфігурація, DC = мій домен, DC = локальний
- 1 - CN = SERVER3, CN = сервери, CN = default-first-site, CN = Sites, CN = конфігурація, DC = мій домен, DC = локальний
- Видалення server1 з сайтів та служб Active Directory Після демонтажу сервера1 я помітив, що він залишається в Сайтах та службах Active Directory, хоча він більше не зазначається як глобальний каталог. Я видалив її згідно з інструкціями в цій статті Microsoft KB .
- Перенесення головних ролей операцій на сервер3 . Основні ролі операцій трохи перевищують мій кен, але я
ntdsutilвсе-таки передав їх на сервер3 цього ранку. Помилок не було, але перезавантаження та тести показали, що server1 все ще робив всю автентифікацію. - Перереєстрація за допомогою DNS та перезапуск Netlogon . Повідомлення форуму запропонувало запустити
ipconfig /registerdnsіnet stop netlogon && net start netlogonна нових серверах, щоб вирішити пов’язану проблему. Здавалося, це не допомогло. - Забезпечення того, що перемогла GPO на нових контролерах домену дозволяє проводити аудит подій входу в систему та облікового запису.
Інші ведучі
- Ця ж проблема описана в цій серії публікацій на форумі . Немає резолюції.
- Це також описано в цьому питанні на експертній біржі . У коментарі, позначеному як відповідь, сказано: "Якщо його [sic] більше не є постійним струмом, тоді немає можливості обробити будь-які запити аутентифікації". Це була б моя реакція, але робота
dcdiagна сервері1 підтверджує, що server1 не вважає себе постійним струмом. І все-таки це єдиний сервер, який підтверджує всіх.
Що тут відбувається?