Como usar a autenticação integrada
O Microsoft ODBC Driver for SQL Server no Linux e macOS é compatível com conexões que usam a autenticação integrada Kerberos. Ele é compatível com o KDC (centro de distribuição de chaves) do MIT Kerberos e funciona com as bibliotecas do Kerberos v5 e GSSAPI (Interface de Programação de Aplicativo de Serviços Genéricos de Segurança).
Da versão 17.6 em diante, o driver também dá suporte à autenticação integrada com o Microsoft Entra ID usando uma conta federada, não obstante as limitações da biblioteca do sistema. Para obter mais informações, consulte O que é o Microsoft Entra ID?
Uso de autenticação integrada para se conectar ao SQL Server de um aplicativo ODBC
Você pode habilitar a autenticação integrada do Kerberos especificando Trusted_Connection=yes na cadeia de conexão do SQLDriverConnect ou do SQLConnect. Por exemplo:
Driver='ODBC Driver 18 for SQL Server';Server=your_server;Encrypt=yes;Trusted_Connection=yes
Ao se conectar com um DSN, você também pode adicionar Trusted_Connection=yes à entrada DSN em odbc.ini.
A opção -E de sqlcmd e a opção -T de bcp também podem ser usadas para especificar a autenticação integrada; veja Conectando-se com sqlcmd e Conectando-se com bcp para obter mais informações.
Verifique se a entidade de segurança do cliente que vai se conectar ao SQL Server já está autenticada com o KDC do Kerberos.
Não há suporte paraServerSPN e FailoverPartnerSPN .
Implantando um aplicativo de Driver ODBC do Linux ou do macOS desenvolvido para execução como serviço
Um administrador do sistema pode implantar um aplicativo para ser executado como um serviço que usa a Autenticação Kerberos para se conectar ao SQL Server.
Você precisa primeiro configurar o Kerberos no cliente e então verificar se o aplicativo pode usar a credencial Kerberos da entidade de segurança padrão.
Verifique se está usando o kinit ou PAM (módulo de autenticação conectável) para obter e armazenar em cache o TGT para a entidade de segurança que a conexão usa por meio de um dos seguintes métodos:
Execute
kinit, passando um nome da entidade de segurança e uma senha.Execute o
kinit, passando um nome de entidade e um local de um arquivo keytab contendo a chave da entidade criada peloktutil.Verifique se o logon no sistema foi feito usando o PAM (módulo de autenticação conectável) do Kerberos.
Quando um aplicativo é executado como um serviço, porque as credenciais do Kerberos expiram por padrão, renove as credenciais para garantir a disponibilidade contínua do serviço. O driver ODBC não renova as credenciais em si; verifique se há um trabalho ou script cron executado periodicamente para renovar as credenciais antes do término. Para evitar a exigência de senha para cada renovação, você pode usar um arquivo keytab.
Detalhes sobre formas de aplicar o Kerberos em serviços no Linux são fornecidos emKerberos Configuration and Use .
Acompanhando o acesso a um banco de dados
Um administrador de banco de dados pode criar uma trilha de auditoria de acesso a um banco de dados usando contas do sistema para acessar o SQL Server usando a Autenticação Integrada.
O logon no SQL Server usa a conta do sistema e não há nenhuma funcionalidade no Linux para representar o contexto de segurança. Portanto, é necessário mais que isso para determinar o usuário.
Para auditar atividades no SQL Server em nome dos usuários além da conta do sistema, o aplicativo precisa usar EXECUTE AS do Transact-SQL.
Para melhorar o desempenho do aplicativo, um aplicativo pode usar o pool de conexões com Autenticação Integrada e auditoria. No entanto, a combinação do pool de conexões, da Autenticação Integrada e da auditoria gera um risco de segurança, pois o gerenciador do driver unixODBC permite que diferentes usuários reutilizem conexões em pool. Para obter mais informações, consulte ODBC Connection Pooling.
Antes da reutilização, um aplicativo deve redefinir conexões em pool executando sp_reset_connection.
Usando o Active Directory para gerenciar identidades de usuário
Um administrador de sistema de aplicativos não precisa gerenciar conjuntos separados de credenciais de logon para o SQL Server. É possível configurar o Active Directory como um centro de distribuição de chaves (KDC) para Autenticação Integrada. Veja Microsoft Kerberos para obter mais informações.
Usando servidor vinculado e consultas distribuídas
Os desenvolvedores podem implantar um aplicativo que usa um servidor vinculado ou consultas distribuídas sem um administrador de banco de dados que mantenha conjuntos separados de credenciais SQL. Nessa situação, um desenvolvedor deve configurar um aplicativo para usar a autenticação integrada:
O usuário faz logon em um computador cliente e se autentica no servidor de aplicativos.
O servidor de aplicativos é autenticado como um banco de dados diferente e se conecta ao SQL Server.
O SQL Server autentica-se como um usuário de banco de dados para outro banco de dados (SQL Server.
Depois que a autenticação integrada for configurada, as credenciais serão passadas para o servidor vinculado.
Autenticação integrada e sqlcmd
Para acessar o SQL Server usando a autenticação integrada, use a opção -E de sqlcmd. Verifique se a conta que executa sqlcmd está associada à entidade de segurança cliente do Kerberos padrão.
Autenticação Integrada e bcp
Para acessar o SQL Server usando a autenticação integrada, use a opção -T de bcp. Verifique se a conta que executa bcp está associada à entidade de segurança cliente do Kerberos padrão.
É um erro usar -T com a opção -U ou -P.
Sintaxe com suporte para um SPN registrado pelo SQL Server
A sintaxe que os SPNs usam em cadeia de conexão ou atributos de conexão é a seguinte:
| Sintaxe | Descrição |
|---|---|
| MSSQLSvc/fqdn:port | O SPN padrão gerado pelo provedor quando o protocolo TCP é usado. port é um número de porta TCP. fqdn é um nome de domínio totalmente qualificado. |
Autenticando um computador Linux ou macOS com o Active Directory
Para configurar o Kerberos, insira dados no arquivo krb5.conf. krb5.conf está em /etc/, mas você pode fazer referência a outro arquivo usando a sintaxe, por exemplo, export KRB5_CONFIG=/home/dbapp/etc/krb5.conf. A seguir, é mostrado um arquivo krb5.conf de exemplo:
[libdefaults]
default_realm = YYYY.CORP.CONTOSO.COM
dns_lookup_realm = false
dns_lookup_kdc = true
ticket_lifetime = 24h
forwardable = yes
[domain_realm]
.yyyy.corp.contoso.com = YYYY.CORP.CONTOSO.COM
.zzzz.corp.contoso.com = ZZZZ.CORP.CONTOSO.COM
Se o computador Linux ou macOS está configurado para usar o protocolo DHCP com um servidor DHCP do Windows fornecendo os servidores DNS para usar, você pode usar dns_lookup_kdc=true. Agora você pode usar o Kerberos para entrar no seu domínio emitindo o comando kinit alias@YYYY.CORP.CONTOSO.COM. Os parâmetros passados para kinit diferenciam maiúsculas de minúsculas e o computador SQL Server configurado para estar no domínio deve ter esse usuário alias@YYYY.CORP.CONTOSO.COM adicionado para logon. Agora você pode usar conexões confiáveis (Trusted_Connection=YES em uma cadeia de conexão, bcp -T ou sqlcmd -E).
A hora no computador Linux ou macOS e a hora no KDC (Centro de Distribuição de Chaves para Kerberos) devem estar próximas. Verifique se a hora do seu sistema está definida corretamente, por exemplo, usando o protocolo NTP.
Se a autenticação Kerberos falhar, o driver ODBC do Linux ou macOS não usará autenticação NTLM.
Para obter mais informações sobre a autenticação de computadores Linux ou macOS com o Active Directory, confira Autenticar clientes Linux com o Active Directory. Para obter mais informações sobre como configurar o Kerberos, veja a Documentação do MIT Kerberos.