# Trabalhar com o Microsoft Active Directory e o RDS Custom para SQL Server O RDS Custom para SQL Server permite associar as instâncias a um Active Directory (AD) autogerenciado ou AWS Managed Microsoft AD. Isso ocorre independentemente de onde o AD esteja hospedado, como em um data center on-premises, no Amazon EC2 ou em qualquer outro provedor de serviços de nuvem. Em relação à autenticação de usuários e de serviços, é possível usar a autenticação NTLM ou Kerberos na instância de banco de dados do RDS Custom para SQL Server sem usar domínios intermediários e relações de confiança de floresta. Quando um usuário tenta se autenticar na instância de banco de dados do RDS Custom para SQL Server com um Active Directory autoassociado, as solicitações de autenticação são encaminhadas a um AD autogerenciado ou AWS Managed Microsoft AD especificado por você. Nas seções a seguir, é possível encontrar informações sobre como trabalhar com um Active Directory autogerenciado e com o Active Directory gerenciado pela AWS para o RDS Custom para SQL Server. **Topics** + [ ## Disponibilidade de regiões e versões ](#custom-sqlserver-WinAuth.Regions) + [ # Configurar o AD autogerenciado ou on-premises ](custom-sqlserver-WinAuth.config-Self-Managed.md) + [ # Configurar o Microsoft Active Directory usando o Directory Service ](custom-sqlserver-WinAuth.config-ADS.md) + [ # Regras de portas para configuração de rede ](custom-sqlserver-WinAuth.NWConfigPorts.md) + [ # Validação da rede ](custom-sqlserver-WinAuth.NWValidation.md) + [ # Configurar a autenticação do Windows para instâncias do RDS Custom para SQL Server ](custom-sqlserver-WinAuth.settingUp.md) + [ # Gerenciamento de uma instância de banco de dados em um domínio ](custom-sqlserver-WinAuth.ManagingDBI.md) + [ # Compreensão da associação de domínio ](custom-sqlserver-WinAuth.Understanding.md) + [ # Solucionar problemas no Active Directory ](custom-sqlserver-WinAuth.Troubleshoot.md) ## Disponibilidade de regiões e versões O RDS Custom para SQL Server aceita o AD autogerenciado e o AWS Managed Microsoft AD usando o NTLM ou o Kerberos em todas as regiões compatíveis com o RDS Custom para SQL Server. Para ter mais informações, consulte [Regiões e mecanismos de banco de dados compatíveis com o RDS Custom](Concepts.RDS_Fea_Regions_DB-eng.Feature.RDSCustom.md). # Configurar o AD autogerenciado ou on-premises Para associar o Microsoft AD on-premises ou autogerenciado à instância de banco de dados do RDS Custom para SQL Server, o Active Domain deve ser configurado da seguinte maneira: + Defina as sub-redes na VPC associada à instância de banco de dados do RDS Custom para SQL Server no AD autogerenciado ou on-premises. Confirme se não há nenhum conflito entre as sub-redes na VPC e as sub-redes nos 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. + O nome de domínio do AD não pode estar no formato de domínio de rótulo único (SLD). O RDS Custom para SQL Server não é compatível com domínios SLD. + O nome de domínio totalmente qualificado (FQDN) do AD não pode exceder 47 caracteres. ## Configurar sua conectividade de rede Configure a conectividade de rede do AD autogerenciado ou on-premises da seguinte maneira: + Configure a conectividade entre a Amazon VPC, em que a instância do RDS Custom para SQL Server está em execução, e o AD. Use Direct Connect, Site-to-Site VPN, AWS Transit Gateway e emparelhamento da VPC. + Permita o tráfego nas portas dos grupos de segurança e ACLs de rede do RDS Custom para SQL Server para o AD autogerenciado ou on-premises. Para obter mais informações, consulte [Regras de portas para configuração de rede](custom-sqlserver-WinAuth.NWConfigPorts.md). ![\[Diretório de autenticação Windows do Microsoft SQL Server\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/custom-sqs-SM-NC.png) ## Configurar a resolução de DNS Defina os seguintes requisitos para configurar a resolução de DNS com ADs autogerenciados ou on-premises: + Configure a resolução de DNS na VPC para resolver um nome de domínio totalmente qualificado (FQDN) do Active Directory auto-hospedado. Um exemplo de FQDN é `corp.example.local`. Para configurar a resolução de DNS, configure o resolvedor de DNS da VPC para encaminhar consultas a determinados domínios com um endpoint de saída do Amazon Route 53 e uma regra de resolvedor. Para ter mais informações, veja [como configurar um endpoint de saída do Route 53 Resolver para resolver registros DNS](https://repost.aws/knowledge-center/route53-resolve-with-outbound-endpoint). + Em relação a workloads que utilizem tanto VPCs quanto recursos on-premises, é necessário resolver os registros DNS hospedados on-premises. Os recursos on-premises talvez precisem resolver nomes hospedados na AWS. Para criar uma configuração de nuvem híbrida, use endpoints de resolvedor e regras de encaminhamento condicional para resolver consultas ao DNS entre os recursos on-premises e a VPC personalizada. Para ter mais informações, consulte [Resolving DNS queries between VPCs and your network](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-overview-DSN-queries-to-vpc.html) no *Guia do desenvolvedor do Amazon Route 53*. **Importante** A modificação das configurações do resolvedor de DNS da interface de rede no RDS Custom para SQL Server faz com que os endpoints da VPC habilitados para DNS deixem de funcionar corretamente. Os endpoints da VPC habilitados para DNS são necessários para instâncias em sub-redes privadas sem acesso à internet. # Configurar o Microsoft Active Directory usando o Directory Service O AWS Managed Microsoft AD cria um Microsoft Active Directory totalmente gerenciado na AWS que é habilitado pelo Windows Server 2019 e opera nos níveis funcionais de floresta e de domínio do 2012 R2. O Directory Service cria os controladores de domínio em diferentes sub-redes em uma Amazon VPC, tornando o diretório altamente disponível mesmo em caso de falha. Para criar um diretório com o AWS Managed Microsoft AD, consulte [Getting started with AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started.html) no *Guia de administração do AWS Directory Service*. ## Configurar sua conectividade de rede ### Habilitar o tráfego entre VPCs entre o diretório e a instância de banco de dados Para localizar o diretório e a instância de banco de dados na mesma VPC, ignore esta etapa e vá para a próxima etapa em [Regras de portas para configuração de rede](custom-sqlserver-WinAuth.NWConfigPorts.md). Para localizar o diretório e a instância de bancos de dados em VPCs diferentes, configure o tráfego entre VPCs usando o emparelhamento da VPC ou o AWS Transit Gateway. Para ter mais informações sobre emparelhamento da VPC, consulte [O que é emparelhamento de VPC?](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) no *Guia de emparelhamento da Amazon VPC* e [What is AWS Transit Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) nos *Gateways de Trânsito da Amazon VPC*. **Habilitar o tráfego entre VPCs usando o emparelhamento da VPC** 1. Configure regras apropriadas de roteamento de VPC para garantir que o tráfego de rede possa fluir em ambos os sentidos. 1. Permita que o grupo de segurança da instância de banco de dados possa receber o tráfego de entrada do grupo de segurança do diretório. Para obter mais informações, consulte [Regras de portas para configuração de rede](custom-sqlserver-WinAuth.NWConfigPorts.md). 1. A lista de controle de acesso (ACL) de rede não deve bloquear o tráfego. Se uma Conta da AWS diferente for proprietária do diretório, será necessário compartilhar o diretório. Para compartilhar o diretório com a Conta da AWS em que a instância do RDS Custom para SQL Server está, siga o [Tutorial: Sharing your AWS Managed Microsoft AD for seamless EC2 domain-join](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_directory_sharing.html) no *Guia de administração do AWS Directory Service*. **Compartilhar um diretório entre Contas da AWS** 1. Faça login no console do Directory Service usando a conta para a instância de banco de dados e confira se o domínio tem o status `SHARED` antes de prosseguir. 1. Depois de fazer login no console do Directory Service usando a conta da instância de banco de dados, observe o valor do **ID do diretório**. Use esse ID para associar a instância de banco de dados ao domínio. ## Configurar a resolução de DNS Quando você cria um diretório do AWS Managed Microsoft AD, o Directory Service cria dois controladores de domínio e adiciona o serviço DNS em seu nome. Se você já tem um AWS Managed Microsoft AD ou planeja inicializá-lo em uma VPC diferente da instância de banco de dados do RDS Custom para SQL Server, configure o resolvedor de DNS da VPC para encaminhar consultas a determinados domínios com uma regra de saída e de resolvedor do Route 53. Veja [como configurar um endpoint de saída do Route 53 Resolver para resolver registros DNS](https://repost.aws/knowledge-center/route53-resolve-with-outbound-endpoint). # Regras de portas para configuração de rede Você precisa atender às seguintes configurações de rede: + Conectividade configurada entre a Amazon VPC na qual você deseja criar a instância de banco de dados do RDS Custom para SQL Server e o Active Directory autogerenciado ou AWS Managed Microsoft AD. Em relação ao Active Directory autogerenciado, configure a conectividade usando o AWS Direct Connect, a AWS VPN, o emparelhamento da VPC ou o AWS Transit Gateway. Em relação ao AWS Managed Microsoft AD, configure a conectividade utilizando emparelhamento da VPC. + 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 Custom 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 do Microsoft Active Directory.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/custom_sqlserver_ActiveDirectory_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/custom-sqlserver-WinAuth.NWConfigPorts.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 instância de banco de dados do RDS Custom 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 Custom 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. # Validação da rede Antes de associar a instância do RDS Custom ao AWS Managed Microsoft AD ou autogerenciado, confira as informações a seguir em uma instância do EC2 na mesma VPC em que você planeja inicializar a instância do RDS Custom para SQL Server. + Confira se consegue resolver o nome de domínio totalmente qualificado (FQDN) para os IPs do controlador de domínio. ``` nslookup corp.example.com ``` O comando deve exibir uma saída semelhante: ``` Server: ip-10-0-0-2.us-west-2.compute.internal Address: 25.0.0.2 Non-authoritative answer: Name: corp.example.com Addresses: 40.0.9.25 (DC1 IP) 40.0.50.123 (DC2 IP) ``` + Resolva os serviços da AWS de uma instância do EC2 na VPC em que planeja iniciar a instância do RDS Custom: ``` $region='input-your-aws-region' $domainFQDN='input-your-domainFQDN' function Test-DomainPorts { param ( [string]$Domain, [array]$Ports ) foreach ($portInfo in $Ports) { try { $conn = New-Object System.Net.Sockets.TcpClient $connectionResult = $conn.BeginConnect($Domain, $portInfo.Port, $null, $null) $success = $connectionResult.AsyncWaitHandle.WaitOne(1000) # 1 second timeout if ($success) { $conn.EndConnect($connectionResult) $result = $true } else { $result = $false } } catch { $result = $false } finally { if ($null -ne $conn) { $conn.Close() } } Write-Host "$($portInfo.Description) port open: $result" } } # Check if ports can be reached $ports = @( @{Port = 53; Description = "DNS"}, @{Port = 88; Description = "Kerberos"}, @{Port = 389; Description = "LDAP"}, @{Port = 445; Description = "SMB"}, @{Port = 5985; Description = "WinRM"}, @{Port = 636; Description = "LDAPS"}, @{Port = 3268; Description = "Global Catalog"}, @{Port = 3269; Description = "Global Catalog over SSL"}, @{Port = 9389; Description = "AD DS"} ) function Test-DomainReachability { param ( [string]$DomainName ) try { $dnsResults = Resolve-DnsName -Name $DomainName -ErrorAction Stop Write-Host "Domain $DomainName is successfully resolving to following IP addresses: $($dnsResults.IpAddress)" Write-Host "" return $true } catch { Write-Host "" Write-Host "Error Message: $($_.Exception.Message)" Write-Host "Domain $DomainName reachability check failed, please Configure DNS resolution" return $false } } $domain = (Get-WmiObject Win32_ComputerSystem).Domain if ($domain -eq 'WORKGROUP') { Write-Host "" Write-Host "Host $env:computername is still part of WORKGROUP and not part of any domain" } else { Write-Host "" Write-Host "Host $env:computername is joined to $domain domain" Write-Host "" } $isReachable = Test-DomainReachability -DomainName $domainFQDN if ($isReachable) { write-Host "Checking if domain $domainFQDN is reachable on required ports " Test-DomainPorts -Domain $domainFQDN -Ports $ports } else { Write-Host "Port check skipped. Domain not reachable" } # Get network adapter configuration $networkConfig = Get-WmiObject Win32_NetworkAdapterConfiguration | Where-Object { $_.IPEnabled -eq $true } | Select-Object -First 1 # Check DNS server settings $dnsServers = $networkConfig.DNSServerSearchOrder if ($dnsServers) { Write-Host "`nDNS Server settings:" foreach ($server in $dnsServers) { Write-Host " - $server" } } else { Write-Host "`nNo DNS servers configured or unable to retrieve DNS server information." } write-host "" # Checks reachability to dependent services $services = "s3", "ec2", "secretsmanager", "logs", "events", "monitoring", "ssm", "ec2messages", "ssmmessages" function Get-TcpConnectionAsync { param ( $ServicePrefix, $region ) $endpoint = "${ServicePrefix}.${region}.amazonaws.com" $tcp = New-Object Net.Sockets.TcpClient $result = $false try { $connectTask = $tcp.ConnectAsync($endpoint, 443) $timedOut = $connectTask.Wait(3000) $result = $tcp.Connected } catch { $result = $false } return $result } foreach ($service in $services) { $validationResult = Get-TcpConnectionAsync -ServicePrefix $service -Region $region Write-Host "Reachability to $service is $validationResult" } ``` O valor `TcpTestSucceeded` deve retornar `True` para `s3`, `ec2`, `secretsmanager`, `logs`, `events`, `monitoring`, `ssm`, `ec2messages` e `ssmmessages`. # 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. + Para criar uma OU e um usuário do domínio do AD no AD on-premises ou autogerenciado, é possível conectar o controlador de domínio como administrador de domínio. + Para criar usuários e grupos em um diretório do Directory Service, é necessário se conectar a uma instância de gerenciamento. Você também precisa fazer login como um usuário com privilégios para criar usuários e grupos. Para ter mais informações, consulte [User and group management in AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups.html) no *Guia de administração do AWS Directory Service*. + Para gerenciar o Active Directory na instância do Windows Server do Amazon EC2, é necessário instalar os serviços de domínio do Active Directory e as ferramentas dos serviços do Active Directory Lightweight Directory na instância do EC2. Para ter mais informações, consulte [Installing the Active Directory Administration ToolsAWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_install_ad_tools.html) no *Guia de administração do AWS Directory Service*. + Para facilitar a administração, recomendamos instalar essas ferramentas em uma instância do EC2 separada para administração, e não na instância de banco de dados do RDS Custom para SQL Server. Veja a seguir os requisitos da conta de serviço do domínio do AD: + É necessário ter uma conta de serviço no domínio do AD com permissões delegadas para associar computadores ao domínio. Uma conta de serviço de domínio é uma conta de usuário no AD que recebeu permissão para realizar determinadas tarefas. + Delegue à conta de serviço de domínio as seguintes permissões na unidade organizacional à qual você está associando a instância do RDS Custom 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 + Em relação ao AD on-premises e autogerenciado, a conta de serviço de domínio deve ser membro do grupo “Administradores do sistema de nomes de domínio delegados da AWS”. + Em relação ao AWS Managed Microsoft AD, a conta de serviço de domínio deve ser membro do grupo “DnsAdmins”. 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](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/access-denied-when-joining-computers) na documentação do Microsoft Windows Server. **Importante** Não mova objetos de computador criados pelo RDS Custom para SQL Server na unidade organizacional (UO) depois da criação da instância de banco de dados. Mover os objetos associados fará com que a instância de banco de dados do RDS Custom para SQL Server tenha configurações incorretas. Se você precisar mover os objetos de computador criados pelo Amazon RDS, use a ação [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) para modificar os parâmetros do domínio com a localização desejada dos objetos de computador. **Topics** + [ ## Etapa 1: criar uma unidade organizacional (UO) no AD ](#custom-sqlserver-WinAuth.settingUp.CreateOU) + [ ## Etapa 2: criar um usuário do domínio do AD ](#custom-sqlserver-WinAuth.settingUp.ADuser) + [ ## Etapa 3: delegar controle ao usuário do AD no AWS Managed Microsoft AD ou autogerenciado ](#custom-sqlserver-WinAuth.settingUp.Delegate) + [ ## Etapa 4: criar um segredo ](#custom-sqlserver-WinAuth.settingUp.ASM) + [ ## Etapa 5: criar ou modificar a instância de banco de dados do RDS Custom para SQL Server ](#custom-sqlserver-WinAuth.settingUp.CreateDBInstance) + [ ## Etapa 6: criar login do SQL Server para autenticação do Windows ](#custom-sqlserver-WinAuth.settingUp.CreateLogins) + [ ## Etapa 7: usar a autenticação do Kerberos ou NTLM ](#custom-sqlserver-WinAuth.settingUp.KerbNTLM) ## Etapa 1: criar uma unidade organizacional (UO) no AD Use as seguintes etapas para criar uma unidade organizacional no AD: **Criar uma UO no AD** 1. Conecte-se ao domínio do 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 **Unidade organizacional**. 1. Insira um nome para a OU. Habilite a opção **Proteger o contêiner contra exclusão acidental**. 1. Escolha **OK**. A nova UO será exibida no domínio. 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. **Criar um usuário do domínio no AD** 1. Abra **Usuários e computadores do Active Directory** e selecione o domínio e a UO 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, um sobrenome e um nome de login para o usuário. Clique em **Next**. 1. Insira uma senha para o usuário. Não selecione as opções **O usuário deve alterar a senha no próximo login** e **A conta está desabilitada**. Clique em **Next**. 1. Clique em **OK**. O novo usuário será exibido no domínio. ## Etapa 3: delegar controle ao usuário do AD no AWS Managed Microsoft AD ou autogerenciado **Como delegar controle ao usuário do domínio de AD** 1. Abra o snap-in do MMC **Usuários e computadores do Active Directory** e selecione o domínio. 1. Clique com o botão direito do mouse na UO criada anteriormente e escolha **Delegar controle**. 1. No **Assistente de controle de delegação**, 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 o usuário do AD que você criou e clique em **Conferir nomes**. Se a verificação de usuário do AD for bem-sucedida, clique em **OK**. 1. Na seção **Usuários ou grupos**, confirme se o usuário do AD foi adicionado e clique em **Próximo**. 1. Na seção **Tarefas para delegar**, selecione **Criar uma tarefa personalizada para delegar** e escolha **Próximo**. 1. Na seção **Tipo de objeto do Active Directory**: Selecione **Somente os objetos a seguir na pasta**. Selecione **Objetos do computador**. Selecione **Criar objetos selecionados nesta pasta**. Selecione **Excluir objetos selecionados nesta pasta** e clique em **Próximo**. 1. Na seção **Permissões**: Mantenha a opção **Geral** selecionada. Selecione **Gravação validada no nome do host DNS**. Selecione **Gravação validada no nome da entidade principal de serviço** e clique em **Próximo**. 1. Em **Concluir o assistente de delegação de controle**, confirme as configurações e clique em **Concluir**. ## 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](#custom-sqlserver-WinAuth.settingUp.ADuser). ------ #### [ 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 o nome do usuário do AD (sem o prefixo do domínio) para o valor. + A segunda chave, `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 \ --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 ^ --tags Key="AWSRDSCustom",Value="custom-sqlserver" ``` ------ ## 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: + 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). **nota** Se a instância do RDS Custom para SQL Server já estiver associada manualmente a um AD, confira as configurações de [Regras de portas para configuração de rede](custom-sqlserver-WinAuth.NWConfigPorts.md) e [Validação da rede](custom-sqlserver-WinAuth.NWValidation.md), depois conclua as etapas de 1 a 4. Atualize o `--domain-fqdn`, `--domain-ou` e `--domain-auth-secret-arn` para o AD, para que as configurações e as credenciais de ingresso no domínio sejam registradas no RDS Custom para monitorar, registrar o CNAME e realizar ações de recuperação. 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: + Em relação ao parâmetro `--domain-fqdn`, use o nome de domínio totalmente qualificado do seu AD autogerenciado. + Para o parâmetro `--domain-ou`, use a OU criada em seu AD autogerenciado. + Em relação ao parâmetro `--domain-auth-secret-arn`, use o valor do **ARN do segredo** que você criou. **Importante** Se você modificar uma instância de banco de dados para associá-la ou removê-la de um domínio do AD autogerenciado ou do AWS Managed Microsoft AD, 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** causa tempo de inatividade para uma instância de banco de dados single-AZ. Um cluster de banco de dados multi-AZ realiza um failover antes de concluir a reinicialização. Para obter mais informações, consulte [Modificar uma instância de banco de dados do Amazon RDS](Overview.DBInstance.Modifying.md). 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 ``` **Importante** Se o NetBIOS para AWS Managed Microsoft AD for **corpexample**, ele aparecerá como uma UO em si. Qualquer nova UO criada anteriormente aparecerá como uma UO aninhada. Para AWS Managed Microsoft AD, defina `--domain-ou` como `"OU=RDSCustomOU,OU=corpexample,DC=corp,DC=example,DC=com"`. 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. ![\[Diretório de autenticação Windows do Microsoft SQL Server\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/images/custom-sqs-WinAuth.png) 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](custom-sqlserver-WinAuth.Troubleshoot.md). ## 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; ``` # Gerenciamento de uma instância de banco de dados em um domínio É 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 no domínio. 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 uma união de domínio novamente cuja associação falhou, use a operação [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) da API e especifique o ID do diretório da associação atual. + Para atualizar o nome da função do IAM para a associação, use a operação `ModifyDBInstance` da API e especifique o ID do diretório da associação atual e a nova função do IAM. + Para remover uma instância de banco de dados de um domínio, use a operação `ModifyDBInstance` da API e especifique `none` como o parâmetro do domínio. + Para mover uma instância de banco de dados de um domínio para outro, use a operação `ModifyDBInstance` da API e especifique o identificador do novo domínio como o parâmetro do domínio. + Para listar a associação de cada instância de banco de dados, use a operação [DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/DescribeDBInstances.html) da API. ## Restaurar uma instância de banco de dados do RDS Custom para SQL Server e adicioná-la a um domínio de Active Directory É possível 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. Depois que a instância de banco de dados for restaurada, modifique-a utilizando o processo explicado em [Etapa 5: criar ou modificar a instância de banco de dados do RDS Custom para SQL Server](custom-sqlserver-WinAuth.settingUp.md#custom-sqlserver-WinAuth.settingUp.CreateDBInstance) para adicionar a instância de banco de dados a um domínio do AD. # Compreensão da associação de domínio Após criar ou modificar sua instância de banco de dados, a instância se tornará um membro do domínio. O console da AWS indica o status da associação de domínio 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. + **joining** – a instância está em processo de se tornar membro do domínio. + **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 durante a próxima janela de manutenção agendada. + **pending-removal** – a remoção da instância do domínio está pendente. + **pending-maintenance-removal**: a AWS tentará remover a instância do domínio durante a próxima janela de manutenção programada. + **failed** – um problema de configuração impediu que a instância se associasse ao domínio. 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. Uma solicitação para se tornar um membro de um domínio pode falhar devido a um problema de conectividade de rede ou a uma função do IAM incorreta. Por exemplo, é possível criar uma instância de banco de dados ou modificar uma instância existente e não conseguir transformar a instância de banco de dados em um membro de um domínio. Nesse caso, reexecute o comando para criar ou modificar a instância de banco de dados ou modifique a instância recém-criada para ingressar no domínio. # Solucionar problemas no Active Directory Veja a seguir alguns problemas que você pode encontrar ao configurar ou modificar um AD. | 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. | | 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. É possível verificar o nome da conta de computador do RDS executando `SELECT @@SERVERNAME` na instância de banco de dados do RDS Custom para SQL Server. Se você estiver usando multi-AZ, tente reinicializar com failover, depois verifique a conta de computador do RDS novamente. Para ter 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. | | Erro 234 / 0xEA | A unidade organizacional (OU) especificada não existe. | A UO especificada com o parâmetro `—domain-ou` não existe no AD. | Revise o parâmetro `—domain-ou` e verifique se a UO especificada existe no AD. | | 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 do domínio também pode estar desabilitada no AD. | Verifique se as credenciais fornecidas no AWS Secrets Manager estão corretas e se a conta de domínio está habilitada no Active Directory. | | 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 instância de banco de dados do RDS Custom para SQL Server e garanta que o AD esteja acessível. | | 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. | Confirme se o serviço RPC está sendo executado nos controladores de domínio e se as portas TCP `135` e `49152-65535` no domínio podem ser acessadas pela instância de banco de dados do RDS Custom para SQL Server. | | Erro 2224 / 0x8B0 | A conta de usuário já existe. | A conta de computador que está tentando ser adicionada ao AD já existe. | Identifique a conta de computador executando `SELECT @@SERVERNAME` na instância de banco de dados do RDS Custom para SQL Server, depois remova-a cuidadosamente do AD. | | 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 Custom para SQL Server ao AD. |