Partilhar via

Compreender a autenticação do Ative Directory para SQL Server em Linux e contêineres

Aplica-se a:SQL Server em Linux

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

Conceitos

Protocolo LDAP (Lightweight Directory Access Protocol)

LDAP é um protocolo de aplicativo para trabalhar com vários serviços de diretório, incluindo o Ative Directory. Os serviços de diretório armazenam informações de usuário e conta e informações de segurança, como senhas. Essas informações são criptografadas e, em seguida, compartilhadas com outros dispositivos na rede.

Para saber mais sobre como proteger o LDAP, consulte Como habilitar a assinatura 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 pensar nisso como uma maneira de verificar o cliente e o servidor.

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

  • Ficheiros Keytab (abreviação de "tabelas de chaves")
  • Arquivos de configuração Kerberos (krb5.conf ou krb5.ini)

O que é um arquivo keytab?

Os processos de servidor em sistemas Linux ou Unix não podem ser configurados para executar processos com uma conta de serviço do Windows. Quando você quiser que um sistema Linux ou Unix faça login automaticamente no Ative Directory na inicialização, você deve usar um keytab arquivo.

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

Keytabs são usados para uma das seguintes opções:

  • autenticar o próprio serviço para outro serviço na rede, ou
  • descriptografar o ticket de serviço Kerberos de um utilizador do diretório de entrada para o serviço.

O que é um arquivo krb5.conf?

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

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 padrão do tíquete Kerberos.

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

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

Configurar Kerberos para SQL Server no Linux

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

Aqui está um exemplo de arquivo krb5.conf para referência:

[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 a máquina deve contatar ao procurar contas do Ative Directory. Se tiver definido mais de um KDC, o KDC para cada conexão será selecionado por rodízio.

  • domain_realm (opcional) - Mapeamentos para cada reino podem ser fornecidos. Caso contrário, o SQL Server no Linux assume que o domínio contoso.com corresponde ao realm CONTOSO.COM.

O processo de autenticação Kerberos

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

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

  • Depois de verificar o nome de utilizador e a senha em relação ao seu armazenamento interno, o DC retorna um TGT do utilizador para o cliente.

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

  • Depois que o usuário tiver o TGT, o cliente iniciará 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 Principal de Serviço no formato MSSQLSvc/<host>:<port>. Este é um formato codificado na maioria dos clientes SQL Server.

  • O cliente inicia o handshake Kerberos solicitando uma chave de sessão do DC para esse SPN. Tanto o TGT como o SPN são enviados para o DC.

Diagrama mostrando a autenticação do Active Directory para SQL Server no Linux: Ticket-Granting Ticket e Nome do Principal de Serviço enviados ao Controlador de Domínio.

  • Depois que o DC valida o TGT e o SPN, ele envia a chave de sessão para o cliente, para conexão com o SPN do SQL Server.

Diagrama mostrando a autenticação do Ative Directory para SQL Server no Linux - chave de sessão retornada ao cliente pelo DC.

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

Diagrama mostrando a autenticação do Ative Directory para SQL Server no Linux - chave de sessão enviada ao servidor.

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

  • O SQL Server descriptografa o blob criptografado do cliente com a senha que ele acabou de pesquisar, para obter o nome de usuário do cliente.

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

  • A conexão é aceita ou negada.

Diagrama mostrando a autenticação do Ative Directory para SQL Server no Linux - conexão aceita ou negada.

Configurar Kerberos para contêineres do SQL Server

A autenticação do Ative Directory para SQL Server em contêineres é essencialmente a mesma do SQL Server no Linux. A única diferença é o SPN de host do SQL Server. No cenário anterior, o SPN foi MSSQLSvc/<host>:<port> porque estávamos nos conectando por meio do nome do host do SQL Server. Agora, no entanto, precisamos nos conectar ao contêiner.

Para contêineres do SQL Server, você pode criar o arquivo krb5.conf dentro do contêiner. O nó do host que executa o contentor não precisa fazer parte do domínio, mas deve ser capaz de conectar-se ao controlador de domínio ao qual o contentor tentará se ligar.

Como estamos nos conectando a um contêiner, o nome do servidor na conexão do cliente pode ser diferente de apenas o nome do host. 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 para o SQL Server não seja a 1433padrão.

Você deve usar o SPN armazenado no 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, usaria sqlcontainer.domain.com,8000 como cadeia de ligação no cliente.

Observação

Você pode se conectar a uma instância do SQL Server usando qualquer ferramenta de cliente familiar do SQL Server, como sqlcmd, SQL Server Management Studio (SSMS) ou a extensão MSSQL para Visual Studio Code.

Diagrama mostrando a autenticação do Ative Directory para contêineres do SQL Server.

Atualização de grupo do SQL Server

Pode estar a perguntar-se por que há uma conta de utilizador no arquivo keytab se apenas precisa de um Nome Principal de Serviço para autenticar.

Imagine que você tem um usuário adUser, que é membro de um grupo adGroup. Se o adGroup for adicionado como um logon ao SQL Server, isso significa que o adUser também tem permissão para entrar na instância do SQL Server. Embora o utilizador AD ainda esteja ligado ao SQL Server, um administrador de domínio pode remover o utilizador AD do grupo AD. Agora, adUser não deve 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 de atualização de grupo para proteger contra um cenário em que um usuário conectado não tem mais permissão para executar uma ação privilegiada (como criar um login ou alterar um banco de dados).

O SQL Server tem uma conta privilegiada do Ative Directory que usa para atualização de grupo. Esta conta é configurada usando mssql-conf com a definição network.privilegedadaccount, ou como padrão assume a conta da máquina host (<hostname>$).

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

A atualização de grupo requer as duas condições a seguir:

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

Conteúdo relacionado

  • Last updated on