Usar Microsoft AD administrado con Cloud SQL

MySQL |PostgreSQL |SQL Server

En esta página, se describen las formas de usar Cloud SQL para hacer lo siguiente:

Integrarte con el servicio administrado para Microsoft Active Directory (también llamado Microsoft AD administrado)
Conectarte a una instancia con un usuario de AD.

Una instancia de Cloud SQL integrada en Microsoft AD administrado admite la autenticación de Windows, además de la autenticación de SQL.

Antes de comenzar

En la consola de Google Cloud, selecciona el nombre del proyecto.
Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud. Obtén información sobre cómo confirmar que tienes habilitada la facturación para tu proyecto.
Instala e inicializa la CLI de gcloud.
Asegúrate de tener el rol Cloud SQL Admin en tu cuenta de usuario. Ir a la página de IAM.
Revisa los requisitos previos para la integración.

Crea una instancia con autenticación de Windows

Puedes integrarlo en Microsoft AD administrado durante la creación de la instancia, lo que habilita la autenticación de Windows para la instancia. Para integrar, elige un dominio a fin de que la instancia se una. Si la unión a un dominio falla, falla la creación de la instancia.

A fin de prepararte para crear una instancia con autenticación de Windows, revisa las sugerencias y las limitaciones y alternativas.

Se admite una instancia con IP pública, siempre que también tenga una IP privada. La IP privada debe estar habilitada para la instancia. Luego, puedes usar una IP pública o privada para conectarte a la instancia, siempre que ambas estén disponibles.

Nota: Después de crear una instancia con la autenticación de Windows, se crea un acceso adicional de Cloud SQL para SQL Server. El acceso tiene el formato [domain]\sql_[letters-and-digits]. Por ejemplo, Cloud SQL puede crear un acceso llamado AD\sql_1a1a6145bc1aaaa. El acceso está en el dominio de AD administrado. Puedes ignorar el acceso. No puedes quitarlo. Sin embargo, si inhabilitas la autenticación de Windows para la instancia, el acceso se borra de forma automática.

A continuación, se muestran las opciones para crear una instancia integrada en Microsoft AD administrado.

Console

En la consola de Google Cloud, ve a la página Instancias de Cloud SQL.

Ir a Instancias de Cloud SQL
Haga clic en Crear instancia.
Haz clic en Elegir SQL Server.
Ingresa un nombre para la instancia. No incluyas información sensible ni información de identificación personal en el nombre de la instancia, ya que es visible a nivel externo. No debes incluir el ID del proyecto en el nombre de la instancia. Este se creará de forma automática cuando corresponda (por ejemplo, en los archivos de registro).
Ingresa la contraseña para el usuario 'sqlserver'.
Configura la región de tu instancia. Consulta Recomendaciones para la integración con Microsoft AD administrado.
En la sección Opciones de configuración, establece las opciones que desees (pero espera hasta el siguiente paso para ver las opciones de autenticación).
Haz clic en Autenticación. El menú desplegable para unirse a un dominio de Active Directory administrado tiene una lista de todos los dominios de Microsoft AD administrado que se agregaron antes en tu proyecto.
Selecciona un dominio en el menú desplegable para unirse a un dominio de Active Directory administrado.
Cuando termines de seleccionar las opciones de configuración, haz clic en Crear. Cloud SQL crea de forma automática una cuenta de servicio por producto y por proyecto. Si la cuenta no tiene el rol apropiada, se te solicitará que otorgues la función managedidentities.sqlintegrator.

gcloud

El siguiente comando crea una instancia que está integrada en Microsoft AD administrado y, por lo tanto, está habilitada para la autenticación de Windows. Si quieres obtener más información sobre el comando básico para crear una instancia, consulta Crea instancias.

Especifica un parámetro de --active-directory-domain=DOMAIN en el comando de gcloud. Por ejemplo, especifica lo siguiente: --active-directory-domain=ad.mydomain.com

Este es un prototipo del comando de gcloud:

gcloud beta sql instances create INSTANCE_NAME \
--database-version=EDITION \
--root-password=PASSWORD \
--active-directory-domain=DOMAIN\
--cpu=CPU \
--memory=MEMORY  \
--network=NETWORK

Terraform

Para crear una instancia integrada en Managed Microsoft AD, usa un recurso de Terraform.

