[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.

Link do Artigo

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.

1

Imagem01

3

Imagem02

Abaixo em não conseguir registrar os SPN, esse processo é criado automaticamente

2

Imagem03

Abaixo logs de Kerberos.

12 - cópia

Imagem04

Abaixo outro erro de Log Kerberos.

13

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;

1

2

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:

5

 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.

2019-05-19_18-57-30

 Imagem09

  • Conforme imagem abaixo, não habilitar essas opções.

sql

 Imagem10

  • Conforme imagem abaixo habilitar, somente esta opção.

serpro

 Imagem11

4 – Verificar as contas no ADSIEDIT, Service Principal Name

22

 Imagem12

23

  Imagem13

25

  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

26

  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.

27

 Imagem16

6 – Permissão no AD para registar automaticamente SPN:

Permissões para a conta de Serviço:

Read public information.

Write public information.

2019-05-22_01-15-50

 Imagem17

  • DAS TELAS FINAIS DEPOIS DO PROCESSO TROUBLESHOOTING (SUCESSO)

Abaixo um query mais refinada, e com maiores detalhes (origem e destino).

16   

 Imagem18

Abaixo query final, com conexões Kerberos (sucesso).

18 

 Imagem19