Información general sobre Microsoft AD gestionado en Cloud SQL

Puedes integrar Cloud SQL para SQL Server con el servicio gestionado de Microsoft Active Directory (también llamado Microsoft AD gestionado).

En esta página se incluye información que debe revisar antes de iniciar una integración. Después de revisar la siguiente información, incluidas las limitaciones, consulta el artículo Usar Cloud SQL con Microsoft AD gestionado.

Ventajas de la integración con Microsoft AD gestionado

La autenticación, la autorización y más funciones están disponibles a través de Managed Microsoft AD. Por ejemplo, si unes una instancia a un dominio de Microsoft AD gestionado, podrás iniciar sesión con la autenticación de Windows mediante una identidad basada en AD.

Integrar Cloud SQL para SQL Server con un dominio de AD tiene la ventaja adicional de la integración de Cloud con tus dominios de AD locales.

Requisitos previos para la integración

Puedes integrar Managed Microsoft AD y añadir compatibilidad con la autenticación de Windows a una instancia. Sin embargo, antes de integrar, tu proyectoGoogle Cloud debe cumplir los siguientes requisitos:

Crear y configurar una cuenta de servicio

Necesitas una cuenta de servicio por producto y por proyecto para cada proyecto que quieras integrar con Microsoft AD gestionado. Usa gcloud o la consola para crear la cuenta a nivel de proyecto. A la cuenta de servicio por producto y por proyecto se le debe conceder el rol managedidentities.sqlintegrator en el proyecto. Para obtener más información, consulta gcloud projects set-iam-policy.

Si usas la Google Cloud consolamanagedidentities.sqlintegrator, Cloud SQL crea automáticamente una cuenta de servicio y te pide que le asignes el rol managedidentities.sqlintegrator.

Para crear una cuenta de servicio con gcloud, ejecuta el siguiente comando:

gcloud beta services identity create --service=sqladmin.googleapis.com \
    --project=PROJECT_NUMBER

Ese comando devuelve un nombre de cuenta de servicio con el siguiente formato:

    service-PROJECT_NUMBER@gcp-sa-cloud-sql.iam.gserviceaccount.com

Este es un ejemplo de nombre de cuenta de servicio:

    service-333445@gcp-sa-cloud-sql.iam.gserviceaccount.com

Para conceder el permiso necesario para la integración, se necesitan permisos. Para saber qué permisos son obligatorios, consulta Permisos necesarios.

Para conceder el permiso necesario para la integración, ejecuta el siguiente comando. Si tu Managed Microsoft AD está en otro proyecto, AD_PROJECT_ID debe ser el que contenga la instancia de Managed Service for Microsoft Active Directory, mientras que SQL_PROJECT_NUMBER debe ser el que contenga la instancia de SQL Server:

gcloud projects add-iam-policy-binding AD_PROJECT_ID \
--member=serviceAccount:service-SQL_PROJECT_NUMBER@gcp-sa-cloud-sql.iam.gserviceaccount.com \
--role=roles/managedidentities.sqlintegrator

Consulta también gcloud beta services identity create.

Prácticas recomendadas para integrar Managed Microsoft AD

Cuando planifique una integración, revise lo siguiente:

Tener una instancia de SQL Server y una instancia de AD gestionada en la misma región ofrece la latencia de red más baja y el mejor rendimiento. Por lo tanto, cuando sea posible, configura una instancia de SQL Server y una instancia de AD en la misma región. Además, tanto si las configuras en la misma región como si no, configura una región principal y una de copia de seguridad para aumentar la disponibilidad.

Topologías para la integración con Microsoft AD gestionado

Cloud SQL para SQL Server no admite grupos locales de dominio. Sin embargo, puedes:

  • Añadir grupos globales o inicios de sesión de usuarios concretos directamente en SQL Server
  • Usa grupos universales cuando todos los grupos y usuarios pertenezcan al mismo bosque

Si se admitieran los grupos locales de dominio, se podrían añadir cuentas de usuario individuales y grupos globales y universales como elementos secundarios de un grupo local de dominio (que protege el acceso a SQL Server). De esta forma, podrás añadir un grupo local de dominio como inicio de sesión de SQL Server. En Cloud SQL para SQL Server, puedes habilitar funciones similares, tal como se describe en esta sección.

Opción 1: Añadir cuentas de usuario y grupos como inicios de sesión en SQL Server

