Usar Microsoft AD gestionado con Cloud SQL

En esta página se describen las formas de usar Cloud SQL para hacer lo siguiente:

• Integración con el servicio gestionado de Microsoft Active Directory (también llamado Managed Microsoft AD).
• Conéctate a una instancia con un usuario de AD.

Una instancia de Cloud SQL integrada con Microsoft AD gestionado admite la autenticación de Windows, además de la autenticación de SQL.

Antes de empezar

1. En la Google Cloud consola, selecciona el nombre de tu proyecto.
2. Comprueba que la facturación esté habilitada en tu Google Cloud proyecto. Consulta cómo confirmar que la facturación está habilitada en tu proyecto.
3. Instala e inicializa gcloud CLI.
4. Asegúrate de que tienes el rol Cloud SQL Admin en tu cuenta de usuario. Ve a la página de gestión de identidades y accesos.
5. Consulta los requisitos previos para la integración.

Crear una instancia con autenticación de Windows

Puedes integrar Managed Microsoft AD durante la creación de la instancia, lo que permite la autenticación de Windows en la instancia. Para integrar, elige un dominio al que se unirá la instancia. Si no se puede unir a un dominio, no se podrá crear la instancia.

Antes de crear una instancia con autenticación de Windows, consulta los consejos y las limitaciones y alternativas.

Se admite una instancia con IP pública, siempre que también tenga una IP privada. La IP privada debe estar habilitada en la instancia. Después, puedes elegir si quieres usar una IP pública o una IP privada para conectarte a la instancia, siempre que ambas estén disponibles.

Estas son las opciones para crear una instancia integrada con Microsoft AD gestionado.

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"
      }
   }
}

Actualizar una instancia con autenticación de Windows

Puede actualizar el dominio de una instancia, cambiarlo o añadir uno.

Para obtener información general sobre cómo actualizar una instancia, consulta el artículo Editar instancias.

Si una instancia está unida a un dominio de Managed AD, primero se desunirá de ese dominio antes de unirse al nuevo. Si la actualización falla, es posible que la instancia ya no esté unida a ningún dominio.

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

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

Integrar con un dominio de AD gestionado en otro proyecto

Puedes integrar tu instancia con un dominio de Microsoft AD gestionado que esté en otro proyecto.

Cuando planifiques tu integración, consulta las restricciones.

Habilitar el emparejamiento de dominios

Antes de seguir los pasos que se indican en las secciones siguientes, habilita el peering de dominio para que tu dominio esté disponible en todos los proyectos necesarios con instancias de Cloud SQL para SQL Server.

Para ver una lista de los dominios de otros proyectos que ya están disponibles, puedes especificar lo siguiente:

`gcloud active-directory peerings list`

Para obtener más información, consulta Listar las conexiones entre dominios.

El comando gcloud active-directory peerings list requiere el permiso managedidentities.peerings.list. Los siguientes roles tienen este permiso:

• roles/managedidentities.peeringViewer
• roles/managedidentities.viewer

Para obtener más información, consulta Control de acceso con IAM.

Crear una cuenta de servicio

Repite estos pasos con cada proyecto que contenga una instancia de Cloud SQL para SQL Server que quieras integrar.

1. Consulta la información general para crear cuentas de servicio.

2. Usa un comando similar al siguiente para crear una cuenta de servicio. Especifica el ID del proyecto que contiene las instancias de Cloud SQL para SQL Server:

   gcloud beta services identity create --service=sqladmin.googleapis.com \
   --project=[PROJECT_ID]

3. Concede el rol managedidentities.sqlintegrator en el proyecto que contiene la instancia de Microsoft AD gestionado. Especifica el ID del proyecto que contiene la instancia de Managed Microsoft AD:

   gcloud projects add-iam-policy-binding [PROJECT_ID] \
   --member=serviceAccount:SERVICE_ACCOUNT --role=roles/managedidentities.sqlintegrator

Habilitar la autenticación de Windows entre proyectos

Puede integrar un dominio de AD en otro proyecto mediante comandos de gcloud o la API REST de Cloud SQL. En cualquier caso, debe especificar el nombre de recurso de dominio completo.

