# Trabalhar com um Active Directory autogerenciado com uma instância de banco de dados do Amazon RDS para SQL Server
O Amazon RDS para SQL Server se integra perfeitamente ao seu domínio Active Directory (AD) autogerenciado, independentemente de onde seu AD esteja hospedado, seja no data center, no Amazon EC2 ou em outros provedores de nuvem. Essa integração permite a autenticação direta do usuário por meio dos protocolos NTLM ou Kerberos, eliminando a necessidade de domínios intermediários complexos ou relacionamentos de confiança na floresta. Quando você se conecta à sua instância de banco de dados do SQL Server do RDS, as solicitações de autenticação são encaminhadas com segurança para seu domínio AD designado, mantendo sua estrutura de gerenciamento de identidade existente e utilizando os recursos de banco de dados gerenciado do Amazon RDS.
**Topics**
+ [Disponibilidade de regiões e versões](#USER_SQLServer_SelfManagedActiveDirectory.RegionVersionAvailability)
+ [Requisitos](USER_SQLServer_SelfManagedActiveDirectory.Requirements.md)
+ [Considerações](#USER_SQLServer_SelfManagedActiveDirectory.Limitations)
+ [Configurar um Active Directory autogerenciado](USER_SQLServer_SelfManagedActiveDirectory.SettingUp.md)
+ [Associar a instância de banco de dados ao Active Directory autogerenciado](USER_SQLServer_SelfManagedActiveDirectory.Joining.md)
+ [Gerenciar uma instância de banco de dados em um domínio de Active Directory autogerenciado](USER_SQLServer_SelfManagedActiveDirectory.Managing.md)
+ [Entender a associação a um domínio de Active Directory autogerenciado](#USER_SQLServer_SelfManagedActiveDirectory.Understanding)
+ [Solução de problemas de Active Directory autogerenciado](USER_SQLServer_SelfManagedActiveDirectory.TroubleshootingSelfManagedActiveDirectory.md)
+ [Restaurar uma instância de banco de dados do SQL Server e adicioná-la a um domínio de Active Directory autogerenciado](#USER_SQLServer_SelfManagedActiveDirectory.Restore)
## Disponibilidade de regiões e versões
O Amazon RDS comporta o AD autogerenciado para SQL Server usando NTLM e Kerberos em todas as Regiões da AWS e AWS GovCloud (US) Regions comerciais.
# Requisitos
Verifique se você atendeu aos seguintes requisitos antes de unir uma instância de banco de dados do RDS para SQL Server ao seu domínio de AD autogerenciado.
**Topics**
+ [Configurar um AD on-premises](#USER_SQLServer_SelfManagedActiveDirectory.Requirements.OnPremConfig)
+ [Configurar sua conectividade de rede](#USER_SQLServer_SelfManagedActiveDirectory.Requirements.NetworkConfig)
+ [Configurar uma conta de serviço do domínio de AD](#USER_SQLServer_SelfManagedActiveDirectory.Requirements.DomainAccountConfig)
+ [Configurar a comunicação segura via LDAPS](#USER_SQLServer_SelfManagedActiveDirectory.Requirements.LDAPS)
## Configurar um AD on-premises
Você precisa ter um Microsoft AD on-premises ou autogerenciado ao qual possa associar a instância do Amazon RDS para SQL Server. O AD on-premises deve ter a seguinte configuração:
+ Se você tiver sites do AD definidos, verifique se as sub-redes na VPC associada à sua instância de banco de dados do RDS para SQL Server estão definidas em seu site do AD. Confirme se não há nenhum conflito entre as sub-redes em sua VPC e as sub-redes em seus outros sites do AD.
+ Seu controlador de domínios de AD tem um nível funcional de domínio do Windows Server 2008 R2 ou posterior.
+ Seu nome de domínio de AD não pode estar no formato de domínio de rótulo único (SLD). O RDS para SQL Server não oferece suporte a domínios SLD.
+ O nome de domínio totalmente qualificado (FQDN) do AD não pode exceder 47 caracteres.
## Configurar sua conectividade de rede
Você precisa atender às seguintes configurações de rede:
+ Configure a conectividade entre a Amazon VPC na qual deseja criar a instância de banco de dados do RDS para SQL Server e o AD autogerenciado. Você pode configurar a conectividade usando o AWS Direct Connect, o AWS VPN, o emparelhamento de VPC ou o AWS Transit Gateway.
+ Para grupos de segurança de VPC, o grupo de segurança padrão para sua Amazon VPC padrão já está adicionado à sua instância de banco de dados do RDS para SQL Server no console. Verifique se o grupo de segurança e as ACLs de rede da VPC para as sub-redes em que você vai criar a instância de banco de dados do RDS para SQL Server permitem tráfego nas portas e nas direções mostradas no diagrama a seguir.
![\[Regras de portas para configuração de rede de um AD autogerenciado.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/SQLServer_SelfManagedActiveDirectory_Requirements_NetworkConfig.png)
A tabela a seguir identifica o perfil de cada porta.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/USER_SQLServer_SelfManagedActiveDirectory.Requirements.html)
+ Em geral, os servidores DNS do domínio estão localizados nos controladores do domínio de AD. Você não precisa configurar o conjunto de opções DHCP da VCP para usar esse atributo. Para obter mais informações, consulte [Conjuntos de opções DHCP](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html) no *Guia do usuário do Amazon VPC*.
**Importante**
Se você estiver usando ACLs de rede de VPC, também deverá permitir tráfego de saída em portas dinâmicas (49152-65535) da sua instância de banco de dados do RDS para SQL Server. Confira se essas regras de tráfego também são refletidas nos firewalls que se aplicam a cada um dos controladores do domínio de AD, servidores DNS e instâncias de banco de dados do RDS para SQL Server.
Embora os grupos de segurança de VPC exijam que as portas sejam abertas somente na direção em que o tráfego de rede é iniciado, a maioria dos firewalls do Windows e das ACLs da rede de VPC exigem que as portas sejam abertas nas duas direções.
## Configurar uma conta de serviço do domínio de AD
Verifique se você atendeu aos seguintes requisitos para uma conta de serviço do domínio de AD:
+ Confira se você tem uma conta de serviço em seu domínio AD autogerenciado com permissões delegadas para associar computadores ao domínio. Uma conta de serviço de domínio é uma conta de usuário em seu AD autogerenciado à qual foi delegada permissão para realizar determinadas tarefas.
+ É necessário delegar à conta de serviço de domínio as seguintes permissões na unidade organizacional (OU) à qual você está associando a instância de banco de dados do RDS para SQL Server:
+ Capacidade validada para gravar no nome do host DNS
+ Capacidade validada para gravar no nome da entidade principal de serviço
+ Criar e excluir objetos de computador
Essas permissões representam o conjunto mínimo de permissões necessárias para associar objetos de computador ao AD autogerenciado. Para obter mais informações, consulte [Erros ao tentar associar computadores a um domínio](https://learn.microsoft.com/en-US/troubleshoot/windows-server/identity/access-denied-when-joining-computers) na documentação do Microsoft Windows Server.
+ Para usar a autenticação Kerberos, você precisa fornecer nomes de entidades principais de serviço (SPNs) e permissões de DNS à sua conta de serviço de domínio AD:
+ **Gravar SPN**: delegue a permissão **Gravar SPN** à conta de serviço de domínio AD na UO à qual você precisa associar a instância de banco de dados do RDS para SQL Server. Essas permissões são diferentes do SPN de gravação validado.
+ **Permissões de DNS**: forneça as seguintes permissões para a conta de serviço de domínio AD no gerenciador de DNS em nível de servidor para seu controlador de domínio:
+ Listar conteúdo
+ Ler todas as propriedades
+ Permissões de leitura
**Importante**
Não mova objetos de computador criados pelo RDS para SQL Server na unidade organizacional depois da criação da instância de banco de dados. Mover os objetos associados fará com que sua instância de banco de dados do RDS para SQL Server fique malconfigurada. Se você precisar mover os objetos de computador criados pelo Amazon RDS, use a operação de API [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) do RDS para modificar os parâmetros do domínio com a localização desejada dos objetos de computador.
## Configurar a comunicação segura via LDAPS
A comunicação via LDAPS é recomendada para que o RDS consulte e acesse objetos de computador, bem como SPNs no controlador de domínio. Para usar o LDAP seguro, use um certificado SSL válido em seu controlador de domínio que atenda aos requisitos de LDAPS seguro. Se não existir um certificado SSL válido no controlador de domínio, a instância de banco de dados do RDS para SQL Server usará como padrão o LDAP. Para acessar mais informações sobre a validade do certificado, consulte [Requirements for an LDAPS certificate](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-over-ssl-3rd-certification-authority#requirements-for-an-ldaps-certificate).
## Considerações
Ao adicionar uma instância de banco de dados do RDS para SQL Server a um AD autogerenciado, pense no seguinte:
+ Suas instâncias de banco de dados são sincronizadas com o serviço NTP da AWS e não com o servidor de horário do domínio AD. Em relação a conexões de banco de dados entre instâncias vinculadas do SQL Server em seu domínio AD, você pode usar somente a autenticação SQL e não a autenticação do Windows.
+ As configurações de Objeto de Política de Grupo do seu domínio do AD autogerenciado não são propagadas em suas instâncias do RDS para SQL Server.
# Configurar um Active Directory autogerenciado
Para configurar um AD autogerenciado, siga as etapas abaixo.
**Topics**
+ [Etapa 1: Criar uma unidade organizacional no AD](#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.CreateOU)
+ [Etapa 2: criar uma conta de serviço de domínio AD em seu AD](#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.CreateADuser)
+ [Etapa 3: delegar controle à conta de serviço de domínio AD](#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.DelegateControl)
+ [Etapa 4: Criar uma chave do AWS KMS](#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.CreateKMSkey)
+ [Etapa 5: Criar um segredo da AWS](#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.CreateSecret)
## Etapa 1: Criar uma unidade organizacional no AD
**Importante**
Recomendamos criar uma OU e uma credencial de serviço dedicadas com escopo para essa OU para todas as contas da AWS que tenham uma instância de banco de dados do RDS para SQL Server associada ao seu domínio de AD autogerenciado. Ao dedicar uma OU e uma credencial de serviço, você pode evitar permissões conflitantes e seguir o princípio de privilégio mínimo.
**Como criar uma OU no AD**
1. Conecte-se ao seu domínio de AD como administrador do domínio.
1. Abra **Usuários e computadores do Active Directory** e selecione o domínio em que deseja criar a OU.
1. Clique com o botão direito do mouse no domínio, escolha **Novo** e selecione **Unidade organizacional**.
1. Insira um nome para a OU.
1. Mantenha a caixa **Proteger o contêiner contra exclusão acidental** selecionada.
1. Clique em **OK**. A nova OU será exibida em seu domínio.
## Etapa 2: criar uma conta de serviço de domínio AD em seu AD
As credenciais da conta de serviço de domínio serão usadas para o segredo no AWS Secrets Manager.
**Como criar uma conta de serviço de domínio AD em seu AD**
1. Abra **Usuários e computadores do Active Directory** e selecione o domínio e a OU em que deseja criar o usuário.
1. Clique com o botão direito do mouse no objeto **Usuários**, escolha **Novo** e selecione **Usuário**.
1. Insira um nome, sobrenome e nome de login para o usuário. Clique em **Next**.
1. Insira uma senha para o usuário. Não selecione a opção **“O usuário deve alterar a senha no próximo login”**. Não selecione a opção **“A conta está desabilitada”**. Clique em **Next**.
1. Clique em **OK**. O novo usuário será exibido em seu domínio.
## Etapa 3: delegar controle à conta de serviço de domínio AD
**Como delegar controle à conta de serviço de domínio AD em seu domínio**
1. Abra o snap-in do MMC **Usuários e computadores do Active Directory** e selecione o domínio em que deseja criar o usuário.
1. Clique com o botão direito do mouse na OU criada anteriormente e escolha **Delegar controle**.
1. No **Assistente de delegação de controle**, clique em **Próximo**.
1. Na seção **Usuários ou grupos**, clique em **Adicionar**.
1. Na seção **Selecionar usuários, computadores ou grupos**, insira a conta de serviço de domínio AD que você criou e clique em **Conferir nomes**. Se a verificação de sua conta de serviço de domínio AD for bem-sucedida, clique em **OK**.
1. Na seção **Usuários ou grupos**, confirme se seu serviço de domínio AD foi adicionado e clique em **Próximo**.
1. Na página **Tarefas para delegar**, selecione **Criar uma tarefa personalizada para delegar** e escolha **Próximo**.
1. Na seção **Tipo de objeto do Active Directory**:
1. Selecione **Somente os objetos a seguir na pasta**.
1. Selecione **Objetos do computador**.
1. Selecione **Criar objetos selecionados nesta pasta**.
1. Selecione **Excluir objetos selecionados nesta pasta** e clique em **Próximo**.
1. Na seção **Permissões**:
1. Mantenha a opção **Geral** selecionada.
1. Selecione **Gravação validada no nome do host DNS**.
1. Selecione **Gravação validada no nome da entidade principal de serviço** e clique em **Próximo**.
1. Para habilitar a autenticação Kerberos, mantenha a opção **Específico da propriedade** selecionada e escolha **Gravar servicePrincipalName** na lista.
1. Em **Concluir o assistente de delegação de controle**, revise e confirme as configurações e clique em **Concluir**.
1. Para a autenticação Kerberos, abra o Gerenciador DNS e abra as propriedades do **servidor**.
1. Na caixa de diálogo do Windows, digite `dnsmgmt.msc`.
1. Inclua a conta do serviço de domínio AD na guia **Segurança**.
1. Selecione a permissão de **leitura** e aplique suas alterações.
## Etapa 4: Criar uma chave do AWS KMS
A chave do KMS é usada para criptografar o segredo da AWS.
**Para criar uma chave do AWS KMS**
**nota**
Em **Chave de criptografia**, não use a chave do KMS padrão da AWS. Crie a chave do AWS KMS na mesma conta da AWS que contém a instância de banco de dados do RDS para SQL Server que você deseja associar ao AD autogerenciado.
1. No console do AWS KMS, escolha **Criar chave**.
1. Em **Tipo de chave**, escolha **Simétrica**.
1. Em **Uso da chave**, escolha **Criptografar e descriptografar**.
1. Em **Advanced options (Opções avançadas)**:
1. Em **Origem do material de chaves**, escolha **Externa**.
1. Em **Regionalidade**, escolha **Chave de região única** e clique em **Próximo**.
1. Em **Alias**, forneça um nome para a chave do KMS.
1. (Opcional) Em **Descrição**, forneça uma descrição da chave do KMS.
1. (Opcional) Em **Etiquetas**, forneça uma etiqueta da chave do KMS e clique em **Próximo**.
1. Em **Administradores de chaves**, forneça o nome de um usuário do IAM e selecione-o.
1. Em **Exclusão de chaves**, mantenha a caixa **Permitir que administradores de chaves excluam esta chave** selecionada e clique em **Próximo**.
1. Em **Usuários de chaves**, informe o mesmo usuário do IAM da etapa anterior e selecione-o. Clique em **Next**.
1. Revise a configuração.
1. Em **Política de chave**, inclua o seguinte na **Instrução** da política:
```
{
"Sid": "Allow use of the KMS key on behalf of RDS",
"Effect": "Allow",
"Principal": {
"Service": [
"rds.amazonaws.com"
]
},
"Action": "kms:Decrypt",
"Resource": "*"
}
```
1. Clique em **Finish (Concluir)**.
## Etapa 5: Criar um segredo da AWS
**Como criar um segredo**
**nota**
Crie o segredo na mesma conta da AWS que contém a instância de banco de dados do RDS para SQL Server que você deseja associar ao AD autogerenciado.
1. No AWS Secrets Manager, escolha **Armazenar um novo segredo**.
1. Em **Tipo de segredo**, escolha **Outro tipo de segredo**.
1. Em **Pares de chave/valor**, adicione suas duas chaves:
1. Para a primeira chave, insira `SELF_MANAGED_ACTIVE_DIRECTORY_USERNAME`.
1. Para o valor da primeira chave, insira somente o nome de usuário (sem o prefixo do domínio) do usuário do AD. Não inclua o nome do domínio, pois isso faz com que a criação da instância falhe.
1. Para a segunda chave, insira `SELF_MANAGED_ACTIVE_DIRECTORY_PASSWORD`.
1. Para o valor da segunda chave, insira a senha que você criou para o usuário do AD no domínio.
1. Em **Chave de criptografia**, insira a chave do KMS que você criou em uma etapa anterior e clique em **Próximo**.
1. Em **Nome do secreto**, insira um nome descritivo que ajude você a encontrar o segredo posteriormente.
1. (Opcional) Em **Descrição**, insira uma descrição para o nome do segredo.
1. Em **Permissão de recurso**, clique em **Editar**.
1. Adicione a política a seguir à política de permissões:
**nota**
Recomendamos que você use as condições `aws:sourceAccount` e `aws:sourceArn` na política para evitar o problema de *representante confuso*. Use sua Conta da AWS em `aws:sourceAccount` e o ARN da instância de banco de dados do RDS para SQL Server em `aws:sourceArn`. Para obter mais informações, consulte [Prevenção do problema do substituto confuso entre serviços](cross-service-confused-deputy-prevention.md).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":
[
{
"Effect": "Allow",
"Principal":
{
"Service": "rds.amazonaws.com"
},
"Action": "secretsmanager:GetSecretValue",
"Resource": "*",
"Condition":
{
"StringEquals":
{
"aws:sourceAccount": "123456789012"
},
"ArnLike":
{
"aws:sourceArn": "arn:aws:rds:us-west-2:123456789012:db:*"
}
}
}
]
}
```
------
1. Clique em **Salvar**, depois em **Próximo**.
1. Em **Definir configurações de rotação**, mantenha os valores padrão e escolha **Próximo**.
1. Revise as configurações do segredo e clique em **Armazenar**.
1. Escolha o segredo que você criou e copie o valor do **ARN do segredo**. Isso será usado na próxima etapa para configurar o Active Directory autogerenciado.
# Associar a instância de banco de dados ao Active Directory autogerenciado
Para associar a instância de banco de dados do RDS para SQL Server ao seu AD autogerenciado, siga estas etapas:
## Etapa 1: Criar ou modificar a instância de banco de dados do SQL Server
Você pode usar o console, a CLI ou a API do RDS para associar uma instância de banco de dados do RDS para SQL Server a um domínio de AD autogerenciado. Você pode fazer isso por meio de uma das seguintes maneiras:
+ Crie uma instância de banco de dados do SQL Server usando o console, o comando [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) da CLI ou a operação da API [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) do RDS.
Para obter instruções, consulte [Criar uma instância de banco de dados do Amazon RDS](USER_CreateDBInstance.md).
+ Modifique uma instância de banco de dados existente do SQL Server usando o console, o comando [ modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) da CLI ou a operação da API [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) do RDS.
Para obter instruções, consulte [Modificar uma instância de banco de dados do Amazon RDS](Overview.DBInstance.Modifying.md).
+ Restaure uma instância de banco de dados do SQL Server de um snapshot de banco de dados usando o console, o comando [ restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) da CLI ou a operação da API [ RestoreDBInstanceFromDBSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html) do RDS.
Para obter instruções, consulte [Restaurar uma instância de banco de dados](USER_RestoreFromSnapshot.md).
+ Restaure uma instância de banco de dados SQL Server em um determinado momento usando o console, o comando [ restore-db-instance-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) da CLI ou a operação da API [ RestoreDBInstanceToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html) do RDS.
Para obter instruções, consulte [Restaurar uma instância de banco de dados para um momento especificado no Amazon RDS](USER_PIT.md).
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 domínio AD autogerenciado que você criou:
+ Em relação ao parâmetro `--domain-fqdn`, use o nome de domínio totalmente qualificado (FQDN) do seu AD autogerenciado.
+ Para o parâmetro `--domain-ou`, use a OU criada em seu AD autogerenciado.
+ Para o parâmetro `--domain-auth-secret-arn`, use o valor do **ARN do segredo** criado em uma etapa anterior.
+ Para o parâmetro `--domain-dns-ips`, use os endereços IPv4 primário e secundário dos servidores DNS para seu AD autogerenciado. Se você não tiver um endereço IP de servidor DNS secundário, insira o endereço IP principal duas vezes.
O exemplo a seguir de comandos da CLI mostra como criar, modificar e remover uma instância de banco de dados do RDS para SQL Server com um domínio de AD autogerenciado.
**Importante**
Se você modificar uma instância de banco de dados para associá-la ou removê-la de um domínio de AD autogerenciado, será necessária uma reinicialização da instância de banco de dados para que a modificação entre em vigor. Você pode optar por aplicar as alterações imediatamente ou esperar até a próxima janela de manutenção. Escolher a opção **Aplicar imediatamente** causará tempo de inatividade para uma instância de banco de dados single-AZ. Uma instância de banco de dados multi-AZ realizará um failover antes de concluir a reinicialização. Para obter mais informações, consulte [Usar a configuração de programação de modificações](USER_ModifyInstance.ApplyImmediately.md).
O comando da CLI a seguir cria uma instância de banco de dados do RDS para SQL Server e a associa a um domínio de AD autogerenciado.
Para Linux, macOS ou Unix:
```
aws rds create-db-instance \
--db-instance-identifier my-DB-instance \
--db-instance-class db.m5.xlarge \
--allocated-storage 50 \
--engine sqlserver-se \
--engine-version 15.00.4043.16.v1 \
--license-model license-included \
--master-username my-master-username \
--master-user-password my-master-password \
--domain-fqdn my_AD_domain.my_AD.my_domain \
--domain-ou OU=my-AD-test-OU,DC=my-AD-test,DC=my-AD,DC=my-domain \
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:my-AD-test-secret-123456" \
--domain-dns-ips "10.11.12.13" "10.11.12.14"
```
Para Windows:
```
aws rds create-db-instance ^
--db-instance-identifier my-DB-instance ^
--db-instance-class db.m5.xlarge ^
--allocated-storage 50 ^
--engine sqlserver-se ^
--engine-version 15.00.4043.16.v1 ^
--license-model license-included ^
--master-username my-master-username ^
--master-user-password my-master-password ^
--domain-fqdn my-AD-test.my-AD.mydomain ^
--domain-ou OU=my-AD-test-OU,DC=my-AD-test,DC=my-AD,DC=my-domain ^
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:my-AD-test-secret-123456" \ ^
--domain-dns-ips "10.11.12.13" "10.11.12.14"
```
O comando da CLI a seguir modifica uma instância de banco de dados do RDS para SQL Server existente para usar um domínio AD autogerenciado.
Para Linux, macOS ou Unix:
```
aws rds modify-db-instance \
--db-instance-identifier my-DB-instance \
--domain-fqdn my_AD_domain.my_AD.my_domain \
--domain-ou OU=my-AD-test-OU,DC=my-AD-test,DC=my-AD,DC=my-domain \
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:my-AD-test-secret-123456" \
--domain-dns-ips "10.11.12.13" "10.11.12.14"
```
Para Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier my-DBinstance ^
--domain-fqdn my_AD_domain.my_AD.my_domain ^
--domain-ou OU=my-AD-test-OU,DC=my-AD-test,DC=my-AD,DC=my-domain ^
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:my-AD-test-secret-123456" ^
--domain-dns-ips "10.11.12.13" "10.11.12.14"
```
O comando da CLI a seguir remove uma instância de banco de dados do RDS para SQL Server de um domínio AD autogerenciado.
Para Linux, macOS ou Unix:
```
aws rds modify-db-instance \
--db-instance-identifier my-DB-instance \
--disable-domain
```
Para Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier my-DB-instance ^
--disable-domain
```
## Etapa 2: usar a autenticação do Kerberos ou NTLM
### Autenticações NTLM
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 ou ao endpoint do receptor se estiver usando uma implantação multi-AZ.
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 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 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**.
![\[Modificar a quantidade de armazenamento para uma instância de banco de dados\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/kerb-endpoint-selfManagedAD-RDSMS.png)
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;
```
Se sua instância exibir uma conexão NTLM quando você se conectar a um endpoint Kerberos, verifique sua configuração de rede e as configurações do usuário. Consulte [Configurar sua conectividade de rede](USER_SQLServer_SelfManagedActiveDirectory.Requirements.md#USER_SQLServer_SelfManagedActiveDirectory.Requirements.NetworkConfig).
## Etapa 3: Criar logins do SQL Server de 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 de AD autogerenciado, você pode provisionar logins e usuários do SQL Server. Você faz isso usando o utilitário de usuários e grupos de AD em seu domínio de AD autogerenciado. 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 uma conta de serviço de domínio AD autogerenciado seja autenticada com o SQL Server, deve existir um login do Windows para SQL Server para a conta em questão ou um grupo do AD autogerenciado 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. Uma conta de serviço de domínio AD autogerenciado que não tenha um login do SQL Server ou que não pertença a um grupo do AD autogerenciado com esse 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 de AD autogerenciado do SQL Server. Se você ainda não criou logins com essa permissão, conecte-se como o usuário mestre da instância de banco de dados usando a autenticação do SQL Server e crie logins de AD autogerenciado do SQL Server no contexto do usuário principal.
Você pode executar um comando de linguagem de definição de dados (DDL) como o seguinte para criar um login do SQL Server para um grupo uma conta de serviço de domínio AD autogerenciado.
**nota**
Especifique usuários e grupos que usam o nome de login anterior ao Windows 2000 no formato `my_AD_domain\my_AD_domain_user`. Não é possível usar um User Principal Name (UPN – Nome de usuário principal) no formato *`my_AD_domain_user`*`@`*`my_AD_domain`*.
```
USE [master]
GO
CREATE LOGIN [my_AD_domain\my_AD_domain_user] FROM WINDOWS WITH DEFAULT_DATABASE = [master], DEFAULT_LANGUAGE = [us_english];
GO
```
Para obter mais informações, consulte [CREATE LOGIN (Transact-SQL)](https://msdn.microsoft.com/en-us/library/ms189751.aspx) na documentação da Microsoft Developer Network.
Os usuários (humanos e aplicações) do seu domínio agora podem se conectar à instância do RDS para SQL Server por meio de uma máquina cliente associada ao domínio de AD autogerenciado usando a autenticação do Windows.
# Gerenciar uma instância de banco de dados em um domínio de Active Directory autogerenciado
É possível usar o console, a AWS CLI ou a API do Amazon RDS para gerenciar a instância de banco de dados e a respectiva relação com o domínio de AD autogerenciado. Por exemplo, é possível mover a instância de banco de dados para dentro, para fora, de e entre os domínios.
Por exemplo, usando a API do Amazon RDS, você pode fazer o seguinte:
+ Para tentar novamente uma associação a um domínio de AD autogerenciado em caso de falha, use a operação de API [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) e especifique o mesmo conjunto de parâmetros:
+ `--domain-fqdn`
+ `--domain-dns-ips`
+ `--domain-ou`
+ `--domain-auth-secret-arn`
+ Para remover uma instância de banco de dados de um domínio autogerenciado, use a operação de API `ModifyDBInstance` e especifique `--disable-domain` como parâmetro do domínio.
+ Para mover uma instância de banco de dados de um domínio autogerenciado para outro, use a operação de API `ModifyDBInstance` e especifique os parâmetros do novo domínio:
+ `--domain-fqdn`
+ `--domain-dns-ips`
+ `--domain-ou`
+ `--domain-auth-secret-arn`
+ Para listar a associação de cada instância de banco de dados ao domínio de AD autogerenciado, use a operação de API [DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/DescribeDBInstances.html).
## Entender a associação a um domínio de Active Directory autogerenciado
Depois de criar ou modificar uma instância de banco de dados, ela se tornará um membro do domínio AD autogerenciado. O console da AWS indica o status da associação ao domínio de AD autogerenciado para a instância de banco de dados. O status da instância de banco de dados pode ser um dos seguintes:
+ **joined**: a instância é membro do domínio de AD.
+ **joining**: a instância está em processo de se tornar membro do domínio de AD.
+ **pending-join** – a associação da instância está pendente.
+ **pending-maintenance-join**: a AWS tentará tornar a instância um membro do domínio de AD durante a próxima janela de manutenção agendada.
+ **pending-removal**: a remoção da instância do domínio de AD está pendente.
+ **pending-maintenance-removal**: a AWS tentará remover a instância do domínio de AD durante a próxima janela de manutenção agendada.
+ **failed**: um problema de configuração impediu que a instância se associasse ao domínio de AD. Verifique e corrija sua configuração antes de emitir novamente o comando de modificação da instância.
+ **removing**: a instância está sendo removida do domínio de AD.
**Importante**
Uma solicitação para se tornar um membro de um domínio de AD autogerenciado pode falhar devido a um problema de conectividade de rede. Por exemplo, você pode conseguir criar uma instância de banco de dados ou modificar uma instância existente, mas não conseguir transformar a instância de banco de dados em um membro de um domínio de AD autogerenciado. Nesse caso, execute novamente o comando para criar ou modificar a instância de banco de dados ou modifique a instância recém-criada para associá-la ao domínio de AD autogerenciado.
# Solução de problemas de Active Directory autogerenciado
Veja a seguir alguns problemas que você pode encontrar ao configurar ou modificar um AD autogerenciado.
****
| Código de erro | Descrição | Causas comuns | Sugestões de solução de problemas |
| --- | --- | --- | --- |
| Erro 2 / 0x2 | O sistema não conseguiu encontrar o arquivo especificado. | O formato ou a localização da unidade organizacional (OU) especificada com o parâmetro `—domain-ou` é inválido. A conta de serviço do domínio especificada por meio do AWS Secrets Manager não tem as permissões necessárias para se associar à OU. | Revise o parâmetro `—domain-ou`. Certifique-se de que a conta de serviço do domínio tenha as permissões corretas para a OU. Para obter mais informações, consulte [Configurar uma conta de serviço do domínio de AD](USER_SQLServer_SelfManagedActiveDirectory.Requirements.md#USER_SQLServer_SelfManagedActiveDirectory.Requirements.DomainAccountConfig). |
| Erro 5 / 0x5 | Acesso negado. | Permissões configuradas incorretamente para a conta de serviço do domínio, ou a conta de computador já existe no domínio. | Revise as permissões da conta de serviço no domínio e verifique se a conta de computador do RDS não está duplicada no domínio. Você pode verificar o nome da conta de computador do RDS executando `SELECT @@SERVERNAME` em sua instância de banco de dados do RDS para SQL Server. Se você estiver usando multi-AZ, tente reinicializar com failover, depois verifique a conta de computador do RDS novamente. Para obter mais informações, consulte [Reinicializar uma instância de banco de dados](USER_RebootInstance.md). |
| Erro 87 / 0x57 | O parâmetro está incorreto. | A conta de serviço do domínio especificada por meio do AWS Secrets Manager não tem as permissões corretas. O perfil do usuário também pode estar corrompido. | Revise os requisitos da conta de serviço do domínio. Para obter mais informações, consulte [Configurar uma conta de serviço do domínio de AD](USER_SQLServer_SelfManagedActiveDirectory.Requirements.md#USER_SQLServer_SelfManagedActiveDirectory.Requirements.DomainAccountConfig). |
| Erro 234 / 0xEA | A unidade organizacional (OU) especificada não existe. | A OU especificada com o parâmetro `—domain-ou` não existe em seu AD autogerenciado. | Revise o parâmetro `—domain-ou` e verifique se a OU especificada existe em seu AD autogerenciado. |
| Erro 1326 / 0x52E | O nome de usuário ou a senha estão incorretos. | As credenciais da conta de serviço do domínio fornecidas no AWS Secrets Manager contêm um nome de usuário desconhecido ou uma senha incorreta. A conta de domínio também pode estar desabilitada em seu AD autogerenciado. | Verifique se as credenciais fornecidas no AWS Secrets Manager estão corretas e se a conta de domínio está habilitada no AD autogerenciado. |
| Erro 1355 / 0x54B | O domínio especificado não existe ou não foi possível estabelecer conexão. | O domínio está inativo, o conjunto especificado de IPs DNS está inacessível ou o FQDN especificado está inacessível. | Revise os parâmetros `—domain-dns-ips` e `—domain-fqdn` para garantir que estejam corretos. Revise a configuração de rede da sua instância de banco de dados do RDS para SQL Server e garanta que seu AD autogerenciado esteja acessível. Para obter mais informações, consulte [Configurar sua conectividade de rede](USER_SQLServer_SelfManagedActiveDirectory.Requirements.md#USER_SQLServer_SelfManagedActiveDirectory.Requirements.NetworkConfig). |
| Erro 1722 / 0x6BA | O servidor RPC não está disponível. | Houve um problema ao acessar o serviço RPC do domínio de AD. Isso pode ser devido a um problema de serviço ou rede. | Valide se o serviço RPC está sendo executado nos controladores de domínio e se as portas TCP `135` e `49152-65535` em seu domínio podem ser acessadas por sua instância de banco de dados do RDS para SQL Server. |
| Erro 1727/0x6BF | A chamada do procedimento remoto falhou e não foi executada. | Problema de conectividade de rede ou restrição de firewall que bloqueia a comunicação RPC com o controlador de domínio. | Se estiver usando a união de domínios VPC cruzados, verifique se a comunicação entre a VPC está configurada corretamente com o emparelhamento de VPC ou o Transit Gateway. Garanta que portas TCP altas `49152-65535` em seu domínio possam ser acessadas por sua instância de banco de dados do RDS para SQL Server, incluindo possíveis restrições de firewall. |
| Erro 2224 / 0x8B0 | A conta de usuário já existe. | A conta de computador que está tentando ser adicionada ao AD autogerenciado já existe. | Identifique a conta de computador executando `SELECT @@SERVERNAME` em sua instância de banco de dados do RDS para SQL Server, depois remova-a cuidadosamente do AD autogerenciado. |
| Erro 2242 / 0x8c2 | A senha deste usuário expirou. | A senha da conta de serviço do domínio especificada por meio do AWS Secrets Manager expirou. | Atualize a senha da conta de serviço do domínio usada para associar a instância de banco de dados do RDS para SQL Server ao seu AD autogerenciado. |
Depois de unir sua instância de banco de dados a um domínio Active Directory autogerenciado, você pode receber eventos do RDS relacionados à integridade do seu domínio.
```
Unhealthy domain state detected while attempt to verify or
configure your Kerberos endpoint in your domain on
node node_n. message
```
Para instâncias multi-AZ, você pode observar o relatório de erros para node1 e node2, o que indica que a configuração do Kerberos da sua instância não está pronta para failover. No caso de um failover, você pode ter dificuldades de autenticação usando o Kerberos. Resolva os problemas de configuração para garantir que a configuração do Kerberos seja válida e atualizada. Para instâncias multi-AZ, nenhuma ação é necessária para usar a autenticação do Kerberos no novo host primário, já que todas as configurações de rede e permissão estão em vigor.
Em relação a instâncias Single-AZ, o node1 é o nó primário. Se sua autenticação Kerberos não estiver funcionando conforme o esperado, confira os eventos da instância e resolva os problemas de configuração para garantir que a configuração do Kerberos seja válida e atualizada.
## Restaurar uma instância de banco de dados do SQL Server e adicioná-la a um domínio de Active Directory autogerenciado
Você pode restaurar um snapshot de banco de dados ou fazer uma recuperação para um ponto no tempo (PITR) de uma instância de banco de dados do SQL Server e adicioná-la a um domínio de Active Directory autogerenciado. Depois que a instância de banco de dados tiver sido restaurada, modifique-a usando o processo explicado em [Etapa 1: Criar ou modificar a instância de banco de dados do SQL Server](USER_SQLServer_SelfManagedActiveDirectory.Joining.md#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.CreateModify) para adicioná-la a um domínio de AD autogerenciado.