Présentation du service Microsoft AD géré dans Cloud SQL

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 :

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 la console Google Cloud, 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_NUMBER

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 du service géré pour Microsoft Active Directory, tandis que 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 :

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 :

Topologie AD, 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 :

Topologie AD, 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 pour ad\user plutôt que pour ad.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 la console Google Cloud.
  • 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