Especifica el nombre de recurso de dominio completo cuando se cree o se actualice una instancia de Cloud SQL para SQL Server. Se admiten dos formatos:

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

A continuación, se muestra un ejemplo con gcloud:

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

Si usas un nombre de recurso de dominio corto (como DOMAIN_NAME), el sistema asume que tu dominio de Microsoft AD gestionado está en el mismo proyecto que tus instancias de Cloud SQL para SQL Server.

Restricciones para integrar con diferentes proyectos

Si vas a integrar un dominio de AD gestionado en otro proyecto, se aplican las siguientes restricciones:

• Hasta 10 redes con instancias de Cloud SQL para SQL Server pueden compartir una instancia de Microsoft AD gestionado ubicada en otro proyecto.
• La consola Google Cloud solo admite instancias de Microsoft AD gestionado ubicadas en el mismo proyecto. En lugar de usar la consola de Google Cloud , puedes integrar comandos de gcloud o la API REST de Cloud SQL.
• Si se usan Controles de Servicio de VPC, las instancias de Cloud SQL para SQL Server y una instancia de Microsoft AD gestionado deben estar ubicadas en el mismo perímetro.

Además, si una instancia está integrada con un dominio de AD gestionado en un proyecto diferente, el nombre de dominio completo (FQDN) que se muestra en la consolaGoogle Cloud puede no ser preciso para esa instancia. En concreto, en la página Resumen de esa instancia, en Conectarse a esta instancia, los FQDNs pueden contener cadenas separadas por barras, que puedes ignorar. Por ejemplo, un FQDN incorrecto podría mostrarse de la siguiente manera:

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

En ese caso, el FQDN correcto es:

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

Quitar la autenticación de Windows de una instancia

Puedes quitar la autenticación de Windows y, por lo tanto, una integración de Microsoft AD gestionado de una instancia ya creada.

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

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

Conectarse a una instancia con un usuario

En Cloud SQL para SQL Server, el usuario predeterminado es sqlserver.

Después de integrar una instancia con Managed Microsoft AD, puedes conectarte a la instancia con el usuario sqlserver de la siguiente manera:

1. Crea un inicio de sesión de SQL Server basado en un usuario o grupo de Windows de la siguiente manera:

   CREATE LOGIN [domain\user_or_group] FROM WINDOWS

2. Inicia sesión en la instancia mediante la autenticación de Windows con el nombre DNS de la instancia. Estos son algunos ejemplos de nombres DNS de instancias que puedes especificar:

   • Para conectarte a través de una IP privada, sigue estos pasos:

     private.myinstance.us-central1.myproject.cloudsql.mydomain.com

   • Para conectarte a través de una IP pública, sigue estos pasos:

     public.myinstance.us-central1.myproject.cloudsql.mydomain.com

   • Para conectarse a través del proxy de autenticación de Cloud SQL (consulta también la sección más abajo):

     proxy.myinstance.us-central1.myproject.cloudsql.mydomain.com

   Si usas la dirección IP de la instancia, debes configurar los clientes de Kerberos para que admitan nombres de host IP. Cloud SQL no admite inicios de sesión desde dominios conectados mediante una relación de confianza.

Usar el proxy de autenticación de Cloud SQL con la autenticación de Windows

Puedes usar el proxy de autenticación de Cloud SQL con tu integración de Microsoft AD gestionado.

Antes de empezar, consulta lo siguiente:

• Información sobre el proxy de autenticación de Cloud SQL

• Conectarse mediante el proxy de autenticación de Cloud SQL

Pasos para la autenticación de Windows

Para obtener información general sobre cómo iniciar el proxy de autenticación de Cloud SQL, consulta Iniciar el proxy de autenticación de Cloud SQL.

Para la autenticación de Windows, debes ejecutar el proxy de autenticación de Cloud SQL en el puerto 1433. Para asignar una entrada de nombre principal de servicio (SPN) predefinida a una dirección del proxy de autenticación de Cloud SQL, usa lo siguiente:

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

Ejecutar el proxy de autenticación de Cloud SQL de forma local

Si ejecutas el proxy de autenticación de Cloud SQL de forma local, usa el archivo de hosts para asignar lo siguiente a 127.0.0.1:

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

