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

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

1. Dans la console Google Cloud, sélectionnez le nom de votre projet.
2. 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.
3. Installez et initialisez gcloud CLI.
4. Assurez-vous que vous disposez du rôle Cloud SQL Admin sur votre compte utilisateur. Accédez à la page IAM.
5. 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.

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

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

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
}

{
   "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.

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

{
   "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.

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.

1. Consultez les informations générales pour créer des comptes de service.

2. 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]

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

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

{
   "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 :

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

2. 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 :

• À propos du proxy d'authentification Cloud SQL

• Se connecter à l'aide du proxy d'authentification Cloud SQL

É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 :

1. Connectez-vous avec les identifiants sur site de votre choix (n'utilisez pas "Exécuter en tant que…").
2. Ouvrez une invite de commande.
3. Exécutez klist purge.
4. À partir de SSMS, essayez de vous connecter à SQL Server avec l'authentification Windows.
5. Exécutez klist et vérifiez si un ticket est émis pour "MSSQLSvc/<address>:1433 @ domain".
6. Si ce n'est pas le cas, le remplacement NTLM est la cause de l'erreur.
7. 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

1. Configurez un client Kerberos :

   sudo apt-get install krb5-user
   

2. Lorsque vous êtes invité à renseigner le domaine par défaut, saisissez un nom de domaine sur site en lettres majuscules.

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

1. Exécutez l'outil kinit comme suit : kinit <user_account>
2. Pour vous connecter avec l'authentification Windows, exécutez la commande suivante : /opt/mssql-tools/bin/sqlcmd -S <address >>
3. Exécutez la commande klist et vérifiez si un ticket a été émis spécifiquement pour : "MSSQLSvc/<address>:1433 @ domain"
4. 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é.

Configurer une VM Windows et créer une connexion Windows

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 :

1. 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.
2. Associez la VM Windows au domaine Microsoft AD géré.
3. Installez SSMS sur la VM Windows.
4. 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.

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

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

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

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

Conseils

• 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 :

  • 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 qu'elle est validée. Si une approbation unidirectionnelle existe entre le domaine AD géré et le domaine sur site, il est possible que les autres domaines sur site approuvés par le domaine sur site ne soient pas 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. Un appairage de VPC est toujours effectué 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. Nous vous recommandons plutôt d'utiliser un tunnel VPN pour connecter un domaine sur site à Cloud SQL. Une connexion d'appairage au moins doit exister 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 vérifier la connectivité du domaine sur site via 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 :

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