resource "google_sql_database_instance" "instance_with_ad" {
  name             = "database-instance-name"
  region           = "us-central1"
  database_version = "SQLSERVER_2019_STANDARD"
  root_password    = "INSERT-PASSWORD-HERE"

  depends_on = [google_service_networking_connection.private_vpc_connection]

  settings {
    tier = "db-custom-2-7680"
    active_directory_config {
      domain = "ad.domain.com"
    }
    ip_configuration {
      ipv4_enabled    = "false"
      private_network = google_compute_network.private_network.id
    }
  }
  # set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
  # use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
  deletion_protection = false
}

REST

Con la API de REST, puedes crear una instancia que esté integrada en Microsoft AD administrado. Especifica un dominio, como subdomain.mydomain.com, para el campo domain, como se muestra en este prototipo de una solicitud:

{
   "databaseVersion":"database-version",
   "name":"instance-id",
   "region":"region",
   "rootPassword":"password",
   "settings":{
      "tier":"machine-type",
      "ipConfiguration":{
         "privateNetwork":"network"
      },
      "activeDirectoryConfig":{
         "domain":"domain"
      }
   }
}

Actualiza una instancia con autenticación de Windows

Puedes actualizar el dominio de una instancia existente, cambiar o agregar un dominio.

Para obtener información general sobre cómo actualizar una instancia, consulta Edita instancias.

Si una instancia está unida actualmente a un dominio de AD administrado, la instancia inicialmente se separa de ese dominio, antes de que se una al dominio nuevo. Si la actualización falla, es posible que la instancia ya no se una a ningún dominio.

Console

En la consola de Google Cloud, ve a la página Instancias de Cloud SQL.

Ir a Instancias de Cloud SQL
Para abrir la página de Descripción general de una instancia, haz clic en su nombre.
Haz clic en Edit.
Haz clic en Autenticación. En el menú desplegable Unirse a un dominio de Active Directory, se muestra una lista de los dominios de Microsoft AD administrado que se agregaron antes en tu proyecto.
En el menú desplegable en el que puedes unirte a un dominio administrado de Active Directory, selecciona un dominio nuevo (reemplazo) para tu instancia.
Haz clic en Guardar para aplicar los cambios.

gcloud

El siguiente es el prototipo de un comando para actualizar una instancia existente. El comando agrega o reemplaza un dominio. Pasa --active-directory-domain=DOMAIN al comando de la siguiente manera:

gcloud beta sql instances patch INSTANCE_NAME \
--active-directory-domain=DOMAIN

REST

Con la API de REST, puedes actualizar una instancia existente. Especifica un dominio, como subdomain.mydomain.com, en el campo domain. El siguiente es el prototipo de una solicitud:

{
   "settings":{
      "activeDirectoryConfig":{
         "domain":"domain"
      }
   }
}

Integra un dominio de AD administrado en un proyecto diferente

Puedes integrar tu instancia en un dominio de Microsoft AD administrado que esté en un proyecto diferente.

Nota: La integración en un dominio de AD en un proyecto diferente requiere el uso de comandos de gcloud o la API de REST de Cloud SQL. Actualmente, no puedes usar la consola de Google Cloud para este fin.

Cuando planifiques la integración, revisa las restricciones.

Habilita el intercambio de tráfico de dominio

Antes de continuar con los pasos en las siguientes secciones, habilita el intercambio de tráfico entre dominios para que tu dominio esté disponible para todos los proyectos necesarios con instancias de Cloud SQL para SQL Server.

Para obtener una lista de dominios de otros proyectos que ya están disponibles, puedes especificar lo siguiente:

`gcloud active-directory peerings list`

Para obtener más información, consulta Enumera intercambios de tráfico de dominio.

El comando gcloud active-directory peerings list requiere el permiso managedidentities.peerings.list. Los siguientes roles tienen este permiso:

roles/managedidentities.peeringViewer
roles/managedidentities.viewer

Para obtener más información, consulta Control de acceso con IAM.

Crea una cuenta de servicio

Repite estos pasos para cada proyecto que contenga una instancia de Cloud SQL para SQL Server que desees integrar.

Revisa la información general para crear cuentas de servicio.
Usa un comando similar al siguiente para crear una cuenta de servicio. Especifica el ID del proyecto que contiene instancias de Cloud SQL para SQL Server:
```
gcloud beta services identity create --service=sqladmin.googleapis.com \
--project=[PROJECT_ID]
```
Otorga el rol managedidentities.sqlintegrator en el proyecto con la instancia de Microsoft AD administrado. Especifica el ID del proyecto que contiene la instancia de Microsoft AD administrado:
```
gcloud projects add-iam-policy-binding [PROJECT_ID] \
--member=serviceAccount:SERVICE_ACCOUNT --role=roles/managedidentities.sqlintegrator
```

