Présentation d'Active Directory géré par le client (CMAD)

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 Utiliser Active Directory géré par le client.

Vous pouvez intégrer Cloud SQL pour SQL Server à Microsoft Active Directory géré par le client (également appelé AD géré par le client ou CMAD).

L'authentification, l'autorisation et bien plus sont disponibles via CMAD. Par exemple, la jointure d'une instance à un domaine CMAD 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 Google Cloud à vos domaines AD sur site.

Avant de commencer

Vous pouvez l'intégrer à CMAD, ce qui ajoute la compatibilité avec l'authentification Windows à une instance. Toutefois, avant d'effectuer l'intégration, votre projetGoogle Cloud doit remplir les conditions suivantes :

  • Pour que l'authentification fonctionne, vos instances Cloud SQL doivent disposer d'une connectivité réseau à tous les domaines Active Directory concernés. Cela inclut le domaine principal auquel l'instance est associée, ainsi que tous les domaines enfants ou approuvés contenant des utilisateurs qui doivent accéder à Cloud SQL pour SQL Server. Pour ce faire, assurez-vous que les ports suivants (TCP et UDP) sont ouverts entre vos instances Cloud SQL et tous vos contrôleurs de domaine : 53, 88, 135, 389, 445, 464, 3268, 3269 et 49152 à 65535.
  • Vous devez créer une unité organisationnelle (UO) pour stocker tous les objets d'intégration associés.
    • Dans cette UO, vous avez également besoin d'un compte administrateur disposant des autorisations suivantes :
      • Créer des objets Ordinateur
      • Supprimer des objets ordinateur
      • Créer des objets User
      • Supprimer des objets utilisateur
      • Écrire toutes les propriétés
      • Réinitialiser le mot de passe
      • Durée de verrouillage en lecture, durée de verrouillage en écriture
    • Nous vous recommandons également d'accorder à ce compte administrateur l'autorisation de gérer les enregistrements DNS, par exemple en l'ajoutant au groupe DnsAdmins.

      Si vous n'accordez pas ces autorisations, l'intégration fonctionnera quand même. Toutefois, pour vous connecter à votre instance, vous devrez créer manuellement les enregistrements DNS nécessaires, comme décrit dans Se connecter à une instance avec un utilisateur.

      L'autre option consiste à se connecter à l'aide de l'adresse IP de l'instance, ce qui présente des limites et ne fonctionnera pas pour les connexions à partir de domaines approuvés.

  • Vous devez stocker vos identifiants d'administrateur dans un secret Secret Manager, au format JSON suivant : 
        {
      "credentials": [
        {
          "validAfterUTC": "VALID_AFTER_UTC_VALUE",
          "administratorLogin": "ADMINISTRATOR_LOGIN_VALUE_1",
          "administratorPassword": "ADMINISTRATOR_PASSWORD_VALUE_1"
        },
        {
          "validAfterUTC": "VALID_AFTER_UTC_VALUE_2",
          "administratorLogin": "ADMINISTRATOR_LOGIN_VALUE_2",
          "administratorPassword": "ADMINISTRATOR_PASSWORD_VALUE_2"
        }
      ]
    }

    Remplacez les éléments suivants :

    • VALID_AFTER_UTC_VALUE_1 : première valeur UTC que vous souhaitez utiliser, fournie au format YYYY-MM-DDThh:mm:ssZ. Par exemple, 2099-07-01T10:30:00Z.
    • ADMINISTRATOR_LOGIN_VALUE_1 : première identifiant d'administrateur que vous souhaitez utiliser, par exemple myadmin. N'incluez pas le nom de domaine dans la valeur. Les entrées semblables à myadmin@my-domain-name.com ne sont pas acceptées.
    • ADMINISTRATOR_PASSWORD_VALUE_1 : mot de passe de l'administrateur.
    • VALID_AFTER_UTC_VALUE_2 : deuxième valeur UTC que vous souhaitez utiliser, fournie au format YYYY-MM-DDThh:mm:ssZ. Par exemple, 2099-07-01T10:30:00Z.
    • ADMINISTRATOR_LOGIN_VALUE_2 : identifiant de connexion du deuxième administrateur que vous souhaitez utiliser, par exemple myadmin2. De même, n'incluez pas le nom de domaine dans la valeur. Les entrées semblables à myadmin2@my-domain-name.com ne sont pas acceptées.
    • ADMINISTRATOR_PASSWORD_VALUE_2 : mot de passe du deuxième administrateur.

    Ce fichier peut contenir plusieurs entrées d'identifiants pour atténuer les problèmes de propagation lente ou pour tenir compte des rotations planifiées à l'avance.

    Le champ validAfterUTC est facultatif. S'il n'est pas spécifié, les identifiants sont considérés comme toujours valides. Nous vous recommandons de conserver ces identifiants disponibles en permanence dans Secret Manager et d'utiliser l'automatisation pour mettre à jour le mot de passe si vous faites tourner les identifiants.

    Vous pouvez supprimer le secret après la création de l'instance, mais sachez que les opérations futures telles que le clonage ou l'ajout d'un réplica en lecture entraîneront la non-association de la nouvelle instance au domaine.

    De plus, la suppression de l'instance d'origine laissera des objets orphelins, tels que le compte de l'ordinateur, dans votre CMAD.

  • Disposer d'une liste d'adresses IP de serveur DNS pour votre Active Directory géré par le client, qui sont généralement vos contrôleurs de domaine. Nous vous recommandons d'utiliser des adresses IP statiques pour ces serveurs.
  • Attribuez des comptes de service par produit et par projet.

