Utiliser le service Microsoft AD géré avec Cloud SQL

MySQL | PostgreSQL | SQL Server

Cette page décrit les différentes manières d'utiliser Cloud SQL pour :

Intégrer le service géré pour Microsoft Active Directory (également appelé Microsoft AD géré).
Vous connecter à une instance avec un utilisateur AD.

Une instance Cloud SQL intégrée à Microsoft AD géré est compatible avec l'authentification Windows en plus de l'authentification SQL.

Avant de commencer

Dans Google Cloud Console, sélectionnez le nom de votre projet.
Vérifiez que la facturation est activée pour votre projet Google Cloud. Découvrez comment vérifier que la facturation est activée pour votre projet.
Installez et initialisez gcloud CLI.
Assurez-vous que vous disposez du rôle Cloud SQL Admin sur votre compte utilisateur. Accédez à la page IAM.
Consultez les conditions préalables à l'intégration.

Créer une instance avec l'authentification Windows

Vous pouvez intégrer le service Microsoft AD géré lors de la création d'une instance afin de permettre l'authentification Windows pour l'instance. Pour procéder à l'intégration, choisissez un domaine que l'instance peut rejoindre. Si l'association au domaine échoue, la création de l'instance échoue.

Pour préparer la création d'une instance avec l'authentification Windows, consultez les conseils, ainsi que les limites et alternatives.

Une instance avec une adresse IP publique est compatible, à condition qu'elle possède également une adresse IP privée. L'adresse IP privée doit être activée pour l'instance. Vous pouvez ensuite choisir d'utiliser l'adresse IP publique ou l'adresse IP privée pour vous connecter à l'instance, tant que les deux sont disponibles.

Remarque : Une fois que vous avez créé une instance avec l'authentification Windows, une connexion Cloud SQL pour SQL Server supplémentaire est créée. La connexion est au format [domain]\sql_[letters-and-digits]. Par exemple, Cloud SQL peut créer une connexion nommée AD\sql_1a1a6145bc1aaaa. La connexion se trouve dans le domaine AD géré. Vous pouvez ignorer la connexion. Vous ne pouvez pas la supprimer. Toutefois, si vous désactivez l'authentification Windows pour l'instance, la connexion est automatiquement supprimée.

Vous trouverez ci-dessous les options permettant de créer une instance intégrée au service Microsoft AD géré.

Console

Dans Google Cloud Console, accédez à la page Instances Cloud SQL.

Accéder à la page Instances Cloud SQL
Cliquez sur Create instance (Créer une instance).
Cliquez sur Choisir SQL Server.
Entrez un nom pour l'instance. N'incluez pas d'informations sensibles ou personnelles dans le nom de l'instance, car les utilisateurs externes peuvent le voir. Vous n'avez pas besoin d'indiquer l'ID du projet. qui est créé automatiquement le cas échéant (dans les fichiers journaux, par exemple).
Saisissez le mot de passe de l'utilisateur 'sqlserver'.
Définissez la région de l'instance. Consultez les bonnes pratiques pour l'intégration à Microsoft AD géré.
Dans la section Options de configuration, définissez les options que vous souhaitez, mais attendez l'étape suivante pour les options d'authentification.
Cliquez sur Authentification. Le menu déroulant permettant d'associer un domaine Active Directory géré répertorie tous les domaines Microsoft AD gérés préalablement ajoutés à votre projet.
Dans le menu déroulant permettant de joindre un domaine Active Directory géré, sélectionnez un domaine.
Lorsque vous avez fini de sélectionner vos options de configuration, cliquez sur Créer. Cloud SQL crée automatiquement pour vous un compte de service par produit et par projet. Si le compte ne dispose pas du rôle approprié, vous êtes invité à lui accorder le rôle managedidentities.sqlintegrator.

gcloud

La commande suivante crée une instance intégrée au service Microsoft AD géré et qui est donc activée pour l'authentification Windows. Pour en savoir plus sur la commande de base pour créer une instance, consultez la page Créer des instances.

Spécifiez un paramètre de domaine --active-directory-domain=DOMAIN dans la commande gcloud. Par exemple, indiquez les éléments suivants : --active-directory-domain=ad.mydomain.com

Voici un prototype de la commande gcloud :

gcloud beta sql instances create INSTANCE_NAME \
--database-version=EDITION \
--root-password=PASSWORD \
--active-directory-domain=DOMAIN\
--cpu=CPU \
--memory=MEMORY  \
--network=NETWORK

Terraform

Pour créer une instance intégrée au service Microsoft AD géré, utilisez une ressource Terraform.

