Partilhar via


Tutorial: Usar a autenticação do Ative Directory com o SQL Server no Linux

Aplica-se a:SQL Server - Linux

Este tutorial explica como configurar o SQL Server no Linux para dar suporte à autenticação do Ative Directory, também conhecida como autenticação integrada. Para obter uma visão geral, consulte Autenticação do Active Directory para SQL Server no Linux.

Este tutorial consiste nas seguintes tarefas:

  • Associar o host do SQL Server ao domínio do Ative Directory
  • Criar usuário do Ative Directory para SQL Server e definir SPN
  • Configurar o keytab de serviço do SQL Server
  • Proteja o arquivo keytab
  • Configurar o SQL Server para usar o arquivo keytab para autenticação Kerberos
  • Criar logins baseados no Ative Directory no Transact-SQL
  • Conectar-se ao SQL Server usando a Autenticação do Ative Directory

Pré-requisitos

Antes de configurar a Autenticação do Ative Directory, você precisa:

Associar o host do SQL Server ao domínio do Ative Directory

Junte-se ao host Linux do SQL Server com um controlador de domínio do Ative Directory. Para obter informações sobre como ingressar em um domínio do Ative Directory, consulte ingressar o SQL Server em um host Linux a um domínio do Ative Directory.

Criar usuário do Ative Directory para SQL Server e definir SPN

Observação

As etapas a seguir usam o seu nome de domínio totalmente qualificado (FQDN). Se você estiver no Azure, deverá criar um FQDN antes de continuar.

  1. No controlador de domínio, execute o comando New-ADUser PowerShell para criar um novo usuário do Ative Directory com uma senha que nunca expira. O exemplo a seguir nomeia a conta sqlsvc, mas o nome da conta pode ser o que você quiser. Ser-lhe-á pedido que introduza uma nova palavra-passe para a conta.

    Import-Module ActiveDirectory
    
    New-ADUser sqlsvc -AccountPassword (Read-Host -AsSecureString "Enter Password") -PasswordNeverExpires $true -Enabled $true
    

    Observação

    É uma prática recomendada de segurança ter uma conta dedicada do Ative Directory para o SQL Server, para que as credenciais da instância do SQL Server não sejam compartilhadas com outros serviços usando a mesma conta. No entanto, você pode, opcionalmente, reutilizar uma conta existente do Ative Directory se souber a senha da conta (que é necessária para gerar um arquivo keytab na próxima etapa). Além disso, a conta deve ser habilitada para oferecer suporte à criptografia AES Kerberos de 128 bits e 256 bits (atributomsDS-SupportedEncryptionTypes) na conta de usuário. Para validar que a conta está habilitada para criptografia AES, localize a conta no utilitário Active Directory de Usuários e Computadores e selecione Propriedades. Localize o separador Contas em Propriedadese verifique se as duas caixas de seleção a seguir estão marcadas.

    1. Esta conta suporta criptografia Kerberos AES de 128 bits

    2. Esta conta suporta criptografia Kerberos AES de 256 bits

  2. Defina o ServicePrincipalName (SPN) para essa conta usando a ferramenta setspn.exe. O SPN deve ser formatado exatamente como especificado no exemplo a seguir. Você pode encontrar o nome de domínio totalmente qualificado da máquina que hospeda o SQL Server executando hostname --all-fqdns no host do SQL Server. A porta TCP deve ser 1433, a menos que você tenha configurado o SQL Server para usar um número de porta diferente.

    setspn -A MSSQLSvc/<fully qualified domain name of host machine>:<tcp port> sqlsvc
    setspn -A MSSQLSvc/<netbios name of the host machine>:<tcp port> sqlsvc
    

    Observação

    Se receber um erro, Insufficient access rights, verifique com o administrador do domínio se tem permissões suficientes para definir um SPN nesta conta. A conta usada para registrar um SPN precisará das Write servicePrincipalName permissões. Para obter mais informações, consulte Registar um nome de entidade de serviço para conexões Kerberos.

    Se você alterar a porta TCP no futuro, deverá executar o comando setspn novamente com o novo número da porta. Você também precisa adicionar o novo SPN à keytab do SQL Server, seguindo as etapas na próxima seção.

Para obter mais informações, consulte Registar um Nome Principal do Serviço para conexões Kerberos.

