Configurar a autenticação do Windows para instâncias do RDS Custom para SQL Server

Recomendamos criar uma OU dedicada e credenciais de serviço com escopo para essa OU para qualquer Conta da AWS que seja proprietária de uma instância de banco de dados do RDS Custom para SQL Server associada ao domínio do AD. Ao dedicar uma OU e credenciais de serviço, é possível evitar permissões conflitantes e seguir o princípio de privilégio mínimo.

As políticas de grupo ao nível do Active Directory podem entrar em conflito com automações e permissões da AWS. Recomendamos selecionar GPOs que se apliquem somente à OU criados para o RDS Custom para SQL Server.

Veja a seguir os requisitos da conta de serviço do domínio do AD:

Essas permissões representam o conjunto mínimo de permissões necessárias para associar objetos de computador ao AD autogerenciado e ao AWS Managed Microsoft AD. Para ter mais informações, consulte Error: Access is denied when non-administrator users who have been delegated control try to join computers to a domain controller na documentação do Microsoft Windows Server.

Etapa 1: criar uma unidade organizacional (UO) no AD

Use as seguintes etapas para criar uma unidade organizacional no AD:

Em relação ao AWS Managed Microsoft AD, o nome dessa UO é baseado no nome NetBIOS digitado quando você criou o diretório. Essa UO é de propriedade da AWS e contém todos os objetos de diretório relacionados à AWS, dos quais você recebeu controle total. Por padrão, existem duas UOs secundárias sob essa UO, a saber, Computadores e Usuários. As novas UOs criadas pelo RDS Custom são secundárias da OU baseada no NetBIOS.

Etapa 2: criar um usuário do domínio do AD

As credenciais do usuário do domínio são usadas para o segredo no Secrets Manager.

Etapa 3: delegar controle ao usuário do AD no AWS Managed Microsoft AD ou autogerenciado

Etapa 4: criar um segredo

Crie o segredo na mesma Conta da AWS e região que contém a instância de banco de dados do RDS Custom para SQL Server a ser incluída no Active Directory. Armazene as credenciais do usuário do domínio do AD criado em Etapa 2: criar um usuário do domínio do AD.

Console

• No AWS Secrets Manager, selecione Armazenar um novo segredo.

• Em Tipo de segredo, escolha Outro tipo de segredo.

• Em Pares de chave/valor, adicione duas chaves:

  • A primeira chave, SELF_MANAGED_ACTIVE_DIRECTORY_USERNAME, e insira o nome do usuário do AD para o valor.

  • Para a segunda chave, insira SELF_MANAGED_ACTIVE_DIRECTORY_PASSWORD e a senha do usuário do AD no domínio.

• Em Chave de criptografia, insira a mesma chave do AWS KMS que você usou para criar a instância do RDS Custom para SQL Server.

• Em Nome do segredo, escolha o nome do segredo que começa com do-not-delete-rds-custom- para permitir que o perfil de instância acesse esse segredo. Se você quiser escolher um nome diferente para o segredo, atualize RDSCustomInstanceProfile para acessar o Nome do segredo.

• (Opcional) Em Descrição, insira uma descrição para o nome do segredo.

• Adicione as etiquetas Key="AWSRDSCustom",Value="custom-sqlserver".

• Clique em Salvar, depois em Próximo.

• Em Definir configurações de rotação, mantenha os valores padrão e escolha Próximo.

• Revise as configurações do segredo e clique em Armazenar.

• Escolha o novo segredo e copie o valor do ARN do segredo. Usaremos isso na próxima etapa para configurar o Active Directory.

CLI

Execute o seguinte comando na CLI para criar um serviço:

# Linux based
aws secretsmanager create-secret \
--name do-not-delete-rds-custom-DomainUserCredentails \ 
--description "Active directory user credentials for managing RDS Custom" \ 
--secret-string "{\"SELF_MANAGED_ACTIVE_DIRECTORY_USERNAME\":\"tester\",\"SELF_MANAGED_ACTIVE_DIRECTORY_PASSWORD\":\"xxxxxxxx\"}" \
--kms-key-id <RDSCustomKMSKey> \
--tags Key="AWSRDSCustom",Value="custom-sqlserver"

# Windows based
aws secretsmanager create-secret ^
--name do-not-delete-rds-custom-DomainUserCredentails ^ 
--description "Active directory user credentials for managing RDS Custom" ^
--secret-string "{\"SELF_MANAGED_ACTIVE_DIRECTORY_USERNAME\":\"tester\",\"SELF_MANAGED_ACTIVE_DIRECTORY_PASSWORD\":\"xxxxxxxx\"}" ^
--kms-key-id <RDSCustomKMSKey> ^
--tags Key="AWSRDSCustom",Value="custom-sqlserver"

anchoranchor

• Console
• CLI

• No AWS Secrets Manager, selecione Armazenar um novo segredo.

• Em Tipo de segredo, escolha Outro tipo de segredo.

