Descripción general de Microsoft AD administrado en Cloud SQL

Puedes integrar Cloud SQL para SQL Server con el Servicio administrado para Microsoft Active Directory (también llamado Microsoft AD administrado).

En esta página, se proporciona información que debes revisar antes de comenzar una integración. Después de revisar la siguiente información, incluidas las limitaciones, consulta Usa Cloud SQL con Microsoft AD administrado.

Ventajas de la integración con Microsoft AD administrado

La autenticación, la autorización y mucho más están disponibles a través de Microsoft AD administrado. Por ejemplo, unir una instancia a un dominio administrado de Microsoft AD te permite acceder con la autenticación de Windows con una identidad basada en AD.

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

Requisitos previos para la integración

Puedes integrarlo en Microsoft AD administrado y agregar compatibilidad con la autenticación de Windows a una instancia. Sin embargo, antes de la integración, se requiere lo siguiente para tu proyecto de Google Cloud:

Crea y configura una cuenta de servicio

Necesitas una cuenta de servicio por producto y por proyecto que planeas integrar a Microsoft AD administrado. Usa gcloud o Console para crear la cuenta a nivel de proyecto. La cuenta de servicio por proyecto y por producto debe tener la función managedidentities.sqlintegrator en el proyecto. Para obtener más información, consulta gcloud projects set-iam-policy.

Si usas la consola de Google Cloud, Cloud SQL crea de forma automática una cuenta de servicio y te solicita que otorgues 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

Con ese comando, se muestra un nombre de cuenta de servicio en el siguiente formato:

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

Este es un ejemplo de un nombre de cuenta de servicio: 

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

Otorgar los permisos necesarios para la integración requiere los permisos existentes. Para conocer los permisos necesarios, consulta Permisos necesarios.

A fin de otorgar el permiso necesario para la integración, ejecuta el siguiente comando. Si tu Microsoft AD administrado está en un proyecto diferente, AD_PROJECT_ID debe ser el que contiene la instancia de servicio administrado para Microsoft Active Directory, mientras que el SQL_PROJECT_NUMBER de la cuenta de servicio debe ser el que contiene 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 crea identidad de servicios beta de gcloud.

Recomendaciones para la integración con Microsoft AD administrado.

Cuando planifiques la integración, revisa lo siguiente:

Tener una instancia de SQL Server y una instancia de AD administrada en la misma región ofrece la menor latencia de red 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, sin importar si los configuraste en la misma región, configura una principal y una alternativa para obtener una mayor disponibilidad.

Topologías para la integración en Microsoft AD administrado

Cloud SQL para SQL Server no es compatible con grupos locales de dominio. Sin embargo, puede:

  • Agregar grupos globales o accesos de usuario individuales directamente en SQL Server
  • Usar grupos universales cuando todos los grupos y usuarios pertenezcan al mismo bosque

Si se admitieran los grupos locales de dominio, podrían agregarse 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). Esto te permitiría agregar un grupo local de dominio como acceso de SQL Server. En Cloud SQL para SQL Server, puedes habilitar capacidades similares, como se describe en esta sección.

Opción 1: Agrega cuentas de usuario y grupos como accesos a SQL Server

Si tienes varios dominios, en varios bosques y tienes varios grupos globales, puedes agregar todas las cuentas de usuario individuales y los grupos globales y universales, directamente como accesos a SQL Server. Como ejemplo de la opción 1, consulta el siguiente diagrama:

Topología de AD, opción 1.

Opción 2: Define 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. Luego, puedes agregar todas las cuentas de usuario individuales y los grupos globales y universales, como secundarios de ese grupo universal definido, y agregar el grupo universal definido como acceso de SQL Server. Como ejemplo de la opción 2, consulta el siguiente diagrama:

Topología de AD, opción 2.

Limitaciones y alternativas

Las siguientes limitaciones se aplican cuando se integra a Microsoft AD administrado:

  • Los grupos locales de dominio no son compatibles, pero puedes agregar grupos globales o accesos de usuarios individuales directamente en SQL Server. Como alternativa, puedes usar grupos universales cuando todos los grupos y los usuarios pertenezcan al mismo bosque.
  • En general, a los usuarios nuevos creados a través de la consola de Google Cloud se les asigna el rol CustomerDbRootRole, que tiene este rol de base de datos fija de agente de SQL Server: SQLAgentUserRole. Sin embargo, los usuarios creados a través de SQL Server directamente, como los usuarios de Microsoft AD administrado, no pueden recibir este rol, o pueden usar el agente de SQL Server, ya que la base de datos de MSDB en la que se debe otorgar este rol está protegida.
  • Algunas operaciones restringidas pueden generar el siguiente error: “Could not obtain information about Windows NT group/user”. Un ejemplo de este tipo de operación restringida es crear accesos de usuarios de dominios conectados a través de una relación de confianza. Otro ejemplo es otorgar privilegios a los usuarios desde dominios que están conectados a través de una relación de confianza. En estos casos, reintentar la operación suele dar buenos resultados. Si los reintentos fallan, cierra la conexión y abre una nueva.
  • Los nombres de dominio completamente calificados (FQDN) no son compatibles con SQL Server en Windows. Por lo tanto, usa nombres de dominio (nombres cortos), en lugar de FQDN, cuando crees accesos de SQL Server. Por ejemplo, si el nombre de tu dominio es ad.mydomain.com, crea accesos de SQL Server para ad\user, en lugar de ad.mydomain.com\user.
  • Para acceder a las instancias de SQL Server, usa siempre FQDN. Por ejemplo, podrías 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 accesos de SQL Server basados en usuarios y grupos de Active Directory no se pueden administrar desde la consola de Google Cloud.
  • En Cloud SQL, si una instancia de SQL Server se creó el 12 de marzo de 2021 o antes, no se puede integrar en Microsoft AD administrado.
  • La autenticación de Windows no funcionará con una relación de confianza externa. El error podría ser el siguiente: “The target principal name is incorrect. Cannot generate SSPI context.” Además, en relación con las recomendaciones de Microsoft, usa una relación de confianza de bosque en lugar de una externa para la autenticación de Kerberos.

No se admite para la integración

Las siguientes características no son compatibles cuando se integra con Microsoft AD administrado:

  • Grupos locales de dominio
  • Quitar los accesos de SQL Server por parte de usuarios de dominios conectados a través de una relación de confianza Puedes realizar esta operación con un usuario de tu dominio administrado o a través del acceso sqlserver.
  • Autenticación NTLM
  • Accede con una dirección IP desde dominios conectados mediante una relación de confianza.
  • Instancias con nombres largos (más de 63 caracteres).

¿Qué sigue?