resource "google_sql_database_instance" "instance_with_ad" {
  name             = "database-instance-name"
  region           = "us-central1"
  database_version = "SQLSERVER_2019_STANDARD"
  root_password    = "INSERT-PASSWORD-HERE"

  depends_on = [google_service_networking_connection.private_vpc_connection]

  settings {
    tier = "db-custom-2-7680"
    active_directory_config {
      domain = "ad.domain.com"
    }
    ip_configuration {
      ipv4_enabled    = "false"
      private_network = google_compute_network.private_network.id
    }
  }
  # set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
  # use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
  deletion_protection = false
}

REST

L'API REST vous permet de créer une instance intégrée au service Microsoft AD géré. Spécifiez un domaine, tel que subdomain.mydomain.com, pour le champ domain, comme indiqué dans ce prototype de requête :

{
   "databaseVersion":"database-version",
   "name":"instance-id",
   "region":"region",
   "rootPassword":"password",
   "settings":{
      "tier":"machine-type",
      "ipConfiguration":{
         "privateNetwork":"network"
      },
      "activeDirectoryConfig":{
         "domain":"domain"
      }
   }
}

Mettre à jour une instance avec l'authentification Windows

Vous pouvez mettre à jour le domaine d'une instance existante en modifiant ou en ajoutant un domaine.

Pour obtenir des informations générales sur la mise à jour d'une instance, consultez la section Modifier des instances.

Si une instance est actuellement associée à un domaine AD géré, l'instance est initialement dissociée de ce domaine avant d'être associée au nouveau domaine. Si la mise à jour échoue, l'instance risque de ne plus être associée à aucun domaine.

Console

Dans Google Cloud Console, accédez à la page Instances Cloud SQL.

Accéder à la page Instances Cloud SQL
Pour ouvrir la page Présentation d'une instance, cliquez sur son nom.
Cliquez sur Modifier.
Cliquez sur Authentification. Le menu déroulant Rejoindre un domaine Active Directory répertorie tous les domaines Microsoft AD gérés précédemment ajoutés à votre projet.
Dans le menu déroulant permettant d'associer un domaine Active Directory géré, sélectionnez un nouveau domaine (remplacement) pour votre instance.
Cliquez sur Enregistrer pour appliquer les modifications.

gcloud

Voici le prototype d'une commande permettant de mettre à jour une instance existante : La commande ajoute ou remplace un domaine. Transmettez le paramètre --active-directory-domain=DOMAIN à la commande, comme suit :

gcloud beta sql instances patch INSTANCE_NAME \
--active-directory-domain=DOMAIN

REST

L'API REST vous permet de mettre à jour une instance existante. Spécifiez un domaine, tel que subdomain.mydomain.com, dans le champ domain. Voici un prototype de requête :

{
   "settings":{
      "activeDirectoryConfig":{
         "domain":"domain"
      }
   }
}

Intégrer une instance à un domaine AD géré dans un autre projet

Vous pouvez intégrer votre instance à un domaine Microsoft AD géré qui se trouve dans un projet différent.

Remarque : L'intégration à un domaine AD dans un autre projet nécessite l'utilisation des commandes gcloud ou de l'API REST Cloud SQL. Actuellement, vous ne pouvez pas utiliser la console Google Cloud à cette fin.

Au cours de la planification de votre intégration, examinez les contraintes.

Activer l'appairage de domaines

Pour suivre les étapes décrites dans les sections ci-dessous, activez l'appairage de domaines afin que votre domaine soit disponible dans tous les projets requis contenant des instances Cloud SQL pour SQL Server.

Pour obtenir la liste des domaines des autres projets déjà disponibles, vous pouvez spécifier les éléments suivants :

`gcloud active-directory peerings list`

Pour en savoir plus, consultez la section Répertorier les appairages de domaines.

La commande gcloud active-directory peerings list nécessite l'autorisation managedidentities.peerings.list. Les rôles suivants disposent de cette autorisation :

roles/managedidentities.peeringViewer
roles/managedidentities.viewer

Pour en savoir plus, consultez la page Contrôle des accès avec IAM.

Créer un compte de service

Répétez ces étapes pour chacun des projets contenant une instance Cloud SQL pour SQL Server à intégrer.

Consultez les informations générales pour créer des comptes de service.
Exécutez une commande semblable à la suivante pour créer un compte de service. Spécifiez l'ID du projet contenant les instances Cloud SQL pour SQL Server :
```
gcloud beta services identity create --service=sqladmin.googleapis.com \
--project=[PROJECT_ID]
```
Attribuez le rôle managedidentities.sqlintegrator au projet contenant l'instance Microsoft AD gérée. Spécifiez l'ID du projet contenant l'instance Microsoft AD gérée :
```
gcloud projects add-iam-policy-binding [PROJECT_ID] \
--member=serviceAccount:SERVICE_ACCOUNT --role=roles/managedidentities.sqlintegrator
```

