Información general sobre Active Directory gestionado por el cliente (CMAD)

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

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

CMAD ofrece autenticación, autorización y más. Por ejemplo, al unir una instancia a un dominio de CMAD, puedes iniciar sesión con la autenticación de Windows con una identidad basada en AD. Integrar Cloud SQL para SQL Server con un dominio de AD tiene la ventaja adicional de Google Cloud integrarse con tus dominios de AD locales.

Antes de empezar

Puedes integrar CMAD 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:

  • Para que la autenticación funcione, tus instancias de Cloud SQL deben tener conectividad de red con todos los dominios de Active Directory pertinentes. Esto incluye el dominio principal al que se une la instancia, así como cualquier dominio secundario o de confianza que contenga usuarios que necesiten acceder a Cloud SQL para SQL Server. Para habilitarlo, asegúrate de que los siguientes puertos (tanto TCP como 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 organizativa (UO) para almacenar todos los objetos de integración relacionados.
    • En esta unidad organizativa, también necesitas una cuenta de administrador que tenga los siguientes permisos:
      • Crear objetos de ordenador
      • Eliminar objetos de equipo
      • Crear objetos User
      • Eliminar objetos User
      • Escribir todas las propiedades
      • Cambiar contraseña
      • Leer tiempo de bloqueo, escribir tiempo de bloqueo
    • También te recomendamos que concedas permisos a esta cuenta de administrador para gestionar registros DNS. Por ejemplo, puedes añadirla al grupo DnsAdmins.

      Si no concedes estos permisos, la integración se realizará correctamente. Sin embargo, para conectarte a tu instancia, tendrás que crear manualmente los registros DNS necesarios, tal como se describe en el artículo Conectarse a una instancia con un usuario.

      La otra opción es conectarse mediante 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"
        }
      ]
    }

    Haz los cambios siguientes:

    • VALID_AFTER_UTC_VALUE_1: el primer valor UTC que quieras usar, proporcionado en el formato YYYY-MM-DDThh:mm:ssZ. Por ejemplo, 2099-07-01T10:30:00Z.
    • ADMINISTRATOR_LOGIN_VALUE_1: el primer inicio de sesión de administrador que quieras usar, como myadmin. No incluyas el nombre de dominio en el valor. No se admiten entradas similares a myadmin@my-domain-name.com.
    • ADMINISTRATOR_PASSWORD_VALUE_1: la contraseña de administrador.
    • VALID_AFTER_UTC_VALUE_2: el segundo valor UTC que quieras usar, proporcionado en el formato YYYY-MM-DDThh:mm:ssZ. Por ejemplo, 2099-07-01T10:30:00Z.
    • ADMINISTRATOR_LOGIN_VALUE_2: el inicio de sesión del segundo administrador que quieras 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.
    • ADMINISTRATOR_PASSWORD_VALUE_2: 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 las rotaciones planificadas con antelación.

    El campo validAfterUTC es opcional. Si no se especifica, se asumirá que las credenciales son válidas siempre. 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 cambias las credenciales.

    Aunque puedes eliminar el secreto después de crear la instancia, ten en cuenta que las operaciones futuras, como clonar o añadir una réplica de lectura, harán que la nueva instancia no se una al dominio.

    Además, si eliminas la instancia original, se quedarán objetos huérfanos, como la cuenta de ordenador, en tu CMAD.

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

Crear y configurar una cuenta de servicio

Para crear una cuenta de servicio con los permisos necesarios, comprueba 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

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

  service-PROJECT_ID@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, ejecuta el siguiente comando:

  gcloud iam roles create secretIamPolicyManager --project=PROJECT_ID 

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

Después, ejecuta el siguiente comando:

  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 integrar CMAD

Cuando integres CMAD, te recomendamos que sigas estos 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 consola de Google Cloud . Omite los pasos relacionados con el servicio gestionado para Microsoft Active Directory.

Topologías para la integración con CMAD

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

  • Añade grupos globales o inicios de sesión de usuarios concretos directamente en SQL Server.
  • Usa grupos universales si todos los grupos y usuarios pertenecen al mismo bosque.

Cloud SQL para SQL Server no admite grupos locales de dominio como inicios de sesión. Para conceder permisos a usuarios del dominio, debes usar grupos globales o universales, 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 agregar 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 CMAD, 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 ellos. Después, puede añadir todas las cuentas de usuario individuales y los grupos globales y universales como elementos secundarios de ese grupo universal definido, y 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 CMAD, opción 2.

Limitaciones y alternativas

Se aplican las siguientes limitaciones al integrar CMAD:

  • No se admiten instancias de Cloud SQL para SQL Server que usen Private Service Connect (PSC) para la conectividad privada. Usa el acceso a servicios privados (PSA).
  • No se admiten grupos locales de dominio, pero puedes añadir grupos globales o inicios de sesión de usuarios concretos directamente en SQL Server. También puedes usar grupos universales cuando todos los grupos y usuarios pertenezcan al mismo bosque.
  • Si hay dominios de confianza adicionales y tienes previsto acceder a instancias de SQL Server con nombres de usuario de esos dominios, deben conectarse mediante una confianza bidireccional. No se admiten las relaciones de confianza unidireccionales ni externas.
  • Por lo general, a los nuevos usuarios creados a través de la consola Google Cloud se les asigna el rol CustomerDbRootRole, 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 CMAD, no pueden tener este rol ni usar el agente de SQL Server, ya que la base de datos MSDB en la que se debe conceder este rol está protegida.
  • SQL Server no admite nombres de dominio completos (FQDNs). Por lo tanto, usa nombres de dominio (nombres cortos) en lugar de FQDNs al crear 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 de 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 de Google Cloud .
  • La autenticación de Windows no funcionará con una confianza externa. El error devuelto puede 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 confianza de bosque en lugar de una confianza 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.

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 volver a rotar el certificado de servidor y probar la conexión de nuevo.

No se admite la integración

.

Las siguientes funciones no se admiten al integrar CMAD:

  • Grupos locales de dominio.
  • Autenticación NTLM.
  • Iniciar sesión con una dirección IP de dominios conectados mediante una relación de confianza.
  • Instancias con nombres largos (más de 63 caracteres).

Supervisión

Puede usar la siguiente métrica para monitorizar el estado y el buen funcionamiento de CMAD:

cloudsql.googleapis.com/database/active_directory/domain_reachable

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

cloudsql.googleapis.com/database/active_directory/instance_available

Siguientes pasos