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 autogéré avec une instance de base de données Amazon RDS for SQL Server
Vous pouvez joindre vos instances de base de données RDS for SQL Server directement à votre domaine Active Directory (AD) autogéré, quel que soit l'endroit où votre AD est hébergé : dans les centres de données d'entreprise AWS EC2, sur ou auprès d'autres fournisseurs de cloud. Avec AD autogéré, vous utilisez l'NTLMauthentification pour contrôler directement l'authentification des utilisateurs et des services sur vos instances de base de données RDS de SQL serveur sans utiliser de domaines intermédiaires ni d'approbations forestières. Lorsque les utilisateurs s'authentifient avec une instance de base de données RDS for SQL Server jointe à votre domaine AD autogéré, les demandes d'authentification sont transférées vers un domaine AD autogéré que vous spécifiez.
Rubriques
Disponibilité des régions et des versions
Amazon RDS prend en charge l'utilisation d'AD autogéré pour les SQL serveurs NTLM dans tous les domaines Régions AWS.
Limites
Les limitations suivantes s'appliquent à Self Managed AD for SQL Server.
-
NTLMest le seul type d'authentification pris en charge. L'authentification Kerberos n'est pas prise en charge. Si vous devez utiliser l'authentification Kerberos, vous pouvez utiliser AWS Managed AD au lieu d'AD autogéré.
-
Le service Microsoft Distributed Transaction Coordinator (MSDTC) n'est pas pris en charge, car il nécessite une authentification Kerberos.
-
Vos instances de base de données RDS for SQL Server n'utilisent pas le serveur Network Time Protocol (NTP) de votre domaine AD autogéré. Ils utilisent plutôt un AWS NTP service.
-
SQLLes serveurs liés au serveur doivent utiliser SQL l'authentification pour se connecter à d'autres RDS instances de base de données de SQL serveur jointes à votre domaine AD autogéré.
-
Les paramètres Microsoft Group Policy Object (GPO) de votre domaine AD autogéré ne sont pas appliqués aux instances de base RDS de données de SQL serveur.
Vue d'ensemble de la configuration d'Active Directory autogéré
Pour configurer AD autogéré pour une instance de base de données RDS pour SQL serveur, suivez les étapes suivantes, expliquées plus en détail dans Configuration d'Active Directory autogéré :
Dans votre domaine AD :
-
Créez une unité d'organisation (OU).
-
Créez un utilisateur de domaine AD.
-
Déléguez le contrôle à l'utilisateur du domaine AD.
Depuis le AWS Management Console ou API :
-
Créez une AWS KMS clé.
-
Créez un secret à l'aide de AWS Secrets Manager.
-
Créez ou modifiez une instance de base de données RDS for SQL Server et associez-la à votre domaine AD autogéré.
Comprendre l'appartenance à un domaine Active Directory autogéré
Après la création ou la modification de votre instance de base de données, 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.
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é.
Restaurer une instance de base de données de SQL serveur, puis l'ajouter à 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 de SQL serveur, 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 6 : créer ou modifier une instance de base de données de SQL serveur afin d'ajouter l'instance de base de données à un domaine AD autogéré.
