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 d'Active Directory avec RDS for SQL Server Vous pouvez joindre une instance de base de données RDS for SQL Server à un domaine Microsoft Active Directory (AD). Votre domaine AD peut être hébergé sur AWS Managed AD au sein AWS d'AD ou sur un AD autogéré à l'emplacement de votre choix, y compris dans les centres de données de votre entreprise AWS EC2, sur ou auprès d'autres fournisseurs de cloud. Vous pouvez authentifier les utilisateurs du domaine à l'aide de l'authentification NTLM et de l'authentification Kerberos avec Active Directory autogéré et. AWS Managed Microsoft AD Dans les sections suivantes, vous trouverez des informations sur l'utilisation d'Active Directory autogéré et d'Active Directory AWS géré pour Microsoft SQL Server sur Amazon RDS. **Topics** + [Utilisation d’Active Directory autogéré avec une instance de base de données Amazon RDS for SQL Server](USER_SQLServer_SelfManagedActiveDirectory.md) + [Utilisation d'Active Directory AWS géré avec RDS pour SQL Server](USER_SQLServerWinAuth.md) # Utilisation d’Active Directory autogéré avec une instance de base de données Amazon RDS for SQL Server Amazon RDS for SQL Server s’intègre parfaitement à votre domaine Active Directory (AD) autogéré, où que votre AD soit hébergé : dans votre centre de données, dans Amazon EC2 ou auprès d’autres fournisseurs de services cloud. Cette intégration permet l’authentification directe des utilisateurs via les protocoles NTLM ou Kerberos, éliminant ainsi le besoin de domaines intermédiaires complexes ou d’approbations de forêt. Lorsque vous vous connectez à votre instance de base de données SQL Server RDS, les demandes d’authentification sont transférées de manière sécurisée vers le domaine AD que vous avez désigné, ce qui permet de conserver votre structure de gestion des identités existante tout en tirant parti des fonctionnalités de base de données gérées d’Amazon RDS. **Topics** + [Disponibilité des régions et des versions](#USER_SQLServer_SelfManagedActiveDirectory.RegionVersionAvailability) + [Prérequis](USER_SQLServer_SelfManagedActiveDirectory.Requirements.md) + [Considérations](#USER_SQLServer_SelfManagedActiveDirectory.Limitations) + [Configuration d’Active Directory autogéré](USER_SQLServer_SelfManagedActiveDirectory.SettingUp.md) + [Joindre votre instance de base de données à Active Directory autogéré](USER_SQLServer_SelfManagedActiveDirectory.Joining.md) + [Gestion d'une instance de base de données dans un domaine Active Directory autogéré](USER_SQLServer_SelfManagedActiveDirectory.Managing.md) + [Comprendre l'appartenance à un domaine Active Directory autogéré](#USER_SQLServer_SelfManagedActiveDirectory.Understanding) + [Résolution des problèmes liés à Active Directory autogéré](USER_SQLServer_SelfManagedActiveDirectory.TroubleshootingSelfManagedActiveDirectory.md) + [Restauration d'une instance de base de données SQL Server, puis ajout de cette instance à un domaine Active Directory autogéré](#USER_SQLServer_SelfManagedActiveDirectory.Restore) ## Disponibilité des régions et des versions Amazon RDS prend en charge l'autogestion d'AD pour SQL Server à l'aide de NTLM et de Kerberos dans toutes les applications commerciales et. Régions AWS AWS GovCloud (US) Regions # Prérequis Assurez-vous de respecter les exigences suivantes avant de joindre une instance de base de données RDS for SQL Server à votre domaine AD autogéré. **Topics** + [Configuration de votre annuaire AD sur site](#USER_SQLServer_SelfManagedActiveDirectory.Requirements.OnPremConfig) + [Configuration de votre connectivité réseau](#USER_SQLServer_SelfManagedActiveDirectory.Requirements.NetworkConfig) + [Configuration de votre compte de service de domaine AD](#USER_SQLServer_SelfManagedActiveDirectory.Requirements.DomainAccountConfig) + [Configuration d’une communication sécurisée via LDAPS](#USER_SQLServer_SelfManagedActiveDirectory.Requirements.LDAPS) ## Configuration de votre annuaire AD sur site Assurez-vous de disposer d'un annuaire Microsoft AD sur site ou autogéré auquel vous pouvez joindre l'instance Amazon RDS for SQL Server. Votre annuaire AD sur site doit avoir la configuration suivante : + Si vous avez défini des sites AD, assurez-vous que les sous-réseaux du VPC associé à votre instance de base de données RDS for SQL Server sont définis dans votre site AD. 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 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 Assurez-vous de respecter les configurations réseau suivantes : + Configurez la connectivité entre le VPC Amazon sur lequel vous souhaitez créer l’instance de base de données RDS for SQL Server et votre AD autogéré. Vous pouvez configurer la connectivité à l'aide de AWS Direct Connect, d' AWS un VPN, d'un peering VPC ou de Transit Gateway AWS . + Pour les groupes de sécurité VPC, le groupe de sécurité par défaut de votre VPC Amazon par défaut est déjà ajouté à votre instance de base de données RDS for SQL Server dans la console. Assurez-vous que le groupe de sécurité et le réseau VPC du ou ACLs des sous-réseaux sur lesquels vous créez votre instance de base de données RDS pour 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 d’AD autogéré.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/SQLServer_SelfManagedActiveDirectory_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/USER_SQLServer_SelfManagedActiveDirectory.Requirements.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 un réseau VPC ACLs, vous devez également autoriser le trafic sortant sur les ports dynamiques (49152-65535) depuis votre instance de base de données RDS pour 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 for SQL Server. Alors que les groupes de sécurité VPC nécessitent que les ports soient ouverts uniquement dans le sens où le trafic réseau est initié, la plupart des pare-feux Windows et des réseaux VPC ACLs nécessitent que les ports soient ouverts dans les deux sens. ## Configuration de votre compte de service de domaine AD Assurez-vous de respecter les exigences suivantes pour un compte de service de domaine AD : + Assurez-vous de 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 autogéré 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 (UO) à laquelle vous joignez votre instance de base de données RDS 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 Il s’agit de l’ensemble minimal d’autorisations requises pour joindre des objets informatiques à votre AD autogéré. Pour plus d'informations, consultez [Erreurs lors d'une tentative visant à joindre des ordinateurs à un domaine](https://learn.microsoft.com/en-US/troubleshoot/windows-server/identity/access-denied-when-joining-computers) dans la documentation de Microsoft Windows Server. + Pour utiliser l'authentification Kerberos, vous devez fournir des noms principaux de service (SPNs) et des autorisations DNS à votre compte de service de domaine AD : + **SPN validé en écriture** : déléguez l’autorisation de **SPN validé en écriture** au compte de service de domaine AD dans l’unité organisationnelle où vous devez rejoindre l’instance de base de données RDS for SQL Server. Ces autorisations sont différentes du SPN validé en écriture validé. + **Autorisations DNS** : accordez les autorisations suivantes au compte de service de domaine AD dans le Gestionnaire DNS au niveau du serveur pour votre contrôleur de domaine : + Contenu de la liste + Lire toutes les propriétés + Autorisations de lecture **Important** Ne déplacez pas les objets informatiques créés par RDS for SQL Server dans l’unité organisationnelle après la création de votre instance de base de données. Le déplacement des objets associés entraînera une mauvaise configuration de votre instance de base de données RDS for SQL Server. Si vous devez déplacer les objets informatiques créés par Amazon RDS, utilisez l'opération [Modify DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) RDS API pour modifier les paramètres du domaine avec l'emplacement souhaité pour les objets informatiques. ## Configuration d’une communication sécurisée via LDAPS La communication via LDAPS est recommandée pour que RDS puisse interroger des objets informatiques et y accéder, ainsi que SPNs dans le contrôleur de domaine. Pour utiliser le protocole LDAP sécurisé, utilisez un certificat SSL valide sur votre contrôleur de domaine qui répond aux exigences du protocole LDAPS sécurisé. Si aucun certificat SSL valide n’existe sur le contrôleur de domaine, l’instance de base de données RDS for SQL Server utilise par défaut le protocole LDAP. Pour plus d’informations sur la validité des certificats, consultez [Exigences relatives à un certificat LDAPS](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-over-ssl-3rd-certification-authority#requirements-for-an-ldaps-certificate). ## Considérations Lorsque vous ajoutez une instance de base de données RDS for SQL Server à un AD autogéré, tenez compte des points suivants : + Vos instances de base AWS de données se synchronisent avec le service NTP et non avec le serveur de temps du domaine AD. Pour les connexions de base de données entre des instances SQL Server liées au sein de votre domaine AD, vous pouvez uniquement utiliser l’authentification SQL et non l’authentification Windows. + Les paramètres des objets de stratégie de groupe issus de votre domaine AD autogéré ne sont pas propagés à vos instances RDS pour SQL Server. # Configuration d’Active Directory autogéré Pour configurer un AD autogéré, procédez comme suit. **Topics** + [Étape 1 : Création d’une unité organisationnelle dans votre AD](#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.CreateOU) + [Étape 2 : Création d’un compte de service de domaine AD dans votre AD](#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.CreateADuser) + [Étape 3 : Délégation du contrôle au compte de service de domaine AD](#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.DelegateControl) + [Étape 4 : Création d'une AWS KMS clé](#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.CreateKMSkey) + [Étape 5 : Créez un AWS secret](#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.CreateSecret) ## Étape 1 : Création d’une unité organisationnelle dans votre AD **Important** Nous vous recommandons de créer une unité d'organisation dédiée et des informations d'identification de service étendues à cette unité d'organisation pour tout AWS compte propriétaire d'une instance de base de données RDS pour SQL Server jointe à votre domaine AD autogéré. En dédiant une unité organisationnelle et des informations d’identification de service, vous pouvez éviter les conflits d’autorisations et suivre le principe de moindre privilège. **Pour créer 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é organisationnelle. 1. Cliquez avec le bouton droit sur le domaine et choisissez **Nouveau**, puis **Unité d'organisation**. 1. Saisissez un nom pour l’unité organisationnelle. 1. Laissez la case cochée pour **Protéger le conteneur contre la suppression accidentelle**. 1. Cliquez sur **OK**. Votre nouvelle unité organisationnelle apparaîtra sous votre domaine. ## Étape 2 : Création d’un compte de service de domaine AD dans votre AD Les informations d'identification du compte du service de domaine seront utilisées pour le secret dans AWS Secrets Manager. **Pour créer un compte de service de domaine AD dans votre AD** 1. Ouvrez **Utilisateurs et ordinateurs Active Directory** et sélectionnez le domaine et l’unité organisationnelle où vous souhaitez créer votre 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 »**. Ne sélectionnez pas **« 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 au compte de service de domaine AD **Pour déléguer le contrôle au compte de service de domaine AD dans votre domaine** 1. Ouvrez le composant logiciel enfichable MMC **Utilisateurs et ordinateurs Active Directory** et sélectionnez le domaine où vous souhaitez créer votre utilisateur. 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 le compte de service de domaine AD que vous avez créé et cliquez sur **Vérifier les noms**. Si votre vérification du compte de service de domaine AD aboutit, cliquez sur **OK**. 1. Dans la section **Utilisateurs ou groupes**, confirmez que votre compte de service de domaine 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** : 1. Choisissez **Seulement les objets suivants dans le dossier**. 1. Sélectionnez **Objets informatiques**. 1. Sélectionnez **Créer les objets sélectionnés dans ce dossier**. 1. Sélectionnez **Supprimer les objets sélectionnés dans ce dossier** et cliquez sur **Suivant**. 1. Dans la section **Autorisations** : 1. Gardez l'option **Général** sélectionnée. 1. Sélectionnez **Écriture validée sur le nom d'hôte DNS**. 1. Sélectionnez **Écriture validée sur le nom du principal de service** et cliquez sur **Suivant**. 1. Pour activer l'authentification Kerberos, maintenez l'option **Spécifique à la propriété** sélectionnée et sélectionnez **Écrire servicePrincipalName** dans la liste. 1. Pour **Fin de l'Assistant Délégation de contrôle**, passez en revue et confirmez vos paramètres, puis cliquez sur **Terminer**. 1. Pour l’authentification Kerberos, ouvrez le Gestionnaire DNS et ouvrez les propriétés **Serveur**. 1. Dans la boîte de dialogue Windows, tapez `dnsmgmt.msc`. 1. Ajoutez le compte de service de domaine AD sous l’onglet **Sécurité**. 1. Sélectionnez l’autorisation **Lecture** et appliquez vos modifications. ## Étape 4 : Création d'une AWS KMS clé La clé KMS est utilisée pour chiffrer votre AWS secret. **Pour créer une AWS KMS clé** **Note** Pour la **clé de chiffrement**, n'utilisez pas la clé KMS AWS par défaut. Assurez-vous de créer la AWS KMS clé dans le même AWS compte qui contient l'instance de base de données RDS pour SQL Server que vous souhaitez joindre à votre AD autogéré. 1. Dans la AWS KMS console, choisissez **Create key**. 1. Pour **Type de clé**, choisissez **Symétrique**. 1. Pour **Utilisation de la clé**, choisissez **Chiffrer et déchiffrer**. 1. Pour **Options avancées** : 1. Pour **Origine des clés**, choisissez **KMS**. 1. Pour **Régionalité**, choisissez **Clé à région unique** et cliquez sur **Suivant**. 1. Pour **Alias**, attribuez un nom à la clé KMS. 1. (Facultatif) Pour **Description**, fournissez une description de la clé KMS. 1. (Facultatif) Pour **Balises**, spécifiez une balise pour la clé KMS et cliquez sur **Suivant**. 1. Pour **Administrateurs de clé**, spécifiez le nom d'un utilisateur IAM et sélectionnez-le. 1. Pour **Suppression de clé**, laissez la case cochée pour **Autoriser les administrateurs de clé à supprimer cette clé** et cliquez sur **Suivant**. 1. Pour **Utilisateurs de clé**, spécifiez le même utilisateur IAM que celui de l'étape précédente et sélectionnez-le. Cliquez sur **Suivant**. 1. Passez en revue la configuration. 1. Pour **Stratégie de clé**, ajoutez ce qui suit à la **déclaration** de stratégie : ``` { "Sid": "Allow use of the KMS key on behalf of RDS", "Effect": "Allow", "Principal": { "Service": [ "rds.amazonaws.com" ] }, "Action": "kms:Decrypt", "Resource": "*" } ``` 1. Cliquez sur **Finish**. ## Étape 5 : Créez un AWS secret **Pour créer un secret** **Note** Assurez-vous de créer le secret dans le même AWS compte qui contient l'instance de base de données RDS pour SQL Server que vous souhaitez joindre à votre AD autogéré. 1. Dans AWS Secrets Manager, choisissez **Enregistrer un nouveau secret**. 1. Pour **Secret type** (Type de secret), choisissez **Other type of secret** (Autre type de secret). 1. Pour **Paires clé/valeur**, ajoutez vos deux clés : 1. Pour la première clé, entrez `SELF_MANAGED_ACTIVE_DIRECTORY_USERNAME`. 1. Pour la valeur de la première clé, saisissez uniquement le nom utilisateur (sans le préfixe de domaine) de l’utilisateur AD. N’incluez pas le nom de domaine, car cela entraîne l’échec de la création de l’instance. 1. Pour la deuxième clé, entrez `SELF_MANAGED_ACTIVE_DIRECTORY_PASSWORD`. 1. Pour la valeur de la deuxième clé, saisissez le mot de passe que vous avez créé pour l'utilisateur AD sur votre domaine. 1. Pour **Clé de chiffrement**, saisissez la clé KMS que vous avez créée à une étape précédente et cliquez sur **Suivant**. 1. Dans **Nom du secret**, saisissez un nom descriptif qui vous aidera à rechercher votre secret ultérieurement. 1. (Facultatif) Pour **Description**, saisissez une description du nom du secret. 1. Pour **Autorisation des ressources**, cliquez sur **Modifier**. 1. Ajoutez la politique suivante à la politique d'autorisation : **Note** Nous vous recommandons d'utiliser les conditions `aws:sourceAccount` et `aws:sourceArn` dans la politique pour éviter le problème de l’*adjoint confus*. Utilisez votre Compte AWS for `aws:sourceAccount` et l'ARN de votre instance de base de données RDS pour SQL Server pour`aws:sourceArn`. Pour de plus amples informations, veuillez consulter [Prévention des problèmes d'adjoint confus entre services](cross-service-confused-deputy-prevention.md). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "rds.amazonaws.com" }, "Action": "secretsmanager:GetSecretValue", "Resource": "*", "Condition": { "StringEquals": { "aws:sourceAccount": "123456789012" }, "ArnLike": { "aws:sourceArn": "arn:aws:rds:us-west-2:123456789012:db:*" } } } ] } ``` ------ 1. Cliquez sur **Enregistrer**, puis sur **Suivant**. 1. Pour **Configurer les paramètres de rotation**, conservez les valeurs par défaut et choisissez **Suivant**. 1. Passez en revue les paramètres du secret et cliquez sur **Stocker**. 1. Choisissez le secret que vous avez créé et copiez la valeur de l'**ARN du secret**. Il sera utilisé à l'étape suivante pour configurer Active Directory autogéré. # Joindre votre instance de base de données à Active Directory autogéré Pour joindre votre instance de base de données RDS for SQL Server à Active Directory autogéré, procédez comme suit : ## Étape 1 : Création ou modification d’une instance de base de données SQL Server Vous pouvez utiliser la console, l'interface de ligne de commande ou l'API RDS pour associer une instance de base de données RDS for SQL Server à un domaine AD autogéré. Vous pouvez effectuer cette opération de différentes manières : + Créez une nouvelle instance de base de données SQL Server à l'aide de la console, de la commande [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)CLI ou de l'opération [Create DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) RDS API. Pour obtenir des instructions, veuillez consulter [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 [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)CLI ou de l'opération [DBInstanceModify](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) RDS API. Pour obtenir des instructions, veuillez consulter [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 base de données à l'aide de la console, de la commande 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 DBInstance Restore DBSnapshot From](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html) RDS API. Pour obtenir des instructions, veuillez consulter [Restauration d’une instance de base de données](USER_RestoreFromSnapshot.md). + Restaurez une instance de base de données SQL Server à point-in-time l'aide de la console, de la commande [restore-db-instance-to- point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) CLI ou de l'opération [Restore DBInstance ToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html) RDS API. Pour obtenir des instructions, veuillez consulter [Restauration d’une instance de base de données à un instant précis pour Amazon RDS](USER_PIT.md). Lorsque vous utilisez le AWS CLI, les paramètres suivants sont requis pour que l'instance de base de données puisse utiliser le domaine AD autogéré que vous avez créé : + Pour le paramètre `--domain-fqdn`, utilisez le nom de domaine entièrement qualifié (FQDN) de votre 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. + Pour le `--domain-dns-ips` paramètre, utilisez les IPv4 adresses principale et secondaire des serveurs DNS de votre AD autogéré. Si vous ne possédez pas d'adresse IP de serveur DNS secondaire, entrez deux fois l'adresse IP principale. Les exemples de commandes CLI suivants montrent comment créer, modifier et supprimer une instance de base de données RDS for SQL Server avec un domaine AD autogéré. **Important** Si vous modifiez une instance de base de données pour la joindre à un domaine AD autogéré 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 un temps d'arrêt pour l'instance de base de données mono-AZ. Une instance de base de données multi-AZ effectuera un basculement avant de terminer le redémarrage. Pour de plus amples informations, veuillez consulter [Utilisation du paramètre de planification des modifications](USER_ModifyInstance.ApplyImmediately.md). La commande CLI suivante crée une nouvelle instance de base de données RDS for SQL Server et la joint à un domaine AD autogéré. Pour Linux, macOS ou Unix : ``` aws rds create-db-instance \ --db-instance-identifier my-DB-instance \ --db-instance-class db.m5.xlarge \ --allocated-storage 50 \ --engine sqlserver-se \ --engine-version 15.00.4043.16.v1 \ --license-model license-included \ --master-username my-master-username \ --master-user-password my-master-password \ --domain-fqdn my_AD_domain.my_AD.my_domain \ --domain-ou OU=my-AD-test-OU,DC=my-AD-test,DC=my-AD,DC=my-domain \ --domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:my-AD-test-secret-123456" \ --domain-dns-ips "10.11.12.13" "10.11.12.14" ``` Pour Windows : ``` aws rds create-db-instance ^ --db-instance-identifier my-DB-instance ^ --db-instance-class db.m5.xlarge ^ --allocated-storage 50 ^ --engine sqlserver-se ^ --engine-version 15.00.4043.16.v1 ^ --license-model license-included ^ --master-username my-master-username ^ --master-user-password my-master-password ^ --domain-fqdn my-AD-test.my-AD.mydomain ^ --domain-ou OU=my-AD-test-OU,DC=my-AD-test,DC=my-AD,DC=my-domain ^ --domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:my-AD-test-secret-123456" \ ^ --domain-dns-ips "10.11.12.13" "10.11.12.14" ``` La commande d’interface de ligne de commande suivante modifie une instance de base de données RDS for SQL Server existante afin d’utiliser un domaine AD autogéré. Pour Linux, macOS ou Unix : ``` aws rds modify-db-instance \ --db-instance-identifier my-DB-instance \ --domain-fqdn my_AD_domain.my_AD.my_domain \ --domain-ou OU=my-AD-test-OU,DC=my-AD-test,DC=my-AD,DC=my-domain \ --domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:my-AD-test-secret-123456" \ --domain-dns-ips "10.11.12.13" "10.11.12.14" ``` Pour Windows : ``` aws rds modify-db-instance ^ --db-instance-identifier my-DBinstance ^ --domain-fqdn my_AD_domain.my_AD.my_domain ^ --domain-ou OU=my-AD-test-OU,DC=my-AD-test,DC=my-AD,DC=my-domain ^ --domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:my-AD-test-secret-123456" ^ --domain-dns-ips "10.11.12.13" "10.11.12.14" ``` La commande d’interface de ligne de commande suivante supprime une instance de base de données RDS for SQL Server d’un domaine AD autogéré. Pour Linux, macOS ou Unix : ``` aws rds modify-db-instance \ --db-instance-identifier my-DB-instance \ --disable-domain ``` Pour Windows : ``` aws rds modify-db-instance ^ --db-instance-identifier my-DB-instance ^ --disable-domain ``` ## Étape 2 : Utilisation de l’authentification Kerberos ou NTLM ### Authentifications NTLM 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 ou au point de terminaison d’écouteur si vous utilisez un déploiement multi-AZ. Lors de la maintenance planifiée de la base de données ou d'une interruption de service imprévue, Amazon RDS bascule automatiquement vers la base de données up-to-date secondaire 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 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 for 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**. ![\[Modification de la capacité de stockage d'une instance de base de données\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/kerb-endpoint-selfManagedAD-RDSMS.png) 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; ``` Si votre instance renvoie une connexion NTLM lorsque vous vous connectez à un point de terminaison Kerberos, vérifiez votre configuration réseau et les configurations utilisateur. Consultez [Configuration de votre connectivité réseau](USER_SQLServer_SelfManagedActiveDirectory.Requirements.md#USER_SQLServer_SelfManagedActiveDirectory.Requirements.NetworkConfig). ## Étape 3 : 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 autogéré, vous pouvez provisionner des connexions et des utilisateurs SQL Server. Pour ce faire, utilisez l'utilitaire Utilisateurs et groupes AD de votre domaine AD autogéré. 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 compte de domaine de service AD autogéré puisse s’authentifier à SQL Server, une connexion Windows SQL Server doit exister pour le compte de domaine de service AD autogéré ou un groupe AD autogéré 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 compte de domaine de service AD autogéré qui n’a pas de connexion SQL Server ou qui n’appartient pas à un groupe AD autogéré 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 à AD autogéré. Si vous n'avez pas créé de connexion 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 à AD autogéré 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 compte de domaine de service ou un groupe AD autogéré. **Note** Spécifiez les utilisateurs et les groupes à l'aide du nom de connexion antérieur à Windows 2000 au format `my_AD_domain\my_AD_domain_user`. Vous ne pouvez pas utiliser un nom d'utilisateur principal (UPN) au format *`my_AD_domain_user`*`@`*`my_AD_domain`*. ``` USE [master] GO CREATE LOGIN [my_AD_domain\my_AD_domain_user] FROM WINDOWS WITH DEFAULT_DATABASE = [master], DEFAULT_LANGUAGE = [us_english]; GO ``` Pour plus d'informations, consultez [CREATE LOGIN (Transact-SQL)](https://msdn.microsoft.com/en-us/library/ms189751.aspx) dans la documentation de Microsoft Developer Network. Les utilisateurs (personnes et applications) de votre domaine peuvent désormais se connecter à l'instance RDS for SQL Server à partir d'un ordinateur client joint au domaine AD autogéré à l'aide de l'authentification Windows. # Gestion d'une instance de base de données dans un domaine Active Directory autogéré Vous pouvez utiliser la console ou l'API Amazon RDS pour gérer votre instance de base de données et sa relation avec votre domaine AD autogéré. AWS CLI 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 réessayer de joindre un domaine autogéré en cas d'échec d'adhésion, utilisez l'opération [Modify DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) API et spécifiez le même ensemble de paramètres : + `--domain-fqdn` + `--domain-dns-ips` + `--domain-ou` + `--domain-auth-secret-arn` + Pour supprimer une instance de base de données d'un domaine autogéré, utilisez l'opération d'API `ModifyDBInstance` et spécifiez `--disable-domain` pour le paramètre de domaine. + Pour déplacer une instance de base de données d'un domaine autogéré à un autre, utilisez l'opération d'API `ModifyDBInstance` et spécifiez les paramètres de domaine pour le nouveau domaine : + `--domain-fqdn` + `--domain-dns-ips` + `--domain-ou` + `--domain-auth-secret-arn` + Pour répertorier les membres de domaines AD autogérés pour chaque instance de base de données, utilisez l'opération d'DBInstancesAPI [Describe](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/DescribeDBInstances.html). ## Comprendre l'appartenance à un domaine Active Directory autogéré Une fois que vous avez créé ou modifié votre instance de base de données tout en spécifiant les détails d’AD, l’instance devient un membre du domaine AD autogéré. La AWS console indique l'état de l'appartenance au domaine Active Directory autogéré 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 AD. + **joining** : l'instance est en train de devenir membre du domaine AD. + **pending-join** – L'appartenance de l'instance est en attente. + **pending-maintenance-join**— AWS tentera de faire de l'instance un membre du domaine AD lors de la prochaine fenêtre de maintenance planifiée. + **pending-removal** : la suppression de l'instance du domaine AD est en attente. + **pending-maintenance-removal**— AWS tentera de supprimer l'instance du domaine AD lors de la prochaine fenêtre de maintenance planifiée. + **failed** : un problème de configuration a empêché de joindre l'instance au domaine AD. 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 AD autogéré est en cours. **Important** Une demande pour devenir membre d'un domaine AD autogéré peut échouer à cause d'un problème de connectivité réseau. 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 AD autogéré. 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 la joindre au domaine AD autogéré. # Résolution des problèmes liés à Active Directory autogéré 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 dispose pas des autorisations requises pour rejoindre l'unité d'organisation. | 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é organisationnelle. Pour de plus amples informations, veuillez consulter [Configuration de votre compte de service de domaine AD](USER_SQLServer_SelfManagedActiveDirectory.Requirements.md#USER_SQLServer_SelfManagedActiveDirectory.Requirements.DomainAccountConfig). | | 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 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 de plus amples informations, veuillez consulter [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. Pour de plus amples informations, veuillez consulter [Configuration de votre compte de service de domaine AD](USER_SQLServer_SelfManagedActiveDirectory.Requirements.md#USER_SQLServer_SelfManagedActiveDirectory.Requirements.DomainAccountConfig). | | Erreur 234 / 0xEA | L’unité organisationnelle (UO) 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 autogéré. | Vérifiez le paramètre `—domain-ou` et assurez-vous que l’unité organisationnelle spécifiée existe dans votre annuaire AD autogéré. | | 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 autogéré. | Assurez-vous que les informations d’identification fournies dans AWS Secrets Manager sont correctes et que le compte de domaine est activé dans votre AD autogéré. | | Erreur 1355 / 0x54B | Le domaine spécifié n'existe pas ou n'a pas pu être contacté. | Le domaine est en panne, l'ensemble de DNS IPs spécifié est inaccessible ou le 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 for SQL Server et assurez-vous que votre annuaire AD autogéré est accessible. Pour de plus amples informations, veuillez consulter [Configuration de votre connectivité réseau](USER_SQLServer_SelfManagedActiveDirectory.Requirements.md#USER_SQLServer_SelfManagedActiveDirectory.Requirements.NetworkConfig). | | 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 for SQL Server. | | Erreur 1727 / 0x6BF | L’appel de procédure à distance a échoué et n’a pas été exécuté. | Problème de connectivité réseau ou restriction du pare-feu bloquant la communication RPC avec le contrôleur de domaine. | Si vous utilisez la jonction de domaines entre VPC, vérifiez que la communication entre VPC est correctement configurée avec l’appairage de VPC ou la passerelle de transit. Vérifiez que les ports élevés TCP `49152-65535` sont accessibles dans votre domaine à partir de votre instance de base de données RDS for SQL Server, y compris les éventuelles restrictions de pare-feu. | | Erreur 2224 / 0x8B0 | Le compte d'utilisateur existe déjà. | Le compte d'ordinateur qui tente d'être ajouté à votre annuaire AD autogéré existe déjà. | Identifiez le compte d'ordinateur en exécutant `SELECT @@SERVERNAME` sur votre instance de base de données RDS for SQL Server, puis supprimez-le avec précaution de votre annuaire AD autogéré. | | 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 for SQL Server à votre annuaire AD autogéré. | Après avoir joint votre instance de base de données à un domaine Active Directory autogéré, vous pouvez recevoir des événements RDS liés à l’état de santé de votre domaine. ``` Unhealthy domain state detected while attempt to verify or configure your Kerberos endpoint in your domain on node node_n. message ``` Pour les instances multi-AZ, vous remarquerez peut-être le rapport d’erreur pour node1 et node2, qui indique que la configuration Kerberos de votre instance n’est pas prête pour le basculement. En cas de basculement, vous pouvez rencontrer des difficultés d’authentification avec Kerberos. Résolvez les problèmes de configuration pour vous assurer que la configuration de Kerberos est valide et à jour. Pour les instances multi-AZ, aucune action n’est requise pour utiliser l’authentification Kerberos sur le nouvel hôte principal étant donné que toutes les configurations réseau et d’autorisation sont en place. Pour les instances mono-AZ, node1 est le nœud primaire. Si votre authentification Kerberos ne fonctionne pas comme prévu, vérifiez les événements de l’instance et résolvez les problèmes de configuration pour vous assurer que la configuration de Kerberos est valide et à jour. ## Restauration d'une instance de base de données SQL Server, puis ajout de cette instance à un domaine Active Directory autogéré Vous pouvez restaurer un instantané de base de données ou effectuer une point-in-time restauration (PITR) pour une instance de base de données SQL Server, puis l'ajouter à un domaine Active Directory autogéré. Une fois l'instance de base de données restaurée, modifiez cette instance à l'aide du processus expliqué dans [Étape 1 : Création ou modification d’une instance de base de données SQL Server](USER_SQLServer_SelfManagedActiveDirectory.Joining.md#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.CreateModify) afin d'ajouter l'instance de base de données à un domaine AD autogéré. # Utilisation d'Active Directory AWS géré avec RDS pour SQL Server Vous pouvez l'utiliser AWS Managed Microsoft AD pour authentifier les utilisateurs avec l'authentification Windows lorsqu'ils se connectent à votre instance de base de données RDS pour SQL Server. L'instance de base de données fonctionne avec AWS Directory Service for Microsoft Active Directory, également appelée AWS Managed Microsoft AD, pour activer l'authentification Windows. Lorsque les utilisateurs s'authentifient à une instance de base de données SQL Server jointe au domaine d'approbation, les demandes d'authentification sont transmises à l'annuaire de domaine que vous créez avec Directory Service. ## Disponibilité des régions et des versions Amazon RDS prend en charge l'utilisation uniquement AWS Managed Microsoft AD pour l'authentification Windows. RDS ne prend pas en charge l'utilisation AD Connector. Pour plus d'informations, consultez les ressources suivantes : + [Politique de compatibilité des applications pour AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_app_compatibility.html) + [Politique de compatibilité des applications pour AD Connector](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_connector_app_compatibility.html) Pour obtenir des informations sur la disponibilité des versions, consultez [Authentification Kerberos avec RDS for SQL Server](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.RDS_Fea_Regions_DB-eng.Feature.KerberosAuthentication.html#Concepts.RDS_Fea_Regions_DB-eng.Feature.KerberosAuthentication.sq). ## Présentation de la configuration de l'authentification Windows Amazon RDS utilise le mode mixte pour l'authentification Windows. Cette approche signifie que l'*utilisateur principal *(nom et mot de passe utilisés pour créer votre instance de base de données SQL Server) utilise l'authentification SQL. Étant donné que le compte utilisateur principal comporte des informations d'identification privilégiées, vous devez limiter l'accès à ce compte. Pour obtenir l'authentification Windows à l'aide d'un compte Microsoft Active Directory sur site ou auto-géré, créez une approbation de forêt. L'approbation peut être unidirectionnelle ou bidirectionnelle. Pour plus d'informations sur la configuration des approbations forestières [à l'aide Directory Service de la section Quand créer une relation de confiance](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_setup_trust.html) dans le *Guide d'AWS Directory Service administration*. Pour configurer l’authentification Windows pour une instance de base de données SQL Server, procédez comme suit. Les étapes sont expliquées de façon plus détaillée dans [Configuration de l'authentification Windows pour les instances de base de données SQL Server](USER_SQLServerWinAuth.SettingUp.md) : 1. AWS Managed Microsoft AD Utilisez-le, soit depuis l' AWS Management Console Directory Service API, soit pour créer un AWS Managed Microsoft AD répertoire. 1. Si vous utilisez l'API AWS CLI ou Amazon RDS pour créer votre instance de base de données SQL Server, créez un rôle Gestion des identités et des accès AWS (IAM). Ce rôle utilise la stratégie IAM gérée `AmazonRDSDirectoryServiceAccess` et autorise Amazon RDS à effectuer des appels vers votre annuaire. Si vous utilisez la console pour créer votre instance de base de données SQL Server, AWS crée le rôle IAM pour vous. Pour que le rôle autorise l'accès, le point de terminaison AWS Security Token Service (AWS STS) doit être activé dans la AWS région de votre AWS compte. AWS STS les points de terminaison sont actifs par défaut dans toutes les AWS régions, et vous pouvez les utiliser sans autre action. Pour plus d’informations, consultez [Gestion de AWS STS dans une Région AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html) dans le *Guide de l’utilisateur IAM*. 1. Créez et configurez des utilisateurs et des groupes dans l' AWS Managed Microsoft AD annuaire à l'aide des outils Microsoft Active Directory. Pour plus d'informations sur la création d'utilisateurs et de groupes dans votre Active Directory, consultez [Gérer les utilisateurs et les 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 AWS Directory Service *. 1. Si vous prévoyez de localiser le répertoire et l'instance de base de données dans un emplacement différent VPCs, activez le trafic inter-VPC. 1. Utilisez Amazon RDS pour créer une nouvelle instance de base de données SQL Server à partir de la console ou de l'API Amazon RDS. AWS CLI Dans la demande de création, vous indiquez l'identifiant du domaine (identifiant « `d-*` ») généré lors de la création de votre annuaire, ainsi que le nom du rôle que vous avez créé. Vous pouvez également modifier une instance de base de données SQL Server pour qu'elle utilise l'authentification Windows en configurant les paramètres de domaine et de rôle IAM de l'instance de base de données. 1. 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. Comme l'instance de base de données est jointe au AWS Managed Microsoft AD domaine, vous pouvez configurer des connexions et des utilisateurs SQL Server à partir des utilisateurs et des groupes Active Directory de leur domaine. (Ceux-ci sont connus sous le nom de connexions SQL Server « Windows ».) 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. Lorsque vous créez une instance de base de données RDS pour SQL Server connectée à un domaine à l'aide de la console Amazon RDS, le rôle IAM est AWS automatiquement créé. `rds-directoryservice-access-role` Ce rôle est essentiel pour gérer les instances connectées au domaine et est requis pour les opérations suivantes : + Apporter des modifications de configuration aux instances SQL Server connectées à un domaine + Gestion des paramètres de l’intégration d’Active Directory + Réalisation d’opérations de maintenance sur des instances jointes à un domaine **Important** Si vous supprimez le rôle IAM `rds-directoryservice-access-role`, vous ne pouvez pas apporter de modifications à votre instance SQL Server connectée au domaine via la console ou l’API Amazon RDS. Toute tentative de modification de l'instance entraîne l'affichage d'un message d'erreur indiquant : Vous n'êtes pas autorisé à utiliser iam : CreateRole. Pour demander l'accès, copiez le texte suivant et envoyez-le à votre AWS administrateur. Cette erreur se produit, car Amazon RDS doit recréer le rôle pour gérer la connexion au domaine, mais ne dispose pas des autorisations nécessaires. De plus, cette erreur n'est pas enregistrée CloudTrail, ce qui peut compliquer le dépannage. Si vous le supprimez accidentellement `rds-directoryservice-access-role`, vous devez avoir les autorisations `iam:CreateRole` pour le recréer avant de pouvoir apporter des modifications à votre instance SQL Server connectée au domaine. Pour recréer le rôle manuellement, assurez-vous qu’il est associé à la politique gérée `AmazonRDSDirectoryServiceAccess` et à la relation de confiance appropriée permettant au service RDS d’assumer le rôle. # Création d'un point de terminaison pour l'authentification Kerberos L'authentification basée sur Kerberos nécessite que le point de terminaison soit le nom d'hôte spécifié par le client, un point, puis le nom de domaine complet (FQDN). Par exemple, l'exemple suivant illustre un point de terminaison à utiliser avec l'authentification basée sur Kerberos. Dans cet exemple, le nom d'hôte de l'instance de base de données SQL Server est `ad-test` et le nom de domaine est `corp-ad.company.com` : ``` ad-test.corp-ad.company.com ``` Pour vérifier que votre connexion utilise Kerberos, exécutez la requête suivante : ``` 1. SELECT net_transport, auth_scheme 2. FROM sys.dm_exec_connections 3. WHERE session_id = @@SPID; ``` # Configuration de l'authentification Windows pour les instances de base de données SQL Server Vous utilisez AWS Directory Service for Microsoft Active Directory, également appelé AWS Managed Microsoft AD, pour configurer l'authentification Windows pour une instance de base de données SQL Server. Pour configurer l'authentification Windows, procédez comme suit. ## Étape 1 : créer un répertoire à l'aide du AWS Directory Service for Microsoft Active Directory Directory Service crée un Microsoft Active Directory entièrement géré dans le AWS cloud. Lorsque vous créez un AWS Managed Microsoft AD annuaire, il Directory Service crée deux contrôleurs de domaine et des serveurs DNS (Domain Name Service) en votre nom. Les serveurs de répertoire sont créés dans deux sous-réseaux sur deux zones de disponibilité différentes avec un VPC. Cette redondance permet de s'assurer que votre répertoire reste accessible y compris en cas de défaillance. Lorsque vous créez un AWS Managed Microsoft AD répertoire, Directory Service exécute les tâches suivantes en votre nom : + Configuration de Microsoft Active Directory dans le VPC. + Création d'un compte d'administrateur d'annuaire avec le nom d'utilisateur Admin et le mot de passe spécifié. Ce compte est utilisé pour gérer votre annuaire. + Création d’un groupe de sécurité pour les contrôleurs de l’annuaire. Lorsque vous lancez un AWS Directory Service for Microsoft Active Directory, AWS crée une unité organisationnelle (UO) qui contient tous les objets de votre répertoire. Cette unité organisationnelle, qui porte le nom NetBIOS que vous avez saisi lorsque vous avez créé votre annuaire, est située dans la racine du domaine. La racine du domaine est détenue et gérée par AWS. Le compte *admin* qui a été créé avec votre annuaire AWS Managed Microsoft AD dispose des autorisations pour les activités administratives les plus courantes pour votre unité organisationnelle : + Créer, mettre à jour ou supprimer des utilisateurs, des groupes et des ordinateurs + Ajouter des ressources à votre domaine, comme des serveurs de fichiers ou d’impression, puis attribuer des autorisations pour ces ressources aux utilisateurs et groupes dans votre unité organisationnelle. + Créez OUs des conteneurs supplémentaires. + Déléguer des autorités. + Créer et associer des stratégies de groupes. + Restaurer des objets supprimés de la corbeille Active Directory. + Exécutez les PowerShell modules Windows AD et DNS sur le service Web Active Directory. Le compte admin dispose également de droits pour exécuter les activités suivantes au niveau du domaine : + Gérer les configurations DNS (ajouter, supprimer ou mettre à jour des enregistrements, des zones et des redirecteurs) + Afficher les journaux d'événements DNS. + Afficher les journaux d'événements de sécurité. **Pour créer un répertoire avec AWS Managed Microsoft AD** 1. Dans le panneau de navigation de la [console Directory Service](https://console.aws.amazon.com/directoryservicev2/), choisissez **Annuaires**, puis **Configurer un annuaire**. 1. Choisissez **AWS Managed Microsoft AD**. Il s'agit de la seule option prise en charge actuellement pour être utilisée avec Amazon RDS. 1. Choisissez **Suivant**. 1. Sur la page **Enter directory information** (Saisir les détails du répertoire), renseignez les informations suivantes : **Edition** Choisissez l’édition qui correspond à vos besoins. **Nom de DNS de l’annuaire** Nom complet de l'annuaire, par exemple `corp.example.com`. Les noms de plus de 47 caractères ne sont pas pris en charge par SQL Server. **Nom NetBIOS de l'annuaire** Nom court facultatif pour l’annuaire, par exemple `CORP`. **Description de l’annuaire** Description facultative de l’annuaire. **Mot de passe administrateur** Mot de passe de l'administrateur de l'annuaire. Le processus de création d’un annuaire crée un compte d’administrateur avec le nom d’utilisateur Admin et ce mot de passe. Le mot de passe de l'administrateur de l'annuaire ne peut pas inclure le terme `admin`. Le mot de passe est sensible à la casse et doit comporter entre 8 et 64 caractères. Il doit également contenir au moins un caractère de trois des quatre catégories suivantes : + Lettres minuscules (a-z) + Lettres majuscules (A-Z) + Chiffres (0-9) + Caractères non alphanumériques (\$1\$1@\$1\$1%^&\$1\$1-\$1=`\$1\$1()\$1\$1[]:;"'<>,.?/) **Confirmer le mot de passe** Saisissez à nouveau le mot de passe de l'administrateur. 1. Choisissez **Suivant**. 1. Sur la page **Choose VPC and subnets** (Choisir un VPC et des sous-réseaux), indiquez les informations suivantes : **VPC** Sélectionnez le VPC pour l’annuaire. Vous pouvez localiser le répertoire et l'instance de base de données différemment VPCs, mais dans ce cas, assurez-vous d'activer le trafic inter-VPC. Pour de plus amples informations, veuillez consulter [Étape 4 : Activer le trafic entre VPC entre le répertoire et l'instance de base de données](#USER_SQLServerWinAuth.SettingUp.VPC-Peering). **Sous-réseaux** Choisissez les sous-réseaux pour les serveurs d’annuaires. Les deux sous-réseaux doivent être dans des zones de disponibilité différentes. 1. Choisissez **Suivant**. 1. Vérifiez les informations de l'annuaire. Si vous devez apporter des modifications, choisissez **Previous (Précédent)**. Lorsque les informations sont correctes, choisissez **Create directory (Créer l'annuaire)**. ![\[Vérification et création de la page\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/WinAuth2.png) La création de l'annuaire prend plusieurs minutes. Lorsqu’il est créé, la valeur du champ **Statut** devient **Actif**. Pour consulter les informations relatives à votre annuaire, choisissez l'ID de l'annuaire dans la liste. Notez la valeur de **ID de l'annuaire**. Vous en aurez besoin pour créer ou modifier votre instance de base de données SQL Server. ![\[Page de détails de l'annuaire\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/WinAuth3.png) ## Étape 2 : Créer le rôle IAM qui sera utilisé par Amazon RDS Si vous utilisez la console pour créer votre instance de base de données SQL Server, vous pouvez ignorer cette étape. Si vous utilisez la CLI ou l'API RDS pour créer votre instance de base de données SQL Server, vous devez créer un rôle IAM qui utilise la stratégie IAM gérée `AmazonRDSDirectoryServiceAccess`. Ce rôle permet à Amazon RDS de passer des appels Directory Service pour vous. Si vous utilisez une politique personnalisée pour rejoindre un domaine, au lieu d'utiliser la `AmazonRDSDirectoryServiceAccess` politique AWS-managed, assurez-vous d'autoriser l'`ds:GetAuthorizedApplicationDetails`action. Cette exigence est effective à partir de juillet 2019, en raison d'une modification de l' Directory Service API. La stratégie IAM suivante, `AmazonRDSDirectoryServiceAccess`, permet d'accéder à Directory Service. **Example Politique IAM pour fournir l'accès à Directory Service** **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "ds:DescribeDirectories", "ds:AuthorizeApplication", "ds:UnauthorizeApplication", "ds:GetAuthorizedApplicationDetails" ], "Effect": "Allow", "Resource": "*" } ] } ``` Nous vous recommandons d’utiliser les clés de contexte de condition globale [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) et [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) dans des relations d’approbation basées sur les ressources pour limiter les autorisations du service à une ressource spécifique. C’est le moyen le plus efficace de se protéger contre le [problème du député confus](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html). Vous pouvez utiliser les deux clés de contexte de condition globale et faire en sorte que la valeur `aws:SourceArn` contienne l'ID de compte. Dans ce cas, la valeur `aws:SourceAccount` et le compte dans la valeur `aws:SourceArn` doivent utiliser le même ID de compte lorsqu'ils sont utilisés dans la même instruction. + Utilisez `aws:SourceArn` si vous souhaitez un accès interservices pour une seule ressource. + Utilisez `aws:SourceAccount` si vous souhaitez autoriser une ressource de ce compte à être associée à l’utilisation interservices. Dans la relation d'approbation, assurez-vous d'utiliser la clé de contexte de condition globale `aws:SourceArn` avec l'Amazon Resource Name (ARN) complet des ressources qui accèdent au rôle. Pour l'authentification Windows, veillez à inclure les instances de base de données, comme illustré dans l'exemple suivant. **Example relation d'approbation avec la clé de contexte de condition globale pour l'authentification Windows** **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "rds.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceArn": [ "arn:aws:rds:Region:my_account_ID:db:db_instance_identifier" ] } } } ] } ``` Créez un rôle IAM à l'aide de cette politique IAM et de cette relation d'approbation. Pour plus d’informations sur la création de rôles IAM, consultez [Création de stratégies gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-using.html#create-managed-policy-console) dans le *Guide de l’utilisateur IAM*. ## Étape 3 : Créer et configurer des utilisateurs et des groupes Vous pouvez créer des utilisateurs et des groupes à l’aide de l’outil Active Directory Users and Computers. Cet outil fait partie des outils Services AD DS (Active Directory Domain Services) et Services AD LDS (Active Directory Lightweight Directory Services). Les utilisateurs représentent des individus ou des entités individuelles qui ont accès à votre annuaire. Les groupes sont très utiles pour octroyer ou refuser des privilèges à des groupes d'utilisateurs, plutôt que d'appliquer ces privilèges à chaque utilisateur. Pour créer des utilisateurs et des groupes dans un Directory Service annuaire, vous devez être connecté à une instance Windows EC2 membre de l' Directory Service annuaire. Vous devez également être connecté en tant qu'utilisateur disposant de privilèges pour créer des utilisateurs et des groupes. Pour plus d'informations, consultez la section [Ajouter des utilisateurs et des groupes (Simple AD et AWS Managed Microsoft AD)](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/creating_ad_users_and_groups.html) dans le *Guide d'AWS Directory Service administration*. ## Étape 4 : Activer le trafic entre VPC entre le répertoire et l'instance de base de données Si vous avez l'intention de rechercher l'annuaire et l'instance de base de données dans le même VPC, ignorez cette étape et passez à [Étape 5 : Créer ou modifier une instance de base de données SQL Server](#USER_SQLServerWinAuth.SettingUp.CreateModify). [Si vous prévoyez de localiser le répertoire et l'instance de base de données différemment VPCs, configurez le trafic inter-VPC à l'aide du peering VPC ou de Transit Gateway.AWS](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) La procédure suivante active le trafic entre les utilisateurs de VPCs l'appairage VPC. Suivez les instructions de [Qu’est-ce que l’appairage de VPC ?](https://docs.aws.amazon.com/vpc/latest/peering/Welcome.html) dans le *Guide de l’appairage Amazon Virtual Private Cloud*. **Pour 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. 1. Assurez-vous qu’il n’existe aucune règle de liste de contrôle d’accès (ACL) pour bloquer le trafic. Si le répertoire appartient à un autre AWS compte, vous devez le partager. **Pour partager le répertoire entre AWS comptes** 1. *Commencez à partager le répertoire avec le AWS compte dans lequel l'instance de base de données sera créée en suivant les instructions du [Tutoriel : Partage de votre AWS Managed Microsoft AD répertoire pour une connexion fluide à un domaine EC2 dans le Directory Service Guide](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_directory_sharing.html) d'administration.* 1. Connectez-vous à la Directory Service console à l'aide du compte de l'instance de base de données et assurez-vous que le domaine possède le `SHARED` statut requis avant de continuer. 1. Lorsque vous êtes 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 d’annuaire pour joindre l’instance de base de données au domaine. ## Étape 5 : Créer ou modifier une instance de base de données SQL Server Créez ou modifiez une instance de base de données 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 nouvelle instance de base de données SQL Server à l'aide de la console, de la commande [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)CLI ou de l'opération [Create DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) RDS API. Pour obtenir des instructions, veuillez consulter [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 [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)CLI ou de l'opération [DBInstanceModify](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) RDS API. Pour obtenir des instructions, veuillez consulter [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 base de données à l'aide de la console, de la commande 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 DBInstance Restore DBSnapshot From](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html) RDS API. Pour obtenir des instructions, veuillez consulter [Restauration d’une instance de base de données](USER_RestoreFromSnapshot.md). + Restaurez une instance de base de données SQL Server à point-in-time l'aide de la console, de la commande [restore-db-instance-to- point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) CLI ou de l'opération [Restore DBInstance ToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html) RDS API. Pour obtenir des instructions, veuillez consulter [Restauration d’une instance de base de données à un instant précis pour Amazon RDS](USER_PIT.md). L'authentification Windows est uniquement prise en charge pour les instances de base de données SQL dans un VPC. Pour que l'instance de base de données puisse utiliser l'annuaire de domaine que vous avez créé, les éléments suivants sont nécessaires : + Pour **Annuaire**, vous devez choisir l'identifiant du domaine (`d-ID`) généré lors de la création de l'annuaire. + Assurez-vous que le groupe de sécurité VPC dispose d'une règle sortante qui permet à l'instance de base de données de communiquer avec l'annuaire. ![\[Annuaire d'authentification Windows à Microsoft SQL Server\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/WinAuth1.png) Lorsque vous utilisez le AWS CLI, les paramètres suivants sont requis pour que l'instance de base de données puisse utiliser le répertoire que vous avez créé : + Pour le paramètre `--domain`, vous devez indiquer l'identifiant du domaine (`d-ID`) généré lors de la création de l'annuaire. + Pour le paramètre `--domain-iam-role-name`, utilisez le rôle que vous avez créé qui utilise la stratégie IAM gérée `AmazonRDSDirectoryServiceAccess`. Par exemple, la commande de CLI suivante modifie une instance de base de données de façon à utiliser un annuaire. Pour Linux, macOS ou Unix : ``` aws rds modify-db-instance \ --db-instance-identifier mydbinstance \ --domain d-ID \ --domain-iam-role-name role-name ``` Pour Windows : ``` aws rds modify-db-instance ^ --db-instance-identifier mydbinstance ^ --domain d-ID ^ --domain-iam-role-name role-name ``` **Important** Si vous modifiez une instance de base de données de façon à activer l’authentification Kerberos, redémarrez l’instance de base de données après avoir effectué la modification. ## Étape 6 : Créer des 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. Comme l'instance de base de données est jointe au AWS Managed Microsoft AD domaine, vous pouvez configurer des connexions et des utilisateurs SQL Server. Vous effectuez cette opération à partir des utilisateurs et groupes Active Directory de votre domaine. 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 Active Directory puisse s'authentifier à SQL Server, une connexion Windows SQL Server doit exister pour l'utilisateur ou un groupe 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 qui n'a pas de connexion SQL Server ou qui n'appartient pas à un groupe 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 Active Directory. Si vous n'avez pas créé de connexion 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. Exécutez une commande DDL (Data Definition Language) telle que l'exemple suivant afin de créer une connexion SQL Server pour un utilisateur ou un groupe Active Directory. **Note** Spécifiez les utilisateurs et les groupes à l'aide du nom de connexion antérieur à Windows 2000 au format `domainName\login_name`. Vous ne pouvez pas utiliser un nom d'utilisateur principal (UPN) au format *`login_name`*`@`*`DomainName`*. Vous ne pouvez créer une connexion d’authentification Windows sur une instance RDS for SQL Server qu’à l’aide d’instructions T-SQL. Vous ne pouvez pas utiliser SQL Server Management Studio pour créer une connexion d’authentification Windows. ``` USE [master] GO CREATE LOGIN [mydomain\myuser] FROM WINDOWS WITH DEFAULT_DATABASE = [master], DEFAULT_LANGUAGE = [us_english]; GO ``` Pour plus d'informations, consultez [CREATE LOGIN (Transact-SQL)](https://msdn.microsoft.com/en-us/library/ms189751.aspx) dans la documentation de Microsoft Developer Network. Les utilisateurs (personnes et applications) de votre domaine peuvent désormais se connecter à l'instance RDS for SQL Server à partir d'un ordinateur client joint au domaine à l'aide de l'authentification Windows. # Gestion d'une instance de base de données dans un domaine Vous pouvez utiliser la console ou l'API Amazon RDS pour gérer votre instance de base de données et sa relation avec votre domaine. AWS CLI 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 réessayer de joindre un domaine en raison d'un échec d'adhésion, utilisez l'opération [DBInstanceModify](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) API et spécifiez l'ID de répertoire de l'adhésion 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 les membres de chaque instance de base de données, utilisez l'opération d'DBInstancesAPI [Describe](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/DescribeDBInstances.html). ## 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 AWS console 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 tentera de faire de l'instance un membre du domaine lors de la prochaine fenêtre de maintenance planifiée. + **pending-removal**–La suppression de l'instance du domaine est en attente. + **pending-maintenance-removal**— AWS tentera de supprimer l'instance du domaine lors de 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. # Connexion à SQL Server avec l'authentification Windows Pour vous connecter à SQL Server via l'authentification Windows, vous devez être connecté à un ordinateur joint au domaine en tant qu'utilisateur de domaine. Après le lancement de SQL Server Management Studio, choisissez le type d'authentification **Windows Authentication**, comme illustré ci-après. ![\[Se connecter à SQL Server en utilisant l'authentification Windows\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/WinAuth4.png) ## Restauration d'une instance de base de données SQL Server puis ajout de cette instance à un domaine Vous pouvez restaurer un instantané de base de données ou effectuer une point-in-time restauration (PITR) pour une instance de base de données SQL Server, puis l'ajouter à un domaine. 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éer ou modifier une instance de base de données SQL Server](USER_SQLServerWinAuth.SettingUp.md#USER_SQLServerWinAuth.SettingUp.CreateModify) afin d'ajouter l'instance de base de données à un domaine.