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 Google Cloud Console, 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. Installer et initialiser le SDK Cloud.
  4. Assurez-vous que vous disposez du rôle d'administrateur Cloud SQL sur votre compte utilisateur. Accéder à 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é.

Console

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

    Accéder à la page Instances Cloud SQL

  2. Cliquez sur Create instance (Créer une instance).
  3. Cliquez sur Choisir SQL Server.
  4. 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).
  5. Saisissez le mot de passe de l'utilisateur 'sqlserver'.
  6. Définissez la région de l'instance. Consultez les bonnes pratiques pour l'intégration à Microsoft AD géré.
  7. Dans la section Options de configuration, définissez les options que vous souhaitez, mais attendez l'étape suivante pour les options d'authentification.
  8. 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.
  9. Dans le menu déroulant permettant de joindre un domaine Active Directory géré, sélectionnez un domaine.
  10. 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

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 Active Directory géré, l'instance est initialement dissociée de ce domaine avant qu'elle ne soit associée au nouveau domaine. Si la mise à jour échoue, l'instance risque de ne plus être associée à aucun domaine.

Console

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

    Accéder à la page Instances Cloud SQL

  2. Cliquez sur le nom de l'instance pour ouvrir la page Présentation.
  3. Cliquez sur Modifier.
  4. Cliquez sur Authentification. Le menu déroulant Rejoindre un domaine Active Directory vous donne la liste de tous les domaines Microsoft AD gérés précédemment ajoutés à votre projet.
  5. Dans le menu déroulant permettant d'associer un domaine Active Directory géré, sélectionnez un nouveau domaine (remplacement) pour votre instance.
  6. 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"
      }
   }
}

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

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

    Accéder à la page Instances Cloud SQL

  2. Cliquez sur le nom de l'instance pour ouvrir la page Présentation.
  3. Cliquez sur Modifier.
  4. 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.
  5. Dans le menu déroulant, sélectionnez Aucun domaine/Associer plus tard pour votre instance.
  6. Lisez le message concernant le redémarrage de l'instance, puis cliquez sur Fermer.
  7. 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 :

  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, les clients Kerberos doivent être configurés pour être compatibles avec les noms d'hôte IP. La connexion avec une adresse IP n'est pas acceptée en provenance 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, le proxy d'authentification Cloud SQL doit s'exécuter sur le port 1433. Vous devez mapper une entrée de nom principal de service (SPN, Service Principal Name) prédéfinie à une adresse de proxy d'authentification Cloud SQL :

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_x64.exe -credential_file credential.json  -instances=project:name=tcp:1433

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, un client Kerberos doit être configuré pour accepter les noms d'hôte IP.

L'authentification NTLM n'est pas prise en charge, mais certains clients Kerberos peuvent néanmoins tenter d'y recourir. 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

À partir de Windows, pour vérifier que l'erreur ci-dessus est due à un recours NTLM, procédez comme suit :

  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, l'erreur est probablement due à un recours NTLM.
  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

Depuis Ubuntu 16.04, pour vérifier que l'erreur ci-dessus est causée par un recours NTLM, 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 ici. Cette méthode ne fonctionne pas avec les identifiants sur site lorsque des noms de domaine complets doivent être utilisés.
  • 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 Google Cloud Console 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 pour les objets AD non gérés dans les réseaux VPC. 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.

Si un problème survient lors d'une connexion à une instance 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.
  • 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 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 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 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." Veuillez noter les points suivants :
    • 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é.
  • Toute tentative de création d'une instance 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.

Dépannage

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 de domaine est correct et existe dans le même projet utilisateur. 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 SQL Server a été créée le 12 mars 2021 ou avant, elle ne peut pas être intégrée à 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.