Activer l'authentification Windows dans plusieurs projets

Vous pouvez effectuer l'intégration à un domaine AD dans un autre projet à l'aide des commandes gcloud ou de l'API REST Cloud SQL. Dans les deux cas, vous devez spécifier le nom complet de la ressource de domaine.

Spécifiez le nom complet de la ressource de domaine lorsqu'une instance Cloud SQL pour SQL Server est créée ou mise à jour. Deux formats sont acceptés :

projects/PROJECT_ID/locations/global/domains/DOMAIN_NAME
projects/PROJECT_NUMBER/locations/global/domains/DOMAIN_NAME

Voici un exemple utilisant la méthode gcloud :

gcloud beta sql instances patch INSTANCE_NAME \
--active-directory-domain=projects/PROJECT_ID/locations/global/domains/DOMAIN_NAME

Si vous utilisez un nom de ressource de domaine court (tel que DOMAIN_NAME), le système suppose que votre domaine Microsoft AD géré se trouve dans le même projet que vos instances Cloud SQL pour SQL Server.

Contraintes de l'intégration dans différents projets

Si vous intégrez un domaine AD géré dans un projet différent, les contraintes suivantes s'appliquent :

Jusqu'à 10 réseaux avec des instances Cloud SQL pour SQL Server peuvent partager une instance Microsoft AD gérée située dans un autre projet.
Google Cloud Console n'accepte que les instances Microsoft AD gérées situées dans le même projet. Au lieu d'utiliser Google Cloud Console, vous pouvez procéder à l'intégration à l'aide des commandes gcloud ou de l'API REST Cloud SQL.
Si vous utilisez VPC Service Controls, les instances Cloud SQL pour SQL Server et l'instance Microsoft AD gérée doivent se trouver dans le même périmètre.

En outre, si une instance est intégrée à un domaine AD géré dans un projet différent, le nom de domaine complet affiché dans la console Google Cloud peut être inexact pour cette instance. Plus précisément, sur la page Présentation de cette instance, sous Se connecter à cette instance, les noms de domaine complets peuvent contenir des chaînes séparées par des barres obliques, que vous pouvez ignorer. Par exemple, un nom de domaine complet inexact peut apparaître comme suit :

private.myinstance.myregion.myproject.projects/mydirectory/locations/global/domains/mydomain.com

Dans ce cas, le nom de domaine complet exact est le suivant :

private.myinstance.myregion.myproject.cloudsql.mydomain.com

Supprimer l'authentification Windows d'une instance

Vous pouvez supprimer l'authentification Windows, ainsi qu'une intégration Microsoft AD géré, sur une instance existante.

Console

Dans Google Cloud Console, accédez à la page Instances Cloud SQL.

Accéder à la page Instances Cloud SQL
Pour ouvrir la page Présentation d'une instance, cliquez sur son nom.
Cliquez sur Modifier.
Cliquez sur Authentification. Le menu déroulant permettant d'associer un domaine Active Directory géré répertorie les domaines Microsoft AD gérés préalablement ajoutés à votre projet.
Dans le menu déroulant, sélectionnez Aucun domaine/Associer plus tard pour votre instance.
Lisez le message concernant le redémarrage de l'instance, puis cliquez sur Fermer.
Cliquez sur Enregistrer pour appliquer les modifications.

gcloud

Pour supprimer une instance d'un domaine, ce qui supprime l'authentification Windows, utilisez une valeur vide pour le domaine. Autrement dit, dans votre commande, utilisez une valeur vide pour le paramètre --active-directory-domain, comme suit :

gcloud beta sql instances patch INSTANCE_NAME \
--active-directory-domain=

REST

Vous pouvez supprimer une instance d'un domaine avec l'API REST. Spécifiez une valeur vide dans le champ domain, comme suit :

{
   "settings":{
      "activeDirectoryConfig":{
         "domain":""
      }
   }
}

Se connecter à une instance avec un utilisateur

Concernant Cloud SQL pour SQL Server, l'utilisateur par défaut est sqlserver.

Après avoir intégré une instance à l'aide de Microsoft AD géré, vous pouvez vous connecter à l'instance avec l'utilisateur sqlserver, comme suit :