Por ejemplo, puedes añadir lo siguiente al archivo hosts (por ejemplo, a c:\windows\system32\drivers\etc\hosts):

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

En ese ejemplo, podrías ejecutar el proxy de autenticación de Cloud SQL con este comando y hacer que esté disponible en 127.0.0.1:1433:

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

Ejecutar el proxy de autenticación de Cloud SQL de forma no local

Para ejecutar el proxy de autenticación de Cloud SQL de forma no local, sigue las instrucciones de Ejecutar el proxy de autenticación de Cloud SQL de forma local, pero usa una entrada diferente en el archivo hosts.

En concreto, si un host no local es, por ejemplo, MyOtherHost, podrías añadir lo siguiente al archivo hosts:

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

Solucionar problemas de fallback de NTLM en clientes

Si usas la autenticación de Windows y una dirección IP de instancia para iniciar sesión en una instancia, debes configurar un cliente de Kerberos para que admita nombres de host IP.

Cloud SQL no admite la autenticación NTLM, pero es posible que algunos clientes de Kerberos intenten usarla como alternativa. Como se explica en esta sección, si intentas conectarte con SQL Server Management Studio (SSMS) y aparece el siguiente mensaje de error, es probable que se deba a una alternativa de NTLM:

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

NTLM es un conjunto de protocolos de seguridad de Microsoft para la autenticación. Consulta también los motivos por los que se recurre a NTLM.

Verificación de una alternativa NTLM para un cliente de Windows

En Windows, para verificar que un error se ha debido a una alternativa NTLM, haz lo siguiente:

1. Inicia sesión con las credenciales locales que quieras (no uses "Ejecutar como...").
2. Abre el símbolo del sistema.
3. Ejecuta klist purge.
4. En SSMS, intenta conectarte a SQL Server con la autenticación de Windows.
5. Ejecuta klist y comprueba si se ha emitido un billete para "MSSQLSvc/<address>:1433 @ domain".
6. Si no existe, es probable que el error se deba a la alternativa NTLM.
7. Si existe un ticket de este tipo, comprueba que tu controlador de SQL Server no aplique la autenticación NTLM. Comprueba también si la autenticación NTLM se aplica mediante una directiva de grupo.

Verificación de una alternativa NTLM para un cliente Linux

En Ubuntu 16.04, para verificar si un error se ha debido a una alternativa NTLM, sigue los pasos de esta sección. Los pasos son similares a los de otras distribuciones de Linux.

Configurar la autenticación de Kerberos

1. Configura un cliente de Kerberos:

   sudo apt-get install krb5-user
   

2. Cuando se te pida el reino predeterminado, escribe un nombre de dominio local en mayúsculas.

3. Ejecuta lo siguiente para instalar las herramientas de línea de comandos de 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
   

Conectarse con la autenticación de Windows

1. Ejecuta la herramienta kinit de la siguiente manera: kinit <user_account>
2. Para conectarte con la autenticación de Windows, ejecuta el siguiente comando: /opt/mssql-tools/bin/sqlcmd -S <address >>
3. Ejecuta el comando klist y comprueba si se ha emitido una entrada específicamente para: "MSSQLSvc/<address>:1433 @ domain"
4. Si no se ha emitido el ticket, es probable que el error anterior indique un problema que provoque la activación de NTLM.

Motivos para usar NTLM como alternativa

El uso de NTLM como alternativa es un error de configuración del cliente que puede estar asociado a las siguientes condiciones:

• De forma predeterminada, Windows no intenta autenticar con Kerberos un host si el nombre de host es una dirección IP. Para habilitar la autenticación de Kerberos desde el dominio gestionado, prueba el método descrito en la documentación de Microsoft. Este método no funciona con credenciales locales cuando debes usar FQDNs.
• La autenticación de Kerberos a través de relaciones de confianza externas no funciona. En su lugar, usa las relaciones de confianza entre bosques, tal como se describe aquí.
• La autenticación de Kerberos requiere el enrutamiento de sufijos de nombres para poder encontrar servicios en otro bosque. Prueba el método que se describe aquí.
• La autenticación de Kerberos no funciona si no hay ningún SPN registrado para el servicio. Para conectarte con la autenticación de Windows, usa solo nombres de dominio completos o direcciones IP que obtengas de la Google Cloud consola.