Habilita la autenticación de Windows entre proyectos

Puedes integrarlo en un dominio de AD en un proyecto diferente mediante los comandos de gcloud o la API de REST de Cloud SQL. En cualquier caso, debes especificar el nombre completo del recurso de dominio.

Especifica el nombre completo del recurso de dominio cuando se crea o actualiza una instancia de Cloud SQL para SQL Server. Se admiten dos formatos:

projects/PROJECT_ID/locations/global/domains/DOMAIN_NAME
projects/PROJECT_NUMBER/locations/global/domains/DOMAIN_NAME

En este ejemplo, se usa gcloud:

gcloud beta sql instances patch INSTANCE_NAME \
--active-directory-domain=projects/PROJECT_ID/locations/global/domains/DOMAIN_NAME

Si usas un nombre de recurso de dominio corto (como DOMAIN_NAME), el sistema supone que tu dominio de Microsoft AD administrado está en el mismo proyecto que tus instancias de Cloud SQL para SQL Server.

Restricciones para la integración con diferentes proyectos

Si te integras a un dominio de AD administrado en un proyecto diferente, se aplican las siguientes restricciones:

Hasta 10 redes con instancias de Cloud SQL para SQL Server pueden compartir una instancia de Microsoft AD administrado que se encuentra en un proyecto diferente.
La consola de Google Cloud solo admite instancias de Microsoft AD administrado ubicadas en el mismo proyecto. En lugar de usar la consola de Google Cloud, puedes integrarlo con los comandos de gcloud o la API de REST de Cloud SQL.
Si se usan los Controles del servicio de VPC, las instancias de Cloud SQL para SQL Server y una instancia de Microsoft AD administrado deben estar ubicadas en el mismo perímetro.

Además, si una instancia está integrada en un dominio de AD administrado en un proyecto diferente, el nombre de dominio completamente calificado (FQDN) que se muestra en la consola de Google Cloud puede ser inexacto para esa instancia. Específicamente, en la página Descripción general de esa instancia, en Conectar a esta instancia, los FQDN pueden contener strings separadas por barras, que puedes ignorar. Por ejemplo, un FQDN inexacto podría aparecer como se muestra a continuación:

private.myinstance.myregion.myproject.projects/mydirectory/locations/global/domains/mydomain.com

En ese caso, el FQDN preciso es el siguiente:

private.myinstance.myregion.myproject.cloudsql.mydomain.com

Quita la autenticación de Windows de una instancia

Puedes quitar la autenticación de Windows y, por lo tanto, una integración administrada de Microsoft AD en una instancia existente.

Console

En la consola de Google Cloud, ve a la página Instancias de Cloud SQL.

Ir a Instancias de Cloud SQL
Para abrir la página de Descripción general de una instancia, haz clic en su nombre.
Haz clic en Edit.
Haz clic en Autenticación. El menú desplegable para unirse a un dominio de Active Directory administrado tiene una lista de los dominios de Microsoft AD administrado que se agregaron antes en tu proyecto.
En el menú desplegable, selecciona Sin dominio/Unirse más tarde para tu instancia.
Lee el mensaje sobre el reinicio de la instancia y haz clic en Cerrar.
Haz clic en Guardar para aplicar los cambios.

gcloud

Para quitar una instancia de un dominio y quitar la autenticación de Windows, usa un valor en blanco para el dominio. Es decir, en tu comando, usa un valor en blanco para el parámetro --active-directory-domain de la siguiente manera:

gcloud beta sql instances patch INSTANCE_NAME \
--active-directory-domain=

REST

Con la API de REST, puedes quitar una instancia de un dominio. Especifica un valor en blanco en el campo domain, de la siguiente manera:

{
   "settings":{
      "activeDirectoryConfig":{
         "domain":""
      }
   }
}

Conéctate a una instancia con un usuario

En Cloud SQL para SQL Server, el usuario predeterminado es sqlserver.

Después de integrar una instancia con Microsoft AD administrado, puedes conectarte a la instancia con el usuario sqlserver, de la siguiente manera:

Crea un acceso a SQL Server basado en un usuario o grupo de Windows, de la siguiente manera:
```
CREATE LOGIN [domain\user_or_group] FROM WINDOWS
```
Accede a la instancia con la autenticación de Windows, con el nombre DNS de la instancia. Estos son algunos ejemplos de nombres de DNS de instancia para especificar:
- Para conectarte mediante una IP privada:
```
private.myinstance.us-central1.myproject.cloudsql.mydomain.com
```
- Para conectarte mediante una IP pública:
```
public.myinstance.us-central1.myproject.cloudsql.mydomain.com
```
- Para conectarte a través del proxy de Cloud SQL Auth (consulta también a continuación):
```
proxy.myinstance.us-central1.myproject.cloudsql.mydomain.com
```
Si usas la dirección IP de la instancia, debes configurar los clientes de Kerberos para admitir nombres de host de IP. Cloud SQL no admite accesos de dominios conectados mediante una relación de confianza.

Usa el proxy de Cloud SQL Auth con la autenticación de Windows

Puedes usar el proxy de Cloud SQL Auth con tu integración de Microsoft AD administrado.

Antes de comenzar, revisa lo siguiente:

Pasos para la autenticación de Windows

Para obtener información general sobre cómo iniciar el proxy de autenticación de Cloud SQL, consulta Cómo iniciar el proxy de Cloud SQL Auth.

Para la autenticación de Windows, debes ejecutar el proxy de Cloud SQL Auth en el puerto 1433. Para mapear una entrada predefinida de nombre principal del servicio (SPN) a una dirección de proxy de Cloud SQL Auth, usa lo siguiente:

proxy.[instance].[location].[project].cloudsql.[domain]

Ejecuta el proxy de Cloud SQL Auth de forma local

Si ejecutas el proxy de Cloud SQL Auth de forma local, usa el archivo de hosts para mapear lo siguiente a 127.0.0.1:

proxy.[instance].[location].[project].cloudsql.[domain]

Por ejemplo, puedes agregar lo siguiente al archivo de hosts (por ejemplo, a c:\windows\system32\drivers\etc\hosts):

127.0.0.1 proxy.[instance].[location].[project].cloudsql.[domain]

En ese ejemplo, puedes ejecutar el proxy de Cloud SQL Auth mediante este comando y hacer que esté disponible en 127.0.0.1:1433:

cloud-sql-proxy.exe --credentials-file credential.json project:name

Ejecuta el proxy de Cloud SQL Auth de forma no local

Para ejecutar el proxy de Cloud SQL Auth de forma no local, sigue las instrucciones de Ejecuta el proxy de Cloud SQL Auth de forma local, pero usa una entrada diferente en el archivo de hosts.

Específicamente, si un host no local es, por ejemplo, MyOtherHost, puedes agregar lo siguiente al archivo de hosts:

127.0.0.1 MyOtherHost proxy.[instance].[location].[project].cloudsql.[domain]

Soluciona problemas de resguardo de NTLM en clientes

Si usas la autenticación de Windows y la dirección IP de una instancia para acceder a una instancia, debes configurar un cliente Kerberos a fin de admitir nombres de host de IP.

Cloud SQL no es compatible con la autenticación NTLM, pero es posible que algunos clientes Kerberos intenten recurrir a ella. Como se explica en esta sección, si intentas conectarte con SQL Server Management Studio (SSMS) y aparece el siguiente mensaje de error, es probable que se deba al resguardo de NTLM:

Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication. (Microsoft SQL Server, Error: 18452)

NTLM es un conjunto de protocolos de seguridad de Microsoft para la autenticación. Consulta también los Motivos para el resguardo de NTLM.

Verificación de un resguardo de NTLM para un cliente de Windows

Desde Windows, para verificar que un resguardo de NTLM haya generado un error, haz lo siguiente:

Accede con las credenciales locales deseadas (no uses “Ejecutar como…”).
Abre un símbolo del sistema.
Ejecuta klist purge.
Desde SSMS, intenta conectarte a SQL Server con la autenticación de Windows.
Ejecuta klist y verifica si se emitió un ticket para "MSSQLSvc/<address>:1433 @ domain".
Si no existe dicho ticket, es probable que se deba al resguardo de NTLM.
Si existe el ticket, verifica que el controlador de SQL Server no aplique la autenticación de NTLM. También verifica si la autenticación de NTLM se aplica a través de la política de grupo.

Verificación de un resguardo de NTLM para un cliente de Linux