Créez une connexion SQL Server basée sur un utilisateur ou un groupe Windows, comme suit :
```
CREATE LOGIN [domain\user_or_group] FROM WINDOWS
```
Connectez-vous à l'instance avec son nom DNS à l'aide de l'authentification Windows. Voici quelques exemples de noms DNS d'instances que vous pouvez spécifier :
- Pour vous connecter via une adresse IP privée :
```
private.myinstance.us-central1.myproject.cloudsql.mydomain.com
```
- Pour vous connecter via une adresse IP publique :
```
public.myinstance.us-central1.myproject.cloudsql.mydomain.com
```
- Pour vous connecter via le proxy Cloud SQL Auth (voir également ci-dessous) :
```
proxy.myinstance.us-central1.myproject.cloudsql.mydomain.com
```
Si vous utilisez l'adresse IP de l'instance, vous devez configurer les clients Kerberos pour accepter les noms d'hôte IP. Cloud SQL n'est pas compatible avec les connexions provenant de domaines connectés via une relation d'approbation.

Utiliser le proxy d'authentification Cloud SQL avec l'authentification Windows

Vous pouvez utiliser le proxy d'authentification Cloud SQL avec votre intégration au service Microsoft AD géré.

Avant de commencer, lisez les articles suivants :

Étapes de l'authentification Windows

Pour en savoir plus sur le démarrage du proxy d'authentification Cloud SQL, consultez la section Démarrer le proxy d'authentification Cloud SQL.

Pour l'authentification Windows, vous devez exécuter le proxy d'authentification Cloud SQL sur le port 1433. Pour mapper une entrée de nom principal de service (SPN, "Service Principal Name") prédéfini à une adresse de proxy d'authentification Cloud SQL, utilisez :

proxy.[instance].[location].[project].cloudsql.[domain]

Exécuter localement le proxy d'authentification Cloud SQL

Si vous exécutez localement le proxy d'authentification Cloud SQL, utilisez votre fichier d'hôtes pour mapper les éléments suivants avec 127.0.0.1 :

proxy.[instance].[location].[project].cloudsql.[domain]

Par exemple, vous pouvez ajouter les éléments suivants au fichier d'hôtes (par exemple, dans c:\windows\system32\drivers\etc\hosts) :

127.0.0.1 proxy.[instance].[location].[project].cloudsql.[domain]

Dans cet exemple, vous pouvez exécuter le proxy d'authentification Cloud SQL à l'aide de cette commande et le rendre disponible sur 127.0.0.1:1433 :

cloud-sql-proxy.exe --credentials-file credential.json project:name

Exécuter le proxy d'authentification Cloud SQL de manière non locale

Pour exécuter le proxy d'authentification Cloud SQL de manière non locale, suivez les instructions de la section Exécuter localement le proxy d'authentification Cloud SQL, mais utilisez une entrée différente dans le fichier d'hôtes.

Plus précisément, si un hôte non local est, par exemple, MyOtherHost, vous pouvez ajouter la ligne suivante au fichier d'hôtes :

127.0.0.1 MyOtherHost proxy.[instance].[location].[project].cloudsql.[domain]

Résoudre les problèmes de recours NTLM dans les clients

Si vous utilisez l'authentification Windows et une adresse IP d'instance pour vous connecter à une instance, vous devez configurer un client Kerberos compatible avec les noms d'hôte IP.

Cloud SQL n'est pas compatible avec l'authentification NTLM, mais certains clients Kerberos peuvent néanmoins tenter de l'utiliser comme solution de remplacement. Comme indiqué dans cette section, si vous essayez de vous connecter à SQL Server Management Studio (SSMS) et que le message d'erreur suivant apparaît, cela est probablement due à un recours NTLM :

Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication. (Microsoft SQL Server, Error: 18452)

NTLM est un ensemble de protocoles de sécurité Microsoft pour l'authentification. Consultez également la section Motifs de recours NTLM.

Vérification d'un recours NTLM pour un client Windows

Sur Windows, pour vérifier qu'un remplacement NTLM a entraîné une erreur :

