Noções básicas sobre a autenticação do Active Directory para SQL Server em Linux e em contêineres

  • Artigo

Aplica-se a:SQL Server – Linux

Este artigo fornece detalhes sobre como a autenticação do Active Directory funciona para o SQL Server implantado em Linux ou em contêineres.

Conceitos

Protocolo LDAP

O LDAP (Lightweight Directory Access Protocol) é um protocolo de aplicativo para trabalhar com vários serviços de diretório, incluindo o Active Directory. Os serviços de diretório armazenam informações de usuários e contas e informações de segurança, como senhas. Essas informações são criptografadas e compartilhadas com outros dispositivos na rede.

Para saber como proteger o LDAP, confira Como habilitar a conexão LDAP no Windows Server.

Kerberos

Kerberos é um protocolo de autenticação usado para verificar a identidade de um usuário ou computador host. Você pode considerar isso como uma maneira de verificar o cliente e o servidor.

Quando você trabalha em um ambiente heterogêneo (misto) em que há servidores e clientes Windows e não Windows, há dois tipos de arquivos necessários para trabalhar com serviços de diretório baseados no Active Directory:

  • Arquivos keytab (abreviação de "tabelas-chave")
  • Arquivos de configuração do Kerberos (krb5.conf ou krb5.ini)

O que é um arquivo keytab?

Os processos do servidor em sistemas Linux ou Unix não podem ser configurados para executar processos com uma conta de serviço do Windows. Para que um sistema Linux ou Unix faça logon automaticamente no Active Directory na inicialização, use um arquivo keytab.

Um keytab é um arquivo criptográfico que contém a representação de um serviço protegido por Kerberos e sua chave de longo prazo de seu nome da entidade de serviço associado no KDC (Centro de Distribuição de Chaves). A chave não é a própria senha.

As keytabs são usadas para:

  • autenticar o serviço para outro serviço na rede, ou
  • descriptografar o tíquete de serviço Kerberos de um usuário do diretório de entrada para o serviço.

O que é um arquivo krb5.conf?

O arquivo /etc/krb5.conf (também conhecido como krb5.ini) fornece entradas de configuração para as bibliotecas KRB5 (Kerberos v5) e GSSAPI (API do GNU Simple Authentication and Security Layer).

Essas informações incluem o domínio padrão, as propriedades de cada domínio (como centros de distribuição de chaves) e o tempo de vida do tíquete Kerberos padrão.

