# Uso de Microsoft Active Directory con RDS Custom para SQL Server RDS Custom para SQL Server permite unir sus instancias a un Active Directory (AD) autoadministrado o AWS Managed Microsoft AD. Esto es independientemente de dónde esté alojado su AD, como un centro de datos en las instalaciones, Amazon EC2 o cualquier otro proveedor de servicios en la nube. Para la autenticación de usuarios y servicios, puede usar la autenticación de NTML o Kerberos en su instancia de base de datos de RDS Custom para SQL Server sin utilizar dominios intermediarios ni relaciones de confianza entre bosques. Cuando un usuario intenta autenticarse en su instancia de base de datos RDS Custom para SQL Server con una instancia de Active Directory autounida, las solicitudes de autenticación se reenvían a un AD autoadministrado o AWS Managed Microsoft AD que usted especifique. En las siguientes secciones, encontrará información sobre cómo utilizar Active Directory autoadministrado y AWS Managed Active Directory para RDS Custom para SQL Server. **Topics** + [ ## Disponibilidad en regiones y versiones ](#custom-sqlserver-WinAuth.Regions) + [ # Configuración de AD autoadministrado o en las instalaciones ](custom-sqlserver-WinAuth.config-Self-Managed.md) + [ # Configuración de Microsoft Active Directory mediante Directory Service ](custom-sqlserver-WinAuth.config-ADS.md) + [ # Reglas de puertos de configuraciones de redes ](custom-sqlserver-WinAuth.NWConfigPorts.md) + [ # Validación de red ](custom-sqlserver-WinAuth.NWValidation.md) + [ # Configuración de la autenticación de Windows para las instancias de RDS Custom para SQL Server ](custom-sqlserver-WinAuth.settingUp.md) + [ # Administración de una instancia de base de datos en un dominio ](custom-sqlserver-WinAuth.ManagingDBI.md) + [ # Descripción de la pertenencia a los dominios ](custom-sqlserver-WinAuth.Understanding.md) + [ # Solución de problemas de Active Directory ](custom-sqlserver-WinAuth.Troubleshoot.md) ## Disponibilidad en regiones y versiones RDS Custom para SQL Server admite AD autoadministrado y AWS Managed Microsoft AD usando NTLM o Kerberos en todas las regiones en las que se admite RDS Custom para SQL Server. Para obtener más información, consulte [Regiones y motores de base de datos admitidos para RDS Custom](Concepts.RDS_Fea_Regions_DB-eng.Feature.RDSCustom.md). # Configuración de AD autoadministrado o en las instalaciones Para unir su Microsoft AD en las instalaciones o autoadministrado a su instancia de base de datos de RDS Custom para SQL Server, debe configurar su dominio activo de la siguiente manera: + Defina las subredes de la VPC asociadas a su instancia de base de datos de RDS Custom para SQL Server en su AD autoadministrado o en las instalaciones. Confirme que no haya ningún conflicto entre las subredes de la VPC y las subredes de sus sitios de AD. + El controlador de dominio de AD tiene un nivel funcional de dominio de Windows Server 2008 R2 o superior. + El nombre de dominio de AD no puede estar en formato de dominio de etiqueta única (SLD). RDS Custom para SQL Server no admite dominios de SLD. + El nombre de dominio completo (FQDN) y su AD no pueden superar los 47 caracteres. ## Configure la conectividad de red Configure la conectividad de red de AD en las instalaciones o autoadministradas de la siguiente manera: + Configure la conectividad entre Amazon VPC en la que esté ejecutándose la instancia de RDS Custom para SQL Server y su AD. Utilice Direct Connect, Site-to-Site VPN, AWS Transit Gateway y emparejamiento de VPC. + Permita que el tráfico de los puertos de los grupos de seguridad y las ACL de su red de RDS Custom para SQL Server se dirija a su AD en las instalaciones o autoadministrado. Para obtener más información, consulte [Reglas de puertos de configuraciones de redes](custom-sqlserver-WinAuth.NWConfigPorts.md). ![\[Directorio de autenticación de Windows de Microsoft SQL Server\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/custom-sqs-SM-NC.png) ## Configuración de la resolución de DNS Configure los siguientes requisitos para configurar la resolución de DNS con los AD autoadministrados o en las instalaciones: + Configure la resolución de DNS en su VPC para resolver el nombre de dominio completo (FQDN) de Active Directory que está hospedado en el servidor. Un ejemplo de un FQDN es `corp.example.local`. Para configurar la resolución de DNS, configure la resolución de DNS de la VPC para que reenvíe las consultas de determinados dominios con una regla de resolución y punto de conexión de salida de Amazon Route 53. Para obtener más información, consulte [Configure a Route 53 Resolver outbound endpoint to resolve DNS records](https://repost.aws/knowledge-center/route53-resolve-with-outbound-endpoint). + Para las cargas de trabajo que aprovechan tanto las VPC como los recursos locales, debe resolver los registros de DNS alojados en las instalaciones. Es posible que los recursos en las instalaciones deban resolver los nombres alojados en AWS. Para crear una configuración de nube híbrida, utilice puntos de conexión del solucionador y riles de reenvío condicional para resolver las consultas de DNS entre recursos ubicados en las instalaciones y VPC personalizadas. Para obtener más información, consulte [Resolving DNS queries between VPCs and your network](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-overview-DSN-queries-to-vpc.html) en la *Guía para desarrolladores de Amazon Route 53*. **importante** La modificación de la configuración del solucionador de DNS de la interfaz de red del servidor RDS Custom para SQL Server provoca que los puntos de conexión de VPC con DNS dejen de funcionar correctamente. Se requieren puntos de conexión de VPC habilitados para DNS para las instancias dentro de subredes privadas sin acceso a Internet. # Configuración de Microsoft Active Directory mediante Directory Service AWS Managed Microsoft AD crea una instancia de Microsoft Active Directory completamente administrada en AWS que está equipada con Windows Server 2019 y que opera en los niveles funcionales de bosque y dominio 2012 R2. Directory Service crea los controladores de dominio en diferentes subredes de una Amazon VPC, lo que hace que su directorio esté altamente disponible incluso en caso de error. Para crear un directorio con AWS Managed Microsoft AD, consulte [Introducción a AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started.html) en la *Guía de administraciónAWS Directory Service*. ## Configure la conectividad de red ### Cómo habilitar el tráfico entre VPC entre el directorio y la instancia de base de datos Para ubicar el directorio y la instancia de base de datos en la misma VPC, omita este paso y continúe con el siguiente paso en [Reglas de puertos de configuraciones de redes](custom-sqlserver-WinAuth.NWConfigPorts.md). Para ubicar el directorio y la instancia de base de datos en diferentes VPC, configure el tráfico entre VPC mediante el emparejamiento de VPC o AWS Transit Gateway. Para obtener más información sobre cómo usar el emparejamiento de VPC, consulte [¿Qué es una interconexión de VPC?](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) en la *Guía de interconexión de Amazon VPC* y [¿Qué es AWS Transit Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) en *Amazon VPC Transit Gateways*. **Cómo habilitar el tráfico entre VPC mediante el emparejamiento de VPC** 1. Configure las reglas de enrutamiento de VPC adecuadas para garantizar que el tráfico de red pueda fluir en ambos sentidos. 1. Permita que el grupo de seguridad de la instancia de base de datos pueda recibir tráfico de entrada del grupo de seguridad del directorio. Para obtener más información, consulte [Reglas de puertos de configuraciones de redes](custom-sqlserver-WinAuth.NWConfigPorts.md). 1. La lista de control de acceso (ACL) de red no debe bloquear el tráfico. Si una Cuenta de AWS distinta es la propietaria del directorio, debe compartirlo. Para compartir el directorio con una Cuenta de AWS en la que se encuentra la instancia de RDS Custom para SQL Server, siga el [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) de la *Guía de administración de AWS Directory Service*. **Uso compartido de un directorio entre Cuentas de AWS** 1. Inicie sesión en la consola de Directory Service utilizando la cuenta para la instancia de base de datos y asegúrese de que el dominio tiene el estado `SHARED` antes de continuar. 1. Una vez iniciada sesión en la consola de Directory Service utilizando la cuenta de la instancia de base de datos, anote el valor de **ID de directorio**. Utilice este identificador para unir la instancia de base de datos al dominio. ## Configuración de la resolución de DNS Al crear un directorio con AWS Managed Microsoft AD, Directory Service crea dos controladores de dominio y añade el servicio DNS en su nombre. Si ya tiene una instancia de AWS Managed Microsoft AD o planea lanzarla en una VPC distinta de su instancia de base de datos de RDS Custom para SQL Server, configure la instancia de resolución de DNS de la VPC para que reenvíe las consultas de determinados dominios con una regla de salida y resolución de Route 53, consulte [¿Cómo configuro un punto de conexión de salida de Route 53 Resolver para resolver los registros DNS alojados en una red remota a partir de los recursos de mi VPC?](https://repost.aws/knowledge-center/route53-resolve-with-outbound-endpoint) # Reglas de puertos de configuraciones de redes Asegúrese de cumplir las siguientes configuraciones de red: + Conectividad configurada entre la Amazon VPC donde desea crear la instancia de base de datos de RDS Custom para SQL Server en su Active Directory autoadministrado o AWS Managed Microsoft AD. En el caso de Active Directory autoadministrado, configure la conectividad mediante AWS Direct Connect, AWS VPN, emparejamiento de VPC o AWS Transit Gateway. Para AWS Managed Microsoft AD, configure la conectividad con el emparejamiento de VPC. + Asegúrese de que el grupo de seguridad y las ACL de red de VPC de las subredes en las que va a crear su instancia de base de datos de RDS Custom para SQL Server permitan el tráfico en los puertos y en las direcciones que se muestran en el siguiente diagrama. ![\[Reglas de puerto de configuración de red para Microsoft Active Directory.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/custom_sqlserver_ActiveDirectory_Requirements_NetworkConfig.png) En la siguiente tabla se identifica la función de cada puerto. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/custom-sqlserver-WinAuth.NWConfigPorts.html) + Por lo general, los servidores DNS de dominio se encuentran en los controladores de dominio de AD. No es necesario configurar el conjunto de opciones de DHCP de VPC para utilizar esta característica. Para obtener más información, consulte [Conjuntos de opciones de DHCP](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html) en la *Guía del usuario de Amazon VPC*. **importante** Si utiliza ACL de red de VPC, también debe permitir el tráfico saliente en los puertos dinámicos (49152-65535) desde su instancia de base de datos de RDS Custom para SQL Server. Asegúrese de que estas reglas de tráfico también se reflejen en los firewalls que se aplican a cada uno de los controladores de dominio de AD, los servidores DNS y las instancias de base de datos de RDS Custom para SQL Server. Si bien los grupos de seguridad de VPC requieren que los puertos se abran solo en la dirección en la que se inicia el tráfico de red, la mayoría de los firewalls de Windows y las ACL de red de VPC requieren que los puertos estén abiertos en ambas direcciones. # Validación de red Antes de unir su instancia de RDS Custom a una instancia autoadministrada o AWS Managed Microsoft AD, compruebe lo siguiente desde una instancia de EC2 de la misma VPC en la que planea lanzar la instancia de RDS Custom para SQL Server. + Compruebe si puede resolver el nombre de dominio completo (FQDN) en las IP del controlador de dominio. ``` nslookup corp.example.com ``` El comando debe devolver un resultado similar: ``` 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) ``` + Resuelva los servicios de AWS de una instancia de EC2 en la VPC en la que va a lanzar su instancia de 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" } ``` El valor de `TcpTestSucceeded` debe devolver `True` para `s3`, `ec2`, `secretsmanager`, `logs`, `events`, `monitoring`, `ssm`, `ec2messages` y `ssmmessages`. # Configuración de la autenticación de Windows para las instancias de RDS Custom para SQL Server Se recomienda crear credenciales de servicio y una OU dedicadas a esa unidad organizativa para todas las Cuenta de AWS que posean una instancia de base de datos de RDS Custom para SQL Server que se haya unido a su dominio de AD. Al crear credenciales de servicio u OU dedicadas, evita conflictos de permisos y seguir el principio de privilegio mínimo. Las políticas de grupo de Active Directory pueden entrar en conflicto con las automatizaciones y los permisos de AWS. Se recomienda seleccionar GPO que se apliquen únicamente a la unidad organizativa que cree para RDS Custom para SQL Server. + Para crear un usuario de dominio OU y AD en su AD en las instalaciones o autoadministrado, puede conectar el controlador de dominio como administrador de dominio. + Para crear usuarios y grupos en un directorio de Directory Service, debe estar conectado a una instancia de administración y haber iniciado sesión como usuario con privilegios para crear usuarios y grupos. Para obtener más información, consulte [Administración de usuarios y grupos en AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups.html) en la *Guía de administración de AWS Directory Service*. + Para administrar su Active Directory desde una instancia de Amazon EC2 de Windows Server, es necesario instalar las herramientas de los servicios de dominio de Active Directory y los servicios de directorio de Active Directory Lightweight en la instancia de EC2. Para obtener más información, consulte [Instalación de las herramientas de administración del Active Directory para AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_install_ad_tools.html) en la *Guía de administración de AWS Directory Service*. + Le recomendamos que instale estas herramientas en una instancia de EC2 independiente para la administración y no en su instancia de base de datos de RDS Custom para SQL Server para facilitar la administración. Estos son los requisitos de la cuenta de servicio de dominio de AD: + Debe tener una cuenta de servicio en su dominio de AD con permisos delegados para unir equipos al dominio. Una cuenta de servicio de dominio es una cuenta de usuario de su AD a la que se le ha delegado permiso para realizar determinadas tareas. + Delegue los siguientes permisos a la cuenta de servicio de dominio de la unidad organizativa a la que va a unir su instancia de RDS Custom para SQL Server: + Capacidad validada para escribir en el nombre de host DNS + Capacidad validada para escribir en el nombre de entidad principal del servicio + Crear y eliminar objetos de equipo + En el caso de AD en las instalaciones y autoadministrado, la cuenta de servicio de dominio debe ser miembro del grupo “Administradores delegados del sistema de nombres de dominio de AWS”. + En el caso de AWS Managed Microsoft AD, la cuenta de servicio de dominio debe ser miembro del grupo “DnsAdmins”. Estos son el conjunto mínimo de permisos que se requieren para unir objetos de equipo a su AD autoadministrado y AWS Managed Microsoft AD. Para obtener más información, consulte [Error: Se deniega el acceso cuando los usuarios que no son administradores que han sido delegados intentan unir equipos a un dominio](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/access-denied-when-joining-computers) en la documentación de Microsoft Windows Server. **importante** No mueva los objetos de equipo que RDS Custom para SQL Server cree en la unidad organizativa (OU) después de crear la instancia de base de datos. Si mueve los objetos asociados, la instancia de base de datos de RDS Custom para SQL Server podría configurarse mal. Si necesita mover los objetos de equipo creados por Amazon RDS, utilice la acción [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) para modificar los parámetros del dominio con la ubicación deseada de los objetos del equipo. **Topics** + [ ## Paso 1: Crear una unidad organizativa (OU) en el AD ](#custom-sqlserver-WinAuth.settingUp.CreateOU) + [ ## Paso 2: Crear un usuario de dominio de AD ](#custom-sqlserver-WinAuth.settingUp.ADuser) + [ ## Paso 3: Delegar el control al usuario de AD de forma autoadministrada o AWS Managed Microsoft AD ](#custom-sqlserver-WinAuth.settingUp.Delegate) + [ ## Paso 4: Crear un secreto ](#custom-sqlserver-WinAuth.settingUp.ASM) + [ ## Paso 5: Crear o modificar una instancia de base de datos de RDS Custom para SQL Server ](#custom-sqlserver-WinAuth.settingUp.CreateDBInstance) + [ ## Paso 6: Crear inicios de sesión de SQL Server de autenticación de Windows ](#custom-sqlserver-WinAuth.settingUp.CreateLogins) + [ ## Paso 7: Uso de la autenticación Kerberos o NTLM ](#custom-sqlserver-WinAuth.settingUp.KerbNTLM) ## Paso 1: Crear una unidad organizativa (OU) en el AD Efectúe los siguientes pasos para crear una unidad organizativa en su AD: **Creación de una OU en su AD** 1. Conéctese a su AD de dominio como administrador de dominio. 1. Abra **Usuarios y equipos de Active Directory** y seleccione el dominio en el que desea crear la OU. 1. Haga clic con el botón derecho en el dominio y seleccione **Nuevo** y, a continuación, **Unidad organizativa**. 1. Escriba un nombre para la OU. Habilite **Proteger el contenedor contra la eliminación accidental**. 1. Seleccione **Aceptar**. La nueva OU aparece en su dominio. Para AWS Managed Microsoft AD, el nombre de esta OU se basa en el nombre NetBIOS que escribió cuando creó el directorio. Esta OU es propiedad de AWS y contiene todos los objetos del directorio relacionados con AWS para los que a usted se le concede control total. De forma predeterminada, esta OU contiene dos OU secundarias **Equipos y usuarios**. Las nuevas OU que crea RDS Custom son secundarias de la unidad organizativa que se basa en NetBIOS. ## Paso 2: Crear un usuario de dominio de AD Las credenciales de usuario del dominio se utilizan para el secreto en Secrets Manager. **Creación de un usuario de dominio de AD en su AD** 1. Abra **Usuarios y equipos de Active Directory** y seleccione el dominio y la OU en los que desea crear el usuario. 1. Haga clic con el botón derecho en el objeto **Usuarios** y seleccione **Nuevo** y, a continuación, **Usuario**. 1. Introduzca el nombre, los apellidos y el nombre de inicio de sesión del usuario. Haga clic en **Next (Siguiente)**. 1. Introduzca una contraseña para el usuario. No seleccione **El usuario debe cambiar la contraseña en el próximo inicio de sesión** ni **La cuenta está deshabilitada**. Haga clic en **Next (Siguiente)**. 1. Haga clic en **OK (Aceptar)**. Su nuevo usuario aparece en su dominio. ## Paso 3: Delegar el control al usuario de AD de forma autoadministrada o AWS Managed Microsoft AD **Para delegar el control al usuario del dominio AD de su dominio** 1. Abra el complemento MMC **Usuarios y equipos de Active Directory** y seleccione su dominio. 1. Haga clic con el botón derecho en la OU que creó anteriormente y seleccione **Delegar control**. 1. En **Asistente para delegación de control**, haga clic en **Siguiente**. 1. En la sección **Usuarios o grupos**, haga clic en **Agregar**. 1. En **Seleccionar usuarios, equipos o grupos**, introduzca el usuario de AD que creó y haga clic en **Verificar nombres**. Si la comprobación de usuario de AD se ha realizado correctamente, haga clic en **Aceptar**. 1. En la sección **Usuarios o grupos**, confirme que ha agregado el usuario de AD y haga clic en **Siguiente**. 1. En la página **Tareas que se delegarán**, seleccione **Crear una tarea personalizada para delegar** y haga clic en **Siguiente**. 1. En la sección **Tipo de objeto de Active Directory**: Elija **Solo los siguientes objetos de la carpeta**. Seleccione **Objetos computacionales**. Seleccione **Crear objetos seleccionados en esta carpeta**. Seleccione **Eliminar los objetos seleccionados en esta carpeta** y haga clic en **Siguiente**. 1. En la sección **Permisos**: Mantenga seleccionada la opción **General**. Seleccione **Escritura validada en el nombre de host DNS**. Seleccione **Escritura validada en el nombre de la entidad de servicio** y haga clic en **Siguiente**. 1. Para **Completar el asistente para delegación de control**, confirme la configuración y haga clic en **Finalizar**. ## Paso 4: Crear un secreto Cree el secreto en la misma región y Cuenta de AWS que contiene la instancia de base de datos de RDS Custom para SQL Server que desea incluir en su directorio activo. Almacene las credenciales del usuario del dominio de AD creado en [Paso 2: Crear un usuario de dominio de AD](#custom-sqlserver-WinAuth.settingUp.ADuser). ------ #### [ Console ] + En AWS Secrets Manager, elija **Almacenar un nuevo secreto**. + En **Secret type** (Tipo de secreto), elija **Other type of secret** (Otro tipo de secreto). + En **Pares clave-valor**, agregue sus dos claves: + La primera clave, `SELF_MANAGED_ACTIVE_DIRECTORY_USERNAME` e ingrese el nombre del usuario de AD (sin el prefijo de dominio) para el valor. + Para la segunda clave, introduzca `SELF_MANAGED_ACTIVE_DIRECTORY_PASSWORD` e introduzca la contraseña de su usuario de AD en su dominio. + En **Clave de cifrado**, introduzca la misma clave de AWS KMS que utilizó para crear la instancia de RDS Custom para SQL Server. + En **Nombre secreto**, elija el nombre secreto que empiece por `do-not-delete-rds-custom-` para permitir que el perfil de la instancia acceda a este secreto. Si quiere elegir un nombre diferente para el secreto, actualice `RDSCustomInstanceProfile` para acceder al **Nombre secreto**. + (Opcional) En **Descripción**, escriba una descripción del nombre del secreto. + Cómo agregar las etiquetas `Key="AWSRDSCustom",Value="custom-sqlserver"` + Haga clic en **Guardar** y, a continuación, en **Siguiente**. + En **Configurar los ajustes de rotación**, mantenga los valores predeterminados y seleccione **Siguiente**. + Revise la configuración del secreto y haga clic en **Guardar**. + Elija el nuevo secreto y copie el valor del **ARN del secreto**. Esto lo utilizaremos en el siguiente paso para configurar su Active Directory. ------ #### [ CLI ] Ejecute el siguiente comando en su CLI para crear un secreto: ``` # 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" ``` ------ ## Paso 5: Crear o modificar una instancia de base de datos de RDS Custom para SQL Server Cree o modifique una instancia de base de datos de RDS Custom para SQL Server para usarla con su directorio. Puede utilizar la consola, CLI, o la API de RDS para asociar una instancia de base de datos con un directorio. Puede hacerlo de una de las siguientes formas: + Cree una nueva instancia de base de datos de SQL Server mediante la consola, el comando de la CLI [ create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) o la operación [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) de la API de RDS. Para obtener instrucciones, consulte [Creación de una instancia de base de datos de Amazon RDS](USER_CreateDBInstance.md). + Modifique una instancia de base de datos de SQL Server existente mediante la consola, el comando de la CLI [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) o la operación [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) de la API de RDS. Para obtener instrucciones, consulte [Modificación de una instancia de base de datos de Amazon RDS](Overview.DBInstance.Modifying.md). + Restaure una instancia de base de datos de SQL Server a partir de una instantánea de base de datos mediante la consola, el comando de la CLI [restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) o la operación [RestoreDBInstanceFromDBSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html) de la API de RDS. Para obtener instrucciones, consulte [Restauración a una instancia de base de datos](USER_RestoreFromSnapshot.md). + Restaure una instancia de base de datos de SQL Server a un punto en el tiempo mediante la consola, el comando de la CLI [restore-db-instance-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) o la operación [RestoreDBInstanceToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html) de la API de RDS. Para obtener instrucciones, consulte [Restauración de una instancia de base de datos a un momento especificado para Amazon RDS](USER_PIT.md). **nota** Si su instancia de RDS Custom para SQL Server ya está unida a un AD manualmente, compruebe la configuración de [Reglas de puertos de configuraciones de redes](custom-sqlserver-WinAuth.NWConfigPorts.md), [Validación de red](custom-sqlserver-WinAuth.NWValidation.md) y complete los pasos del 1 al 4. Actualice `--domain-fqdn`, `--domain-ou` y `--domain-auth-secret-arn` a su AD para que las credenciales y configuraciones de unión al dominio se registren en RDS Custom para supervisar, registrar el CNAME y tomar medidas de recuperación. Cuando utilice la AWS CLI, se necesitan los siguientes parámetros para que la instancia de base de datos pueda usar el directorio que ha creado: + Para el parámetro `--domain-fqdn`, utilice el nombre de dominio completo de su AD autoadministrado. + Para el parámetro `--domain-ou`, utilice la OU que creó en su AD autoadministrado. + Para el parámetro `--domain-auth-secret-arn`, utilice el valor del **ARN del secreto** que ha creado. **importante** Si modifica una instancia de base de datos para unirla a un dominio de AD autoadministrado o AWS Managed Microsoft AD, es necesario reiniciar la instancia de base de datos para que la modificación surta efecto. Puede optar por aplicar los cambios inmediatamente o esperar hasta el próximo período de mantenimiento. Si opta por **Aplicar inmediatamente**, se origina un tiempo de inactividad para las instancias de base de datos Single-AZ. El clúster de base de datos Multi-AZ realiza una conmutación por error antes de completar el reinicio. Para obtener más información, consulte [Modificación de una instancia de base de datos de Amazon RDS](Overview.DBInstance.Modifying.md). El siguiente comando de CLI crea una nueva instancia de base de datos de RDS Custom para SQL Server y la une a un dominio de AWS Managed Microsoft AD o autoadministrado. Para Linux, macOS o 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** Si su NetBIOS para AWS Managed Microsoft AD es **corpexample**, entonces aparece como una OU en sí misma. Cualquier unidad organizativa nueva creada anteriormente aparecerá como una unidad organizativa anidada. En AWS Managed Microsoft AD, establezca `--domain-ou` en `"OU=RDSCustomOU,OU=corpexample,DC=corp,DC=example,DC=com"`. El siguiente comando modifica una instancia de base de datos de RDS Custom para SQL Server existente para que utilice un dominio de Active Directory. Para Linux, macOS o 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" ^ ``` El siguiente comando de CLI elimina una instancia de base de datos de RDS Custom para SQL Server de un dominio de Active Directory. Para Linux, macOS o 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 ``` Cuando utilice la consola para crear o modificar su instancia, haga clic en **Habilitar la autenticación de Microsoft SQL Server Windows** para ver las siguientes opciones. ![\[Directorio de autenticación de Windows de Microsoft SQL Server\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/custom-sqs-WinAuth.png) Usted es responsable de asegurarse de que el FQDN de su dominio se resuelva en las direcciones IP del controlador de dominio. Si las direcciones IP de los controladores de dominio no se resuelven, las operaciones de unión al dominio fallan, pero la creación de la instancia de RDS Custom for SQL Server se realiza correctamente. Para obtener información sobre la resolución de problemas, consulte [Solución de problemas de Active Directory](custom-sqlserver-WinAuth.Troubleshoot.md). ## Paso 6: Crear inicios de sesión de SQL Server de autenticación de Windows Use las credenciales del usuario maestro de Amazon RDS para conectarse a la instancia de base de datos de SQL Server como lo haría con cualquier otra instancia de base de datos. Como la instancia de base de datos está unida al dominio de AD, puede aprovisionar inicios de sesión y usuarios de SQL Server. Para ello, utilice la utilidad de usuarios y grupos de AD de su dominio de AD. Los permisos de bases de datos se administran a través de los permisos de SQL Server estándar otorgados y revocados para estos inicios de sesión de Windows. Para que un usuario de AD se autentique con SQL Server, debe existir un inicio de sesión de Windows de SQL Server para el usuario de AD o para un grupo de Active Directory del que el usuario sea miembro. El control detallado del acceso se gestiona mediante la concesión y la revocación de permisos en estos inicios de sesión de SQL Server. Un usuario de AD que no tenga un inicio de sesión de SQL Server o no pertenezca a un grupo de AD con dicho inicio de sesión no puede tener acceso a la instancia de base de datos de SQL Server. El permiso `ALTER ANY LOGIN` es necesario para crear un inicio de sesión de SQL Server de AD. Si todavía no ha creado ningún inicio de sesión con este permiso, conéctese como usuario maestro de la instancia de base de datos usando la autenticación de SQL Server y cree sus inicios de sesión de SQL Server de AD bajo el contexto del usuario maestro. Puede ejecutar un comando de lenguaje de definición de datos (DDL), como el siguiente, para crear un inicio de sesión de SQL Server para un usuario o grupo de AD. ``` USE [master] GO CREATE LOGIN [mydomain\myuser] FROM WINDOWS WITH DEFAULT_DATABASE = [master], DEFAULT_LANGUAGE = [us_english]; GO ``` Los usuarios (tanto humanos como aplicaciones) del dominio pueden conectarse ahora a la instancia de RDS Custom para SQL Server desde un equipo cliente unido al dominio utilizando la autenticación de Windows. ## Paso 7: Uso de la autenticación Kerberos o NTLM ### Autenticación NTLM mediante un punto de conexión de RDS Cada instancia de base de datos de Amazon RDS contiene un punto de conexión y cada punto de conexión contiene el nombre DNS y el número de puerto para la instancia de base de datos. Para conectarse a su instancia de base de datos mediante una aplicación cliente SQL, necesita el nombre DNS y el número de puerto para la instancia de base de datos. Para autenticarse mediante la autenticación NTLM, debe conectarse al punto de conexión de RDS. Durante una interrupción del servicio no planificada o un mantenimiento planificado de la base de datos, Amazon RDS conmuta automáticamente a la base de datos secundaria actualizada para que las operaciones puedan reanudarse rápidamente sin intervención manual. Las instancias principal y secundaria usan el mismo punto de conexión, cuya dirección de red física cambia a la secundaria como parte del proceso de conmutación por error. No tiene que volver a configurar su aplicación cuando se produzca una conmutación por error. ### Autenticación de Kerberos La autenticación basada en Kerberos para RDS Custom para SQL Server requiere que las conexiones se realicen a un nombre principal de servicio (SPN) específico. Sin embargo, tras un evento de conmutación por error, es posible que la aplicación no conozca el nuevo SPN. Para solucionar este problema, RDS Custom para SQL Server ofrece un punto de conexión basado en Kerberos. El punto de conexión basado en Kerberos sigue un formato específico. Si su punto de conexión de RDS es `rds-instance-name.account-region-hash.aws-region.rds.amazonaws.com`, el punto de conexión correspondiente basado en Kerberos sería `rds-instance-name.account-region-hash.aws-region.awsrds.fully qualified domain name (FQDN)`. Por ejemplo, si el punto de conexión de RDS es `ad-test.cocv6zwtircu.us-east-1.rds.amazonaws.com` y el nombre de dominio es `corp-ad.company.com`, el punto de conexión basado en Kerberos sería `ad-test.cocv6zwtircu.us-east-1.awsrds.corp-ad.company.com`. Este punto de conexión basado en Kerberos se puede usar para autenticarse con la instancia de SQL Server mediante Kerberos, incluso después de un evento de conmutación por error, ya que el punto de conexión se actualiza automáticamente para que apunte al nuevo SPN de la instancia principal de SQL Server. ### Cómo encontrar su CNAME Para encontrar su CNAME, conéctese al controlador de dominio y abra **Administrador de DNS**. Navegue hasta **Zonas de búsqueda avanzada** y su FQDN. Navegue por **awsrds**, **aws-region** y **hash específicos de la cuenta y la región.** Si conecta la instancia de EC2 de RDS Custom e intenta conectarse a la base de datos de forma local mediante CNAME, la conexión utilizará la autenticación NTLM en lugar de Kerberos. Si después de conectar CNAME desde un cliente remoto, se devuelve una conexión NTLM, compruebe si los puertos necesarios están en la lista de permitidos. Para comprobar si su conexión usa Kerberos, ejecute la siguiente consulta: ``` SELECT net_transport, auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SSPID; ``` # Administración de una instancia de base de datos en un dominio Puede usar la consola, la AWS CLI o la API de Amazon RDS para administrar la instancia de base de datos y la relación con su dominio. Por ejemplo, puede mover la instancia de base de datos dentro, fuera o entre dominios. Por ejemplo, con la API de Amazon RDS puede hacer lo siguiente: + Para volver a intentar una unión de dominio para una suscripción que haya generado un error, use la operación [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) de la API y especifique el ID del directorio de suscripción actual. + Para actualizar el nombre del rol de IAM para la suscripción, use la operación `ModifyDBInstance` de la API y especifique el ID del directorio de la suscripción actual y el nuevo rol de IAM. + Para eliminar una instancia de base de datos de un dominio, use la operación `ModifyDBInstance` de la API y especifique `none` como parámetro del dominio. + Para mover una instancia de base de datos de un dominio a otro, use la operación `ModifyDBInstance` de la API y especifique el identificador del nuevo dominio como parámetro del dominio. + Para ver la suscripción de cada instancia de base de datos, use la operación [DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/DescribeDBInstances.html) de la API. ## Restauración de una instancia de base de datos de RDS Custom para SQL Server y adición de esta a un dominio de Active Directory Puede restaurar una instantánea de base de datos o realizar una recuperación en un momento dado (PITR) para una instancia de base de datos de SQL Server y, a continuación, agregarla a un dominio de Active Directory. Una vez que la instancia de base de datos se haya restaurado, modifíquela usando el proceso que se explica en la sección [Paso 5: Crear o modificar una instancia de base de datos de RDS Custom para SQL Server](custom-sqlserver-WinAuth.settingUp.md#custom-sqlserver-WinAuth.settingUp.CreateDBInstance) para agregar la instancia de base de datos a un dominio de AD. # Descripción de la pertenencia a los dominios Una vez que haya creado o modificado una instancia de base de datos, esta se convierte en miembro del dominio. La consola AWS indica el estado de la pertenencia del dominio para la instancia de base de datos. El estado de la instancia de base de datos puede ser uno de los siguientes: + **joined**: la instancia es miembro del dominio. + **joining**: la instancia está en el proceso de convertirse en miembro del dominio. + **pending-join**: la suscripción de la instancia está pendiente. + **pending-maintenance-join**: AWS intentará convertir la instancia en miembro del dominio durante el próximo periodo de mantenimiento programado. + **pending-removal**: la eliminación de la instancia del dominio está pendiente. + **pending-maintenance-removal**: AWS intentará eliminar la instancia del dominio durante el próximo periodo de mantenimiento programado. + **error**: un problema de configuración ha impedido que la instancia se una al dominio. Compruebe y corrija la configuración antes de volver a ejecutar el comando para modificar la instancia. + **removing**: la instancia se está eliminando del dominio. Una solicitud para convertirse en miembro de un dominio puede generar un error a causa de un problema de conectividad de la red o de un rol de IAM incorrecto. Por ejemplo, puede crear una instancia de base de datos o modificar una instancia existente y que se produzca un error al intentar que la instancia de base de datos se convierta en miembro de un dominio. En este caso, vuelva a emitir el comando para crear o modificar la instancia de base de datos o modificar la instancia recién creada para unirse al dominio. # Solución de problemas de Active Directory Los siguientes son los problemas que pueden surgir al configurar o modificar un AD. | Código de error | Descripción | Causas habituales | Sugerencias para la solución de problemas | | --- | --- | --- | --- | | Error 2 / 0x2 | El sistema no puede encontrar el archivo especificado. | El formato o la ubicación de la unidad organizativa (OU) especificados con el parámetro `—domain-ou` no es válido. La cuenta de servicio de dominio especificada mediante AWS Secrets Manager carece de los permisos necesarios para unirse a la OU. | Revise el parámetro `—domain-ou`. Asegúrese de que la cuenta de servicio de dominio tenga los permisos correctos para la OU. | | Error 5 / 0x5 | Se deniega el acceso. | Los permisos de la cuenta de servicio del dominio están mal configurados o la cuenta del equipo ya existe en el dominio. | Revise los permisos de la cuenta de servicio del dominio y compruebe que la cuenta del equipo de RDS no esté duplicada en el dominio. Para comprobar el nombre de la cuenta del equipo de RDS, ejecute `SELECT @@SERVERNAME` en su instancia de base de datos de RDS Custom para SQL Server. Si utiliza Multi-AZ, intente reiniciar con conmutación por error y, a continuación, compruebe de nuevo la cuenta del equipo de RDS. Para obtener más información, consulte [Reinicio de una instancia de base de datos ](USER_RebootInstance.md). | | Error 87 / 0x57 | El parámetro es incorrecto. | La cuenta de servicio de dominio especificada mediante AWS Secrets Manager no tiene los permisos correctos. El perfil de usuario también podría estar dañado. | Revise los requisitos de la cuenta de servicio de dominio. | | Error 234 / 0xEA | La unidad organizativa (OU) especificada no existe. | La OU especificada con el parámetro `—domain-ou` no existe en su AD. | Revise el parámetro `—domain-ou` y asegúrese de que la OU especificada exista en su AD. | | Error 1326 / 0x52E | El nombre de usuario o la contraseña es incorrecto. | Las credenciales de la cuenta de servicio de dominio proporcionadas en AWS Secrets Manager contienen un nombre de usuario desconocido o una contraseña incorrecta. La cuenta de dominio también podría estar deshabilitada en su AD. | Asegúrese de que las credenciales proporcionadas en AWS Secrets Manager sean correctas y de que la cuenta de dominio esté habilitada en su Active Directory. | | Error 1355 / 0x54B | El dominio especificado no existe o no se pudo contactar con él. | El dominio está inactivo, no se puede acceder al conjunto especificado de IP de DNS o no se puede acceder al FQDN especificado. | Revise los parámetros `—domain-dns-ips` y `—domain-fqdn`  para asegurarse de que son correctos. Revise la configuración de red de su instancia de base de datos de RDS Custom para SQL Server y asegúrese de que sea posible acceder a su AD. | | Error 1772/0x6BA | El servidor RPC no está disponible. | Se ha producido un problema al acceder al servicio de RPC de su dominio de AD. Puede deberse a un problema de red o de servicio. | Valide que el servicio de RPC se esté ejecutando en sus controladores de dominio y que se pueda acceder a los puertos de TCP `135` y `49152-65535` en su dominio desde su instancia de base de datos de RDS Custom para SQL Server. | | Error 2224 / 0x8B0 | La cuenta de usuario ya existe. | La cuenta de equipo que se intenta agregar al AD ya existe. | Para identificar la cuenta del equipo, ejecute `SELECT @@SERVERNAME` en su instancia de base de datos de RDS Custom para SQL Server y, a continuación, elimínela cuidadosamente de su AD. | | Error 2242 / 0x8c2 | La contraseña de este usuario ha caducado. | La contraseña de la cuenta de servicio de dominio especificada a través de AWS Secrets Manager ha caducado. | Actualice la contraseña de la cuenta de servicio de dominio utilizada para unir su instancia de base de datos de RDS Custom para SQL Server a su AD. |