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

Всякий раз, когда пользователи входят на рабочие станции с учетными записями домена, этот пониженный 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

Образец Изменение политики аудита событие от 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

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

1. Исправление записей DNS. dcdiag /test:dns сначала возвращал ошибки после server1 был понижен в должности. Например, в наших зонах прямого просмотра были устаревшие записи серверов имен. В итоге я открыл диспетчер DNS и вручную удалил проблемные записи, а также убедился, что записи 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 = Servers, CN = Default-First-Site, CN = Sites, CN = Configuration, DC = mydomain, DC = local.
   2. 1 - CN = SERVER3, CN = Servers, CN = Default-First-Site, CN = Sites, CN = Configuration, DC = mydomain, DC = local.
4. Удаление server1 из сайтов и служб Active Directory. После понижения server1, Я заметил, что он остался в Active Directory Sites and Services, хотя больше не числился в глобальном каталоге. Я удалил его по инструкции в эта статья Microsoft KB.
5. Перенос ролей хозяина операций в server3. Роли мастера операций немного выходят за рамки моего понимания, но я использовал ntdsutil передать их все server3 этим утром. Ошибок не было, но перезагрузки и тесты показали, что server1 по-прежнему выполнял всю аутентификацию.
6. Повторная регистрация в DNS и перезапуск netlogon. Сообщение на форуме предлагало запустить ipconfig /registerdns и net stop netlogon && net start netlogon на новых серверах для решения связанной проблемы. Похоже, это не помогло.
7. Обеспечение того, чтобы победивший объект групповой политики на новых контроллерах домена включал аудит событий входа и входа в учетную запись.

Другие лиды

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

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