Por que um controlador de domínio rebaixado ainda está autenticando usuários?
Sempre que os usuários fazem logon em estações de trabalho com contas de domínio, esse DC rebaixado os autentica. Seu log de segurança mostra seus logons, logoffs e logons especiais. Os registros de segurança de nossos novos DCs mostram alguns logons e logoffs de máquinas, mas nada a ver com usuários de domínio.
Eventos de registro de segurança: link .
Dois exemplos de eventos de 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
Exemplo de evento de alteração de política de auditoria de server3 (há também eventos de alteração de política de auditoria no log com alterações marcadas como "sucesso adicionado") :
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
dcdiag /test:dns no início retornou erros depois que server1 foi rebaixado. Havia entradas desatualizadas do servidor de nomes em nossas zonas de pesquisa direta, por exemplo. Acabei abrindo o DNS Manager e removendo as entradas do problema manualmente, garantindo também que as entradas LDAP e Kerberos apontassem para os novos servidores. Por exemplo, __ldap.Default-First-Site .__ sites.dc .__ msdcs.mydomain.local_ aponta para server3.mydomain.local . nslookup . nslookup -type=srv _kerberos._udp.mydomain.local retorna entradas para server3 e server4 - nada sobre server1 . ntdsutil para limpar os metadados, conforme descrito neste artigo do TechNet , o ntdsutil command list servers in site retorna apenas duas entradas, que parecem estar corretas:
ntdsutil para transferi-las para server3 esta manhã. Não houve erros, mas reinicializações e testes mostraram que server1 ainda estava fazendo toda a autenticação. ipconfig /registerdns e net stop netlogon && net start netlogon nos novos servidores para resolver um problema relacionado. Não parece ajudar. dcdiag em server1 confirma que server1 não se considera um DC. No entanto, ainda é o único servidor que autentica todo mundo. O que está acontecendo aqui?
É um servidor de arquivos - os usuários estão se conectando a ele para obter acesso aos arquivos? É provável que você esteja vendo. Aqueles apareceriam nos logs de segurança.
Poste algumas entradas de log (em sua totalidade - dump de texto ou captura de tela) do server1 que está mostrando o comportamento que você está preocupado.
/ Edit - Obrigado por confirmar. O tipo de logon 3 é "Rede". Geralmente visto ao acessar arquivos compartilhados ou impressoras no computador que registrou o evento.
Um DC despromovido não continuará de forma alguma a autenticar os logons do domínio. O que você está vendo são eventos de logon locais . Quando você faz logon em um servidor membro com credencial de domínio, você verá eventos de logon localmente, além de eventos de validação de credenciais correspondentes no DC.
Quando você fazer logon servidor membro com credencial local, você ainda vê eventos de logon localmente, mas não verá quaisquer eventos de validação de credenciais em DC.