Esse arquivo é necessário para que a autenticação do Active Directory funcione. } é um arquivo INI, mas cada valor no par chave-valor pode ser um subgrupo entre krb5.conf e {.

Para obter mais informações sobre o arquivo krb5.conf, confira a Documentação do MIT Kerberos Consortium.

Configurar o Kerberos para SQL Server em Linux

Esses são os valores de que você precisa no servidor host em execução no SQL Server em Linux. Se você tiver outros serviços (não SQL Server) em execução no mesmo host, seu arquivo krb5.conf poderá precisar de várias entradas adicionais.

Veja um exemplo de arquivo krb5.conf para consulta:

[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.COM

  • libdefaults – o valor default_realm deve estar presente. Esse valor especifica o domínio ao qual a máquina host pertence.

  • realms (opcional) – para cada realm, o valor kdc pode ser definido para especificar quais Centros de Distribuição de Chaves o computador deve contatar ao pesquisar as contas do Active Directory. Se você definiu mais de um KDC, o KDC para cada conexão será selecionado por round-robin.

  • domain_realm (opcional) – os mapeamentos de cada realm podem ser fornecidos. Caso contrário, o SQL Server em Linux pressupõe que o domínio contoso.com é mapeado para o realm CONTOSO.COM.

Processo de autenticação do Kerberos

Assim como na autenticação Kerberos no Windows, as duas primeiras etapas para obter um TGT (tíquete de concessão de tíquete) são as mesmas:

  • Um cliente inicia o processo de logon enviando seu nome de usuário e senha (criptografados) ao DC (controlador de domínio).

  • Depois de verificar o nome de usuário e a senha em seu armazenamento interno, o DC retorna um TGT do usuário para o cliente.

O SQL Server em Linux usa o arquivo keytab para ler a senha do SPN (Nome da Entidade de Serviço) e descriptografa o blob criptografado, que ele usa para autorizar a conexão. As próximas etapas descrevem esse processo.

  • Uma vez que o usuário tenha o TGT, o cliente inicia uma conexão com o SQL Server especificando o nome do host e a porta da instância do SQL Server.

  • O cliente SQL cria internamente um nome da entidade de serviço no formato MSSQLSvc/<host>:<port>. Esse é um formato codificado na maioria dos clientes do SQL Server.

  • O cliente inicia o handshake Kerberos solicitando uma chave de sessão do DC para esse SPN. Tanto o TGT quanto o SPN são enviados para o controlador de domínio.

Diagram showing Active Directory authentication for SQL Server on Linux - Ticket-Granting Ticket and Service Principal Name sent to Domain Controller.

  • Depois que o DC valida o TGT e o SPN, ele envia a chave de sessão para o cliente a fim de se conectar ao SPN do SQL Server.

Diagram showing Active Directory authentication for SQL Server on Linux - session key returned to client by DC.

  • O blob criptografado da chave de sessão é enviado ao servidor.

Diagram showing Active Directory authentication for SQL Server on Linux - session key sent to server.

  • O SQL Server lê a senha do SPN do respectivo keytab (mssql.keytab), que é um arquivo em disco contendo tuplas criptografadas (SPN, senha).

  • O SQL Server descriptografa o blob criptografado do cliente com a senha que acabou de procurar a fim de obter o nome de usuário do cliente.

  • O SQL Server pesquisa o cliente na tabela de sys.syslogins para verificar se o cliente está autorizado a se conectar.

  • A conexão é aceita ou negada.

Diagram showing Active Directory authentication for SQL Server on Linux - connection accepted or denied.

Configurar Kerberos para contêineres do SQL Server

A autenticação do Active Directory para o SQL Server em contêineres é essencialmente a mesma que para o SQL Server em Linux. A única diferença é o SPN do host do SQL Server. No cenário anterior, o SPN era MSSQLSvc/<host>:<port> porque a conexão se deu pelo nome do host do SQL Server. No entanto, agora precisamos nos conectar ao contêiner.

No caso de contêineres do SQL Server, você pode criar o arquivo krb5.conf dentro do contêiner. O nó do host que executa o contêiner não precisa fazer parte do domínio, mas deve conseguir alcançar o controlador de domínio ao qual o contêiner tentará se conectar.

Como estamos nos conectando a um contêiner, o nome do servidor na conexão do cliente pode ser diferente do nome do host. Ele pode ser o nome do host, o nome do contêiner ou outro alias. Além disso, há uma boa chance de que a porta exposta do SQL Server não seja o padrão 1433.

Você precisará usar o SPN armazenado em mssql.keytab para se conectar ao contêiner do SQL Server. Por exemplo, se o SPN em mssql.keytab for MSSQLSvc/sqlcontainer.domain.com:8000, você deverá usar sqlcontainer.domain.com,8000 como sua cadeia de conexão no cliente (incluindo sqlcmd, SQL Server Management Studio e Azure Data Studio).

Diagram showing Active Directory authentication for SQL Server Containers.

Atualização do grupo de SQL Server

Você pode estar se perguntando por que há uma conta de usuário no keytab se você só precisa de um nome de entidade de serviço para a autenticação.

Imagine que você tenha um usuário adUser, que é membro de um grupo adGroup. Se adGroup for adicionado como logon para o SQL Server, o adUser também terá permissão para fazer logon na instância do SQL Server. Embora o adUser ainda esteja conectado ao SQL Server, um administrador de domínio poderá remover adUser de adGroup. Agora, o adUser não deveria mais ter permissão para entrar no SQL Server, mas já passou pelo processo de autenticação Kerberos e está conectado.

Periodicamente, executamos um processo chamado atualização de grupo para proteção contra possíveis cenários em que usuários conectados não tenham mais permissão para executar ações privilegiadas (como criar um logon ou alterar um banco de dados).

O SQL Server tem uma conta do Active Directory privilegiada usada para a atualização de grupo. Essa conta é configurada usando mssql-conf com a definição network.privilegedadaccount, ou o padrão é a conta do computador host (<hostname>$).

As credenciais da conta privilegiada em mssql.keytab são usadas para representar o cliente (adUser, neste exemplo). O SQL Server faz um handshake Kerberos em si mesmo para identificar as informações de associação do grupo e as compara com sys.syslogins para verificar se o adUser ainda tem as permissões necessárias para conectar e executar os comandos Transact-SQL solicitados. Se adUser tiver sido removido de adGroup, a conexão será encerrada pelo SQL Server.

A atualização de grupo exige as duas seguintes condições:

  • Conectividade de rede entre a instância do SQL Server e o domínio do Active Directory local.
  • Relação de confiança bidirecional entre o domínio ao qual o SQL Server está conectado e o domínio do Active Directory local. Para obter mais informações, confira Noções básicas sobre o Active Directory.

Conteúdo relacionado