Connectez-vous avec les identifiants sur site de votre choix (n'utilisez pas "Exécuter en tant que…").
Ouvrez une invite de commande.
Exécutez klist purge.
À partir de SSMS, essayez de vous connecter à SQL Server avec l'authentification Windows.
Exécutez klist et vérifiez si un ticket est émis pour "MSSQLSvc/<address>:1433 @ domain".
Si ce n'est pas le cas, le remplacement NTLM est la cause de l'erreur.
Dans ce cas, vérifiez que votre pilote SQL Server n'applique pas l'authentification NTLM. Vérifiez également si l'authentification NTLM est appliquée via la stratégie de groupe.

Vérification d'un recours NTLM pour un client Linux

Sur Ubuntu 16.04, pour vérifier qu'un remplacement NTLM a entraîné une erreur, suivez les étapes décrites dans cette section. Les étapes sont similaires à celles des autres distributions Linux.

Configurer l'authentification Kerberos

Configurez un client Kerberos :
```
sudo apt-get install krb5-user
```
Lorsque vous êtes invité à renseigner le domaine par défaut, saisissez un nom de domaine sur site en lettres majuscules.

Exécutez la commande suivante pour installer les outils de ligne de commande SQL Server :

curl https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -
curl https://packages.microsoft.com/config/ubuntu/16.04/prod.list | sudo tee /etc/apt/sources.list.d/msprod.list
sudo apt-get update
sudo apt-get install mssql-tools unixodbc-dev

Se connecter avec l'authentification Windows

Exécutez l'outil kinit comme suit : kinit <user_account>
Pour vous connecter avec l'authentification Windows, exécutez la commande suivante : /opt/mssql-tools/bin/sqlcmd -S <address >>
Exécutez la commande klist et vérifiez si un ticket a été émis spécifiquement pour : "MSSQLSvc/<address>:1433 @ domain"
Si le ticket n'a pas été émis, l'erreur ci-dessus indique probablement un problème entraînant le recours NTLM.

Motifs de recours NTLM

Le recours NTLM est une erreur de configuration client pouvant être associée aux conditions suivantes :

Par défaut, Windows ne tente pas l'authentification Kerberos pour un hôte si le nom d'hôte est une adresse IP. Pour activer l'authentification Kerberos à partir du domaine géré, essayez la méthode décrite dans la documentation Microsoft. Cette méthode ne fonctionne pas avec les identifiants sur site lorsque vous devez utiliser le nom de domaine complet (FQDN).
L'authentification Kerberos ne fonctionne pas sur les approbations externes. Utilisez plutôt les approbations de forêts, comme décrit ici.
L'authentification Kerberos nécessite un routage des suffixes de noms pour permettre la recherche de services dans une autre forêt. Essayez la méthode décrite ici.
L'authentification Kerberos ne fonctionne pas si aucun SPN n'est enregistré pour le service. Utilisez uniquement des noms de domaine complets ou des adresses IP obtenus à partir de la console Google Cloud pour vous connecter via l'authentification Windows.

Utilisateurs AD sur site : créer une connexion Windows

Vous pouvez utiliser un utilisateur AD sur site pour créer une connexion Windows à Cloud SQL pour SQL Server.

Vous pouvez par exemple vous connecter à l'aide de SQL Server Management Studio (SMSS) s'exécutant sur une VM Windows hébergée dans le cloud privé virtuel (VPC) de votre projet Google Cloud.

Pour l'authentification Windows dans ce contexte, Cloud SQL pour SQL Server n'est compatible qu'avec le protocole Kerberos. Pour l'authentification Windows basée sur Kerberos, le client doit résoudre le nom DNS du service AD sur site et du service Microsoft AD géré.

Configurer une approbation unidirectionnelle ou bidirectionnelle

Dans un premier temps, décidez si vous souhaitez utiliser une relation d'approbation unidirectionnelle ou bidirectionnelle.

Suivez ensuite les instructions permettant d'établir une approbation entre le domaine AD sur site et le domaine Microsoft AD géré.

Une fois que vous avez établi une approbation entre le domaine AD sur site et le domaine Microsoft AD géré, procédez comme suit : À titre d'exemple, ces étapes utilisent SQL Server Management Studio (SSMS) s'exécutant sur une VM Windows, hébergée dans le VPC de votre projet Google Cloud :

Créez une VM Windows.
- Créez une VM avec une version de Windows compatible avec le service Microsoft AD géré.
- Créez la VM dans le projet qui héberge votre domaine Microsoft AD géré. S'il existe un VPC partagé qui est un réseau autorisé, vous pouvez également créer la VM dans l'un de ses projets de service.
- Créez la VM sur un réseau VPC qui est un réseau autorisé du domaine Microsoft AD géré et qui a configuré l'accès aux services privés pour Cloud SQL.
Associez la VM Windows au domaine Microsoft AD géré.
Installez SSMS sur la VM Windows.
Résolvez le domaine sur site dans le réseau VPC.
- Depuis le réseau autorisé sur lequel la VM Windows est en cours d'exécution, activez la résolution DNS sur site en suivant la procédure décrite sur la page Résoudre les requêtes portant sur des objets autres que des objets Managed Microsoft AD. Les étapes décrites sur cette page sont des conditions requises pour que l'authentification Windows basée sur Kerberos puisse fonctionner pour les utilisateurs sur site.
Créez une connexion Windows pour un utilisateur sur site.
- Suivez les instructions CREATE LOGIN pour créer une connexion Windows pour un utilisateur sur site. Par exemple, spécifiez une commande semblable à celle-ci :
```
CREATE LOGIN [DOMAIN_NAME\USER_NAME] FROM WINDOWS
```
Connectez-vous à votre instance Cloud SQL pour SQL Server en suivant les instructions spécifiques à l'application pour la connexion d'un utilisateur sur site. Par exemple, si vous utilisez SQL Server Management Studio, reportez-vous à ces instructions.

Si un problème survient lors de la connexion à une instance Cloud SQL pour SQL Server, effectuez les vérifications suivantes :

Vérifiez la configuration des pare-feu du réseau sur site et du VPC autorisé par le projet. Pour ce faire, suivez les instructions pour Créer une approbation avec un domaine sur site.
Vérifiez le routage de suffixes de nom pour la relation d'approbation sur site.
Vérifiez que vous pouvez effectuer ces opérations de résolution DNS à partir de la VM Windows qui exécute SSMS :
- nslookup fqdn-for-managed-ad-domain
- nslookup fqdn-for-on-premises-ad-domain
- nslookup fqdn-for-cloud-sql-server-instance

Astuces

Une instance avec une adresse IP publique est compatible, à condition qu'elle possède également une adresse IP privée. L'adresse IP privée doit être activée pour l'instance. Vous pouvez ensuite choisir d'utiliser l'adresse IP publique ou l'adresse IP privée pour vous connecter à l'instance, tant que les deux sont disponibles.
Avant de créer une instance, y compris en tant qu'instance de remplacement, consultez les sections suivantes selon vos besoins :
- En savoir plus sur l'utilisation des adresses IP privées
- Configurer une adresse IP publique
Terraform est compatible.
Si vous recevez l'une des erreurs suivantes, vérifiez que vous remplissez toutes les conditions préalables à l'intégration
- "Le compte de service par produit et par projet est introuvable"
- "Autorisations insuffisantes pour l'intégration au service géré pour le domaine Microsoft Active Directory"
Si vous recevez le message d'erreur "Domaine introuvable", vérifiez que le nom de domaine, qui est sensible à la casse, est correctement orthographié.
Si l'authentification Windows échoue depuis un domaine connecté via une relation d'approbation, vérifiez que l'authentification Windows fonctionne pour un utilisateur issu d'un domaine géré. Si tel est le cas, procédez comme suit :
1. Vérifiez que vous avez utilisé un nom DNS. Les adresses IP ne sont pas acceptées pour les domaines connectés via une relation d'approbation.
2. Assurez-vous d'avoir suivi toutes les étapes de création d'une approbation avec un domaine sur site, y compris l'ouverture de tous les ports de pare-feu.
3. Validez l'approbation.
4. Vérifiez que la direction de l'approbation permet aux utilisateurs du domaine (connectés via une relation d'approbation) de s'authentifier dans le domaine géré.
5. Vérifiez que le routage de suffixes de noms est défini sur le domaine connecté via une relation d'approbation.
6. Vérifiez que l'approbation fonctionne sans utiliser Cloud SQL pour SQL Server :
  1. Créez une VM Windows.
  2. Associez-la au domaine Microsoft AD géré.
  3. Essayez, par exemple, d'exécuter "Bloc-notes" en tant qu'utilisateur du domaine connecté via une relation d'approbation.
