Descripción general de Active Directory administrado por el cliente (CMAD)

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 Active Directory administrado por el cliente.

Puedes integrar Cloud SQL para SQL Server con Microsoft Active Directory administrado por el cliente (también conocido como AD administrado por el cliente [CMAD]).

La autenticación, la autorización y mucho más están disponibles a través de CMAD. Por ejemplo, unir una instancia a un dominio de CMAD 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 Google Cloud integración con tus dominios de AD locales.

Antes de comenzar

Puedes integrarlo en CMAD, 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 Google Cloud proyecto:

  • Para que la autenticación funcione, tus instancias de Cloud SQL deben tener conectividad de red a todos los dominios de Active Directory pertinentes. Esto incluye el dominio principal al que se une la instancia, así como cualquier dominio de confianza o secundario que contenga usuarios que necesiten acceder a Cloud SQL para SQL Server. Para habilitar esto, asegúrate de que los siguientes puertos (TCP y UDP) estén abiertos entre tus instancias de Cloud SQL y todos tus controladores de dominio: 53, 88, 135, 389, 445, 464, 3268, 3269 y 49152 a 65535.
  • Debes crear una unidad organizacional (UO) para almacenar todos los objetos de integración relacionados.
    • Dentro de esta UO, también debes delegar los siguientes permisos en la cuenta de administrador:
      • Administrar objetos de computadora (crear objeto/borrar objeto/modificar propiedades del objeto)
      • Administrar objetos de usuario (crear objeto/borrar objeto/modificar propiedades del objeto)
    • También recomendamos otorgar a esta cuenta de administrador permisos para administrar registros DNS, por ejemplo, agregándola al grupo DnsAdmins.

      Si no otorgas estos permisos, la integración seguirá funcionando. Sin embargo, para conectarte a tu instancia, deberás crear manualmente los registros DNS necesarios, como se describe en, Conéctate a una instancia con un usuario.

      La alternativa es conectarse con la dirección IP de la instancia, que tiene limitaciones y no funcionará para las conexiones de dominios de confianza.

  • Debes almacenar tus credenciales de administrador en un secreto de Secret Manager con el siguiente formato JSON: 
        {
      "credentials": [
        {
          "validAfterUTC": "VALID_AFTER_UTC_VALUE",
          "administratorLogin": "ADMINISTRATOR_LOGIN_VALUE_1",
          "administratorPassword": "ADMINISTRATOR_PASSWORD_VALUE_1"
        },
        {
          "validAfterUTC": "VALID_AFTER_UTC_VALUE_2",
          "administratorLogin": "ADMINISTRATOR_LOGIN_VALUE_2",
          "administratorPassword": "ADMINISTRATOR_PASSWORD_VALUE_2"
        }
      ]
    }

    Reemplaza lo siguiente:

    • VALID_AFTER_UTC_VALUE_1: Es el primer valor UTC que deseas usar, proporcionado en el formato YYYY-MM-DDThh:mm:ssZ. Un ejemplo podría ser 2099-07-01T10:30:00Z.
    • ADMINISTRATOR_LOGIN_VALUE_1: Es el primer acceso de administrador que deseas usar, como myadmin. No incluyas el nombre de dominio en el valor. No se admiten entradas similares a myadmin@my-domain-name.com no son compatibles.
    • ADMINISTRATOR_PASSWORD_VALUE_1: Es la contraseña del administrador.
    • VALID_AFTER_UTC_VALUE_2: Es el segundo valor UTC que deseas usar, proporcionado en el formato YYYY-MM-DDThh:mm:ssZ. Un ejemplo podría ser 2099-07-01T10:30:00Z.
    • ADMINISTRATOR_LOGIN_VALUE_2: Es el segundo acceso de administrador que deseas usar, como myadmin2. Del mismo modo, no incluyas el nombre de dominio en el valor. No se admiten entradas similares a myadmin2@my-domain-name.com no son compatibles.
    • ADMINISTRATOR_PASSWORD_VALUE_2: Es la contraseña del segundo administrador.

    Este archivo puede contener varias entradas de credenciales para mitigar problemas con la propagación lenta o para adaptarse a rotaciones planificadas y por adelantado.

    El campo validAfterUTC es opcional. Si no se especifica, se supondrá que las credenciales siempre son válidas. Te recomendamos que mantengas estas credenciales disponibles de forma permanente en Secret Manager y que uses la automatización para actualizar la contraseña si rotas las credenciales.

    Si bien puedes borrar el secreto después de la creación de la instancia, ten en cuenta que las operaciones futuras, como clonar o agregar una réplica de lectura, harán que la instancia nueva no se una al dominio.

    Además, si borras la instancia original, se dejarán objetos huérfanos, como la cuenta de la computadora, en tu CMAD.

  • Ten una lista de direcciones IP del servidor DNS para tu Active Directory administrado por el cliente, que suelen ser tus controladores de dominio. Te recomendamos que uses direcciones IP estáticas para estos servidores.
  • Asigna cuentas de servicio por producto y por proyecto.