Desde Ubuntu 16.04, para verificar que un resguardo de NTLM haya provocado un error, sigue los pasos de esta sección. Los pasos son similares a los de otras distribuciones de Linux.

Configura la autenticación de Kerberos

Configura un cliente Kerberos:
```
sudo apt-get install krb5-user
```
Cuando se te solicite el dominio predeterminado, escribe un nombre de dominio local en letras mayúsculas.

Ejecuta el siguiente comando para instalar las herramientas de línea de comandos de SQL Server:

curl https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -
curl https://packages.microsoft.com/config/ubuntu/16.04/prod.list | sudo tee /etc/apt/sources.list.d/msprod.list
sudo apt-get update
sudo apt-get install mssql-tools unixodbc-dev

Conéctate con la autenticación de Windows

Ejecuta la herramienta kinit de la siguiente manera: kinit <user_account>
Para conectarse con la autenticación de Windows, ejecuta: /opt/mssql-tools/bin/sqlcmd -S <address >>
Ejecuta el comando klist y verifica si se emitió un ticket específico para: "MSSQLSvc/<address>:1433 @ domain"
Si no se emitió el ticket, es posible que el error anterior indique un problema que produzca el resguardo de NTLM.

Motivos para el resguardo de NTLM

El resguardo de NTLM es una configuración incorrecta de cliente que se puede asociar con las siguientes condiciones:

De forma predeterminada, Windows no intenta la autenticación de Kerberos para un host si el nombre de host es una dirección IP. Para habilitar la autenticación Kerberos desde el dominio administrado, prueba el método que se describe en la documentación de Microsoft. Este método no funciona con credenciales locales cuando debes usar FQDN.
La autenticación de Kerberos mediante relaciones de confianza externas no funciona. En su lugar, usa relaciones de confianza de bosques, como se describe aquí.
La autenticación de Kerberos requiere el enrutamiento de sufijo de nombre para habilitar el hallazgo de servicios en otro bosque. Prueba el método que se describe aquí.
La autenticación de Kerberos no funciona si no hay ningún SPN registrado para el servicio. Usa solo FQDN o direcciones IP que obtienes de la consola de Google Cloud para conectarte con la autenticación de Windows.

Usuarios de AD locales: cómo crear un acceso a Windows

Puedes usar un usuario de AD local con el fin de crear un acceso a Windows en Cloud SQL para SQL Server.

Por ejemplo, puedes conectarte con SQL Server Management Studio (SMSS), que se ejecuta en una VM de Windows alojada en la nube privada virtual (VPC) del proyecto de Google Cloud.

En el caso de la autenticación de Windows, en este contexto, Cloud SQL para SQL Server solo es compatible con el protocolo de Kerberos. Para la autenticación de Windows basada en Kerberos, el cliente debe resolver el nombre de DNS de AD local y Microsoft AD administrado.

Configura relaciones de confianza unidireccionales o bidireccionales

Primero, decide si usarás una relación de confianza unidireccional o bidireccional.

Luego, sigue las instrucciones para establecer la relación de confianza entre el dominio de AD local y el dominio de Microsoft AD administrado.

Después de establecer la relación de confianza entre el dominio de AD local y el dominio de Microsoft AD administrado, completa los siguientes pasos. Para fines de ejemplo, en estos pasos se usa SQL Server Management Studio (SSMS), que se ejecuta en una VM de Windows y se aloja en la VPC del proyecto de Google Cloud:

Crea una VM de Windows.
- Crea una VM con una versión de Windows compatible con Microsoft AD administrado.
- Crea la VM en el proyecto que aloja tu dominio de Microsoft AD administrado. Si hay una VPC compartida que sea una red autorizada, también puedes crear la VM en cualquiera de sus proyectos de servicio.
- Crea la VM en una red de VPC que sea una red autorizada del dominio de Microsoft AD administrado y tenga configurado el acceso a servicios privados para Cloud SQL.
Une la VM de Windows al dominio de Microsoft AD administrado.
Instala SSMS en la VM de Windows.
Resuelve el dominio local en la red de VPC
- Desde la red autorizada en la que se ejecuta la VM de Windows, habilita la resolución de DNS local mediante los pasos que se indican en la página Resuelve consultas para objetos de Microsoft AD no administrados. Los pasos que se indican en esa página son requisitos previos para que la autenticación de Windows basada en Kerberos funcione para los usuarios locales.
Crea un acceso a Windows para un usuario local.
- Sigue las instrucciones para CREAR ACCESO a fin de crear un acceso a Windows para un usuario local. Por ejemplo, especifica un comando similar al siguiente:
```
CREATE LOGIN [DOMAIN_NAME\USER_NAME] FROM WINDOWS
```
Accede a tu instancia de Cloud SQL para SQL Server mediante las instrucciones específicas de la aplicación a fin de acceder a un usuario local. Por ejemplo, si usas SQL Server Management Studio, consulta estas instrucciones.

