Tutorial: Usar autenticação do Active Directory com o SQL Server em Linux

Aplica-se a: SQL Server – Linux

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

Este tutorial é composto pelas seguintes etapas:

• Ingressar host do SQL Server em domínio do Active Directory
• Criar usuário do Active Directory para SQL Server e definir SPN
• Configurar keytab do serviço SQL Server
• Proteger o arquivo keytab
• Configurar o SQL Server para usar o arquivo keytab para autenticação Kerberos
• Criar logons baseados no Active Directory no Transact-SQL
• Conectar-se ao SQL Server usando a autenticação do Active Directory

Pré-requisitos

Antes de iniciar a Autenticação do Active Directory, é necessário:

• Configurar um controlador de domínio do Active Directory (Windows) em sua rede
• Instalar o SQL Server
  • Início Rápido: Instalar o SQL Server e criar um banco de dados no Red Hat
  • Início Rápido: instalar o SQL Server e criar um banco de dados no SUSE Linux Enterprise Server
  • Início Rápido: Instalar o SQL Server e criar um banco de dados no Ubuntu

Ingressar host do SQL Server em domínio do Active Directory

Ingresse no host do SQL Server Linux com um controlador de domínio do Active Directory. Para saber mais sobre como ingressar um domínio do Active Directory, confira Ingressar SQL Server em um host Linux em um domínio do Active Directory.

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

Observação

As seguintes etapas usam seu nome de domínio totalmente qualificado (FQDN). Caso esteja no Azure, você deverá criar um FQDN antes de continuar.

1. No controlador de domínio, execute o comando do PowerShell New-ADUser para criar um usuário do Active Directory com uma senha que nunca expira. O exemplo a seguir dá à conta o nome sqlsvc, mas o nome dela poderá ser qualquer coisa que você quiser. Você deverá inserir uma nova senha para a conta.

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

   Observação

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

   1. Esta conta oferece suporte à criptografia Kerberos AES de 128 bits

   2. Esta conta dá suporte à criptografia Kerberos AES de 256 bits

2. Defina o SPN (ServicePrincipalName) para essa conta usando a ferramenta setspn.exe. O SPN deve ser formatado exatamente como especificado no exemplo a seguir. É possível localizar o nome de domínio totalmente qualificado do computador host do 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 você receber um erro, Insufficient access rights, verifique com seu administrador de domínio se você tem permissões suficientes para definir um SPN nessa conta. A conta usada para registrar um SPN precisará das permissões Write servicePrincipalName. Para obter mais informações, veja Registrar um nome de entidade de serviço para conexões de 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 ao keytab do serviço SQL Server seguindo as etapas na próxima seção.

Para obter mais informações, veja Registrar um nome de entidade de serviço para conexões de Kerberos.

Configurar keytab do serviço SQL Server

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

Importante

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

Entradas keytab do SPN

1. Verifique o KVNO (número de versão da chave) da conta do Active Directory criada na etapa anterior. Normalmente, é 2, mas poderia ser outro inteiro se você alterasse a senha da conta várias vezes. No computador host do SQL Server, execute os seguintes comandos:

   • Os exemplos abaixo pressupõem que o user esteja no domínio @CONTOSO.COM. Modifique o usuário e o nome de domínio para seu nome de usuário e seu 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 poderão levar vários minutos para serem propagados por meio de seu domínio, principalmente se ele for grande. Se você 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 acima só funcionarão se o servidor tiver ingressado em um domínio do Active Directory, que foi abordado na seção anterior.

2. Usando ktpass, adicione entradas keytab para cada SPN usando os seguintes comandos em um prompt de comando do computador Windows:

   • <DomainName>\<UserName> – conta de usuário do Active Directory
   • @CONTOSO.COM: use o nome do seu domínio
   • /kvno <#>: substitua <#> pelo KVNO obtido em uma etapa anterior
   • <StrongPassword>: use uma senha forte

   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 <StrongPassword>
   
   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 <StrongPassword>
   
   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 <StrongPassword>
   
   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 <StrongPassword>
   
   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 <StrongPassword>
   
   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 <StrongPassword>
   

   Observação

   Os comandos acima permitem codificações de criptografia AES e RC4 para autenticação do Active Directory. O RC4 é uma codificação de criptografia mais antiga e, se um nível mais alto de segurança for necessário, você poderá optar por criar as entradas keytab apenas com a codificação de criptografia AES. As duas últimas entradas de UserName devem estar em letras minúsculas, ou a autenticação da permissão poderá falhar.

3. Depois de executar o comando acima, você deverá ter um arquivo keytab chamado mssql.keytab. Copie o arquivo para o computador do SQL Server na pasta /var/opt/mssql/secrets.