Si tiene varios dominios en varios bosques y varios grupos globales, puede añadir todas las cuentas de usuario individuales y los grupos globales y universales directamente como inicios de sesión en SQL Server. Como ejemplo de la opción 1, consulta el siguiente diagrama:

Topología de AD, opción 1.

Opción 2: Definir un grupo universal en uno de tus dominios

Si tus dominios están en el mismo bosque, puedes definir un grupo universal en uno de tus dominios. A continuación, puede añadir todas las cuentas de usuario individuales y los grupos globales y universales como elementos secundarios de ese grupo universal definido, así como añadir el grupo universal definido como inicio de sesión de SQL Server. Como ejemplo de la opción 2, consulta el siguiente diagrama:

Topología de AD, opción 2.

Limitaciones y alternativas

Se aplican las siguientes limitaciones al integrar Managed Microsoft AD:

  • No se admiten grupos locales de dominio, pero puedes añadir grupos globales o inicios de sesión de usuarios individuales directamente en SQL Server. También puedes usar grupos universales cuando todos los grupos y usuarios pertenezcan al mismo bosque.
  • Por lo general, a los nuevos usuarios creados a través de la consola Google Cloud se les asigna el rolCustomerDbRootRole, que tiene este rol de base de datos fijo de SQL Server Agent: SQLAgentUserRole. Sin embargo, los usuarios creados directamente a través de SQL Server, como los usuarios de Microsoft AD gestionado, no pueden tener este rol ni usar el agente de SQL Server porque la base de datos MSDB en la que se debe conceder este rol está protegida.
  • Algunas operaciones restringidas pueden provocar el siguiente error: "No se ha podido obtener información sobre el grupo o el usuario de Windows NT". Un ejemplo de este tipo de operación restringida es la creación de inicios de sesión por parte de usuarios de dominios conectados mediante una relación de confianza. Otro ejemplo es conceder privilegios a usuarios de dominios conectados mediante una relación de confianza. En estos casos, suele funcionar si se vuelve a intentar la operación. Si vuelve a fallar, cierra la conexión y abre una nueva.
  • SQL Server en Windows no admite nombres de dominio completos (FQDNs). Por lo tanto, utilice nombres de dominio (nombres cortos) en lugar de FQDNs cuando cree inicios de sesión de SQL Server. Por ejemplo, si el nombre de tu dominio es ad.mydomain.com, crea inicios de sesión de SQL Server para ad\user en lugar de para ad.mydomain.com\user.
  • Para acceder a las instancias de SQL Server, utiliza siempre nombres de dominio completos. Por ejemplo, puedes usar un FQDN similar a private.myinstance.us-central1.myproject.cloudsql.mydomain.com. No se admiten nombres NetBIOS ni nombres cortos si se omiten los sufijos DNS.
  • Los inicios de sesión de SQL Server basados en usuarios y grupos de Active Directory no se pueden gestionar desde la consola Google Cloud .
  • En Cloud SQL, si se creó una instancia de SQL Server el 12 de marzo del 2021 o antes, no se puede integrar con Microsoft AD gestionado.
  • La autenticación de Windows no funcionará con una confianza externa. El error puede ser el siguiente: "El nombre de la entidad de seguridad de destino no es correcto. No se puede generar el contexto SSPI." Además, en relación con las recomendaciones de Microsoft, usa una confianza de bosque en lugar de una confianza externa para la autenticación de Kerberos.

Puntos finales de Active Directory y conexiones TLS

Si usas la autenticación de Windows y quieres establecer una conexión TLS sin confiar en el certificado del servidor, debes rotar los certificados después de habilitar la autenticación de Windows en la instancia.

Si la conexión falla y uno de tus certificados se creó antes del 15 de marzo del 2025, debes renovar el certificado de servidor de nuevo y volver a intentar la conexión.

No se admite la integración

Las siguientes funciones no se admiten al integrar Managed Microsoft AD:

  • Grupos locales de dominio.
  • Eliminar los inicios de sesión de SQL Server de usuarios de dominios conectados mediante una relación de confianza. Puedes realizar esta operación con un usuario de tu dominio gestionado o iniciando sesión con sqlserver.
  • Autenticación NTLM.
  • Iniciar sesión con una dirección IP de dominios conectados a través de una relación de confianza.
  • Instancias con nombres largos (más de 63 caracteres).

Siguientes pasos