Si se produce un problema durante el acceso a una instancia de Cloud SQL para SQL Server, realiza estas verificaciones:

Verifica las configuraciones del firewall de la red local y la VPC autorizada por el proyecto con las instrucciones para crear una relación de confianza con un dominio local.
Verifica el Enrutamiento de sufijo de nombre para la relación de confianza local.
Verifica que puedas realizar estas operaciones de resolución de DNS desde la VM de Windows que ejecuta SSMS:
- nslookup fqdn-for-managed-ad-domain
- nslookup fqdn-for-on-premises-ad-domain
- nslookup fqdn-for-cloud-sql-server-instance

Sugerencias

Se admite una instancia con IP pública, siempre que también tenga una IP privada. La IP privada debe estar habilitada para la instancia. Luego, puedes usar una IP pública o privada para conectarte a la instancia, siempre que ambas estén disponibles.
Antes de crear una instancia, incluso como instancia de reemplazo, revisa lo siguiente según sea necesario:
- Más información sobre el uso de IP privadas
- Configurar IP públicas
Terraform es compatible.
Si recibes uno de los siguientes errores, confirma que cumples con todos los requisitos previos para la integración:
- "No se encontró la cuenta de servicio por proyecto y por producto"
- “Permiso insuficiente para integrarse con el servicio administrado para el dominio de Microsoft Active Directory”
Si recibes el error “No se encontró el dominio”, verifica que el nombre de dominio, que distingue entre mayúsculas y minúsculas, esté correcto.
Si la autenticación de Windows falla desde un dominio que está conectado a través de una relación de confianza, verifica que la autenticación de Windows funcione para un usuario desde un dominio administrado. Si funciona, sigue estas instrucciones:
1. Verifica que hayas usado un nombre de DNS. Las direcciones IP no son compatibles desde dominios conectados mediante una relación de confianza.
2. Asegúrate de haber seguido todos los pasos para crear una relación de confianza con un dominio local, incluida la apertura de todos los puertos de firewall.
3. Valida la relación de confianza.
4. Verifica que la dirección de la confianza permita a los usuarios del dominio (conectados a través de una relación de confianza) autenticarse en el dominio administrado.
5. Verifica que el enrutamiento de sufijo de nombre esté configurado en el dominio que se conecta a través de una relación de confianza.
6. Verifica que la confianza funcione sin usar Cloud SQL para SQL Server:
  1. Crea una VM de Windows.
  2. Únete al dominio de Microsoft AD administrado.
  3. Intenta ejecutar, por ejemplo, Notepad como un usuario desde el dominio que se conecta a través de una relación de confianza.
7. Reinicia la VM de cliente y vuelve a probar la autenticación de Windows.
Puedes intentar crear un acceso a SQL Server, pero entonces puedes recibir el siguiente error: “No se encontró el usuario de Windows NT o el nombre o dominio del grupo. Vuelve a verificar el nombre”. Esto puede deberse a que los grupos locales del dominio no son compatibles; si corresponde, usa grupos globales o universales.
Cuando un usuario las emite desde un dominio conectado a través de una relación de confianza, las consultas de SQL Server pueden generar el siguiente error: “No se pudo obtener información sobre el grupo o usuario de Windows NT”. Este error se puede producir, por ejemplo, si creas accesos desde dominios conectados a través de una relación de confianza. El error también puede ocurrir si otorgas privilegios a los accesos desde dominios 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.
Si recibes el error "No se pudo obtener información sobre el grupo o usuario de Windows NT", verifica la conectividad de red a los dominios locales con el archivo de registro active_directory.log disponible en Cloud Logging para la instancia de Cloud SQL para SQL Server Este archivo contiene los siguientes diagnósticos sobre los cambios de conectividad al dominio local:

Nota: Las marcas de tiempo del archivo están en la hora local.
- Dominios locales de confianza de la instancia de Cloud SQL para SQL Server Por ejemplo, en el siguiente registro se muestra el cambio de los dominios sin confianza a dos dominios de confianza nuevos como nombres de NetBIOS, ONPREM y CHILD:
```
2023-06-12 20:55:09.975 Detected change in trusted onprem domains: Previously trusted onprem domains: []. Current trusted onprem domains: [ONPREM CHILD]
```
  Si un dominio local no aparece en la lista o se registra como no confiable, verifica si la confianza existe con el dominio de AD administrada y está validado. Si hay una relación de confianza unidireccional entre el dominio de AD administrado y el dominio local, es posible que otros dominios locales de confianza del dominio local no sean visibles.
- Se puede acceder a dominios locales y no se puede acceder a ellos con un ping normal desde la instancia de Cloud SQL para SQL Server. Por ejemplo, en el siguiente registro, se muestra el cambio de los dominios sin confianza a dos dominios de confianza accesibles nuevos, onprem.com y child.onprem.com:
```
2023-06-12 20:55:10.664 Detected change in reachable onprem domains: Previously reachable onprem domains: []. Current reachable onprem domains: [onprem.com child.onprem.com]
```
  Si un dominio no aparece en los registros de accesibilidad, asegúrate de que primero esté registrado como dominio de confianza. De lo contrario, no se verifica su accesibilidad. Siempre tenemos un intercambio de tráfico de VPC entre un proyecto con instancias locales y los proyectos de Google Cloud. Tener aún más un intercambio de tráfico de VPC genera una conexión de intercambio de tráfico transitiva, que Cloud SQL no admite. En cambio, te recomendamos que uses un túnel VPN para conectar un dominio local a Cloud SQL. Debe haber como máximo una conexión de intercambio de tráfico entre el proyecto local y el proyecto de Google Cloud con instancias de Cloud SQL para SQL Server.
- Haz pings de forma correcta y con errores a la llamada de procedimiento remoto de Microsoft (MSRPC) a los dominios locales desde la instancia de Cloud SQL para SQL Server. Por ejemplo, en el siguiente registro, se muestra el cambio de no poder hacer ping en dominios de MSRPC a dos dominios nuevos de MSRPC en los que se puede hacer ping, ONPREM y CHILD:
```
2023-06-12 20:55:10.664 Detected change in MSRPC pingable domains: Previously pingable onprem domains: []. Current pingable onprem domains: [ONPREM CHILD]
```
  Los pings de MSRPC se incluyen como diagnósticos adicionales y es posible que no funcionen en algunas opciones de configuración. Aún puedes verificar la conectividad del dominio local a través de los dos primeros diagnósticos.
Si las consultas de SQL Server generan el error “El acceso es de un dominio no confiable”, ten en cuenta que las direcciones IP no son compatibles con los usuarios de dominios conectados mediante una relación de confianza. Además, las siguientes acciones pueden resolver este problema:
- Si se usa una dirección IP para conectar usuarios desde un dominio administrado, sigue estas instrucciones.
- Evita usar proxies y siempre usa el mismo nombre de DNS a fin de conectarte a Cloud SQL para SQL Server, como lo ves en la consola de Google Cloud.
- Borra definitivamente los tickets de Kerberos existentes. El error anterior puede ocurrir si tenías un cliente que se conectó recientemente a una instancia de Cloud SQL para SQL Server y la instancia se detuvo y se inició. También puede que el error se produzca si se inhabilita la autenticación de Windows y se vuelve a habilitar para la instancia de Cloud SQL para SQL Server. Si el cliente usa la caché de credenciales de Windows, bloquea y desbloquea la estación de trabajo del cliente o ejecuta klist purge.
Un intento de habilitar la autenticación de Windows puede generar el error “Esta instancia necesita una fecha más reciente de creación para admitir el Servicio administrado para Microsoft Active Directory”. Ten en cuenta lo siguiente sobre este error:
- En Cloud SQL, si una instancia de Cloud SQL para SQL Server se creó el 12 de marzo de 2021 o antes, no se puede integrar en Microsoft AD administrado.
- En algunos casos, si creas una instancia de Cloud SQL para SQL Server y no habilitas Microsoft AD administrado durante la creación, es posible que recibas el mismo error. Después de revisar las otras sugerencias en esta sección, crea una instancia nueva, y habilita Microsoft AD administrado en el momento en que la crees.
Un intento de crear una instancia de Cloud SQL para SQL Server puede generar el error "Esta instancia no admite el servicio administrado para Microsoft Active Directory". Si recibes este error, es posible que el proyecto no sea compatible. Intenta usar otro.
Si una instancia tiene problemas continuos con la autenticación de Windows (sin importar si esta se actualizó recientemente o no), intenta desunir el dominio de Active Directory administrado y, luego, volver a unirlo. Para ello, usa el procedimiento de actualización a fin de separar y volver a unir el dominio. Esto no quita los usuarios o accesos autenticados con Windows existentes en tus bases de datos. Sin embargo, quitar la autenticación de Windows hace que una instancia se reinicie.
Usa la herramienta de diagnóstico de AD a fin de 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.

