Почему пониженный контроллер домена все еще аутентифицирует пользователей?

Всякий раз, когда пользователи входят на рабочие станции с учетными записями домена, этот пониженный DC проверяет их подлинность. Его журнал безопасности показывает их входы, выходы из системы и специальные входы в систему. Журналы безопасности наших новых контроллеров домена показывают некоторые входы и выходы из машины, но не имеют ничего общего с пользователями домена.

Задний план

1. server1 (Windows Server 2008): недавно пониженный DC, файловый сервер
2. server3 (Windows Server 2008 R2): новый DC
3. 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

Попытки Решения

1. Исправление DNS записей. dcdiag /test:dnsсначала вернули ошибки после того, как сервер1 был понижен в должности. Например, в наших зонах прямого просмотра были устаревшие записи сервера имен. В итоге я открыл DNS Manager и удалил записи о проблемах вручную, а также убедился, что записи LDAP и Kerberos указывают на новые серверы. Например, __ldap.Default-First-Site .__ sites.dc .__ msdcs.mydomain.local_ указывает на server3.mydomain.local .
2. Проверка записей DNS с помощью nslookup. nslookup -type=srv _kerberos._udp.mydomain.localвозвращает записи для server3 и server4 - ничего о server1 .
3. Очистка метаданных. После использования ntdsutilдля очистки метаданных, как описано в этой статье TechNet , ntdsutilкоманда list servers in siteвозвращает только две записи, обе из которых выглядят нормально:
   1. 0 - CN = SERVER4, CN = серверы, CN = первый сайт по умолчанию, CN = сайты, CN = конфигурация, DC = домен, DC = локальный
   2. 1 - CN = SERVER3, CN = серверы, CN = первый сайт по умолчанию, CN = сайты, CN = конфигурация, DC = mydomain, DC = локальный
4. Удаление server1 из сайтов и служб Active Directory. После демонтажа server1 я заметил, что он остался в сайтах и ​​службах Active Directory, хотя он больше не был указан в качестве глобального каталога. Я удалил его в соответствии с инструкциями в этой статье Microsoft KB .
5. Перенос ролей хозяина операций на сервер3 . Роли хозяина операций немного за пределами моей компетенции, но я обычно ntdsutilпередавал их все на сервер3 сегодня утром. Ошибок не было, но перезагрузки и тесты показали, что server1 все еще выполняет всю аутентификацию.
6. Перерегистрация с DNS и перезапуск netlogon . В сообщении на форуме предлагается запустить ipconfig /registerdnsи net stop netlogon && net start netlogonна новых серверах для решения связанной проблемы. Это не помогло.
7. Обеспечение того, чтобы победивший объект групповой политики на новых контроллерах домена включал аудит событий входа в систему и входа в учетную запись.

Другие потенциальные клиенты

• Та же проблема описана в этой серии сообщений на форуме . Там нет разрешения.
• Это также описано в этом вопросе на бирже экспертов . Комментарий, помеченный как ответ, гласит: «Если его [sic] больше не DC, то он никак не может обрабатывать какие-либо запросы на аутентификацию». Это было бы моей реакцией, но работа dcdiagна сервере server1 подтверждает, что server1 не считает себя DC. И все же это единственный сервер, аутентифицирующий всех.

Что тут происходит?

Это файловый сервер - подключаются ли к нему пользователи, чтобы получить доступ к файлам? Это вероятно то, что вы видите. Они будут отображаться в журналах безопасности.

Опубликуйте некоторые записи журнала (полностью - текстовый дамп или снимок экрана) с сервера1, который показывает поведение, которое вас беспокоит.

/ Edit - Спасибо за подтверждение. Тип входа 3 - «Сеть». Чаще всего наблюдается при доступе к общим файлам или принтерам на компьютере, на котором зарегистрировано событие.

Пониженный DC ни в коем случае не будет продолжать аутентификацию входа в домен. То, что вы видите, это локальные события входа в систему. Когда вы входите на рядовой сервер с учетными данными домена, вы увидите локальные события входа в систему, а также соответствующие события проверки учетных данных на DC.

Когда вы входите на рядовой сервер с локальными учетными данными, вы по-прежнему видите локальные события входа в систему, но не видите никаких событий проверки учетных данных на DC.