Problema: The system detected a possible attempt to compromise security (Parte 1)
Hoje me deparei com um problema bastante interessante em um servidor SQL e gostaria de compartilhar: o servidor retornava erro ao rodar a stored procedure sp_readerrorlog.
Msg 22004, Level 16, State 1, Line 0
Failed to open loopback connection. Please see event log for more information.
Msg 22004, Level 16, State 1, Line 0
error log location not found
Consultando o Event Log, encontrava-se a seguinte mensagem de erro:
Severity: 16 Error:-2146892976, OS: -2146892976 [Microsoft][SQL Server Native Client 10.0]SQL Server Network Interfaces: The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.
Nesse momento, o que fazer?
Decifrando o Código do Erro
Note que a mensagem de erro do Sistema Operacional é um número negativo (-2146892976). O seu significado está escondido na representação hexadecimal.
O primeiro passo é converter o número –2146892976, que corresponde a 0x80090350 em hexadecimal. A partir daqui fica mais fácil procurar pelo código de erro (https://www.bing.com/search?q=0x80090350) e encontrar a correspondência por SEC_E_DOWNGRADE_DETECTED.
Identificando a Origem do Erro
Após a descoberta do erro SEC_E_DOWNGRADE_DETECTED, o próximo passo é isolar qual componente está relacionado com o problema. Basta analisar com calma as mensagens de erro e a resposta aparecerá.
Msg 22004, Level 16, State 1, Line 0
Failed to open loopback connection. Please see event log for more information.Severity: 16 Error:-2146892976, OS: -2146892976 [Microsoft][SQL Server Native Client 10.0]SQL Server Network Interfaces: The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.
Captou? Ao executar a procedure sp_readerrorlog, houve a tentativa de abrir uma conexão com o próprio servidor (loopback connection) usando o provider SQL Server Native Client. Essa abertura de conexão falhou, retornando o erro 0x80090350.
O erro ocorreu durante a abertura de uma nova conexão. Por incrível que pareça, houve um erro na autenticação dentro do próprio servidor!
Falha de Autenticação
A sequência dos fatos foi assim:
- DBA chama a stored procedure sp_readerrorlog
- A procedure inicia uma abertura de um loopback connection
- Durante o processo de autenticação, ocorre o erro SEC_E_DOWNGRADE_DETECTED
Seria possível ocorrer uma falha de autenticação dentro do próprio servidor? Refiz essa pergunta a colegas que são mestres no assunto e recebi a resposta:
SEC_E_DOWNGRADE_DETECTED means that Kerberos failed with an unexpected error, and will not fall back to NTLM, common causes for this one: #1 domain controller cannot be found? (kerberos UDP?) or fragmentation issues (move to kerberos over TCP), so answering your question: yes could be a transient condition, but if happens regularly, netmon traces will be next step (kerberos logging might be helpful too)
A resposta é SIM, falha de autenticação pode ocorrer. No nosso caso, houve uma falha do Kerberos que causou esse tipo de comportamento.
Resolução do Erro
Após poucos minutos, o problema desapareceu. Mas caso continuasse, o próximo passo seria investigar a comunicação com o Domain Controller usando o Network Monitor (ou ferramentas semelhantes para captura de pacotes de rede).
Esse problema foi ocasionado por um fator externo ao SQL Server.
Loopback Connection
Por que o comando sp_readerrorlog precisaria abrir uma conexão loopback? Segue uma captura do Profiler com a resposta:
Comments
Anonymous
January 11, 2011
Fabricio você não postou as outras partes? Uma coisa que eu penso é que o protocolo Kerberos não é usado localmente. Só quando se acessa algo remoto, já que esse protocolo precisa acessar o Domain Controller. Não entendo bem o porque isso aconteceu é bem estranho. Vi esse evento no log do meu Log Shipping quando levei uma máquina para outro servidor e ela teve que autenticar em outro domínio.Anonymous
January 26, 2011
Pior que não! Esse foi um dos primeiros posts e não tinha me habituado ao jeito de "blogar". Então escrevi várias partes e depois consolidei praticamente tudo na Parte 1. Havia uma parte 2, que era bem mais complexa e acabei desistindo de colocar (na verdade, nem eu tinha entendido direito o que havia escrito). Voce disse certo: NTLM é usado para autenticação local, então, por que o Kerberos? Não sei... existe uma DMV chamada sys.dm_os_ring_buffers, que contém os Return Code referentes à interface de segurança. Acredito que a resposta esteja por lá. Como esse evento parou de acontecer, então não pude testar. Obrigado pelo comentário e mande notíficas se tiver ocorrendo esse problema no seu servidor. Abraços, Fabricio