Usuarios de AD local: crear un inicio de sesión de Windows

Puedes usar un usuario de AD local para crear un inicio de sesión de Windows en Cloud SQL para SQL Server.

Por ejemplo, puedes conectarte mediante SQL Server Management Studio (SMSS) que se ejecuta en una máquina virtual de Windows alojada en la nube privada virtual (VPC) de tu proyecto Google Cloud .

En este contexto, Cloud SQL para SQL Server solo admite el protocolo Kerberos para la autenticación de Windows. Para la autenticación de Windows basada en Kerberos, el cliente debe resolver el nombre DNS del AD local y del AD de Microsoft gestionado.

Configurar una relación de confianza unidireccional o bidireccional

Primero, decide si vas a usar una relación de confianza unidireccional o bidireccional.

A continuación, sigue las instrucciones para establecer la confianza entre el dominio de AD local y el dominio de AD de Microsoft gestionado.

Configurar una VM de Windows y crear un inicio de sesión de Windows

Una vez que hayas establecido la confianza entre el dominio de AD local y el dominio de AD de Microsoft gestionado, sigue estos pasos. Por ejemplo, para llevar a cabo estos pasos, se usa SQL Server Management Studio (SSMS), que se ejecuta en una VM de Windows alojada en la VPC de tu proyecto: Google Cloud

1. Crea una VM de Windows.
   • Crea una VM con una versión de Windows compatible con el servicio gestionado de Microsoft AD.
   • Crea la VM en el proyecto que aloja tu dominio de Microsoft AD gestionado. Si hay una VPC compartida que sea una red autorizada, también puedes crear la VM en cualquiera de sus proyectos de servicio.
   • Crea la VM en una red de VPC que sea una red autorizada del dominio de Microsoft AD gestionado y que tenga configurado el acceso al servicio privado para Cloud SQL.
2. Une la VM de Windows al dominio de Microsoft AD gestionado.
3. Instala SSMS en la VM de Windows.
4. Resuelve el dominio local en la red de VPC.
   • En la red autorizada en la que se ejecuta la VM de Windows, habilita la resolución de DNS on-premise siguiendo los pasos que se indican en la página Resolver consultas de objetos de Microsoft AD no gestionados. Los pasos de esa página son requisitos previos para que la autenticación de Windows basada en Kerberos funcione para los usuarios locales.

5. Crea un inicio de sesión de Windows para un usuario local.

   • Sigue las instrucciones para crear un inicio de sesión para crear un inicio de sesión de Windows para un usuario local. Por ejemplo, especifica un comando similar al siguiente:

   CREATE LOGIN [DOMAIN_NAME\USER_NAME] FROM WINDOWS
   

6. Inicia sesión en tu instancia de Cloud SQL para SQL Server siguiendo las instrucciones específicas de la aplicación para iniciar sesión como usuario local. Por ejemplo, si usas SQL Server Management Studio, consulta estas instrucciones.

Resolver problemas relacionados con un usuario de AD local

Si se produce un problema al iniciar sesión en una instancia de Cloud SQL para SQL Server, realiza estas comprobaciones:

• Verifica las configuraciones del cortafuegos de la red on-premise y de la VPC autorizada por el proyecto siguiendo las instrucciones para crear una relación de confianza con un dominio on-premise.
• Verifica el enrutamiento de sufijo de nombre de la relación de confianza local.
• Comprueba que puedes realizar estas operaciones de resolución de DNS desde la máquina virtual de Windows que ejecuta SSMS:
  • nslookup fqdn-for-managed-ad-domain
  • nslookup fqdn-for-on-premises-ad-domain
  • nslookup fqdn-for-cloud-sql-server-instance

Consejos

• Se admite una instancia con IP pública, siempre que también tenga una IP privada. La IP privada debe estar habilitada en la instancia. Después, puedes elegir si quieres usar una IP pública o una IP privada para conectarte a la instancia, siempre que ambas estén disponibles.
• Antes de crear una instancia, incluida una instancia de sustitución, consulta lo siguiente según sea necesario:
  • Información sobre el uso de IP privada
  • Configurar una IP pública
