Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Utilisation de Microsoft Active Directory avec RDS Custom for SQL Server RDS Custom for SQL Server permet de joindre vos instances à un annuaire Active Directory (AD) autogéré ou AWS Managed Microsoft AD. Cela s’applique quel que soit l’endroit où votre annuaire AD est hébergé, par exemple un centre de données sur site, Amazon EC2 ou tout autre fournisseur de services cloud. Pour l’authentification des utilisateurs et des services, vous pouvez utiliser l’authentification NTLM ou Kerberos sur votre instance de base de données RDS Custom for SQL Server sans utiliser de domaines intermédiaires ni d’approbations de forêts. Lorsqu’un utilisateur essaie de s’authentifier auprès de votre instance de base de données RDS Custom for SQL Server auprès d’un annuaire Active Directory autogéré, les demandes d’authentification sont transférées vers un annuaire AD autogéré ou AWS Managed Microsoft AD que vous spécifiez. Dans les sections suivantes, vous trouverez des informations sur l’utilisation d’un annuaire Active Directory autogéré et d’AWS Managed Active Directory pour RDS Custom for SQL Server. **Topics** + [ ## Disponibilité des régions et des versions ](#custom-sqlserver-WinAuth.Regions) + [ # Configuration d’un annuaire AD autogéré ou sur site ](custom-sqlserver-WinAuth.config-Self-Managed.md) + [ # Configurez Microsoft Active Directory à l'aide de Directory Service ](custom-sqlserver-WinAuth.config-ADS.md) + [ # Règles relatives aux ports de configuration réseau ](custom-sqlserver-WinAuth.NWConfigPorts.md) + [ # Validation du réseau ](custom-sqlserver-WinAuth.NWValidation.md) + [ # Configuration de l’authentification Windows pour les instances RDS Custom for SQL Server ](custom-sqlserver-WinAuth.settingUp.md) + [ # Gestion d'une instance de base de données dans un domaine ](custom-sqlserver-WinAuth.ManagingDBI.md) + [ # Présentation de l'appartenance au domaine ](custom-sqlserver-WinAuth.Understanding.md) + [ # Dépannage d’Active Directory ](custom-sqlserver-WinAuth.Troubleshoot.md) ## Disponibilité des régions et des versions RDS Custom for SQL Server prend en charge à la fois l’annuaire AD autogéré et AWS Managed Microsoft AD à l’aide de NTLM ou Kerberos dans toutes les régions où RDS Custom for SQL Server est pris en charge. Pour plus d’informations, consultez [Régions et moteurs de base de données pris en charge pour RDS Custom](Concepts.RDS_Fea_Regions_DB-eng.Feature.RDSCustom.md). # Configuration d’un annuaire AD autogéré ou sur site Pour associer votre annuaire AD Microsoft sur site ou autogéré à votre instance de base de données RDS Custom for SQL Server, votre domaine actif doit être configuré comme suit : + Définissez les sous-réseaux du VPC associé à votre instance de base de données RDS Custom for SQL Server dans votre annuaire AD autogéré ou sur site. Vérifiez qu’il n’existe aucun conflit entre les sous-réseaux de votre VPC et les sous-réseaux de vos autres sites AD. + Votre contrôleur de domaine AD a un niveau fonctionnel de domaine correspondant à Windows Server 2008 R2 ou supérieur. + Votre nom de domaine AD ne peut pas être au format SLD (Single Label Domain). RDS Custom for SQL Server ne prend pas en charge les domaines SLD. + Le nom de domaine complet (FQDN) de votre annuaire AD ne peut pas dépasser 47 caractères. ## Configuration de votre connectivité réseau Configurez la connectivité réseau de votre annuaire AD autogéré ou sur site de la manière suivante : + Configurez la connectivité entre Amazon VPC dans lequel votre instance RDS Custom for SQL Server est exécutée et votre annuaire AD. Utilisez Direct Connect, Site-to-Site VPN AWS Transit Gateway, et le peering VPC. + Autorisez le trafic sur les ports de votre réseau et groupes de sécurité RDS Custom for SQL Server ACLs vers votre AD autogéré ou sur site. Pour de plus amples informations, veuillez consulter [Règles relatives aux ports de configuration réseau](custom-sqlserver-WinAuth.NWConfigPorts.md). ![\[Annuaire d’authentification Windows à Microsoft SQL Server\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/custom-sqs-SM-NC.png) ## Configuration de la résolution DNS Configurez les exigences suivantes pour configurer la résolution DNS avec des annuaires AD autogérés ou sur site : + Configurez la résolution DNS dans votre VPC afin de résoudre le nom de domaine complet (FQDN) de votre annuaire Active Directory que vous avez auto-hébergé. Un exemple de FQDN est `corp.example.local`. Pour configurer la résolution DNS, configurez le résolveur DNS VPC afin de transférer les requêtes pour certains domaines avec un point de terminaison sortant et une règle de résolveur Amazon Route 53. Pour plus d’informations, consultez [Configurer un point de terminaison sortant du résolveur Route 53 pour résoudre les enregistrements DNS](https://repost.aws/knowledge-center/route53-resolve-with-outbound-endpoint). + Pour les charges de travail qui exploitent à la fois les ressources locales VPCs et les ressources locales, vous devez résoudre les enregistrements DNS hébergés sur site. Les ressources sur site peuvent avoir besoin de résoudre les noms hébergés sur AWS. Pour créer une configuration de cloud hybride, utilisez les points de terminaison du résolveur et les règles de transfert conditionnel afin de résoudre les requêtes DNS entre vos ressources sur site et votre VPC personnalisé. Pour plus d'informations, consultez la section [Résolution des requêtes DNS entre VPCs et votre réseau](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-overview-DSN-queries-to-vpc.html) dans le manuel *Amazon Route 53 Developer Guide*. **Important** La modification des paramètres du résolveur DNS de l’interface réseau sur le RDS Custom for SQL Server empêche les points de terminaison d’un VPC compatibles DNS de fonctionner correctement. Les points de terminaison d’un VPC compatibles DNS sont requis pour les instances situées dans des sous-réseaux privés sans accès à Internet. # Configurez Microsoft Active Directory à l'aide de Directory Service AWS Managed Microsoft AD crée un Microsoft Active Directory entièrement géré AWS qui est alimenté par Windows Server 2019 et fonctionne aux niveaux fonctionnels de la forêt et du domaine R2 2012. Directory Service crée les contrôleurs de domaine dans différents sous-réseaux d'un Amazon VPC, ce qui rend votre répertoire hautement disponible même en cas de panne. Pour créer un répertoire avec AWS Managed Microsoft AD, voir [Getting started with AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started.html) dans le *Guide AWS Directory Service d'administration*. ## Configuration de votre connectivité réseau ### Activer le trafic entre VPC entre l’annuaire et l’instance de base de données Pour rechercher l’annuaire et l’instance de base de données dans le même VPC, ignorez cette étape et passez à [Règles relatives aux ports de configuration réseau](custom-sqlserver-WinAuth.NWConfigPorts.md). Pour localiser le répertoire et l'instance de base de données différemment VPCs, configurez le trafic inter-VPC à l'aide de l'appairage VPC ou. AWS Transit Gateway Pour plus d'informations sur l'utilisation de l'appairage VPC, voir Qu'est-ce que l'appairage [VPC](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) ? [dans le *guide de peering Amazon VPC* et qu'est-ce que c'est ? AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) dans les *passerelles Amazon VPC Transit*. **Activer le trafic entre VPC à l’aide de l’appairage de VPC** 1. Configurez les règles de routage de VPC appropriées afin de veiller à ce que le trafic réseau puisse être acheminé dans les deux sens. 1. Assurez-vous que le groupe de sécurité de l’instance de base de données puisse recevoir le trafic entrant depuis le groupe de sécurité de cet annuaire. Pour de plus amples informations, veuillez consulter [Règles relatives aux ports de configuration réseau](custom-sqlserver-WinAuth.NWConfigPorts.md). 1. La liste de contrôle d’accès (ACL) réseau ne doit pas bloquer le trafic. Si le répertoire Compte AWS appartient à une autre personne, vous devez le partager. *Pour partager le répertoire Compte AWS dans lequel se trouve l'instance RDS Custom for SQL Server, suivez le [didacticiel : Partage de votre domaine EC2 AWS Managed Microsoft AD pour une jointure fluide du Guide](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_directory_sharing.html) d'administration.AWS Directory Service * **Partage d'un répertoire entre Comptes AWS** 1. Connectez-vous à la Directory Service console à l'aide du compte de l'instance de base de données et vérifiez si le domaine possède le même `SHARED` statut avant de continuer. 1. Après vous être connecté à la Directory Service console à l'aide du compte de l'instance de base de données, notez la valeur de l'**ID du répertoire**. Vous utilisez cet ID pour joindre l’instance de base de données au domaine. ## Configuration de la résolution DNS Lorsque vous créez un répertoire avec AWS Managed Microsoft AD, vous Directory Service créez deux contrôleurs de domaine et ajoutez le service DNS en votre nom. Si vous en avez un existant AWS Managed Microsoft AD ou prévoyez d'en lancer un dans un VPC autre que votre instance de base de données RDS Custom for SQL Server, configurez le résolveur DNS VPC pour transférer les requêtes pour certains domaines avec une règle de résolution et de sortie Route 53, voir Configurer un point de terminaison sortant du résolveur [Route 53](https://repost.aws/knowledge-center/route53-resolve-with-outbound-endpoint) pour résoudre les enregistrements DNS. # Règles relatives aux ports de configuration réseau Assurez-vous de respecter les configurations réseau suivantes : + Connectivité configurée entre le VPC Amazon sur lequel vous souhaitez créer l’instance de base de données RDS Custom for SQL Server et votre annuaire Active Directory autogéré ou AWS Managed Microsoft AD. Pour l’annuaire Active Directory autogéré, configurez la connectivité à l’aide d’AWS Direct Connect, d’un VPN AWS, de l’appairage de VPC ou de la passerelle de transit AWS. Pour AWS Managed Microsoft AD, configurez la connectivité à l’aide de l’appairage de VPC. + Assurez-vous que le groupe de sécurité et les listes ACL réseau de VPC pour le ou les sous-réseaux dans lesquels vous créez votre instance de base de données RDS Custom for SQL Server autorisent le trafic sur les ports et dans les directions indiquées dans le schéma suivant. ![\[Règles des ports de configuration réseau de Microsoft Active Directory.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/custom_sqlserver_ActiveDirectory_Requirements_NetworkConfig.png) Le tableau suivant identifie le rôle de chaque port. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/custom-sqlserver-WinAuth.NWConfigPorts.html) + En général, les serveurs DNS du domaine se trouvent dans les contrôleurs de domaine AD. Vous n'avez pas besoin de configurer l'option DHCP du VPC pour utiliser cette fonctionnalité. Pour plus d’informations, consultez [Jeux d’options DHCP](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html) dans le *Guide de l’utilisateur Amazon VPC*. **Important** Si vous utilisez des listes ACL réseau de VPC, vous devez également autoriser le trafic sortant sur les ports dynamiques (49152-65535) à partir de votre instance de base de données RDS Custom for SQL Server. Assurez-vous que ces règles de trafic sont également mises en miroir sur les pare-feu qui s’appliquent à chacun des contrôleurs de domaine AD, aux serveurs DNS et aux instances de base de données RDS Custom for SQL Server. Alors que les groupes de sécurité VPC exigent que les ports soient ouverts uniquement dans le sens où le trafic réseau est initié, la plupart des pare-feu Windows et des listes ACL réseau de VPC exigent que les ports soient ouverts dans les deux sens. # Validation du réseau Avant de rejoindre votre instance RDS Custom pour AWS Managed Microsoft AD ou autogéré, vérifiez les points suivants à partir d’une instance EC2 située dans le même VPC que celui où vous prévoyez de lancer l’instance RDS Custom for SQL Server. + Vérifiez si vous êtes en mesure de convertir le nom de domaine complet (FQDN) en adresses IP de contrôleur de domaine. ``` nslookup corp.example.com ``` La commande doit renvoyer un résultat similaire : ``` 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) ``` + Résolvez les services AWS d’une instance EC2 dans le VPC où vous lancez votre instance 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" } ``` La valeur `TcpTestSucceeded` doit renvoyer `True` pour `s3`, `ec2`, `secretsmanager`, `logs`, `events`, `monitoring`, `ssm`, `ec2messages` et `ssmmessages`. # Configuration de l’authentification Windows pour les instances RDS Custom for SQL Server Nous vous recommandons de créer une unité organisationnelle dédiée et des informations d’identification de service adaptées à cette unité organisationnelle pour tout Compte AWS possédant une instance de base de données RDS Custom for SQL Server jointe à votre domaine AD. En dédiant une unité organisationnelle et des informations d’identification de service, vous évitez les conflits d’autorisations et suivez le principe de moindre privilège. Les stratégies de groupe au niveau d’Active Directory peuvent entrer en conflit avec les automatisations et les autorisations AWS. Nous vous recommandons de sélectionner des stratégies de groupe qui s’appliquent uniquement à l’unité organisationnelle que vous créez pour RDS Custom for SQL Server. + Pour créer une unité organisationnelle et un utilisateur de domaine AD dans votre annuaire AD autogéré ou sur site, vous pouvez connecter le contrôleur de domaine en tant qu’administrateur de domaine. + Pour créer des utilisateurs et des groupes dans un annuaire Directory Service, vous devez être connecté à une instance de gestion et être connecté en tant qu’utilisateur disposant des privilèges requis pour créer des utilisateurs et des groupes. Pour plus d’informations, consultez [Gestion des utilisateurs et des groupes dans AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups.html) dans le *Guide d’administration d’AWS Directory Service Directory Service*. + Pour gérer votre Active Directory à partir d’une instance Amazon EC2 Windows Server, vous devez installer les services de domaine Active Directory et les outils de service Active Directory Lightweight Directory sur l’instance EC2. Pour plus d’informations, consultez [Installation des outils d’administration Active Directory pour AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_install_ad_tools.html) dans le *Guide d’administration d’AWS Directory Service*. + Nous vous recommandons d’installer ces outils sur une instance EC2 distincte à des fins d’administration, et non sur votre instance de base de données RDS Custom for SQL Server pour en faciliter l’administration. Les conditions requises pour un compte de service de domaine AD sont les suivantes : + Vous devez disposer d’un compte de service dans votre domaine AD autogéré avec des autorisations déléguées pour joindre des ordinateurs au domaine. Un compte de service de domaine est un compte utilisateur de votre annuaire AD auquel l’autorisation d’effectuer certaines tâches a été déléguée. + Les autorisations suivantes doivent être déléguées au compte de service de domaine dans l’unité organisationnelle à laquelle vous joignez votre instance de base de données RDS Custom for SQL Server : + Capacité validée d’écrire sur le nom d’hôte DNS + Capacité validée d'écrire dans le nom du principal de service + Création et suppression d’objets informatiques + Pour l’annuaire AD autogéré et sur site, le compte de service de domaine doit être membre du groupe « Administrateurs délégués du système de noms de domaine d’AWS ». + Pour AWS Managed Microsoft AD, le compte de service de domaine doit être membre du groupe « DnsAdmins ». Il s’agit de l’ensemble minimal d’autorisations requises pour joindre des objets informatiques à votre annuaire AD autogéré et AWS Managed Microsoft AD. Pour plus d’informations, consultez [Erreur : l’accès est refusé lorsque des utilisateurs non administrateurs auxquels le contrôle a été délégué tentent de joindre des ordinateurs à un contrôleur de domaine](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/access-denied-when-joining-computers) dans la documentation de Microsoft Windows Server. **Important** Ne déplacez pas les objets informatiques créés par RDS Custom for SQL Server dans l’unité organisationnelle (UO) après la création de votre instance de base de données. Le déplacement des objets associés pourrait entraîner une mauvaise configuration de votre instance de base de données RDS Custom for SQL Server. Si vous devez déplacer les objets informatiques créés par Amazon RDS, utilisez l’action [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) pour modifier les paramètres du domaine en fonction de l’emplacement souhaité des objets informatiques. **Topics** + [ ## Étape 1 : création d’une unité organisationnelle (UO) dans votre annuaire AD ](#custom-sqlserver-WinAuth.settingUp.CreateOU) + [ ## Étape 2 : création d’un utilisateur de domaine AD ](#custom-sqlserver-WinAuth.settingUp.ADuser) + [ ## Étape 3 : délégation du contrôle à l’utilisateur de l’annuaire AD en mode autogéré ou AWS Managed Microsoft AD ](#custom-sqlserver-WinAuth.settingUp.Delegate) + [ ## Étape 4 : création d’un secret ](#custom-sqlserver-WinAuth.settingUp.ASM) + [ ## Étape 5 : création ou modification d’une instance de base de données SQL Server ](#custom-sqlserver-WinAuth.settingUp.CreateDBInstance) + [ ## Étape 6 : création de connexions SQL Server pour l’authentification Windows ](#custom-sqlserver-WinAuth.settingUp.CreateLogins) + [ ## Étape 7 : utilisation de l’authentification Kerberos ou NTLM ](#custom-sqlserver-WinAuth.settingUp.KerbNTLM) ## Étape 1 : création d’une unité organisationnelle (UO) dans votre annuaire AD Suivez les étapes ci-dessous pour créer une unité organisationnelle dans votre annuaire AD : **Création d’une unité organisationnelle dans votre annuaire AD** 1. Connectez-vous à votre domaine AD en tant qu’administrateur de domaine. 1. Ouvrez **Utilisateurs et ordinateurs Active Directory** et sélectionnez le domaine où vous souhaitez créer votre unité d’organisation. 1. Cliquez avec le bouton droit sur le domaine et choisissez **Nouveau**, puis **Unité organisationnelle**. 1. Saisissez un nom pour l’unité d’organisation. Activez **Protéger le conteneur contre la suppression accidentelle**. 1. Choisissez **OK**. Votre nouvelle unité organisationnelle apparaît sous votre domaine. Pour AWS Managed Microsoft AD, le nom de cette unité organisationnelle est basé sur le nom NetBIOS que vous avez saisi lors de la création de votre annuaire. Cette unité organisationnelle appartient à AWS et contient tous les objets d’annuaire AWS sur lesquels vous disposez d’un contrôle total. Deux unités organisationnelles enfants existent par défaut sous cette unité organisationnelle, à savoir **Ordinateurs et Utilisateurs**. Les nouvelles unités organisationnelles créées par RDS Custom sont issues de l’unité organisationnelle basée sur NetBIOS. ## Étape 2 : création d’un utilisateur de domaine AD Les informations d’identification de l’utilisateur de domaine seront utilisées pour le secret dans Secrets Manager. **Création d’un utilisateur de domaine AD dans votre annuaire AD** 1. Ouvrez **Utilisateurs et ordinateurs Active Directory** et sélectionnez le domaine et l’unité organisationnelle où vous souhaitez créer l’utilisateur. 1. Cliquez avec le bouton droit sur l’objet **Utilisateurs** et choisissez **Nouveau**, puis **Utilisateur**. 1. Saisissez le prénom, le nom de famille et le nom de connexion de l’utilisateur. Cliquez sur **Suivant**. 1. Saisissez un mot de passe pour l’utilisateur. Ne sélectionnez pas **L’utilisateur doit modifier le mot de passe lors de sa prochaine connexion** ou **Le compte est désactivé**. Cliquez sur **Suivant**. 1. Cliquez sur **OK**. Votre nouvel utilisateur apparaîtra sous votre domaine. ## Étape 3 : délégation du contrôle à l’utilisateur de l’annuaire AD en mode autogéré ou AWS Managed Microsoft AD **Délégation du contrôle à l’utilisateur du domaine AD dans votre domaine** 1. Ouvrez le composant logiciel enfichable MMC **Utilisateurs et ordinateurs Active Directory** et sélectionnez votre domaine. 1. Cliquez avec le bouton droit sur l’unité organisationnelle que vous avez créée précédemment et choisissez **Déléguer le contrôle**. 1. Sur la page **Assistant Délégation de contrôle**, cliquez sur **Suivant**. 1. Dans la section **Utilisateurs ou groupes**, cliquez sur **Ajouter**. 1. Dans la section **Sélectionner les utilisateurs, les ordinateurs ou les groupes**, entrez l’utilisateur AD que vous avez créé et cliquez sur **Vérifier les noms**. Si votre vérification de l’utilisateur de l’annuaire AD aboutit, cliquez sur **OK**. 1. Dans la section **Utilisateurs ou groupes**, confirmez que votre utilisateur d’annuaire AD a été ajouté et cliquez sur **Suivant**. 1. Dans la section **Tâches à déléguer**, choisissez **Créer une tâche personnalisée à déléguer** et cliquez sur **Suivant**. 1. Dans la section **Type d’objet Active Directory** : Choisissez **Seulement les objets suivants dans le dossier**. Sélectionnez **Objets informatiques** Sélectionnez **Créer les objets sélectionnés dans ce dossier** Sélectionnez **Supprimer les objets sélectionnés dans ce dossier** et cliquez sur **Suivant**. 1. Dans la section **Autorisations** : Gardez l’option **Général** sélectionnée. Sélectionnez **Écriture validée sur le nom d'hôte DNS**. Sélectionnez **Écriture validée sur le nom du principal de service** et cliquez sur **Suivant**. 1. Pour **Fin de l’Assistant Délégation de contrôle**, confirmez vos paramètres, puis cliquez sur **Terminer**. ## Étape 4 : création d’un secret Créez le secret dans le même Compte AWS et la même région qui contient l’instance de base de données RDS Custom for SQL Server que vous souhaitez inclure à votre annuaire AD. Stockez les informations d’identification de l’utilisateur du domaine AD créé dans [Étape 2 : création d’un utilisateur de domaine AD](#custom-sqlserver-WinAuth.settingUp.ADuser). ------ #### [ Console ] + Dans AWS Secrets Manager, choisissez **Stocker un nouveau secret**. + Pour **Secret type** (Type de secret), choisissez **Other type of secret** (Autre type de secret). + Pour **Paires clé/valeur**, ajoutez deux clés : + Pour la première valeur, `SELF_MANAGED_ACTIVE_DIRECTORY_USERNAME` et saisissez uniquement votre utilisateur d’annuaire AD (sans le préfixe de domaine) pour la valeur. + Pour la deuxième clé, saisissez `SELF_MANAGED_ACTIVE_DIRECTORY_PASSWORD` et saisissez le mot de passe de votre utilisateur d’annuaire AD sur votre domaine. + Pour **Clé de chiffrement**, saisissez la même clé AWS KMS que celle que vous avez utilisée pour créer l’instance RDS Custom for SQL Server. + Pour **Nom du secret**, choisissez le nom du secret commençant par `do-not-delete-rds-custom-` pour permettre à votre profil d’instance d’accéder à ce secret. SI vous souhaitez choisir un autre nom pour le secret, mettez à jour `RDSCustomInstanceProfile` pour accéder à **Nom du secret**. + (Facultatif) Pour **Description**, saisissez une description du nom du secret. + Ajoutez les balises `Key="AWSRDSCustom",Value="custom-sqlserver"` + Cliquez sur **Enregistrer**, puis sur **Suivant**. + Pour **Configurer les paramètres de rotation**, conservez les valeurs par défaut et choisissez **Suivant**. + Passez en revue les paramètres du secret et cliquez sur **Stocker**. + Choisissez le nouveau secret et copiez la valeur pour **ARN du secret**. Nous l’utiliserons à l’étape suivante pour configurer Active Directory. ------ #### [ CLI ] Exécutez la commande suivante dans votre interface de ligne de commande (CLI) pour créer un secret : ``` # 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" ``` ------ ## Étape 5 : création ou modification d’une instance de base de données SQL Server Créez ou modifiez une instance de base de données RDS Custom for SQL Server en vue de son utilisation avec votre annuaire. Vous pouvez utiliser la console, la CLI ou l’API RDS pour associer une instance de base de données à un annuaire. Vous pouvez effectuer cette opération de différentes manières : + Créez une instance de base de données SQL Server à l'aide de la console, de la commande de CLI [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) ou de l'opération d'API RDS [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html). Pour obtenir des instructions, consultez [Création d'une instance de base de données Amazon RDS](USER_CreateDBInstance.md). + Modifiez une instance de base de données SQL Server existante à l'aide de la console, de la commande de CLI [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) ou de l'opération d'API RDS [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html). Pour obtenir des instructions, consultez [Modification d'une instance de base de données Amazon RDS](Overview.DBInstance.Modifying.md). + Restaurez une instance de base de données SQL Server à partir d'un instantané de bases de données à l'aide de la console, de la commande de CLI [restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) ou de l'opération d'API RDS [RestoreDBInstanceFromDBSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html). Pour obtenir des instructions, consultez [Restauration d’une instance de base de données](USER_RestoreFromSnapshot.md). + Restaurez une instance de base de données SQL Server à un instant dans le passé en utilisant la console, la commande de 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) ou l'opération d'API RDS [RestoreDBInstanceToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html). Pour obtenir des instructions, consultez [Restauration d’une instance de base de données à un instant précis pour Amazon RDS](USER_PIT.md). **Note** Si votre instance RDS Custom pour SQL Server est déjà jointe manuellement à un AD, vérifiez les paramètres de [Règles relatives aux ports de configuration réseau](custom-sqlserver-WinAuth.NWConfigPorts.md)[Validation du réseau](custom-sqlserver-WinAuth.NWValidation.md), et effectuez les étapes 1 à 4. Mettez à jour `--domain-fqdn`, `--domain-ou` et `--domain-auth-secret-arn` sur votre annuaire AD, afin que les informations d’identification et les configurations de jonction de domaine soient enregistrées auprès de RDS Custom pour surveiller, enregistrer le CNAME et prendre des mesures de récupération. Lorsque vous utilisez AWS CLI, les paramètres suivants sont obligatoires pour que l’instance de base de données puisse utiliser l’annuaire que vous avez créé : + Pour le paramètre `--domain-fqdn`, utilisez le nom de domaine entièrement qualifié de votre annuaire AD autogéré. + Pour le paramètre `--domain-ou`, utilisez l’unité d’organisation que vous avez créée dans votre annuaire AD autogéré. + Pour le paramètre `--domain-auth-secret-arn`, utilisez la valeur de l’**ARN du secret** que vous avez créé dans une étape précédente. **Important** Si vous modifiez une instance de base de données pour la joindre à un domaine AD autogéré ou AWS Managed Microsoft AD ou pour l’en supprimer, un redémarrage de l’instance de base de données est requis pour que la modification prenne effet. Vous pouvez choisir d’appliquer les modifications immédiatement ou d’attendre la prochaine fenêtre de maintenance. Le choix de l’option **Appliquer immédiatement** entraînera une durée d’indisponibilité pour l’instance de base de données mono-AZ. Un cluster de bases de données multi-AZ effectuera un basculement avant de terminer le redémarrage. Pour plus d’informations, consultez [Modification d'une instance de base de données Amazon RDS](Overview.DBInstance.Modifying.md). La commande de l’interface de ligne de commande (CLI) suivante crée une nouvelle instance de base de données RDS Custom for SQL Server et la joint à un domaine autogéré ou AWS Managed Microsoft AD. Pour 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 ``` Pour 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 ``` **Important** Si votre NetBIOS pour AWS Managed Microsoft AD est **corpexample**, il apparaît lui-même sous la forme d’une unité organisationnelle. Toute nouvelle unité organisationnelle créée précédemment apparaîtra sous la forme d’une unité organisationnelle imbriquée. Pour AWS Managed Microsoft AD, réglez `--domain-ou` sur `"OU=RDSCustomOU,OU=corpexample,DC=corp,DC=example,DC=com"`. La commande de l’interface de ligne de commande (CLI) suivante modifie une instance de base de données RDS Custom for SQL Server existante afin d’utiliser un domaine Active Directory. Pour 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" \ ``` Pour 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" ^ ``` La commande de l’interface de ligne de commande (CLI) suivante supprime une instance de base de données RDS Custom for SQL Server d’un domaine Active Directory. Pour Linux, macOS ou Unix : ``` aws rds modify-db-instance \ --db-instance-identifier my-custom-instance \ --disable-domain ``` Pour Windows : ``` aws rds modify-db-instance ^ --db-instance-identifier my-custom-instance ^ --disable-domain ``` Lorsque vous utilisez la console pour créer ou modifier votre instance, cliquez sur **Activer l’authentification Microsoft SQL Server Windows** pour voir les options suivantes. ![\[Annuaire d’authentification Windows à Microsoft SQL Server\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/custom-sqs-WinAuth.png) Il est de votre responsabilité de vous assurer que le nom de domaine complet de votre domaine correspond aux adresses IP de contrôleur de domaine. Si les adresses IP de contrôleur de domaine ne sont pas résolues, les opérations de jointure de domaine échouent, mais la création de l’instance RDS Custom for SQL Server réussit. Pour plus d’informations sur le dépannage, consultez [Dépannage d’Active Directory](custom-sqlserver-WinAuth.Troubleshoot.md). ## Étape 6 : création de connexions SQL Server pour l’authentification Windows Utilisez les informations d’identification de l’utilisateur principal Amazon RDS pour vous connecter à l’instance de base de données SQL Server de la même manière qu’à n’importe quelle instance de base de données. Étant donné que l’instance de base de données est jointe au domaine AD, vous pouvez allouer les connexions et utilisateurs SQL. Pour ce faire, utilisez l’utilitaire Utilisateurs et groupes de l’annuaire AD de votre domaine AD. Les autorisations pour la base de données sont gérées via des autorisations SQL Server standard accordées et révoquées en fonction des connexions Windows. Pour qu’un utilisateur d’annuaire AD puisse s’authentifier à SQL Server, une connexion Windows SQL Server doit exister pour l’utilisateur ES ou un groupe Active Directory dont l’utilisateur est membre. Un contrôle précis des accès est géré par l’attribution ou la révocation d’autorisations pour ces connexions SQL Server. Un utilisateur d’annuaire AD qui n’a pas de connexion SQL Server ou qui n’appartient pas à un groupe AD avec une telle connexion ne peut pas accéder à l’instance de base de données SQL Server. L’autorisation `ALTER ANY LOGIN` est requise pour créer une connexion SQL Server à l’annuaire AD. Si vous n’avez pas créé de connexions avec cette autorisation, connectez vous en tant qu’utilisateur principal de l’instance de base de données à l’aide de l’authentification SQL Server et créez vos connexions SQL Server à l’annuaire AD dans le contexte de l’utilisateur principal. Vous pouvez exécuter une commande DDL (Data Definition Language) telle que la suivante afin de créer une connexion SQL Server pour un utilisateur ou un groupe d’annuaire AD. ``` USE [master] GO CREATE LOGIN [mydomain\myuser] FROM WINDOWS WITH DEFAULT_DATABASE = [master], DEFAULT_LANGUAGE = [us_english]; GO ``` Les utilisateurs (personnes et applications) de votre domaine peuvent désormais se connecter à l’instance RDS Custom for SQL Server à partir d’un ordinateur client joint au domaine à l’aide de l’authentification Windows. ## Étape 7 : utilisation de l’authentification Kerberos ou NTLM ### Authentification NTLM à l’aide du point de terminaison RDS Chaque instance de base de données Amazon RDS possède un point de terminaison. Chaque point de terminaison possède un nom DNS et un numéro de port de l’instance de base de données. Pour connecter votre instance de base de données à l’aide d’une application cliente SQL, vous avez besoin du nom DNS et du numéro de port de votre instance de base de données. Pour vous authentifier à l’aide de l’authentification NTLM, vous devez vous connecter au point de terminaison RDS. Lors d’une maintenance de base de données programmée ou d’une interruption non programmée du service, Amazon RDS bascule automatiquement vers la base de données secondaire à jour afin que les opérations puissent reprendre rapidement, sans intervention manuelle. Les instances principales et secondaires utilisent le même point de terminaison, dont l’adresse réseau physique est transférée vers l’instance secondaire dans le cadre du processus de basculement. Vous n’avez pas à reconfigurer votre application lorsqu’un basculement se produit. ### Authentification Kerberos L’authentification basée sur Kerberos pour RDS Custom for SQL Server nécessite l’établissement de connexions à un nom principal de service (SPN) spécifique. Cependant, après un événement de basculement, il est possible que l’application ne connaisse pas le nouveau SPN. Pour résoudre ce problème, RDS Custom pour SQL Server propose un point de terminaison basé sur Kerberos. Le point de terminaison basé sur Kerberos suit un format spécifique. Si votre point de terminaison RDS est `rds-instance-name.account-region-hash.aws-region.rds.amazonaws.com`, le point de terminaison basé sur Kerberos correspondant est `rds-instance-name.account-region-hash.aws-region.awsrds.fully qualified domain name (FQDN)`. Par exemple, si le point de terminaison RDS est `ad-test.cocv6zwtircu.us-east-1.rds.amazonaws.com` et que le nom de domaine est `corp-ad.company.com`, le point de terminaison basé sur Kerberos est `ad-test.cocv6zwtircu.us-east-1.awsrds.corp-ad.company.com`. Ce point de terminaison basé sur Kerberos peut être utilisé pour s’authentifier auprès de l’instance SQL Server à l’aide de Kerberos, même après un événement de basculement, car le point de terminaison est automatiquement mis à jour pour pointer vers le nouveau SPN de l’instance SQL Server principale. ### Trouver votre CNAME Pour trouver votre CNAME, connectez-vous à votre contrôleur de domaine et ouvrez le **Gestionnaire DNS**. Accédez à **Forward Lookup Zones** et à votre FQDN. Parcourez **awsrds**, **aws-region** et le **hachage spécifique au compte et à la région**. Si vous connectez l’instance RDS Custom EC2 et que vous essayez de vous connecter à la base de données localement à l’aide de CNAME, votre connexion utilisera l’authentification NTLM au lieu de Kerberos. Si, après avoir connecté le CNAME à partir d’un client distant, une connexion NTLM est renvoyée, vérifiez si les ports requis sont autorisés. Pour vérifier que votre connexion utilise Kerberos, exécutez la requête suivante : ``` SELECT net_transport, auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SSPID; ``` # Gestion d'une instance de base de données dans un domaine Vous pouvez utiliser la console, l'AWS CLI ou l'API Amazon RDS pour gérer votre instance de base de données et sa relation avec votre domaine. Par exemple, vous pouvez déplacer l'instance de base de données dans, hors ou entre des domaines. Par exemple, l'API Amazon RDS vous permet d'effectuer les actions suivantes : + Pour tenter à nouveau une jonction de domaines pour une appartenance ayant échoué, utilisez l'opération d'API [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) et spécifiez l'ID d'annuaire de l'appartenance actuelle. + Pour mettre à jour le nom du rôle IAM de l'appartenance, utilisez l'opération d'API `ModifyDBInstance` et spécifiez l'ID d'annuaire de l'appartenance actuelle et le nouveau rôle IAM. + Pour supprimer une instance de base de données d'un domaine, utilisez l'opération d'API `ModifyDBInstance` et spécifiez `none` pour le paramètre de domaine. + Pour déplacer une instance de base de données d'un domaine à un autre, utilisez l'opération d'API `ModifyDBInstance` et spécifiez l'identifiant du nouveau domaine en tant que paramètre de domaine. + Pour répertorier l'appartenance pour chaque instance de base de données, utilisez l'opération d'API [DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/DescribeDBInstances.html). ## Restauration d’une instance de base de données RDS Custom for SQL Server et ajout de cette instance à un domaine Active Directory Vous pouvez restaurer un instantané de base de données ou effectuer une reprise ponctuelle (PITR) pour une instance de base de données SQL Server, puis l’ajouter à un domaine Active Directory. Une fois que l’instance de base de données est restaurée, modifiez l’instance à l’aide du processus expliqué dans [Étape 5 : création ou modification d’une instance de base de données SQL Server](custom-sqlserver-WinAuth.settingUp.md#custom-sqlserver-WinAuth.settingUp.CreateDBInstance) afin d’ajouter l’instance de base de données à un domaine AD. # Présentation de l'appartenance au domaine Après la création ou la modification de votre instance de base de données, l'instance devient un membre du domaine. La console AWS indique le statut de l'appartenance au domaine pour l'instance de base de données. Le statut de l'instance de base de données peut avoir les valeurs suivantes : + **joined**–L'instance est membre du domaine. + **joining**–L'instance est en train de devenir membre du domaine. + **pending-join** – L'appartenance de l'instance est en attente. + **pending-maintenance-join** – AWS va tenter de faire de l'instance un membre du domaine pendant la prochaine fenêtre de maintenance planifiée. + **pending-removal**–La suppression de l'instance du domaine est en attente. + **pending-maintenance-removal** – AWS va tenter de supprimer l'instance du domaine pendant la prochaine fenêtre de maintenance planifiée. + **failed**–Un problème de configuration a empêché l'instance d'effectuer la jonction du domaine. Vérifiez et corrigez votre configuration avant d'émettre à nouveau la commande de modification de l'instance. + **removing**–La suppression de l'instance du domaine est en cours. Une demande visant à devenir membre d'un domaine peut échouer à cause d'un problème de connectivité réseau ou d'un rôle IAM incorrect. Par exemple, vous pouvez créer une instance de base de données ou modifier une instance existante et faire échouer la tentative pour que l'instance de base de données devienne membre d'un domaine. Dans ce cas, émettez à nouveau la commande pour créer ou modifier l'instance de base de données, ou modifiez l'instance nouvellement créée pour rejoindre le domaine. # Dépannage d’Active Directory Vous pouvez rencontrer les problèmes suivants lors de la configuration ou de la modification d’un annuaire AD autogéré. | Code d’erreur | Description | Causes courantes | Suggestions de dépannage | | --- | --- | --- | --- | | Erreur 2 / 0x2 | Le fichier spécifié est introuvable. | Le format ou l’emplacement de l’unité organisationnelle (UO) spécifiée avec le paramètre `—domain-ou` est non valide. Le compte de service de domaine spécifié via AWS Secrets Manager ne possède pas les autorisations requises pour rejoindre l’unité organisationnelle. | Passez en revue le paramètre `—domain-ou`. Assurez-vous que le compte de service de domaine dispose des autorisations appropriées pour accéder à l’unité d’organisation. | | Erreur 5 / 0x5 | Accès refusé. | Autorisations mal configurées pour le compte de service de domaine, ou le compte d'ordinateur existe déjà dans le domaine. | Passez en revue les autorisations du compte de service de domaine dans le domaine et vérifiez que le compte d’ordinateur RDS n’est pas dupliqué dans le domaine. Vous pouvez vérifier le nom du compte d’ordinateur RDS en exécutant `SELECT @@SERVERNAME` sur votre instance de base de données RDS Custom for SQL Server. Si vous utilisez un déploiement multi-AZ, essayez un redémarrage avec basculement, puis vérifiez à nouveau que le compte d’ordinateur RDS est actif. Pour plus d’informations, consultez [Redémarrage d'une instance de base de données cluster de base de données](USER_RebootInstance.md). | | Erreur 87 / 0x57 | Le paramètre est incorrect. | Le compte de service de domaine spécifié via AWS Secrets Manager ne dispose pas des autorisations appropriées. Le profil utilisateur est peut-être également endommagé. | Passez en revue les exigences relatives au compte de service de domaine. | | Erreur 234 / 0xEA | L’unité d’organisation (OU) spécifiée n’existe pas. | L’unité organisationnelle spécifiée avec le paramètre `—domain-ou` n’existe pas dans votre annuaire AD. | Vérifiez le paramètre `—domain-ou` et assurez-vous que l’unité organisationnelle spécifiée existe dans votre annuaire AD. | | Erreur 1326 / 0x52E | Le nom d'utilisateur ou le mot de passe est incorrect. | Les informations d’identification du compte de service de domaine fournies dans AWS Secrets Manager contiennent un nom d’utilisateur inconnu ou un mot de passe incorrect. Le compte de domaine peut également être désactivé dans votre annuaire AD. | Assurez-vous que les informations d’identification fournies dans AWS Secrets Manager sont correctes et que le compte de domaine est activé dans votre annuaire Active Directory. | | Erreur 1355 / 0x54B | Le domaine spécifié n'existe pas ou n'a pas pu être contacté. | Le domaine est hors service, les adresses IP DNS spécifiées sont inaccessibles ou le nom FQDN spécifié est inaccessible. | Vérifiez les paramètres `—domain-dns-ips` et `—domain-fqdn` pour vous assurer qu’ils sont corrects. Passez en revue la configuration réseau de votre instance de base de données RDS Custom for SQL Server et assurez-vous que votre annuaire AD est accessible. | | Erreur 1722 / 0x6BA | Le serveur RPC n’est pas disponible. | Un problème est survenu lors de l'accès au service RPC de votre domaine AD. Il peut s’agir d’un problème de service ou de réseau. | Vérifiez que le service RPC s’exécute sur vos contrôleurs de domaine et que les ports TCP `135` et `49152-65535` sont accessibles dans votre domaine à partir de votre instance de base de données RDS Custom for SQL Server. | | Erreur 2224 / 0x8B0 | Le compte d’utilisateur existe déjà. | Le compte d’ordinateur qui tente d’être ajouté à votre annuaire AD existe déjà. | Identifiez le compte d’ordinateur en exécutant `SELECT @@SERVERNAME` sur votre instance de base de données RDS Custom for SQL Server, puis supprimez-le avec précaution de votre annuaire AD. | | Erreur 2242 / 0x8c2 | Le mot de passe de cet utilisateur a expiré. | Le mot de passe du compte de service de domaine spécifié via AWS Secrets Manager a expiré. | Mettez à jour le mot de passe du compte de service de domaine utilisé pour joindre votre instance de base de données RDS Custom for SQL Server à votre annuaire AD. |