7. Redémarrez la VM cliente et testez à nouveau l'authentification Windows.
Vous pouvez tenter de créer une connexion SQL Server, mais recevoir le message d'erreur suivant : "Domaine/nom d'utilisateur ou de groupe Windows NT introuvable. Vérifiez le nom à nouveau". Cela peut être dû au fait que les groupes locaux à un domaine ne sont pas acceptés. Le cas échéant, utilisez plutôt des groupes globaux ou universels.
Les requêtes SQL Server peuvent générer l'erreur suivante lorsqu'elles sont émises par un utilisateur en provenance d'un domaine connecté via une relation d'approbation : "Impossible de récupérer des informations sur le groupe/l'utilisateur Windows NT". Cette erreur peut se produire, par exemple, si vous créez des connexions à partir de domaines connectés via une relation d'approbation. L'erreur peut également se produire si vous accordez des privilèges aux connexions provenant de domaines 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.
Si le message d'erreur "Impossible de récupérer des informations sur le groupe/l'utilisateur Windows NT" s'affiche, vérifiez la connectivité réseau aux domaines sur site à l'aide du fichier journal active_directory.log disponible dans Cloud Logging pour les instances Cloud SQL pour SQL Server. Ce fichier contient les diagnostics suivants concernant les modifications de connectivité sur le domaine sur site :