• Em Pares de chave/valor, adicione duas chaves:

  • A primeira chave, SELF_MANAGED_ACTIVE_DIRECTORY_USERNAME, e insira o nome do usuário do AD para o valor.

  • Para a segunda chave, insira SELF_MANAGED_ACTIVE_DIRECTORY_PASSWORD e a senha do usuário do AD no domínio.

• Em Chave de criptografia, insira a mesma chave do AWS KMS que você usou para criar a instância do RDS Custom para SQL Server.

• Em Nome do segredo, escolha o nome do segredo que começa com do-not-delete-rds-custom- para permitir que o perfil de instância acesse esse segredo. Se você quiser escolher um nome diferente para o segredo, atualize RDSCustomInstanceProfile para acessar o Nome do segredo.

• (Opcional) Em Descrição, insira uma descrição para o nome do segredo.

• Adicione as etiquetas Key="AWSRDSCustom",Value="custom-sqlserver".

• Clique em Salvar, depois em Próximo.

• Em Definir configurações de rotação, mantenha os valores padrão e escolha Próximo.

• Revise as configurações do segredo e clique em Armazenar.

• Escolha o novo segredo e copie o valor do ARN do segredo. Usaremos isso na próxima etapa para configurar o Active Directory.

Etapa 5: criar ou modificar a instância de banco de dados do RDS Custom para SQL Server

Crie ou modifique uma instância de banco de dados do RDS Custom para SQL Server a ser usado com o diretório. É possível usar o console, a CLI ou a API do RDS para associar uma instância de banco de dados a um diretório. Você pode fazer isso por meio de uma das seguintes maneiras:

Quando você usa a AWS CLI, são necessários os seguintes parâmetros para que a instância de banco de dados possa usar o diretório criado:

O comando da CLI a seguir cria uma instância de banco de dados do RDS Custom para SQL Server e a associa a um domínio do AWS Managed Microsoft AD ou autogerenciado.

Para Linux, macOS ou Unix:

aws rds create-db-instance  \
--engine custom-sqlserver-se \
--engine-version 15.00.4312.2.v1 \
--db-instance-identifier my-custom-instance \
--db-instance-class db.m5.large \
--allocated-storage 100 --storage-type io1 --iops 1000 \
--master-username my-master-username \
--master-user-password my-master-password \
--kms-key-id  my-RDSCustom-key-id \
--custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance  \
--domain-fqdn "corp.example.com" \
--domain-ou "OU=RDSCustomOU,DC=corp,DC=example,DC=com" \
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:do-not-delete-rds-custom-my-AD-test-secret-123456" \
--db-subnet-group-name my-DB-subnet-grp \
--vpc-security-group-ids  my-securitygroup-id \
--no-publicly-accessible \
--backup-retention-period 3 \
--port 8200 \
--region us-west-2 \
--no-multi-az 
            

Para Windows:

aws rds create-db-instance  ^
--engine custom-sqlserver-se ^
--engine-version 15.00.4312.2.v1 ^
--db-instance-identifier my-custom-instance ^
--db-instance-class db.m5.large ^
--allocated-storage 100 --storage-type io1 --iops 1000 ^
--master-usernamemy-master-username ^
--master-user-password my-master-password ^
--kms-key-id  my-RDSCustom-key-id ^
--custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance  ^
--domain-fqdn "corp.example.com" ^
--domain-ou "OU=RDSCustomOU,DC=corp,DC=example,DC=com" ^
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:do-not-delete-rds-custom-my-AD-test-secret-123456" ^
--db-subnet-group-name my-DB-subnet-grp ^
--vpc-security-group-ids  my-securitygroup-id ^
--no-publicly-accessible ^
--backup-retention-period 3 ^
--port 8200 ^
--region us-west-2 ^
--no-multi-az

O comando a seguir modifica uma instância de banco de dados do RDS Custom para SQL Server existente para usar um domínio do Active Directory.

Para Linux, macOS ou Unix:

aws rds modify-db-instance \
    --db-instance-identifier my-custom-instance \
    --domain-fqdn "corp.example.com" \
    --domain-ou "OU=RDSCustomOU,DC=corp,DC=example,DC=com" \
    --domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:do-not-delete-rds-custom-my-AD-test-secret-123456" \ 

Para Windows:

aws rds modify-db-instance ^
    --db-instance-identifier my-custom-instance ^
    --domain-fqdn "corp.example.com" ^
    --domain-ou "OU=RDSCustomOU,DC=corp,DC=example,DC=com" ^
    --domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:do-not-delete-rds-custom-my-AD-test-secret-123456" ^

O comando da CLI a seguir remove uma instância de banco de dados do RDS Custom para SQL Server de um domínio do Active Directory.

Para Linux, macOS ou Unix:

aws rds modify-db-instance \
    --db-instance-identifier my-custom-instance \
    --disable-domain

Para Windows:

aws rds modify-db-instance ^
    --db-instance-identifier my-custom-instance ^
    --disable-domain

Ao usar o console para criar ou modificar a instância, clique em Habilitar a autenticação do Microsoft SQL Server Windows para ver as opções a seguir.

