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 controlador de domínio rebaixado os autentica. Seu log de segurança mostra logons, logoffs e logons especiais. Os logs de segurança de nossos novos controladores de domínio mostram alguns logons e logoffs da máquina, mas nada a ver com os usuários do domínio.
fundo
- server1 (Windows Server 2008): DC, servidor de arquivos recentemente rebaixado
- server3 (Windows Server 2008 R2): novo controlador de domínio
- server4 (Windows Server 2008 R2): novo controlador de domínio
Histórico
Eventos de log de segurança: http://imgur.com/a/6cklL .
Dois eventos de amostra do 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 da política de auditoria do server3 (também há eventos de Alteração da política de auditoria no log com as alterações marcadas "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
Tentativas de soluções
- Corrigindo entradas DNS.
dcdiag /test:dnsa princípio retornou erros depois que o servidor1 foi rebaixado. Havia entradas desatualizadas do servidor de nomes em nossas zonas de pesquisa direta, por exemplo. Acabei abrindo o Gerenciador DNS 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 . - Verificando entradas DNS com
nslookup.nslookup -type=srv _kerberos._udp.mydomain.localretorna entradas para server3 e Server4 -nada sobre server1 . - Limpando Metadados. Depois de usar
ntdsutilpara limpar os metadados, conforme descrito neste artigo do TechNet , ontdsutilcomandolist servers in siteretorna apenas duas entradas, que parecem OK:- 0 - CN = SERVER4, CN = Servidores, CN = Primeiro Site Padrão, CN = Sites, CN = Configuração, DC = meu domínio, DC = local
- 1 - CN = SERVIDOR3, CN = Servidores, CN = Primeiro Site Padrão, CN = Sites, CN = Configuração, DC = meu domínio, DC = local
- Excluindo server1 dos Serviços e Sites do Active Directory. Após rebaixar o server1 , notei que ele permanecia nos Serviços e Sites do Active Directory, embora não estivesse mais listado como um catálogo global. Excluí-o de acordo com as instruções deste artigo da Microsoft KB .
- Transferindo funções de mestre de operações para o servidor3 . As funções de mestre de operações estão um pouco além do meu conhecimento, mas eu costumava
ntdsutiltransferi-las para o server3 esta manhã. Não houve erros, mas as reinicializações e testes mostraram que o server1 ainda estava fazendo toda a autenticação. - Registrando novamente com o DNS e reiniciando o logon de rede . Uma postagem no fórum sugeria a execução
ipconfig /registerdnsenet stop netlogon && net start netlogonnos novos servidores para resolver um problema relacionado. Não pareceu ajudar. - Garantir que o GPO vencedor nos novos controladores de domínio permita a auditoria de eventos de logon e logon de conta.
Outros leads
- O mesmo problema é descrito nesta série de postagens no fórum . Não há resolução.
- Também está descrito nesta pergunta no Exchange de Especialistas . O comentário marcado como resposta diz: "Se o seu [sic] não é mais um controlador de domínio, não há como ele processar qualquer solicitação de autenticação". Essa seria a minha reação, mas rodar
dcdiagno servidor1 confirma que o servidor1 não se considera um controlador de domínio. No entanto, ainda é o único servidor que autentica todos.
O que está acontecendo aqui?