Remarque : Les horodatages du fichier sont exprimés en heure locale.
- Domaines sur site approuvés par l'instance Cloud SQL pour SQL Server. Par exemple, le journal suivant montre comment passer de l'absence de domaines de confiance à deux nouveaux domaines de confiance en tant que noms NetBIOS, ONPREM et CHILD :
```
2023-06-12 20:55:09.975 Detected change in trusted onprem domains: Previously trusted onprem domains: []. Current trusted onprem domains: [ONPREM CHILD]
```
  Si un domaine sur site n'apparaît pas ou n'est pas approuvé, vérifiez si l'approbation existe avec le domaine AD géré et est validée. S'il existe une approbation unidirectionnelle entre le domaine AD géré et le domaine sur site, les autres domaines sur site approuvés par le domaine sur site peuvent ne pas être visibles.
- Domaines sur site accessibles et inaccessibles à l'aide d'un ping standard depuis l'instance Cloud SQL pour SQL Server. Par exemple, le journal suivant montre comment passer de l'absence de domaines accessibles à deux nouveaux domaines accessibles, onprem.com et child.onprem.com :
```
2023-06-12 20:55:10.664 Detected change in reachable onprem domains: Previously reachable onprem domains: []. Current reachable onprem domains: [onprem.com child.onprem.com]
```
  Si un domaine n'apparaît pas dans les journaux de joignabilité, assurez-vous d'abord qu'il est enregistré en tant que domaine approuvé. Sinon, son accessibilité ne sera pas vérifiée. Nous avons toujours un appairage de VPC entre un projet avec des instances sur site et des projets Google Cloud. Le fait d'avoir au moins un appairage VPC intègre une connexion d'appairage transitif, qui n'est pas compatible avec Cloud SQL. À la place, nous vous recommandons d'utiliser un tunnel VPN pour connecter un domaine sur site à Cloud SQL. Il doit y avoir au maximum une connexion d'appairage entre le projet sur site et le projet Google Cloud avec les instances Cloud SQL pour SQL Server.
- Un appel de procédure à distance Microsoft (MSRPC) réussi ou échoué pingue vers les domaines sur site à partir de l'instance Cloud SQL pour SQL Server. Par exemple, le journal suivant montre comment passer de l'absence de domaines pouvant être pingués par un MSRPC à deux domaines pouvant être pingués par un MSRPC, ONPREM et CHILD :
```
2023-06-12 20:55:10.664 Detected change in MSRPC pingable domains: Previously pingable onprem domains: []. Current pingable onprem domains: [ONPREM CHILD]
```
  Les pings MSRPC sont inclus en tant que diagnostics supplémentaires et peuvent ne pas fonctionner sur certaines configurations. Vous pouvez toujours valider la connectivité du domaine sur site en effectuant les deux premiers diagnostics.
Si les requêtes SQL Server génèrent l'erreur "La connexion provient d'un domaine non approuvé", notez que les adresses IP ne sont pas disponibles pour les utilisateurs des domaines connectés via une relation d'approbation. Les actions suivantes peuvent également résoudre ce problème :
- Si une adresse IP est utilisée pour connecter des utilisateurs à partir d'un domaine géré, suivez ces instructions.
- Évitez d'utiliser des proxys, et utilisez toujours le même nom DNS (tel que vous le voyez dans Google Cloud Console) pour vous connecter à Cloud SQL pour SQL Server.
- Supprimez les tickets Kerberos existants. L'erreur ci-dessus peut se produire si vous avez récemment fait l'expérience d'un client connecté à une instance Cloud SQL pour SQL Server qui a été arrêtée puis redémarrée. L'erreur peut également se produire si l'authentification Windows a été désactivée puis réactivée pour l'instance Cloud SQL pour SQL Server. Si le client utilise le cache des identifiants Windows, verrouillez et déverrouillez le poste de travail client, ou exécutez klist purge.
Une tentative d'activation de l'authentification Windows peut entraîner l'erreur suivante : "Cette instance aurait besoin d'une date de création plus récente pour la prise en charge du service géré pour Microsoft Active Directory." Prenez en compte les informations suivantes concernant cette erreur :
- Dans Cloud SQL, si une instance Cloud SQL pour SQL Server a été créée le 12 mars 2021 ou avant, elle ne peut pas être intégrée au service Microsoft AD géré.
- Dans certains cas, si vous créez une instance Cloud SQL pour SQL Server et n'activez pas le service Microsoft AD géré lors de la création, vous pouvez recevoir la même erreur. Après avoir examiné les autres conseils de cette section, créez une nouvelle instance en activant le service Microsoft AD géré au moment de créer l'instance.
Toute tentative de création d'une instance Cloud SQL pour SQL Server peut entraîner l'erreur "Cette instance n'est pas compatible avec le service géré pour Microsoft Active Directory". Si vous recevez cette erreur, il est possible que le projet ne soit pas compatible : essayez d'utiliser un autre projet.
Si une instance présente des problèmes continus avec l'authentification Windows (que l'instance ait été mise à jour récemment ou non), essayez de dissocier le domaine Active Directory géré, puis de le rejoindre à nouveau. Pour ce faire, suivez la procédure de mise à jour pour quitter puis rejoindre à nouveau le domaine. Cette action ne supprime pas les utilisateurs Windows authentifiés ou les connexions existant dans vos bases de données. Toutefois, la suppression de l'authentification Windows entraîne un redémarrage de l'instance.
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.