Configurar o keytab do serviço do SQL Server

Configurar a autenticação do Ative Directory para SQL Server no Linux requer uma conta de usuário do Ative Directory e o SPN criado na seção anterior.

Importante

Se a senha da conta do Ative Directory for alterada ou a senha da conta à qual os SPNs estão atribuídos for alterada, você deverá atualizar o keytab com a nova senha e o número da versão da chave (KVNO). Alguns serviços também podem alternar as senhas automaticamente. Revise todas as políticas de rotação de senha para as contas em questão e alinhe-as com as atividades de manutenção programadas para evitar tempo de inatividade inesperado.

Entradas de keytab do SPN

  1. Verifique o número da versão da chave (KVNO) para a conta do Ative Directory criada na etapa anterior. Geralmente é 2, mas pode ser outro inteiro se você alterou a senha da conta várias vezes. Na máquina host do SQL Server, execute os seguintes comandos:

    • Os exemplos abaixo assumem que o user está no domínio @CONTOSO.COM. Modifique o usuário e o nome de domínio para seu nome de usuário e domínio.
    kinit user@CONTOSO.COM
    kvno user@CONTOSO.COM
    kvno MSSQLSvc/<fully qualified domain name of host machine>:<tcp port>@CONTOSO.COM
    

    Observação

    Os SPNs podem levar vários minutos para se propagar pelo seu domínio, especialmente se o domínio for grande. Se receber o erro, kvno: Server not found in Kerberos database while getting credentials for MSSQLSvc/<fully qualified domain name of host machine>:<tcp port>@CONTOSO.COM, aguarde alguns minutos e tente novamente. Os comandos anteriores só funcionam se o servidor tiver sido associado a um domínio do Ative Directory, que foi abordado em uma seção anterior.

  2. Usando ktpass, adicione entradas keytab para cada SPN usando os seguintes comandos em um prompt de comando da máquina Windows:

    • <DomainName>\<UserName> - Conta de usuário do Ative Directory
    • @CONTOSO.COM - Use seu nome de domínio
    • /kvno <#> - Substitua <#> pelo KVNO obtido numa etapa anterior
    • <password> - Sua senha deve seguir a política de senha padrão do SQL Server. Por padrão, a senha deve ter pelo menos oito caracteres e conter caracteres de três dos quatro conjuntos a seguir: letras maiúsculas, letras minúsculas, dígitos de base 10 e símbolos. As palavras-passe podem ter até 128 caracteres. Use senhas tão longas e complexas quanto possível.
    ktpass /princ MSSQLSvc/<fully qualified domain name of host machine>:<tcp port>@CONTOSO.COM /ptype KRB5_NT_PRINCIPAL /crypto aes256-sha1 /mapuser <DomainName>\<UserName> /out mssql.keytab -setpass -setupn /kvno <#> /pass <password>
    
    ktpass /princ MSSQLSvc/<fully qualified domain name of host machine>:<tcp port>@CONTOSO.COM /ptype KRB5_NT_PRINCIPAL /crypto rc4-hmac-nt /mapuser <DomainName>\<UserName> /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno <#> /pass <password>
    
    ktpass /princ MSSQLSvc/<netbios name of the host machine>:<tcp port>@CONTOSO.COM /ptype KRB5_NT_PRINCIPAL /crypto aes256-sha1 /mapuser <DomainName>\<UserName> /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno <#> /pass <password>
    
    ktpass /princ MSSQLSvc/<netbios name of the host machine>:<tcp port>@CONTOSO.COM /ptype KRB5_NT_PRINCIPAL /crypto rc4-hmac-nt /mapuser <DomainName>\<UserName> /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno <#> /pass <password>
    
    ktpass /princ <UserName>@CONTOSO.COM /ptype KRB5_NT_PRINCIPAL /crypto aes256-sha1 /mapuser <DomainName>\<UserName> /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno <#> /pass <password>
    
    ktpass /princ <UserName>@CONTOSO.COM /ptype KRB5_NT_PRINCIPAL /crypto rc4-hmac-nt /mapuser <DomainName>\<UserName> /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno <#> /pass <password>
    

    Os comandos anteriores permitem cifras de criptografia AES e RC4 para autenticação do Ative Directory. RC4 é uma cifra de encriptação mais antiga e, se for necessário um maior grau de segurança, pode optar por criar as entradas keytab apenas com a cifra de encriptação AES.

    Observação

    As duas últimas entradas UserName devem estar em minúsculas ou a autenticação de permissão pode falhar.

  3. Depois de executar os comandos anteriores, você deve ter um arquivo keytab chamado mssql.keytab. Copie o arquivo para a máquina do SQL Server na pasta /var/opt/mssql/secrets.

  4. Proteja o arquivo keytab.

    Qualquer pessoa com acesso a esse arquivo keytab pode representar o SQL Server no domínio, portanto, certifique-se de restringir o acesso ao arquivo de modo que apenas a conta mssql tenha acesso de leitura:

    sudo chown mssql:mssql /var/opt/mssql/secrets/mssql.keytab
    sudo chmod 400 /var/opt/mssql/secrets/mssql.keytab
    
  5. A seguinte opção de configuração precisa ser definida com a ferramenta de mssql-conf para especificar a conta a ser usada ao acessar o arquivo keytab.

    sudo mssql-conf set network.privilegedadaccount <username>
    

    Observação

    Inclua apenas o nome de usuário e não o nome de domínio\nome de usuário ou username@domain. O SQL Server adiciona internamente o nome de domínio conforme necessário, juntamente com esse nome de usuário quando usado.

  6. Use as etapas a seguir para configurar o SQL Server para começar a usar o arquivo keytab para autenticação Kerberos.

    sudo mssql-conf set network.kerberoskeytabfile /var/opt/mssql/secrets/mssql.keytab
    sudo systemctl restart mssql-server
    

    Opcionalmente, você pode desabilitar conexões UDP com o controlador de domínio para melhorar o desempenho. Em muitos casos, as conexões UDP falham consistentemente ao se conectar a um controlador de domínio, para que você possa definir opções de configuração em /etc/krb5.conf ignorar chamadas UDP. Edite /etc/krb5.conf e defina as seguintes opções:

    /etc/krb5.conf
    [libdefaults]
    udp_preference_limit=0
    