Crea y configura una cuenta de servicio

Para crear una cuenta de servicio con los permisos requeridos, verifica lo siguiente:

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

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

      --project=PROJECT_ID

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

  service-PROJECT_ID@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

A fin de otorgar el permiso necesario para la integración, ejecuta el siguiente comando:

  gcloud iam roles create secretIamPolicyManager --project=PROJECT_ID 

    --permissions="secretmanager.secrets.getIamPolicy,secretmanager.secrets.setIamPolicy"

Luego, ejecuta el comando siguiente:

  gcloud secrets add-iam-policy-binding ADCredentials --project="722300452883" 

    --member="serviceAccount:service-SQL_PROJECT_NUMBER@gcp-sa-cloud-sql.iam.gserviceaccount.com" 

    --role="projects/PROJECT-ID/roles/secretIamPolicyManager"

Para obtener más información, consulta gcloud beta services identity create.

Prácticas recomendadas para la integración con CMAD

Cuando realices la integración con CMAD, te recomendamos que completes los siguientes pasos.

Requisitos previos para la integración

Usa la herramienta de diagnóstico de Active Directory para solucionar problemas de configuración de AD con tu dominio local y las instancias de Cloud SQL para SQL Server en la Google Cloud consola. Omite los pasos relacionados con el servicio administrado para Microsoft Active Directory.

Topologías para la integración en CMAD

Cloud SQL para SQL Server no es compatible con grupos locales de dominio. Sin embargo, están disponibles las siguientes alternativas:

  • 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

Cloud SQL para SQL Server no admite grupos locales de dominio como accesos. Para otorgar permisos a los usuarios del dominio, debes usar grupos globales o universales, 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 CMAD, 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 CMAD, opción 2.

Limitaciones y alternativas

Las siguientes limitaciones se aplican cuando se integra a CMAD:

  • No se admiten las instancias de Cloud SQL para SQL Server que usan Private Service Connect (PSC) para la conectividad privada. En su lugar, usa el acceso privado a servicios (PSA).
  • 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.
  • Si hay dominios de confianza adicionales y planeas acceder a instancias de SQL Server con nombres de usuario desde allí, deben conectarse a través de una relación de confianza bidireccional. No se admiten las relaciones de confianza unidireccionales ni externas.
  • En general, a los usuarios nuevos creados a través de la Google Cloud consola se les asigna el CustomerDbRootRole rol, 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 CMAD, no pueden obtener este rol ni usar el agente de SQL Server, porque la base de datos de MSDB en la que deben otorgarse estas funciones está protegida.
  • Los nombres de dominio completamente calificados (FQDN) no son compatibles con SQL Server. 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, 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 accesos de SQL Server basados en usuarios y grupos de Active Directory no se pueden administrar desde la Google Cloud consola.
  • La autenticación de Windows no funcionará con una relación de confianza externa. Es posible que se muestre el siguiente error: 
      "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.
  • Siempre se usa la versión más reciente del secreto. El secreto debe estar activo y no se puede destruir.

Extremos de Active Directory y conexiones TLS

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

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

No se admite para la integración

Las siguientes características no son compatibles cuando se integra con CMAD:

  • Grupos locales de dominio
  • 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).

Supervisión

Puedes usar la siguiente métrica para supervisar el estado y el estado de CMAD:

cloudsql.googleapis.com/database/active_directory/domain_reachable

Esta métrica informa si se puede acceder a CMAD desde la instancia de Cloud SQL. Es una herramienta útil para solucionar problemas de red:

cloudsql.googleapis.com/database/active_directory/instance_available

¿Qué sigue?