Você é responsável por garantir que o FQDN do domínio seja resolvido para os endereços IP do controlador de domínio. Se os IPs do controlador de domínio não estiverem sendo resolvidos, as operações de ingresso no domínio falharão, mas a criação da instância do RDS Custom para SQL Server será bem-sucedida. Para obter informações sobre a solução de problemas, consulte Solucionar problemas no Active Directory.

Etapa 6: criar login do SQL Server para autenticação do Windows

Use as credenciais de usuário mestre do Amazon RDS para se conectar à instância de banco de dados do SQL Server como você faria para qualquer outra instância de banco de dados. Como a instância de banco de dados é associada ao domínio do AD, é possível provisionar logins e usuários do SQL Server. Faça isso usando o utilitário de usuários e grupos do AD no domínio do AD. As permissões de banco de dados são gerenciadas por meio de permissões padrão do SQL Server concedidas e revogadas a esses logins do Windows.

Para que um usuário do AD faça a autenticação com o SQL Server, deve existir um login do Windows para SQL Server para o usuário do AD ou um grupo do Active Directory do qual o usuário seja membro. O controle de acesso refinado é gerenciado por meio da concessão e revogação de permissões nesses logins do SQL Server. Um usuário que não tenha um login do SQL Server nem pertença a um grupo que tenha um login não consegue acessar a instância de banco de dados do SQL Server.

A permissão ALTER ANY LOGIN é necessária para criar um login do AD para SQL Server. Se você ainda não criou logins com essa permissão, conecte-se como o usuário principal da instância de banco de dados usando a autenticação do SQL Server e crie logins do AD para SQL Server no contexto do usuário principal.

É possível executar um comando de linguagem de definição de dados (DDL) como o seguinte para criar um login do SQL Server para um usuário ou um grupo do AD.

USE [master]
GO
CREATE LOGIN [mydomain\myuser] FROM WINDOWS WITH DEFAULT_DATABASE = [master], DEFAULT_LANGUAGE = [us_english];
GO

Os usuários (humanos e aplicações) do domínio agora podem se conectar à instância do RDS Custom para SQL Server por meio de uma máquina cliente conectada ao domínio usando a autenticação do Windows.

Etapa 7: usar a autenticação do Kerberos ou NTLM

Autenticação do NTLM usando um endpoint do RDS

Cada instância de banco de dados do Amazon RDS tem um endpoint, e cada endpoint tem um nome de DNS e um número de porta para a instância de banco de dados. Para se conectar à sua instância de banco de dados usando um aplicativo cliente SQL, você precisa do nome DNS e do número da porta para sua instância de banco de dados. Para se autenticar usando o NTLM, é necessário se conectar ao endpoint do RDS.

Durante uma manutenção planejada do banco de dados ou de uma interrupção do serviço não planejada, o Amazon RDS faz failover automático para o banco de dados secundário atualizado. Dessa maneira, as operações podem ser retomadas rapidamente sem intervenção manual. As instâncias primária e secundária usam o mesmo endpoint, cujo endereço de rede física faz a transição para a secundária como parte do processo de failover. Não é necessário reconfigurar seu aplicativo quando ocorre um failover.

Autenticação de Kerberos

A autenticação baseada em Kerberos para o RDS Custom para SQL Server exige que as conexões sejam feitas com um nome de entidade principal de serviço (SPN) específico. No entanto, após um evento de failover, a aplicação pode não estar ciente do novo SPN. Para resolver isso, o RDS Custom para SQL Server oferece um endpoint baseado em Kerberos.

O endpoint baseado em Kerberos segue um formato específico. Caso o endpoint do RDS seja rds-instance-name.account-region-hash.aws-region.rds.amazonaws.com, o endpoint correspondente baseado em Kerberos será rds-instance-name.account-region-hash.aws-region.awsrds.fully qualified domain name (FQDN).

Por exemplo, se o endpoint do RDS for ad-test.cocv6zwtircu.us-east-1.rds.amazonaws.com e o nome do domínio for corp-ad.company.com, o endpoint baseado em Kerberos será ad-test.cocv6zwtircu.us-east-1.awsrds.corp-ad.company.com.

Esse endpoint baseado em Kerberos pode ser usado para se autenticar na instância do SQL Server usando o Kerberos, mesmo após um evento de failover, pois o endpoint é atualizado automaticamente para apontar para o novo SPN da instância primária do SQL Server.

Encontrar o CNAME

Para encontrar o CNAME, conecte-se ao controlador de domínio e abra o Gerenciador de DNS. Acesse Forward Lookup Zones e o FQDN.

Navegue por awsrds, aws-region e hash específico de conta e região.

Se você estiver conectando a instância do EC2 do RDS Custom e tentando estabelecer conexão com o banco de dados localmente usando o CNAME, a conexão usará a autenticação do NTLM em vez do Kerberos.

Se uma conexão do NTLM for retornada depois que você conectar o CNAME por meio do cliente remoto, confira se as portas necessárias estão na lista de permissões.

Para conferir se a conexão está usando o Kerberos, realize a seguinte consulta:

SELECT net_transport, auth_scheme
    FROM sys.dm_exec_connections
    WHERE session_id = @@SSPID;