Résoudre les problèmes

Cliquez sur les liens du tableau pour en savoir plus :

Pour cette erreur...	Le problème peut être...	Essayez ce qui suit...
`Per-product, per-project service account not found.`	Le nom du compte de service est incorrect.	Sur la page Comptes de service, vérifiez que vous avez créé un compte de service pour le bon projet utilisateur.
`Insufficient permission to integrate with Managed Service for Microsoft Active Directory domain.`	Le rôle `managedidentities.sqlintegrator` n'est pas spécifié sur le compte de service.	Sur la page IAM et administration, ajoutez le rôle `managedidentities.sqlintegrator` sur votre compte de service.
`Domain not found`.	Le domaine n'existe pas ou comporte une faute de frappe.	Assurez-vous que le nom du domaine est correct. Ce champ est sensible à la casse.
`The domain is busy with another operation. Please retry.`	Une autre instance Cloud SQL exécute une opération sur le même domaine Active Directory géré.	Effectuez une nouvelle tentative. Si vous effectuez un lot de mises à jour sur des instances Cloud SQL connectées au même domaine, limitez le nombre de tâches en parallèle.
`The operation completed but an update to Active Directory failed. You may experience issues with Windows Authentication on this instance, please see https://cloud.google.com/sql/docs/sqlserver/configure-ad for tips`.	Les mises à jour requises n'ont pas pu être effectuées sur le domaine Active Directory géré.	Si vous rencontrez des problèmes avec l'authentification Windows, vous pouvez essayer de dissocier le domaine Active Directory géré, puis de le rejoindre à nouveau. Pour ce faire, suivez la procédure de mise à jour pour quitter puis rejoindre à nouveau le domaine. Cette action ne supprime pas les utilisateurs Windows authentifiés ou les connexions existant dans vos bases de données. Toutefois, la suppression de l'authentification Windows entraîne un redémarrage de l'instance.
`This instance would need a more recent creation date to support Managed Service for Microsoft Active Directory.`	Dans Cloud SQL, si une instance Cloud SQL pour SQL Server a été créée le 12 mars 2021 ou avant, elle ne peut pas être intégrée au service Microsoft AD géré.	Essayez d'effectuer votre opération sur une instance créée après le 12 mars 2021.

Étape suivante

Vérifiez que vous avez entièrement lu la page de présentation, qui inclut les limites et les fonctionnalités non compatibles. Cette page contient également des liens vers de la documentation supplémentaire.

Utiliser le service Microsoft AD géré avec Cloud SQL

Avant de commencer

Créer une instance avec l'authentification Windows

Console

gcloud

Terraform

REST

Mettre à jour une instance avec l'authentification Windows

Console

gcloud

REST

Intégrer une instance à un domaine AD géré dans un autre projet

Activer l'appairage de domaines

Créer un compte de service

Activer l'authentification Windows dans plusieurs projets

Contraintes de l'intégration dans différents projets

Supprimer l'authentification Windows d'une instance

Console

gcloud

REST

Se connecter à une instance avec un utilisateur

Utiliser le proxy d'authentification Cloud SQL avec l'authentification Windows

Étapes de l'authentification Windows

Exécuter localement le proxy d'authentification Cloud SQL

Exécuter le proxy d'authentification Cloud SQL de manière non locale

Résoudre les problèmes de recours NTLM dans les clients

Vérification d'un recours NTLM pour un client Windows

Vérification d'un recours NTLM pour un client Linux

Configurer l'authentification Kerberos

Se connecter avec l'authentification Windows

Motifs de recours NTLM

Utilisateurs AD sur site : créer une connexion Windows

Configurer une approbation unidirectionnelle ou bidirectionnelle

Configurer une VM Windows et créer une connexion Windows

Résoudre les problèmes liés à un utilisateur AD sur site

Astuces

Résoudre les problèmes

Étape suivante