Compartilhar via


Girar a keytab gerenciada pelo cliente da Instância Gerenciada de SQL habilitada pelo Azure Arc

Este artigo descreve como girar keytabs gerenciados pelo cliente para a Instância Gerenciada de SQL habilitada pelo Azure Arc. Esses keytabs são usados para habilitar logons do Active Directory para a instância gerenciada.

Pré-requisitos:

Antes de prosseguir com este artigo, você deve ter um conector do Active Directory no modo keytab gerenciado pelo cliente e uma Instância Gerenciada de SQL habilitada pelo Azure Arc criada.

Como girar keytabs gerenciados pelo cliente em uma instância gerenciada

As seguintes etapas precisam ser seguidas para girar o keytab:

  1. Obtenha o valor kvno para a geração atual de credenciais para a conta do SQL MI Active Directory.
  2. Crie um novo arquivo de keytab com entradas para a geração atual de credenciais. Especificamente, o valor kvno deve corresponder à etapa (1.) acima.
  3. Atualize o novo arquivo de keytab com novas entradas para as novas credenciais para a conta do SQL MI Active Directory.
  4. Crie um segredo do kubernetes que contém o novo conteúdo do arquivo keytab no mesmo namespace que o SQL MI.
  5. Edite a especificação de MI do SQL para apontar a configuração do segredo do keytab do Active Directory para esse novo segredo.
  6. Altere a senha no domínio do Active Directory.

Fornecemos os seguintes scripts do PowerShell e bash que cuidarão das etapas 1 a 5 para você:

  • rotate-sqlmi-keytab.sh - Esse script bash usa ktutil ou adutil (se o --use-adutil sinalizador for especificado) para gerar o novo keytab para você.
  • rotate-sqlmi-keytab.ps1 - Esse script do PowerShell usa ktpass.exe para gerar o novo keytab para você.

A execução do script acima resultaria no seguinte arquivo de keytab para o usuário arcsqlmi@CONTOSO.COM, o segredo sqlmi-keytab-secret-kvno-2-3 e o namespace test:

KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   2 02/16/2023 17:12:05 arcsqlmiuser@CONTOSO.COM (aes256-cts-hmac-sha1-96) 
   2 02/16/2023 17:12:05 arcsqlmiuser@CONTOSO.COM (arcfour-hmac) 
   2 02/16/2023 17:12:05 MSSQLSvc/arcsqlmi.contoso.com@CONTOSO.COM (aes256-cts-hmac-sha1-96) 
   2 02/16/2023 17:12:05 MSSQLSvc/arcsqlmi.contoso.com@CONTOSO.COM (arcfour-hmac) 
   2 02/16/2023 17:12:05 MSSQLSvc/arcsqlmi.contoso.com:31433@CONTOSO.COM (aes256-cts-hmac-sha1-96) 
   2 02/16/2023 17:12:05 MSSQLSvc/arcsqlmi.contoso.com:31433@CONTOSO.COM (arcfour-hmac) 
   3 02/16/2023 17:13:41 arcsqlmiuser@CONTOSO.COM (aes256-cts-hmac-sha1-96) 
   3 02/16/2023 17:13:41 arcsqlmiuser@CONTOSO.COM (arcfour-hmac) 
   3 02/16/2023 17:13:41 MSSQLSvc/arcsqlmi.contoso.com@CONTOSO.COM (aes256-cts-hmac-sha1-96) 
   3 02/16/2023 17:13:41 MSSQLSvc/arcsqlmi.contoso.com@CONTOSO.COM (arcfour-hmac) 
   3 02/16/2023 17:13:41 MSSQLSvc/arcsqlmi.contoso.com:31433@CONTOSO.COM (aes256-cts-hmac-sha1-96) 
   3 02/16/2023 17:13:41 MSSQLSvc/arcsqlmi.contoso.com:31433@CONTOSO.COM (arcfour-hmac)

E a seguinte especificação updated-secret.yaml:

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: sqlmi-keytab-secret-kvno-2-3
  namespace: test
data:
  keytab:
    <keytab-contents>

Por fim, altere a senha da conta de usuário arcsqlmi no controlador de domínio contoso.com do Active Directory:

  1. Abra o Gerenciador do Servidor no controlador de domínio para o domínio contoso.com do Active Directory. Você pode pesquisar o Gerenciador do Servidor ou abri-lo por meio do menu Iniciar.

  2. Ir para Ferramentas>Usuários e computadores do Active Directory

    Captura de tela de Usuários e Computadores do Active Directory.

  3. Selecione o usuário para o qual você deseja alterar a senha. Clique com o botão direito do mouse para selecionar o usuário. Selecione Redefinir senha:

    Captura de tela do controle para redefinir a senha de uma conta de usuário do Active Directory.

  4. Insira uma nova senha e selecione OK.

Solução de problemas de erros após a rotação

Caso haja erros ao tentar usar a Autenticação do Active Directory depois de concluir a rotação de keytab, os seguintes arquivos no contêiner arc-sqlmi no pod MI do SQL são um bom lugar para começar a investigar a causa raiz:

  • security.log arquivo localizado em /var/opt/mssql/log - Este arquivo de log tem logs para interações do SQL com o domínio do Active Directory.
  • errorlog arquivo localizado em /var/opt/mssql/log - Este arquivo de log contém logs do SQL Server em execução no contêiner.
  • mssql.keytab arquivo localizado em /var/run/secrets/managed/keytabs/mssql - Verifique se esse arquivo de keytab contém as entradas recém-atualizadas e corresponde ao arquivo keytab criado usando os scripts fornecidos acima. O arquivo keytab pode ser lido usando o comando klist, ou seja, klist -k mssql.keytab -e

Além disso, depois de obter o TGT (tíquete de concessão de tíquete) kerberos usando o comando kinit, verifique se o kvno do usuário do SQL corresponde ao kvno mais alto no arquivo mssql.keytab no contêiner de arc-sqlmi. Por exemplo, para arcsqlmi@CONTOSO.COM usuário:

  • Obtenha o TGT kerberos do domínio do Active Directory executando kinit arcsqlmi@CONTOSO.COM. Isso solicitará uma entrada do usuário para a senha do usuário arcsqlmi.
  • Depois que isso for bem-sucedido, o kvno poderá ser consultado executando kvno arcsqlmi@CONTOSO.COM.

Também podemos habilitar o registro em log de depuração para o comando kinit executando o seguinte: KRB5_TRACE=/dev/stdout kinit -V arcsqlmi@CONTOSO.COM. Isso aumenta a verbosidade e gera os logs para stdout à medida que o comando está sendo executado.