4. Proteja o arquivo keytab.

   Qualquer pessoa com acesso ao esse arquivo keytab pode representar o SQL Server no domínio; portanto, restrinja o acesso ao arquivo de tal forma 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 opção de configuração a seguir precisa ser definida com a ferramenta 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 domainname\username ou username@domain. O SQL Server adiciona internamente o nome de domínio, conforme necessário, junto com esse nome de usuário, quando usado.

6. Use as etapas a seguir para configurar o SQL Server para ser iniciado usando o arquivo keytab para a autenticação Kerberos.

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

   Dica

   Opcionalmente, desabilite as conexões UDP com o controlador de domínio para aprimorar o desempenho. Em muitos casos, as conexões UDP falham consistentemente ao conectar-se a um controlador de domínio; portanto, você pode definir as opções de configuração no /etc/krb5.conf para 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 Active Directory no SQL Server.

Criar logons baseados no Active Directory no Transact-SQL

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

   CREATE LOGIN [CONTOSO\user] FROM WINDOWS;
   

2. Verifique se o logon 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 Active Directory

Entre em um computador cliente usando suas credenciais de domínio. Agora você pode se conectar ao SQL Server sem reinserir sua senha usando a Autenticação do Active Directory. Se você criar um logon para um grupo do Active Directory, qualquer usuário do Active 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 Active Directory depende de qual driver você está usando. Considere os exemplos nas seções a seguir.

sqlcmd em um cliente Linux ingressado em domínio

Entre em um cliente Linux ingressado em domínio usando SSH e suas credenciais de domínio:

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

Verifique se você instalou o pacote mssql-tools e conecte-se usando sqlcmd sem especificar credenciais:

sqlcmd -S mssql-host.contoso.com

Ao contrário das janelas do SQL, a autenticação Kerberos funciona para a conexão local no SQL Linux. No entanto, você ainda precisará fornecer o FQDN do host do SQL Linux, e a Autenticação do Active Directory não funcionará se você tentar se conectar a ., localhost, 127.0.0.1 etc.

SSMS em um cliente Windows ingressado em domínio

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

Autenticação do Active Directory usando outros drivers do cliente

A tabela a seguir descreve recomendações para outros drivers do 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 de Cadeia de Conexão.

Opções de configuração adicionais

Caso esteja usando utilitários de terceiros, como PBIS, VAS ou Centrify para ingressar o host do Linux no domínio do Active Directory e gostaria de forçar o SQL Server a usar a biblioteca OpenLDAP diretamente, você 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

Há utilitários, como o 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 o domínio do Active Directory não configurar o SSSD, é recomendável configurar a opção disablesssd como true. Embora não seja necessário, pois o SQL Server tentará usar o SSSD para Active Directory antes de fazer fallback para o mecanismo de OpenLDAP, seria mais eficaz configurá-lo para que o SQL Server faça chamadas OpenLDAP que ignoram diretamente o mecanismo de SSSD.

Se o controlador de domínio der suporte ao LDAPS, será possível forçar todas as conexões do SQL Server com os controladores de domínio para ocorrerem pelo LDAPS. Para verificar se seu cliente pode contatar o controlador de domínio pelo LDAPS, execute o seguinte comando Bash, ldapsearch -H ldaps://contoso.com:3269. Para configurar o SQL Server para usar apenas LDAPS, execute o seguinte:

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

Isso usará o LDAPS pelo SSSD se o ingresso no domínio do Active Directory no host for feito por meio do pacote SSSD e disablesssd não for definido como true. Se disablesssd for definido como true junto com forcesecureldap sendo definido como true, então ele usará o protocolo LDAPS sobre chamadas de biblioteca OpenLDAP feitas pelo SQL Server.

Post SQL Server 2017 CU 14

Do SQL Server 2017 (14.x) CU 14 em diante, se o SQL Server foi ingressado em um controlador de domínio do Active Directory usando provedores de terceiros e foi configurado para usar chamadas OpenLDAP para pesquisa geral do Active Directory definindo disablesssd como true, você pode usar a opção enablekdcfromkrb5 para forçar o SQL Server a usar a biblioteca krb5 para pesquisa KDC, em vez de pesquisa DNS inversa para o servidor KDC.

Isso pode ser útil para o cenário em que convém 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 em /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 ingressar o host Linux no domínio e, ao mesmo tempo, configurar o disablesssd como true para que o SQL Server use chamadas OpenLDAP em vez do SSSD para chamadas relacionadas ao Active Directory.

Observação

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

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

Conteúdo relacionado

• Criptografar conexões para o SQL Server no Linux
• Noções básicas sobre a autenticação do Active Directory para SQL Server no Linux e em contêineres
• Solucionar problemas de autenticação do Active Directory para SQL Server no Linux e em contêineres

Contribua com a documentação do SQL

Você sabia que pode editar conteúdo do SQL por conta própria? Ao fazer isso, além de melhorar nossa documentação, você também será creditado como um colaborador da página.

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