Solucionar problemas de autenticação do Active Directory para SQL Server em Linux e em contêineres
Aplica-se a:
SQL Server – Linux
Este artigo ajuda você a solucionar problemas de autenticação do Active Directory Domain Services com o SQL Server em Linux e em contêineres. Ele inclui verificações de pré-requisitos e dicas para uma configuração bem-sucedida do Active Directory, bem como uma lista de erros comuns e etapas de solução de problemas.
Validar configuração atual
Antes de começar a solução de problemas, você deverá validar o usuário atual, o mssql.conf, o SPN (Nome da Entidade de Serviço) e as configurações de realm.
Obtenha ou renove o TGT (tíquete de concessão de tíquete) do Kerberos usando
kinit:kinit privilegeduser@CONTOSO.COMExecute o seguinte comando, certificando-se de que o usuário sob o qual você está executando este comando tenha acesso ao
mssql.keytab:/opt/mssql/bin/mssql-conf validate-ad-config /var/opt/mssql/secrets/mssql.keytabPara obter mais informações sobre o comando
validate-ad-config, confira a ajuda usando o comando/opt/mssql/bin/mssql-conf validate-ad-config --help.
Pesquisa DNS e DNS reverso
As pesquisas DNS no nome de domínio e no nome NetBIOS devem retornar o mesmo endereço IP, que normalmente corresponde ao endereço IP do DC (controlador de domínio). Execute esses comandos no computador host SQL Server.
nslookup contoso nslookup contoso.comSe os endereços IP não correspondem, confira Unir SQL Server em um host Linux a um domínio do Active Directory para corrigir as pesquisas DNS e a comunicação com o controlador de domínio.
Execute uma pesquisa de rDNS (DNS inverso) para cada endereço IP listado nos resultados anteriores. Isso inclui endereços IPv4 e IPv6 quando aplicável.
nslookup <IPs returned from the above commands>Tudo deve retornar
<hostname>.contoso.com. Se esse não for o caso, confira os registros PTR (ponteiro) criados no Active Directory.Talvez seja necessário trabalhar com o administrador de domínio para que o rDNS funcione. Se não for possível adicionar entradas PTR para todos os endereços IP retornados, você também poderá limitar o SQL Server a um subconjunto de controladores de domínio. Essa alteração afeta todos os outros serviços que usam
krb5.confno host.Para obter mais informações sobre DNS reverso, confira O que é DNS reverso?
Verificar o arquivo keytab e as permissões
Verifique se você criou o arquivo keytab (tabela de chaves) e se mssql-conf está configurado para usar o arquivo correto com as permissões apropriadas. O keytab deve estar acessível para a conta de usuário
mssql. Para obter mais informações, confira Usar adutil para configurar a autenticação do Active Directory com SQL Server no Linux.Garanta que você pode listar o conteúdo do keytab e se adicionou SPNs, porta, tipo de criptografia e conta de usuário corretos. Se você não digitar as senhas corretamente ao criar os SPNs e entradas keytab, encontrará erros ao tentar entrar usando a autenticação do Active Directory.
klist -kte /var/opt/mssql/secrets/mssql.keytabConfira a seguir um exemplo de uma keytab de trabalho. O exemplo usa dois tipos de criptografia, mas você pode usar apenas um ou mais, dependendo dos tipos de criptografia com suporte em seu ambiente. No exemplo,
sqluser@CONTOSO.COMé a conta privilegiada (que corresponde à configuração network.privilegedadaccount em mssql-conf) e o nome do host para SQL Server ésqllinux.contoso.comouvindo na porta padrão 1433.$ kinit privilegeduser@CONTOSO.COM Password for privilegeduser@CONTOSO.COM: $ klist Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: privilegeduser@CONTOSO.COM Valid starting Expires Service principal 01/26/22 20:42:02 01/27/22 06:42:02 krbtgt/CONTOSO.COM@CONTOSO.COM renew until 01/27/22 20:41:57 $ klist -kte mssql.keytab Keytab name: FILE:mssql.keytab KVNO Timestamp Principal ---- ----------------- -------------------------------------------------------- 2 01/13/22 13:19:47 MSSQLSvc/sqllinux@CONTOSO.COM (aes256-cts-hmac-sha1-96) 2 01/13/22 13:19:47 MSSQLSvc/sqllinux@CONTOSO.COM (aes128-cts-hmac-sha1-96) 2 01/13/22 13:19:47 MSSQLSvc/sqllinux.contoso.com@CONTOSO.COM (aes256-cts-hmac-sha1-96) 2 01/13/22 13:19:47 MSSQLSvc/sqllinux.contoso.com@CONTOSO.COM (aes128-cts-hmac-sha1-96) 2 01/13/22 13:19:47 MSSQLSvc/sqllinux:1433@CONTOSO.COM (aes256-cts-hmac-sha1-96) 2 01/13/22 13:19:47 MSSQLSvc/sqllinux:1433@CONTOSO.COM (aes128-cts-hmac-sha1-96) 2 01/13/22 13:19:47 MSSQLSvc/sqllinux.contoso.com:5533@CONTOSO.COM (aes256-cts-hmac-sha1-96) 2 01/13/22 13:19:47 MSSQLSvc/sqllinux.contoso.com:5533@CONTOSO.COM (aes128-cts-hmac-sha1-96) 2 01/13/22 13:19:55 sqluser@CONTOSO.COM (aes256-cts-hmac-sha1-96) 2 01/13/22 13:19:55 sqluser@CONTOSO.COM (aes128-cts-hmac-sha1-96)
Validar informações de realm no krb5.conf
No
krb5.conf(localizado em/etc/krb5.conf), verifique se você forneceu valores para o realm padrão, informações de realm e mapeamento de domínio para realm. O exemplo a seguir é um arquivokrb5.confde amostra. Para obter mais informações, confira Entender a autenticação do Active Directory para SQL Server no Linux e em contêineres.[libdefaults] default_realm = CONTOSO.COM [realms] CONTOSO.COM = { kdc = adVM.contoso.com admin_server = adVM.contoso.com default_domain= contoso.com } [domain_realm] .contoso.com = CONTOSO.COM contoso.com = CONTOSO.COMVocê pode restringir SQL Server a entrar em contato com um subconjunto de controladores de domínio, o que é será útil se a sua configuração DNS retornar mais controladores de domínio do que SQL Server precisa contatar. O SQL Server em Linux permite que você especifique uma lista de controladores de domínio que o SQL Server contata com distribuição equilibrada ao executar uma pesquisa LDAP.
Há duas etapas precisam ser concluídas. Primeiro, modifique
krb5.confadicionando qualquer número de controladores de domínio necessários, prefixados comkdc =.[realms] CONTOSO.COM = { kdc = kdc1.contoso.com kdc = kdc2.contoso.com .. .. }Lembre-se que
krb5.confé um arquivo de configuração de cliente Kerberos comum. Portanto, todas as alterações feitas nesse arquivo afetarão outros serviços além do SQL Server. Antes de fazer alterações, consulte seu administrador de domínio.Você pode habilitar a configuração network.enablekdcfromkrb5conf usando mssql-conf e reiniciar o SQL Server:
sudo /opt/mssql/bin/mssql-conf set network.enablekdcfromkrb5conf true sudo systemctl restart mssql-server
Solucionar problemas do Kerberos
Confira os detalhes a seguir para ajudá-lo a solucionar problemas de autenticação do Active Directory e identificar mensagens de erro específicas.
Rastrear o Kerberos
Depois de criar o usuário, os SPNs e os keytabs e configurar mssql-conf para conferir se a configuração do Active Directory para SQL Server em Linux está correta, você poderá exibir as mensagens de rastreamento Kerberos para o console (stdout) ao tentar obter ou renovar o TGT Kerberos com a conta com privilégios, usando este comando:
root@sqllinux mssql# KRB5_TRACE=/dev/stdout kinit -kt /var/opt/mssql/secrets/mssql.keytab sqluser
Se não houver nenhum problema, você deverá ver uma saída semelhante à amostra a seguir. Caso contrário, o rastreamento fornece contexto sobre quais etapas você deve revisar.
3791545 1640722276.100275: Getting initial credentials for sqluser@CONTOSO.COM
3791545 1640722276.100276: Looked up etypes in keytab: aes256-cts, aes128-cts
3791545 1640722276.100278: Sending unauthenticated request
3791545 1640722276.100279: Sending request (202 bytes) to CONTOSO.COM
3791545 1640722276.100280: Initiating TCP connection to stream 10.0.0.4:88
3791545 1640722276.100281: Sending TCP request to stream 10.0.0.4:88
3791545 1640722276.100282: Received answer (185 bytes) from stream 10.0.0.4:88
3791545 1640722276.100283: Terminating TCP connection to stream 10.0.0.4:88
3791545 1640722276.100284: Response was from master KDC
3791545 1640722276.100285: Received error from KDC: -1765328359/Additional pre-authentication required
3791545 1640722276.100288: Preauthenticating using KDC method data
3791545 1640722276.100289: Processing preauth types: PA-PK-AS-REQ (16), PA-PK-AS-REP_OLD (15), PA-ETYPE-INFO2 (19), PA-ENC-TIMESTAMP (2)
3791545 1640722276.100290: Selected etype info: etype aes256-cts, salt "CONTOSO.COMsqluser", params ""
3791545 1640722276.100291: Retrieving sqluser@CONTOSO.COM from /var/opt/mssql/secrets/mssql.keytab (vno 0, enctype aes256-cts) with result: 0/Success
3791545 1640722276.100292: AS key obtained for encrypted timestamp: aes256-cts/E84B
3791545 1640722276.100294: Encrypted timestamp (for 1640722276.700930): plain 301AA011180F32303231313XXXXXXXXXXXXXXXXXXXXXXXXXXXXX, encrypted 333109B95898D1B4FC1837DAE3E4CBD33AF8XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
3791545 1640722276.100295: Preauth module encrypted_timestamp (2) (real) returned: 0/Success
3791545 1640722276.100296: Produced preauth for next request: PA-ENC-TIMESTAMP (2)
3791545 1640722276.100297: Sending request (282 bytes) to CONTOSO.COM
3791545 1640722276.100298: Initiating TCP connection to stream 10.0.0.4:88
3791545 1640722276.100299: Sending TCP request to stream 10.0.0.4:88
3791545 1640722276.100300: Received answer (1604 bytes) from stream 10.0.0.4:88
3791545 1640722276.100301: Terminating TCP connection to stream 10.0.0.4:88
3791545 1640722276.100302: Response was from master KDC
3791545 1640722276.100303: Processing preauth types: PA-ETYPE-INFO2 (19)
3791545 1640722276.100304: Selected etype info: etype aes256-cts, salt "CONTOSO.COMsqluser", params ""
3791545 1640722276.100305: Produced preauth for next request: (empty)
3791545 1640722276.100306: AS key determined by preauth: aes256-cts/E84B
3791545 1640722276.100307: Decrypted AS reply; session key is: aes256-cts/05C0
3791545 1640722276.100308: FAST negotiation: unavailable
3791545 1640722276.100309: Initializing KCM:0:37337 with default princ sqluser@CONTOSO.COM
3791545 1640722276.100310: Storing sqluser@CONTOSO.COM -> krbtgt/CONTOSO.COM@CONTOSO.COM in KCM:0:37337
3791545 1640722276.100311: Storing config in KCM:0:37337 for krbtgt/CONTOSO.COM@CONTOSO.COM: pa_type: 2
3791545 1640722276.100312: Storing sqluser@CONTOSO.COM -> krb5_ccache_conf_data/pa_type/krbtgt/CONTOSO.COM@CONTOSO.COM@X-CACHECONF: in KCM:0:37337
$ sudo klist
Ticket cache: KCM:0:37337
Default principal: sqluser@CONTOSO.COM
Valid starting Expires Service principal
12/28/2021 20:11:16 12/29/2021 06:11:16 krbtgt/CONTOSO.COM@CONTOSO.COM
renew until 01/04/2022 20:11:16
Habilitar o registro em log de PAL baseado em segurança e Kerberos
Você pode habilitar o registro em log security.kerberos e security.ldap para identificar mensagens de erro específicas na PAL (Camada de Abstração de Plataforma). Crie um arquivo logger.ini com o conteúdo /var/opt/mssql/ a seguir, reinicie o SQL Server e reproduza a falha. As mensagens de erro e de depuração do Active Directory da PAL serão registradas em /var/opt/mssql/log/security.log.
[Output:security]
Type = File
Filename = /var/opt/mssql/log/security.log
[Logger]
Level = Silent
[Logger:security.kerberos]
Level = Debug
Outputs = security
[Logger:security.ldap]
Level = debug
Outputs = security
Você não precisa reiniciar o SQL Server para que as alterações do agente sejam selecionadas do logger.ini, mas podem ocorrer falhas durante a inicialização do serviço do Active Directory durante a inicialização do SQL Server que, de outra forma, passariam despercebidas. Reiniciar o SQL Server garante que todas as mensagens de erro sejam capturadas.
O log de segurança continua a gravar na unidade até que você remova as alterações no logger.ini. Lembre-se de desabilitar o registro em log de security.kerberos e security.ldap depois de identificar e resolver o problema para evitar ficar sem espaço na unidade.
O agente PAL gera arquivos de log no seguinte formato:
<DATETIME> <Log level> [<logger>] <<process/thread identifier>> <message>
Por exemplo, uma linha de amostra do log está a seguir:
12/28/2021 13:56:31.609453055 Error [security.kerberos] <0003753757/0x00000324> Request ticket server MSSQLSvc/sql.contoso.com:1433@CONTOSO.COM kvno 3 enctype aes256-cts found in keytab but cannot decrypt ticket
Depois de habilitar o registro em log do PAL e reproduzir o problema, procure a primeira mensagem com um nível de log de Error, use a tabela a seguir para encontrar o erro e siga as diretrizes e recomendações para solucionar o problema.
Mensagens de erro comuns
Mensagem de erro: "Falha no logon. O logon é de um domínio não confiável e não pode ser usado com a autenticação do Windows."
Causa possível
Esse erro será encontrado quando você tentar registrar em log usando uma conta do Active Directory, depois de configurar a autenticação do Active Directory.
Diretrizes
Essa é uma mensagem de erro genérica e você deve habilitar o registro em log do PAL para identificar a mensagem de erro específica.
Você pode conferir essa lista de erros comuns para identificar a possível causa de cada erro e seguir as diretrizes de solução de problemas para resolver o problema.
Mensagem de erro: usuário ou grupo Windows NT "CONTOSO\user" não encontrado
Causa possível
Você poderá encontrar esse erro ao tentar criar o logon do Windows ou durante a atualização do grupo.
Diretrizes
Para validar o problema, siga as diretrizes, conforme documentado para "Falha no logon. O logon é de um domínio não confiável e não pode ser usado com a autenticação do Windows. (Microsoft SQL Server, Erro: 18452)" habilita o registro em log do PAL para identificar o erro específico e solucionar problemas de acordo.
Mensagem de erro: "Não foi possível procurar um nome de domínio curto devido a um erro"
Causa possível
A sintaxe Transact-SQL para criar um logon do Active Directory é:
CREATE LOGIN [CONTOSO\user] FROM WINDOWS;
O nome NetBIOS (CONTOSO) é necessário no comando, mas ao executar uma conexão LDAP no back-end, o FQDN do domínio (contoso.com) deverá ser fornecido. Para fazer essa conversão, uma pesquisa DNS é executada em CONTOSO para resolver o IP de um controlador de domínio, que pode ser vinculado a para consultas LDAP.
Diretrizes
A mensagem de erro "Não foi possível pesquisar um nome de domínio curto devido a um erro" sugere que nslookup para contoso não resolve para o endereço IP do controlador de domínio. Você deve revisar as consultas DNS e DNS reverso para confirmar que nslookup para NetBIOS e nome de domínio devem corresponder.
Mensagens de erro: "Não foi possível executar a pesquisa rDNS para o host <hostname> devido a um erro" ou "FQDN não retornado pela pesquisa rDNS"
Causa possível
Esta mensagem de erro indica principalmente que os registros DNS reversos (registros PTR) não existem para todos os controladores de domínio.
Diretrizes
Confira as consultas DNS e DNS reverso. Depois que os controladores de domínio que não têm entradas rDNS são identificados, há duas opções:
Adicionar entradas rDNS para todos os controladores de domínio
Essa não é uma configuração do SQL Server e deve ser definida no nível de domínio. Talvez seja necessário trabalhar com sua equipe de administração de domínio para criar os registros PTR necessários para todos os controladores de domínio retornados quando executar
nslookupno nome de domínio.Restringir SQL Server a um subconjunto de controladores de domínio
Se não for possível adicionar registros PTR para todos os controladores de domínio retornados, você poderá limitar o SQL Server a um subconjunto de controladores de domínio.
Mensagem de erro: "Falha ao se vincular ao servidor LDAP ldap://CONTOSO.COM:3268: Erro Local"
Causa possível
Este é um erro genérico do OpenLDAP, mas normalmente significa uma das duas coisas:
- Nenhuma credencial
- Problemas de rDNS
Aqui está um exemplo da mensagem de erro:
12/09/2021 14:32:11.319933684 Error [security.ldap] <0000000142/0x000001c0> Failed to bind to LDAP server ldap://[CONTOSO.COM:3268]: Local error
Diretrizes
Nenhuma credencial
Outras mensagens de erro serão lançadas primeiro se as credenciais não puderem ser carregadas para conexões LDAP. Você deve habilitar o registro em log do PAL e verificar se há mensagens de erro no log antes dessa. Se não houver nenhum outro erro, provavelmente não será um problema de credencial. Se for encontrado, trabalhe para corrigir a mensagem de erro exibida. Na maioria dos casos, será uma das mensagens de erro abordadas neste artigo.
Problemas de rDNS
Confira as consultas DNS e DNS reverso.
Quando a biblioteca OpenLDAP se conecta a um controlador de domínio, o FQDN de domínio (
contoso.com) ou o FQDN do DC (kdc1.contoso.com) é fornecido. Depois que a conexão for feita (mas antes de retornar êxito ao chamador), a biblioteca OpenLDAP verificará o IP do servidor ao qual ele se conectou. Ele executará uma pesquisa DNS inverso e verificará se o nome do servidor conectado ao (kdc1.contoso.com) corresponde ao domínio para o qual a conexão foi solicitada (contoso.com). Se isso não corresponder, a biblioteca OpenLDAP falhará na conexão como um recurso de segurança. É por isso que as configurações rDNS são muito importantes para o SQL Server em Linux e foram o foco deste documento.
Mensagem de erro: "Entrada de tabela de chave não encontrada"
Causa possível
Este erro indica problemas de acesso com o arquivo keytab ou que o keytab não tem todas as entradas necessárias.
Diretrizes
Garanta que o arquivo keytab tenha o nível de acesso e as permissões corretas. O local padrão e o nome do arquivo keytab é /var/opt/mssql/secrets/mssql.keytab. Para exibir as permissões atuais em todos os arquivos na pasta de segredos, você poderá executar este comando:
sudo ls -lrt /var/opt/mssql/secrets
Você pode usar estes comandos para definir as permissões e o nível de acesso no arquivo keytab:
sudo chown mssql /var/opt/mssql/secrets/mssql.keytab
sudo chmod 440 /var/opt/mssql/secrets/mssql.keytab
Para obter mais detalhes sobre como listar as entradas keytab e definir as permissões corretas, confira a seção anterior Verificar arquivo keytab e permissões. Se qualquer uma das condições dessa seção não for atendida, você verá este erro ou um equivalente: "Key table entry not found".
Mensagem de erro: "Nenhuma entrada de tabela de chave encontrada para <entidade de segurança>"
Causa possível
Ao tentar recuperar as credenciais de <principal> do keytab, nenhuma entrada aplicável foi encontrada.
Diretrizes
Siga a seção Verificar arquivo keytab e permissões deste documento para listar todas as entradas no keytab. Garanta que <principal> esteja presente. Neste caso, a conta principal geralmente é network.privilegedadaccount para a qual os SPNs são registrados. Se não estiver, adicione usando o comando adutil. Para obter mais informações, confira Usar adutil para configurar a autenticação do Active Directory com SQL Server no Linux.
Mensagem de erro: "Servidor de tíquete de solicitação <entidade de segurança> não encontrado na keytab (tíquete kvno <KVNO>)"
Causa possível
Este erro indica que o SQL Server não consegue encontrar uma entrada keytab para o tíquete solicitado com o KVNO (Número de Versão da Chave) especificado.
Diretrizes
Siga a seção Verificar arquivo keytab e permissões deste documento para listar todas as entradas no keytab. Se você não encontrar uma mensagem de erro que corresponde ao <principal> e ao KVNO, adicione essa entrada atualizando o arquivo keytab usando as etapas mencionadas nessa seção.
Você também pode executar o comando a seguir para obter o KVNO mais recente do DC. Antes de executar este comando, você precisará obter ou renovar o TGT Kerberos usando o comando kinit. Para obter mais informações, confira Usar adutil para criar um usuário do Active Directory para o SQL Server e definir o SPN (Nome da Entidade de Serviço).
kvno MSSQLSvc/<hostname>
Mensagem de erro: "Servidor de tíquete de solicitação <entidade de segurança> kvno <KVNO> encontrado na keytab, mas não com o enctype <tipo de criptografia>"
Causa possível
Este erro significa que o tipo de criptografia solicitado pelo cliente não estava presente na keytab do SQL Server.
Diretrizes
Para validar, siga a seção Verificar arquivo keytab e permissões deste documento para listar todas as entradas no keytab. Se você não encontrar uma mensagem de erro que corresponde ao principal, ao KVNO e ao tipo de criptografia, adicione essa entrada atualizando o arquivo keytab usando as etapas mencionadas nessa seção.
Mensagem de erro: "Servidor de tíquete de solicitação <entidade de segurança> do kvno <KVNO> enctype <tipo de criptografia> encontrado na keytab, mas não é possível descriptografar o tíquete"
Causa possível
Este erro indica que o SQL Server não conseguiu usar uma credencial do arquivo keytab para descriptografar a solicitação de autenticação de entrada. O erro geralmente é marcado por uma senha incorreta.
Diretrizes
Recrie o keytab usando a senha correta. Se você usar adutil, siga as etapas em Usar adutil para configurar a autenticação do Active Directory com SQL Server em Linux para criar o keytab com a senha correta.
Portas comuns
Esta tabela mostra as portas comuns usadas pelo SQL Server em Linux para configurar e administrar a autenticação do Active Directory.
| Serviço do Active Directory | Porta |
|---|---|
| DNS | 53 |
| LDAP | 389 |
| LDAPS | 636 |
| Kerberos | 88 |
Conteúdo relacionado
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de