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 o 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 proyecto deGoogle Cloud :

  • 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 habilitar esta opción, 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 organizacional (UO) para almacenar todos los objetos de integración relacionados.
    • Dentro de esta UO, también necesitas una cuenta de administrador que tenga los siguientes permisos:
      • Cómo crear objetos de computadora
      • Borra objetos de Computer
      • Crea objetos User
      • Borra objetos de usuario
      • Escribir todas las propiedades
      • Restablecer contraseña
      • Tiempo de bloqueo de lectura y tiempo de bloqueo de escritura
    • 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 se realizará correctamente de todos modos. 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 desde 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 de 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: 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.
    • ADMINISTRATOR_PASSWORD_VALUE_1: La contraseña del administrador
    • VALID_AFTER_UTC_VALUE_2: Es el segundo valor de 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 acceso del segundo 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.
    • 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 rotaciones planificadas 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 crear la instancia, ten en cuenta que las operaciones futuras, como la clonación o la adición de una réplica de lectura, harán que la instancia nueva no se una al dominio.

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

  • Tener 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 necesarios, 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 consola de Google Cloud . Omitir 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
  • 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 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

Se aplican las siguientes limitaciones cuando se realiza la integración con 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 confianza bidireccional. No se admiten las relaciones de confianza unidireccionales ni externas.
  • En general, a los usuarios nuevos creados a través de la consola de Google Cloud se les asigna el rol deCustomerDbRootRole, 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 recibir este rol ni usar el agente de SQL Server, ya que la base de datos de MSDB en la que se debe otorgar este rol 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, 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 .
  • La autenticación de Windows no funcionará con una relación de confianza externa. El error que se devuelve 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 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 la conexión falla y uno de tus certificados se creó antes del 15 de marzo de 2025, debes rotar el certificado del servidor nuevamente y volver a intentar la conexión.

No se admite para la integración

Las siguientes funciones no son compatibles cuando se realiza la integración con CMAD:

  • Grupos locales de dominio
  • Autenticación NTLM
  • Accede con una dirección IP desde dominios conectados a través de 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 funcionamiento del CMAD:

cloudsql.googleapis.com/database/active_directory/domain_reachable

Esta métrica informa 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

¿Qué sigue?