Créer et configurer un compte de service

Pour créer un compte de service disposant des autorisations requises, vérifiez les points suivants :

Pour créer un compte de service avec la gcloud CLI, exécutez la commande suivante :

  gcloud beta services identity create --service=sqladmin.googleapis.com 

      --project=PROJECT_ID

Cette commande renvoie un nom de compte de service au format suivant :

  service-PROJECT_ID@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

Pour accorder l'autorisation nécessaire à l'intégration, exécutez la commande suivante :

  gcloud iam roles create secretIamPolicyManager --project=PROJECT_ID 

    --permissions="secretmanager.secrets.getIamPolicy,secretmanager.secrets.setIamPolicy"

Exécutez ensuite la commande suivante :

  gcloud secrets add-iam-policy-binding ADCredentials --project="722300452883" 

    --member="serviceAccount:service-SQL_PROJECT_NUMBER@gcp-sa-cloud-sql.iam.gserviceaccount.com" 

    --role="projects/PROJECT-ID/roles/secretIamPolicyManager"

Pour en savoir plus, consultez gcloud beta services identity create.

Bonnes pratiques pour l'intégration à CMAD

Lorsque vous intégrez CMAD, nous vous recommandons de suivre les étapes ci-dessous.

Conditions préalables à l'intégration

Utilisez l'outil de diagnostic Active Directory 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 . Ignorez les étapes liées au service géré pour Microsoft Active Directory.

Topologies pour l'intégration à CMAD

Cloud SQL pour SQL Server n'est pas compatible avec les groupes locaux à un domaine. Toutefois, les alternatives suivantes sont disponibles :

  • Ajoutez des groupes globaux ou des connexions utilisateur individuelles directement dans SQL Server.
  • Utilisez des groupes universels si tous les groupes et tous les utilisateurs appartiennent à la même forêt.

Cloud SQL pour SQL Server n'est pas compatible avec les groupes locaux à un domaine en tant que connexions. Pour accorder des autorisations aux utilisateurs du domaine, vous devez utiliser des groupes globaux ou universels, 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 CMAD, 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 CMAD, option 2.

Limites et alternatives

Les limites suivantes s'appliquent lors de l'intégration à CMAD :

  • Les instances Cloud SQL pour SQL Server qui utilisent Private Service Connect (PSC) pour la connectivité privée ne sont pas compatibles. Utilisez plutôt l'accès aux services privés (PSA).
  • 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.
  • S'il existe d'autres domaines approuvés et que vous prévoyez d'accéder aux instances SQL Server avec des noms d'utilisateur provenant de ces domaines, ils doivent être connectés via une approbation bidirectionnelle. Les relations d'approbation unidirectionnelles et externes ne sont pas prises en charge.
  • 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 CMAD, 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.
  • Les noms de domaine complets (FQDN, fully qualified domain names) ne sont pas acceptés par SQL Server. 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 .
  • L'authentification Windows ne fonctionnera pas avec une approbation externe. L'erreur renvoyée peut être la suivante : 
      "The target principal name is incorrect. Cannot generate SSPI context."
    De plus, comme pour les recommandations de Microsoft, utilisez une approbation de forêt au lieu d'une approbation externe pour l'authentification Kerberos.
  • La dernière version du secret est toujours utilisée. Le secret doit être actif et ne peut pas être détruit.

Points de terminaison Active Directory et connexions TLS

Si vous utilisez l'authentification Windows et que vous souhaitez établir une connexion TLS sans faire confiance au certificat du serveur, vous devez faire une rotation des certificats une fois l'authentification Windows activée sur l'instance.

Si la connexion échoue et que l'un de vos certificats a été créé avant le 15 mars 2025, vous devez à nouveau faire pivoter le certificat de serveur et réessayer d'établir la connexion.

Non compatible avec l'intégration

Les fonctionnalités suivantes ne sont pas compatibles lors de l'intégration à CMAD :

  • Les groupes locaux à un domaine.
  • 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).

Surveillance

Vous pouvez utiliser la métrique suivante pour surveiller l'état et l'intégrité de CMAD :

cloudsql.googleapis.com/database/active_directory/domain_reachable

Cette métrique indique si le CMAD est accessible depuis l'instance Cloud SQL. Il s'agit d'un outil utile pour résoudre les problèmes de réseau :

cloudsql.googleapis.com/database/active_directory/instance_available

Étapes suivantes