Neste ponto, você está pronto para usar logons baseados no Ative Directory no SQL Server.

Criar logins baseados no Ative Directory no Transact-SQL

  1. Conecte-se ao SQL Server e crie um novo logon baseado no Ative Directory:

    CREATE LOGIN [CONTOSO\user]
        FROM WINDOWS;
    
  2. Verifique se o login agora está listado na exibição do catálogo do sistema sys.server_principals:

    SELECT name
    FROM sys.server_principals;
    

Conectar-se ao SQL Server usando a autenticação do Ative Directory

Entre em uma máquina cliente usando suas credenciais de domínio. Agora você pode se conectar ao SQL Server sem reinserir sua senha usando a autenticação do Ative Directory. Se você criar um logon para um grupo do Ative Directory, qualquer usuário do Ative Directory que seja membro desse grupo poderá se conectar da mesma maneira.

O parâmetro de cadeia de conexão específico para os clientes usarem a autenticação do Ative Directory depende do driver que você está usando. Considere os exemplos nas seções a seguir.

sqlcmd em um cliente Linux associado a um domínio

Entre em um cliente Linux associado a um domínio usando ssh e suas credenciais de domínio:

ssh -l user@contoso.com client.contoso.com

Certifique-se de ter instalado o pacote de mssql-tools e, em seguida, conecte-se usando sqlcmd sem especificar nenhuma credencial:

sqlcmd -S mssql-host.contoso.com

Diferente do SQL Windows, a autenticação Kerberos funciona para conexão local no SQL Linux. No entanto, você ainda precisa fornecer o FQDN do host SQL Linux e a autenticação do Ative Directory não funcionará se você tentar se conectar a ., localhost, 127.0.0.1, etc.

SSMS em um cliente Windows associado a um domínio

Entre em um cliente Windows associado a um domínio usando suas credenciais de domínio. Verifique se o SQL Server Management Studio está instalado e, em seguida, conecte-se à sua instância do SQL Server (por exemplo, mssql-host.contoso.com) especificando Autenticação do Windows na caixa de diálogo Conectar ao Servidor.

Autenticação do Ative Directory usando outros drivers de cliente

