Olá Ninjas e amantes da área, tudo bem!!
Nesse artigo, vamos compartilhar uma experiência que passamos de autenticação Kerberos + AD, seja em um único domínio e sub-domínios.
[LINK DO ARTIGO TECHNET]
[IMPORTANTE]
Esse artigo, foi criado e desenvolvido em conjunto com a equipe de Banco de Dados envolvida no problema, que são: André do Nascimento Vieira e Marcelo Bossa Godoy.
Também utilizamos como referência, o artigo do Dirceu Resende e Rodrigo Ribeiro Gomes.
Tivemos um problema em um cliente, no qual, fazia com que todos os Linked Servers que apontavam para algumas instâncias, começaram a apresentar o erro abaixo, tanto para tentar consultar dados quanto para tentar alterar objetos (como Stored Procedures) que utilizavam esse linked server.
- DOS ERROS:
Abaixo ao realizar acesso via Linked Server.
Imagem01
Imagem02
Abaixo em não conseguir registrar os SPN, esse processo é criado automaticamente
Imagem03
Abaixo logs de Kerberos.
Imagem04
Abaixo outro erro de Log Kerberos.
Imagem05
Estávamos com estes problemas em Servidores, do mesmo domínio e de outros domínios na mesma Floresta AD.
- DO PROCESSO DE TROUBLESHOOTING
Abaixo alguns códigos de erros e o link microsoft:
Vimos que nos erros, estávamos com problema de configuração no:
- SPN;
- DNS;
- Configurações Kerberos na conta de Computador e Usuário;
Imagem06
Link de todos os códigos Kerberos
1 – Utilizando uma query simples, conseguimos verificar a quantidade de conexões em cada modo de autenticação:
Imagem07
Como vimos acima durante a análise, não havia nenhuma conexão utilizando a autenticação Kerberos, apenas SQL (quando você utiliza logins SQL Server para conectar no SQL Server) e NTLM (Conexão utilizando Autenticação Windows quando o Kerberos não está disponível).
Segundo passo importante é habilitar auditoria nos servidores envolvidos, desta forma, entender melhor o que está acontecendo.
2 – Ativar o log do Kerberos:
Criar a chave de registro LogLevel (DWORD) com o valor = 1 no endereço HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters.
Imagem08
3 – Habilitar as contas de usuários e computador para Kerberos:
- Conforme imagem abaixo habilitar, somente esta opção.
Imagem09
- Conforme imagem abaixo, não habilitar essas opções.
Imagem10
- Conforme imagem abaixo habilitar, somente esta opção.
Imagem11
4 – Verificar as contas no ADSIEDIT, Service Principal Name
Imagem12
Imagem13
Imagem14
Código do erro: 0x19 KDC_ERR_PREAUTH_REQUIRED
Quando consultamos na internet, podemos entender que esse erro é “normal” do Kerberos e pode ser ignorado. Sendo assim, analisei os servidores registrados no SPN da conta de serviço do SQL Server Database Engine, que é um usuário do AD no formato “DOMINIO\Usuario”:
Listando os SPNs registrados para o conta do AD que executa o serviço do SQL Server, conforme imagem03.
setspn -L DOMINIO\usuario
Caso não crie automaticamente, pode registrar manualmente os registros do SPN dessa instância da mesma forma que eles haviam sido registrados inicialmente.
setspn -A MSSQLSvc/INSTANCIA.dominio.local:porta DOMINIO\USUARIO
setspn -A MSSQLSvc/INSTANCIA.dominio.local:INSTANCIA DOMINIO\USUARIO
Imagem15
5 – Outro processo importante é a questão de DNS, sejam:
– HostA;
Verificar esses registros se estão OK.
– Pointer (Ptr);
Verificar esses registros se estão OK.
– Sufixo DNS;
Caso tenha sub-domínios ou florestas, importante inserir isso no processo. No processo abaixo temos: Floresta ARQENGTI.CORP, 02 subdomínios SP e RJ.
Imagem16
6 – Permissão no AD para registar automaticamente SPN:
Permissões para a conta de Serviço:
Read public information.
Write public information.
Imagem17
- DAS TELAS FINAIS DEPOIS DO PROCESSO TROUBLESHOOTING (SUCESSO)
Abaixo um query mais refinada, e com maiores detalhes (origem e destino).
Imagem18
Abaixo query final, com conexões Kerberos (sucesso).
Imagem19
Esperam que tenham gostado, vamos juntos!
#disseminarconhecimento
Abraços FOL!
🔵Fábio FOL 
Discussão
Nenhum comentário ainda.