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

MySQL | PostgreSQL | SQL Server

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 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).

L'authentification, l'autorisation et bien plus sont disponibles via l'AD géré par le client. Par exemple, la jointure d'une instance à un domaine AD géré par le client 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 à un domaine AD présente l'avantage supplémentaire de l'intégration à vos domaines AD sur site. Google Cloud

Avant de commencer

Vous pouvez l'intégrer à l'AD géré par le client, ce qui ajoute la compatibilité avec l'authentification Windows à une instance. Toutefois, avant l'intégration, les éléments suivants sont requis pour votre Google Cloud projet :

Pour que l'authentification fonctionne, vos instances Cloud SQL doivent disposer d'une connectivité réseau à tous les domaines Active Directory pertinents. Cela inclut le domaine principal auquel l'instance est jointe, ainsi que tous les domaines approuvés ou enfants 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 devez également déléguer les autorisations suivantes au compte administrateur :
  - Gérer les objets ordinateur (créer un objet/supprimer un objet/modifier les propriétés d'un objet)
  - Gérer les objets utilisateur (créer un objet/supprimer un objet/modifier les propriétés d'un objet)
- Nous vous recommandons également d'accorder à ce compte administrateur des autorisations pour gérer les enregistrements DNS, par exemple en l'ajoutant au groupe DnsAdmins.
  Si vous n'accordez pas ces autorisations, l'intégration réussira quand même. Toutefois, pour vous connecter à votre instance, vous devrez créer manuellement les enregistrements DNS nécessaires, comme décrit dans la section Se connecter à une instance avec un utilisateur.
  
  Vous pouvez également vous connecter à l'aide de l'adresse IP de l'instance, mais cette méthode présente des limites et ne fonctionne pas pour les connexions à partir de domaines approuvés.
Vous devez stocker vos identifiants d'administrateur dans un Secret Manager secret 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, au format YYYY-MM-DDThh:mm:ssZ. Par exemple pourrait être 2099-07-01T10:30:00Z.
- ADMINISTRATOR_LOGIN_VALUE_1 : première connexion 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, au format YYYY-MM-DDThh:mm:ssZ. Par exemple pourrait être 2099-07-01T10:30:00Z.
- ADMINISTRATOR_LOGIN_VALUE_2 : deuxième connexion 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 laisser ces identifiants disponibles en permanence dans Secret Manager et d'utiliser l'automatisation pour mettre à jour le mot de passe si vous faites pivoter 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'une instance dupliquée en lecture seule entraîneront la non-jointure de la nouvelle instance au domaine.

De plus, la suppression de l'instance d'origine laissera des objets orphelins, tels que le compte d'ordinateur, dans votre AD géré par le client.
Disposez 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 :

Vous devez activer l'API Cloud SQL Admin.
Vous devez disposer des autorisations suivantes :
Vous devez disposer d'un compte de service par produit et par projet pour chaque projet que vous prévoyez d'intégrer à l'AD géré par le client. Utilisez gcloud CLI pour créer le compte au niveau du projet. Le compte de service par produit et par projet doit se voir accorder les autorisations secretmanager.secrets.getIamPolicy et secretmanager.secrets.setIamPolicy pour le secret créé à l'étape précédente. Pour en savoir plus, consultez la section Autorisations Secret Manager.

Nous vous recommandons de créer un rôle personnalisé avec les autorisations dont vous avez besoin.

Pour créer un compte de service avec 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 à l'AD géré par le client

Lorsque vous effectuez une intégration à l'AD géré par le client, 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 Google Cloud console. Ignorez les étapes liées au service géré pour Microsoft Active Directory.

Topologies pour l'intégration à l'AD géré par le client

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 de l'option 2, consultez le schéma suivant :

Topologie CMAD, option 2.

Limites et alternatives

Les limites suivantes s'appliquent lors de l'intégration à l'AD géré par le client :

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 .
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 des domaines approuvés supplémentaires et que vous prévoyez d'accéder aux instances SQL Server avec des noms d'utilisateur à partir de ces domaines, ils doivent être connectés via une approbation bidirectionnelle. Les approbations unidirectionnelles et externes ne sont pas acceptées.
En général, les nouveaux utilisateurs créés via la Google Cloud console se voient attribuer le CustomerDbRootRole rôle, 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 de l'AD géré par le client, 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 pourriez 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 Google Cloud console.
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 approuver le certificat de serveur, vous devez faire pivoter les 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 faire pivoter à nouveau le certificat de serveur et réessayer la connexion.

Non compatible avec l'intégration

Les fonctionnalités suivantes ne sont pas compatibles lors de l'intégration à l'AD géré par le client :

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 l'AD géré par le client :

cloudsql.googleapis.com/database/active_directory/domain_reachable

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

cloudsql.googleapis.com/database/active_directory/instance_available