A tabela a seguir descreve recomendações para outros drivers de cliente:

Driver do cliente Recomendação
JDBC Use a autenticação integrada Kerberos para conectar o SQL Server.
ODBC Use a autenticação integrada.
ADO.NET Sintaxe da cadeia de conexão.

Opções de configuração adicionais

Se você estiver usando utilitários de terceiros, como PBIS, VASou Centrify para unir o host Linux ao domínio do Ative Directory e quiser forçar o SQL Server a usar a biblioteca OpenLDAP diretamente, poderá configurar a opção disablesssd com mssql-conf da seguinte maneira:

sudo mssql-conf set network.disablesssd true
systemctl restart mssql-server

Observação

Existem utilitários como realmd que configuram o SSSD, enquanto outras ferramentas como PBIS, VAS e Centrify não configuram o SSSD. Se o utilitário usado para ingressar no domínio do Active Directory não configurar o SSSD, deverá configurar a opção disablesssd para true. Embora não seja necessário, pois o SQL Server tentará usar o SSSD para o Ative Directory antes de voltar para o mecanismo OpenLDAP, seria mais eficiente configurá-lo para que o SQL Server faça chamadas OpenLDAP ignorando diretamente o mecanismo SSSD.

Se o controlador de domínio oferecer suporte a LDAPS, você poderá forçar todas as conexões do SQL Server com os controladores de domínio a serem feitas por LDAPS. Para verificar se o cliente pode entrar em contato com o controlador de domínio sobre LDAPS, execute o seguinte comando bash, ldapsearch -H ldaps://contoso.com:3269. Para definir o SQL Server para usar apenas LDAPS, execute o seguinte:

sudo mssql-conf set network.forcesecureldap true
systemctl restart mssql-server

Isso usará LDAPS sobre SSSD se a associação de domínio do Ative Directory no host foi feita via pacote SSSD e disablesssd não estiver definido como true. Se disablesssd estiver definido como true junto com forcesecureldap sendo definido como true, ele usará o protocolo LDAPS em chamadas de biblioteca OpenLDAP feitas pelo SQL Server.

Pós Atualização Cumulativa (CU) 14 do SQL Server 2017

A partir do SQL Server 2017 (14.x) CU 14, se o SQL Server tiver aderido a um controlador de domínio do Active Directory usando provedores de terceiros e estiver configurado para usar chamadas OpenLDAP para pesquisa geral do Active Directory, definindo disablesssd como verdadeiro, você também poderá usar a opção enablekdcfromkrb5 para forçar o SQL Server a usar a biblioteca krb5 para pesquisa KDC em vez de pesquisa reversa de DNS para servidor KDC.

Isso pode ser útil para o cenário em que você deseja configurar manualmente os controladores de domínio com os quais o SQL Server tenta se comunicar. E você usa o mecanismo de biblioteca OpenLDAP usando a lista KDC em krb5.conf.

Primeiro, defina disablesssd e enablekdcfromkrb5conf como true e, em seguida, reinicie o SQL Server:

sudo mssql-conf set network.disablesssd true
sudo mssql-conf set network.enablekdcfromkrb5conf true
systemctl restart mssql-server

Em seguida, configure a lista KDC de /etc/krb5.conf da seguinte maneira:

[realms]
CONTOSO.COM = {
  kdc = dcWithGC1.contoso.com
  kdc = dcWithGC2.contoso.com
}

Embora não seja recomendado, é possível usar utilitários, como realmd, que configuram o SSSD ao unir o host Linux ao domínio, enquanto configuram disablesssd como true para que o SQL Server use chamadas OpenLDAP em vez de SSSD para chamadas relacionadas ao Ative Directory.

Observação

Não há suporte para logon do SQL Server usando um FQDN (por exemplo, CONTOSO.COM\Username) . Use o formato CONTOSO\Username.

Não há suporte para logons do SQL Server de grupos de Domínio Local. Em vez disso, use grupos de Domínio de Segurança Global.

Contribuir para a documentação SQL

Você sabia que você mesmo pode editar conteúdo SQL? Se o fizer, não só ajudará a melhorar a nossa documentação, como também será creditado como contribuidor da página.

Para obter mais informações, consulte Como contribuir para a documentação do SQL Server