• Se admite Terraform.
• Si recibes uno de los siguientes errores, confirma que cumples todos los requisitos previos para la integración:
  • "No se ha encontrado la cuenta de servicio por producto y por proyecto"
  • "Permisos insuficientes para integrar con el dominio de Managed Service for Microsoft Active Directory"
• Si aparece el error "No se ha encontrado el dominio", compruebe que el nombre de dominio distingue entre mayúsculas y minúsculas y que es correcto.
• Si la autenticación de Windows falla en un dominio conectado a través de una relación de confianza, comprueba que la autenticación de Windows funciona para un usuario de un dominio gestionado. Si es así, haz lo siguiente:
  1. Comprueba que has usado un nombre DNS. No se admiten direcciones IP de dominios conectados mediante una relación de confianza.
  2. Asegúrate de haber seguido todos los pasos para crear una relación de confianza con un dominio on‐premise, incluido el de abrir todos los puertos del cortafuegos.
  3. Valida la relación de confianza.
  4. Verifica que la dirección de la confianza permita que los usuarios del dominio (conectado a través de una relación de confianza) se autentiquen en el dominio gestionado.
  5. Verifica que el enrutamiento de sufijo de nombre esté configurado en el dominio que esté conectado a través de una relación de confianza.
  6. Verifica que la confianza funciona sin usar Cloud SQL para SQL Server:
     1. Crea una VM de Windows.
     2. Únelo al dominio de Microsoft AD gestionado.
     3. Intenta ejecutar, por ejemplo, el Bloc de notas como usuario del dominio que está conectado a través de una relación de confianza.
  7. Reinicia la VM cliente y vuelve a probar la autenticación de Windows.
• Puede que intentes crear un inicio de sesión de SQL Server, pero recibas el siguiente error: "No se ha encontrado el usuario o el grupo de Windows NT domain\name. Vuelve a comprobar el nombre". Esto puede deberse a que no se admiten grupos locales de dominio. Si procede, utilice grupos globales o universales.
• Cuando un usuario de un dominio conectado a través de una relación de confianza emite consultas de SQL Server, se puede producir el siguiente error: "No se ha podido obtener información sobre el grupo o el usuario de Windows NT". Este error puede producirse, por ejemplo, si creas inicios de sesión desde dominios conectados a través de una relación de confianza. El error también puede producirse si concedes privilegios a inicios de sesión de dominios conectados a través de una relación de confianza. En estos casos, suele ser posible volver a intentar la operación. Si no funciona, cierra la conexión y abre una nueva.

• Si aparece el error "Could not obtain information about Windows NT group/user" (No se ha podido obtener información sobre el grupo o el usuario de Windows NT), comprueba la conectividad de red con los dominios locales mediante el archivo de registro active_directory.log disponible en Cloud Logging para la instancia de Cloud SQL para SQL Server. Este archivo contiene los siguientes diagnósticos sobre los cambios de conectividad en el dominio local:

  • Dominios locales de confianza de la instancia de Cloud SQL para SQL Server. Por ejemplo, el siguiente registro muestra el cambio de ningún dominio de confianza a dos nuevos dominios de confianza con sus nombres NetBIOS, ONPREM y 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 dominio local no aparece en la lista o se registra como no de confianza, comprueba si existe la confianza con el dominio de AD gestionado y si se ha validado. Si hay una confianza unidireccional entre el dominio de AD gestionado y el dominio local, es posible que no se vean otros dominios locales en los que confíe el dominio local.
  • Dominios locales accesibles y no accesibles mediante un ping normal desde la instancia de Cloud SQL para SQL Server. Por ejemplo, el siguiente registro muestra el cambio de ningún dominio accesible a dos nuevos dominios accesibles, onprem.com y 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 dominio no aparece en los registros de accesibilidad, asegúrate de que se haya registrado como dominio de confianza. De lo contrario, no se comprueba si se puede acceder a ella. Siempre tenemos un peering de VPC entre un proyecto con instancias on-premise y Google Cloud proyectos. Si se añade un emparejamiento de VPC, se introduce una conexión de emparejamiento transitivo, que Cloud SQL no admite. En su lugar, te recomendamos que uses un túnel VPN para conectar un dominio local a Cloud SQL. Debe haber como máximo una conexión de peering entre el proyecto local y el proyecto Google Cloud con las instancias de Cloud SQL para SQL Server.
  • Pings de llamada a procedimiento remoto (MSRPC) de Microsoft correctos y fallidos a dominios locales desde la instancia de Cloud SQL para SQL Server. Por ejemplo, el siguiente registro muestra el cambio de no tener ningún dominio al que se pueda enviar un ping de MSRPC a tener dos nuevos dominios a los que se pueda enviar un ping de MSRPC, ONPREM y CHILD:

    2023-06-12 20:55:10.664 Detected change in MSRPC pingable domains: Previously pingable onprem domains: []. Current pingable onprem domains: [ONPREM CHILD]

    Los pings de MSRPC se incluyen como diagnósticos adicionales y es posible que no funcionen en algunas configuraciones. Aun así, puedes verificar la conectividad del dominio local mediante los dos primeros diagnósticos.

