Vous pouvez intégrer Cloud SQL pour SQL Server au service géré pour Microsoft Active Directory (également appelé service Microsoft AD géré).
Cette page contient des informations à examiner avant de commencer une intégration. Après avoir consulté les informations ci-dessous, y compris les limites, consultez la page Utiliser Cloud SQL avec le service Microsoft AD géré.
Avantages de l'intégration avec le service Microsoft AD géré
L'authentification, l'autorisation et bien plus sont disponibles via le service Microsoft AD géré. Par exemple, la jointure d'une instance à un domaine Microsoft AD géré vous permet de vous connecter à l'aide de l'authentification Windows avec une identité basée sur AD.
L'intégration de Cloud SQL pour SQL Server avec un domaine AD présente l'avantage supplémentaire de l'intégration du cloud à vos domaines AD sur site.
Conditions préalables à l'intégration
Vous pouvez l'intégrer au service Microsoft AD géré, ce qui ajoute la compatibilité avec l'authentification Windows à une instance. Toutefois, avant d'effectuer l'intégration, votre projet Google Cloud doit remplir les conditions suivantes :
- Un domaine Microsoft AD géré. Pour en savoir plus sur la configuration d'un domaine, consultez la page Créer un domaine.
- Les domaines AD sur site nécessitent une approbation AD gérée. Consultez les sections Créer une approbation unidirectionnelle et Utiliser un utilisateur AD sur site pour créer une connexion Windows à Cloud SQL.
- Un compte de service par produit et par projet, comme décrit ci-dessous. Consultez la section Créer un compte de service.
Créer et configurer un compte de service
Vous devez disposer d'un compte de service par produit et par projet pour chaque projet que vous prévoyez d'intégrer au service Microsoft AD géré. Utilisez gcloud
ou la console pour créer le compte au niveau du projet. Le compte de service par produit et par projet doit se voir attribuer le rôle managedidentities.sqlintegrator
sur le projet. Pour en savoir plus, consultez la section gcloud projects set-iam-policy.
Si vous utilisez Google Cloud Console, Cloud SQL crée automatiquement un compte de service pour vous et vous invite à attribuer le rôle managedidentities.sqlintegrator
.
Pour créer un compte de service avec gcloud
, exécutez la commande suivante :
gcloud beta services identity create --service=sqladmin.googleapis.com \ --project=[PROJECT]
Cette commande renvoie un nom de compte de service au format suivant :
service-[PROJECT_NUMBER]@gcp-sa-cloud-sql.iam.gserviceaccount.com
Voici un exemple de nom de compte de service :
service-333445@gcp-sa-cloud-sql.iam.gserviceaccount.com
Accorder les autorisations nécessaires à l'intégration nécessite des autorisations existantes. Pour connaître les autorisations requises, consultez la section Autorisations requises.
Pour accorder l'autorisation nécessaire à l'intégration, exécutez la commande suivante. Si votre service Microsoft AD géré se trouve dans un autre projet, [AD_PROJECT_ID] doit contenir l'instance Microsoft AD gérée, tandis que le projet [SQL_PROJECT_NUMBER] du compte de service doit contenir l'instance SQL Server :
gcloud projects add-iam-policy-binding [AD_PROJECT_ID] \ --member=serviceAccount:service-[SQL_PROJECT_NUMBER]@gcp-sa-cloud-sql.iam.gserviceaccount.com \ --role=roles/managedidentities.sqlintegrator
Consultez aussi la page gcloud beta services identity create.
Bonnes pratiques pour l'intégration au service Microsoft AD géré
Lorsque vous planifiez une intégration, consultez les ressources suivantes :
- Conditions préalables à l'intégration
- Intégrer une instance à un domaine AD géré dans un autre projet
- Bonnes pratiques pour l'exécution d'Active Directory sur Google Cloud
- Documentation de Microsoft AD géré
- Déployer des contrôleurs de domaine dans des régions supplémentaires
- Utilisez l'outil de diagnostic AD pour résoudre les problèmes de configuration d'AD avec votre domaine sur site et vos instances Cloud SQL pour SQL Server dans la console Google Cloud.
Disposer d'une instance SQL Server et d'une instance AD gérée dans la même région offre la latence réseau la plus faible et les performances les meilleures. Ainsi, dans la mesure du possible, configurez une instance SQL Server et une instance AD dans la même région. En outre, que vous les configuriez dans la même région ou non, configurez une région principale et une région de secours pour une plus grande disponibilité.
Topologies pour l'intégration au service Microsoft AD géré
Cloud SQL pour SQL Server n'est pas compatible avec les groupes locaux à un domaine. Cependant, vous pouvez :
- Ajouter des groupes globaux ou des connexions utilisateur individuelles directement dans SQL Server
- Utiliser des groupes universels lorsque tous les groupes et tous les utilisateurs appartiennent à la même forêt
Si les groupes locaux à un domaine étaient compatibles, des comptes utilisateur individuels et des groupes globaux et universels pourraient être ajoutés en tant qu'enfants d'un groupe local à un domaine (qui protège l'accès à SQL Server). Vous pourriez ainsi ajouter un groupe local à un domaine en tant que connexion SQL Server. Dans Cloud SQL pour SQL Server, vous pouvez activer des fonctionnalités similaires, comme décrit dans cette section.
Option 1 : Ajouter des comptes utilisateur et des groupes en tant que connexions à SQL Server
Si vous avez plusieurs domaines, dans plusieurs forêts et que vous avez plusieurs groupes globaux, vous pouvez ajouter tous les comptes utilisateur individuels, ainsi que les groupes globaux et universels, directement en tant que connexions à SQL Server. À titre d'exemple, consultez le schéma suivant pour l'option 1 :
Option 2 : Définir un groupe universel dans l'un de vos domaines
Si vos domaines se trouvent dans la même forêt, vous pouvez définir un groupe universel dans l'un de vos domaines. Vous pouvez ensuite ajouter tous les comptes utilisateur individuels ainsi que les groupes globaux et universels en tant qu'enfants de ce groupe universel défini, puis ajouter le groupe universel défini en tant que connexion SQL Server. À titre d'exemple, consultez le schéma suivant pour l'option 2 :
Limites et alternatives
Les limites suivantes s'appliquent lors de l'intégration au service Microsoft AD géré :
- Les groupes locaux à un domaine ne sont pas acceptés, mais vous pouvez ajouter des groupes globaux ou des connexions utilisateur individuelles directement dans SQL Server. Vous pouvez également utiliser des groupes universels lorsque tous les groupes et tous les utilisateurs appartiennent à la même forêt.
- En général, les nouveaux utilisateurs créés via la console Google Cloud se voient attribuer le rôle
CustomerDbRootRole
, qui dispose de ce rôle de base de données fixe pour l'agent SQL Server :SQLAgentUserRole
Toutefois, les utilisateurs créés directement via SQL Server, tels que les utilisateurs Microsoft AD gérés, ne peuvent pas se voir attribuer ce rôle, ni utiliser l'agent SQL Server : en effet, la base de données MSDB dans laquelle ce rôle doit être attribué est protégée. - Certaines opérations restreintes peuvent renvoyer l'erreur suivante : "Impossible de récupérer des informations sur le groupe/l'utilisateur Windows NT". Un exemple de ce type d'opération restreinte consiste à créer des connexions par des utilisateurs à partir de domaines qui sont connectés via une relation d'approbation. Un autre exemple consiste à accorder des droits aux utilisateurs à partir de domaines qui sont connectés via une relation d'approbation. Dans ce cas, une nouvelle tentative réussit souvent. Si la nouvelle tentative échoue, fermez la connexion et ouvrez une nouvelle connexion.
- Les noms de domaine complets (FQDN, fully qualified domain names) ne sont pas acceptés par SQL Server sous Windows. Par conséquent, utilisez des noms de domaine (noms courts) plutôt que des noms de domaine complets lorsque vous créez des connexions SQL Server. Par exemple, si votre nom de domaine est
ad.mydomain.com
, créez des connexions SQL Server pourad\user
plutôt que pourad.mydomain.com\user
. - Pour accéder aux instances SQL Server, utilisez toujours les noms de domaine complets. Par exemple, vous pouvez utiliser un nom de domaine complet semblable à
private.myinstance.us-central1.myproject.cloudsql.mydomain.com
. Les noms Netbios ne sont pas acceptés. C'est également le cas des noms courts si les suffixes DNS sont omis. - Les connexions SQL Server basées sur des utilisateurs et des groupes Active Directory ne peuvent pas être gérées depuis Google Cloud Console.
- Dans Cloud SQL, si une instance SQL Server a été créée le 12 mars 2021 ou avant, elle ne peut pas être intégrée à Microsoft AD géré.
- L'authentification Windows ne fonctionnera pas avec une approbation externe. L'erreur peut se présenter comme suit : "Le nom principal cible est incorrect. Impossible de générer le contexte SSPI." De plus, comme pour les recommandations de Microsoft, utilisez une approbation de forêt au lieu d'une approbation externe pour l'authentification Kerberos.
Non compatible avec l'intégration
Les fonctionnalités suivantes ne sont actuellement pas compatibles lors de l'intégration au service Microsoft AD géré :
- Les groupes locaux à un domaine.
- La suppression des connexions SQL Server par les utilisateurs des domaines qui sont connectés via une relation d'approbation. Vous pouvez effectuer cette opération avec un utilisateur de votre domaine géré ou via la connexion
sqlserver
. - L'authentification NTLM.
- La connexion avec une adresse IP à partir de domaines connectés via une relation d'approbation.
- Les instances avec des noms longs (plus de 63 caractères).
Étape suivante
- Consultez le guide de démarrage rapide pour créer un domaine Microsoft AD géré.
- Préparez-vous à créer une instance Cloud SQL intégrée.
- Découvrez comment créer une relation d'approbation entre des domaines sur site et un domaine Microsoft AD géré.
- Découvrez comment afficher les instances intégrées.