Solucionar problemas

Haz clic en los vínculos de la tabla para obtener más información:

Para este error…	El problema podría ser…	Solución
`Per-product, per-project service account not found.`	El nombre de la cuenta de servicio es incorrecto.	En la página Cuentas de servicio, asegúrate de haber creado una cuenta de servicio para el proyecto de usuario correcto.
`Insufficient permission to integrate with Managed Service for Microsoft Active Directory domain.`	Falta la función `managedidentities.sqlintegrator` en la cuenta de servicio.	En la página IAM y administración, agrega la función `managedidentities.sqlintegrator` a tu cuenta de servicio.
`Domain not found`.	El dominio no existe o se escribió mal.	Asegúrate de que el nombre de dominio sea correcto. Distingue entre mayúsculas y minúsculas.
`The domain is busy with another operation. Please retry.`	Otra instancia de Cloud SQL ejecuta una operación en el mismo dominio de Active Directory administrado.	Vuelve a intentar la operación. Si realizas un lote de actualizaciones en las instancias de Cloud SQL conectadas al mismo dominio, limita cuántas se realizan en paralelo.
`The operation completed but an update to Active Directory failed. You may experience issues with Windows Authentication on this instance, please see https://cloud.google.com/sql/docs/sqlserver/configure-ad for tips`.	No se pudieron realizar las actualizaciones necesarias en el dominio de Active Directory administrado.	Si tienes problemas con la autenticación de Windows, puedes intentar separar el dominio de Active Directory administrado y, luego, volver a unirlo. Para ello, usa el procedimiento de actualización a fin de separar y volver a unir el dominio. Esto no quita los usuarios o accesos autenticados con Windows existentes en tus bases de datos. Sin embargo, quitar la autenticación de Windows hace que una instancia se reinicie.
`This instance would need a more recent creation date to support Managed Service for Microsoft Active Directory.`	En Cloud SQL, si una instancia de Cloud SQL para SQL Server se creó el 12 de marzo de 2021 o antes, no se puede integrar en Microsoft AD administrado.	Prueba tu operación en una instancia creada después del 12 de marzo de 2021.

¿Qué sigue?

Confirma que revisaste por completo la página de descripción general, que incluye las limitaciones y las funciones no compatibles. Esa página también incluye vínculos a documentación adicional.

Usar Microsoft AD administrado con Cloud SQL

Antes de comenzar

Crea una instancia con autenticación de Windows

Console

gcloud

Terraform

REST

Actualiza una instancia con autenticación de Windows

Console

gcloud

REST

Integra un dominio de AD administrado en un proyecto diferente

Habilita el intercambio de tráfico de dominio

Crea una cuenta de servicio

Habilita la autenticación de Windows entre proyectos

Restricciones para la integración con diferentes proyectos

Quita la autenticación de Windows de una instancia

Console

gcloud

REST

Conéctate a una instancia con un usuario

Usa el proxy de Cloud SQL Auth con la autenticación de Windows

Pasos para la autenticación de Windows

Ejecuta el proxy de Cloud SQL Auth de forma local

Ejecuta el proxy de Cloud SQL Auth de forma no local

Soluciona problemas de resguardo de NTLM en clientes

Verificación de un resguardo de NTLM para un cliente de Windows

Verificación de un resguardo de NTLM para un cliente de Linux

Configura la autenticación de Kerberos

Conéctate con la autenticación de Windows

Motivos para el resguardo de NTLM

Usuarios de AD locales: cómo crear un acceso a Windows

Configura relaciones de confianza unidireccionales o bidireccionales

Configura una VM de Windows y crea un acceso a Windows

Resuelve problemas relacionados con un usuario de AD local

Sugerencias

Solucionar problemas

¿Qué sigue?