• Si las consultas de SQL Server devuelven el error "El inicio de sesión es de un dominio no confiable", ten en cuenta que las direcciones IP no se admiten para los usuarios de dominios conectados a través de una relación de confianza. Además, puedes probar a hacer lo siguiente para solucionar el problema:

  • Si se usa una dirección IP para conectar a los usuarios de un dominio gestionado, sigue estas instrucciones.
  • No uses ningún proxy y utiliza siempre el mismo nombre de DNS para conectarte a Cloud SQL para SQL Server, tal como aparece en la consola de Google Cloud .
  • Purgar los tickets de Kerberos. El error anterior puede producirse si tenías un cliente que se conectó recientemente a una instancia de Cloud SQL para SQL Server y la instancia se detuvo y se inició. También puede producirse si la autenticación de Windows se ha inhabilitado y, a continuación, se ha vuelto a habilitar en la instancia de Cloud SQL para SQL Server. Si el cliente usa la caché de credenciales de Windows, bloquea y desbloquea la estación de trabajo del cliente o ejecuta klist purge.

• Si intentas habilitar la autenticación de Windows, puede que aparezca el error "Esta instancia necesita una fecha de creación más reciente para admitir Managed Service for Microsoft Active Directory". Ten en cuenta lo siguiente sobre este error:

  • En Cloud SQL, si una instancia de Cloud SQL para SQL Server se creó el 12 de marzo del 2021 o antes, no se puede integrar con Microsoft AD gestionado.
  • En algunos casos, si creas una instancia de Cloud SQL para SQL Server y no habilitas Managed Microsoft AD al crearla, es posible que recibas el mismo error. Después de consultar los demás consejos de esta sección, cree una instancia y habilite Managed Microsoft AD al hacerlo.

• Si intentas crear una instancia de Cloud SQL para SQL Server, puede que se produzca el error "Esta instancia no admite el servicio gestionado de Microsoft Active Directory". Si recibes este error, es posible que el proyecto no sea compatible. Prueba a usar otro proyecto.

• Si una instancia tiene problemas continuos con la autenticación de Windows (tanto si la instancia se ha actualizado recientemente como si no), prueba a abandonar el dominio de Active Directory gestionado y, a continuación, vuelve a unirte. Para ello, sigue el procedimiento de actualización para abandonar el dominio y, después, volver a unirte a él. Si lo haces, no se eliminarán los usuarios ni los inicios de sesión autenticados con Windows que haya en tus bases de datos. Sin embargo, si quitas la autenticación de Windows, la instancia se reiniciará.

• Usa la herramienta de diagnóstico de AD para solucionar problemas de configuración de AD con tu dominio local y las instancias de Cloud SQL para SQL Server en la consola de Google Cloud .

Solucionar problemas

Haga clic en los enlaces de la tabla para obtener más información:

Siguientes pasos

• Confirme que ha leído detenidamente la página de resumen, que incluye las limitaciones y las funciones no admitidas. En esa página también se incluyen enlaces a documentación adicional.