Usar o Microsoft AD gerenciado com o Cloud SQL

Nesta página, você verá maneiras de usar o Cloud SQL para:

• Integrar ao serviço gerenciado do Microsoft Active Directory, também conhecido como Microsoft AD gerenciado.
• Conectar-se a uma instância com um usuário do AD.

Uma instância do Cloud SQL integrada ao Microsoft AD gerenciado é compatível com a Autenticação do Windows, além da autenticação do SQL.

Antes de começar

1. No Console do Google Cloud, selecione o nome do seu projeto.
2. Verifique se a cobrança está ativada para o seu projeto do Google Cloud. Saiba como confirmar se a cobrança está ativada para o seu projeto.
3. Instalar e inicializar a CLI gcloud.
4. Verifique se você tem o papel Cloud SQL Admin na conta de usuário. Acesse a página IAM.
5. Releia os pré-requisitos para integração.

Criar uma instância com o Windows Authentication

É possível integrar-se ao Microsoft AD gerenciado durante a criação da instância, ativando a Autenticação do Windows para a instância. Para vincular, escolha um domínio para a instância a ser mesclada. Se não for possível vincular um domínio, a criação da instância falhará.

Durante a preparação para criar uma instância com a Autenticação do Windows, consulte as dicas e as limitações e alternativas.

Uma instância com IP público é compatível, desde que ela também tenha um IP particular. O IP particular precisa estar ativado para a instância. Depois, é possível usar o IP público ou particular para se conectar à instância, desde que ambos estejam disponíveis.

Veja a seguir as opções para criar uma instância integrada ao Microsoft AD gerenciado.

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

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
}

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

Atualizar uma instância com a autenticação do Windows

É possível atualizar o domínio de uma instância atual, alterando ou adicionando um domínio.

Para informações gerais sobre como atualizar uma instância, consulte Como editar instâncias.

Se uma instância estiver vinculada a um domínio gerenciado do Active Directory, ela primeiro será desvinculada desse domínio antes de ser vinculada ao novo domínio. Se a atualização falhar, a instância talvez não esteja mais vinculada a nenhum domínio.

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

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

Integrar com um domínio AD gerenciado em um projeto diferente

É possível integrar sua instância a um domínio do Microsoft AD gerenciado que esteja em um projeto diferente.

Ao planejar sua integração, analise as restrições.

Ativar o peering de domínio

Antes de prosseguir com as etapas nas seções abaixo, ative o peering de domínio para que seu domínio esteja disponível a todos os projetos necessários com instâncias do Cloud SQL para SQL Server.

Para uma lista de domínios de outros projetos que já estão disponíveis, especifique o seguinte:

`gcloud active-directory peerings list`

Para mais informações, consulte Listar peerings de domínio.

O comando gcloud active-directory peerings list requer a permissão managedidentities.peerings.list. Os papéis a seguir têm essa permissão:

• roles/managedidentities.peeringViewer
• roles/managedidentities.viewer

Para mais informações, consulte Controle de acesso com o IAM.

Crie uma conta de serviço

Repita estas etapas para cada projeto que contém uma instância do Cloud SQL para SQL Server que você pretende integrar.

1. Analise as informações de criação para contas de serviço.

2. Use um comando semelhante ao seguinte para criar uma conta de serviço. Especifique o ID do projeto que contém instâncias do Cloud SQL para SQL Server:

   gcloud beta services identity create --service=sqladmin.googleapis.com \
   --project=[PROJECT_ID]

3. Conceda o papel managedidentities.sqlintegrator no projeto com a instância gerenciada do Microsoft AD. Especifique o ID do projeto que contém a instância gerenciada do Microsoft AD:

   gcloud projects add-iam-policy-binding [PROJECT_ID] \
   --member=serviceAccount:SERVICE_ACCOUNT --role=roles/managedidentities.sqlintegrator

Ativar autenticação do Windows entre projetos

É possível integrar com um domínio do AD em um projeto diferente usando comandos gcloud ou a API REST do Cloud SQL. Em ambos os casos, é preciso especificar o nome completo do recurso do domínio.

Especifique o nome completo do recurso do domínio quando uma instância do Cloud SQL para SQL Server for criada ou atualizada. Há dois formatos compatíveis:

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

Este é um exemplo que usa gcloud:

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

Se você usar um nome de recurso de domínio curto (como DOMAIN_NAME), o sistema presumirá que o domínio do Microsoft AD gerenciado está no mesmo projeto que as instâncias do Cloud SQL for SQL Server.

Restrições para integração com projetos diferentes

Se você estiver fazendo a integração com um domínio do AD gerenciado em um projeto diferente, as seguintes restrições se aplicam:

• Uma única instância do Microsoft AD gerenciado localizada em um projeto diferente pode ser compartilhada por até 10 redes com instâncias do Cloud SQL para SQL Server.
• O Console do Google Cloud só é compatível com instâncias gerenciadas do Microsoft AD localizadas no mesmo projeto. Em vez de usar o Console do Google Cloud, é possível fazer a integração usando os comandos gcloud ou a API REST do Cloud SQL.
• Se o VPC Service Controls for usado, as instâncias do Cloud SQL para SQL Server e uma instância do Microsoft AD gerenciado precisarão estar localizadas no mesmo perímetro.

Além disso, se uma instância estiver integrada a um domínio do AD gerenciado em um projeto diferente, poderá haver imprecisão no nome de domínio totalmente qualificado (FQDN, na sigla em inglês) mostrado no console do Google Cloud para essa instância. Especificamente, na página Visão geral dessa instância, em Conectar-se a esta instância, os FQDNs podem conter strings separadas por barras, que você pode ignorar. Por exemplo, um FQDN impreciso pode ser exibido como:

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

Nesse caso, o FQDN preciso é o seguinte:

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

Remover a autenticação do Windows de uma instância

É possível remover a autenticação do Windows e, portanto, uma integração com o Microsoft AD gerenciado, de uma instância atual.

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

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

Conectar-se a uma instância com um usuário

Para o Cloud SQL para SQL Server, o usuário padrão é sqlserver.

Depois de integrar uma instância ao Microsoft AD gerenciado, é possível se conectar à instância com o usuário sqlserver da seguinte maneira:

1. Crie um login do SQL Server com base em um usuário ou grupo do Windows da seguinte maneira:

   CREATE LOGIN [domain\user_or_group] FROM WINDOWS

2. Faça login na instância usando a Autenticação do Windows com o nome de DNS da instância. Exemplos de nomes de DNS de instância a serem especificados são:

   • Para se conectar por IP particular:

     private.myinstance.us-central1.myproject.cloudsql.mydomain.com

   • Para se conectar por IP público:

     public.myinstance.us-central1.myproject.cloudsql.mydomain.com

   • Para se conectar por meio do proxy do Cloud SQL Auth (consulte também abaixo):

     proxy.myinstance.us-central1.myproject.cloudsql.mydomain.com

   Se você usar o endereço IP da instância, configure os clientes do Kerberos para aceitar nomes de host IP. O Cloud SQL não é compatível com logins de domínios conectados por uma relação de confiança.

Usar o proxy do Cloud SQL Auth com a autenticação do Windows

Use o proxy do Cloud SQL Auth com a integração do Microsoft AD gerenciado.

Antes de começar, revise:

• Sobre o proxy de autenticação do Cloud SQL

• Como se conectar por meio do proxy de autenticação do Cloud SQL

Etapas para autenticação do Windows

Para informações sobre como iniciar o proxy do Cloud SQL Auth, consulte Iniciar o proxy do Cloud SQL Auth.

Para autenticação do Windows, execute o proxy do Cloud SQL Auth na porta 1433. Se você quiser mapear uma entrada predefinida do Service Principal Name (SPN) para um endereço de proxy do Cloud SQL Auth, use:

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

Executar o proxy do Cloud SQL Auth localmente

Se você executar o proxy do Cloud SQL Auth localmente, use o arquivo de hosts para mapear o seguinte para 127.0.0.1:

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

Por exemplo, você pode adicionar o seguinte ao arquivo de hosts (por exemplo, a c:\windows\system32\drivers\etc\hosts):

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

Nesse exemplo, é possível executar o proxy do Cloud SQL Auth usando esse comando e disponibilizá-lo em 127.0.0.1:1433:

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

Executar o proxy do Cloud SQL Auth não localmente

Para executar o proxy do Cloud SQL Auth não localmente, siga as instruções em Como executar o proxy do Cloud SQL Auth localmente, mas use uma entrada diferente no arquivo de hosts.

Especificamente, se um host não local for, por exemplo, MyOtherHost, é possível adicionar o seguinte ao arquivo hosts:

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

Solução de problemas de fallback NTLM em clientes

Se você usa a autenticação do Windows e um endereço IP de instância para fazer login em uma instância, configure um cliente do Kerberos para aceitar nomes de host IP.

O Cloud SQL não é compatível com a autenticação NTLM, mas alguns clientes do Kerberos podem tentar um fallback. Conforme discutido nesta seção, se você tentar se conectar ao SQL Server Management Studio (SSMS) e a seguinte mensagem de erro ocorrer, uma causa provável é o fallback do NTLM:

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

O NTLM é um conjunto de protocolos de segurança para autenticação da Microsoft. Consulte também Motivos para o fallback do NTLM.

Verificação de um fallback do NTLM para um cliente Windows

No Windows, para verificar se um fallback de NTLM causou um erro:

1. Faça login com as credenciais locais desejadas (não use "Executar como...").
2. Abra um prompt de comando.
3. Execute klist purge.
4. No SSMS, tente se conectar ao SQL Server com a autenticação do Windows.
5. Execute klist e verifique se há um ticket emitido para "MSSQLSvc/<address>:1433 @ domain".
6. Se não houver um ticket como esse, o fallback de NTLM é a causa provável do erro.
7. Se o ticket existir, verifique se o driver do SQL Server não exige a autenticação do NTLM. Verifique também se a autenticação do NTLM é aplicada por meio da Política de Grupo.

Verificação de um fallback de NTLM para um cliente Linux

No Ubuntu 16.04, para verificar se um fallback de NTLM causou um erro, use as etapas nesta seção. As etapas são semelhantes às de outras distribuições do Linux.

Configurar a autenticação do Kerberos

1. Para configurar um cliente do Kerberos, faça o seguinte:

   sudo apt-get install krb5-user
   

2. Quando for solicitado o realm padrão, digite um nome de domínio local em letras maiúsculas.

3. Execute o seguinte comando para instalar as ferramentas de linha de comando do 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
   

Conectar-se com a autenticação do Windows

1. Execute a ferramenta kinit da seguinte maneira: kinit <user_account>
2. Para se conectar à autenticação do Windows, execute: /opt/mssql-tools/bin/sqlcmd -S <address >>
3. Execute o comando klist e verifique se um ticket foi emitido especificamente para: "MSSQLSvc/<address>:1433 @ domain"
4. Se o ticket não foi emitido, o erro acima provavelmente indica um problema que causa o fallback do NTLM.

Motivos para o fallback do NTLM

O fallback do NTLM é uma configuração incorreta do cliente que pode ser associada às seguintes condições:

• Por padrão, o Windows não tentará a autenticação do Kerberos para um host se o nome do host for um endereço IP. Para ativar a autenticação do Kerberos no domínio gerenciado, teste o método descrito na documentação da Microsoft. Esse método não funciona com credenciais locais quando é preciso usar FQDNS.
• A autenticação do Kerberos pelas relações de confiança externas não funciona. Em vez disso, use relações de confiança entre florestas, conforme descrito aqui.
• A autenticação do Kerberos requer o roteamento de sufixo de nome para permitir a descoberta de serviços em outra floresta. Tente o método descrito aqui.
• A autenticação do Kerberos não funcionará se não houver SPN registrado no serviço. Use apenas FQDNs ou endereços IP recebidos do console do Google Cloud para se conectar à autenticação do Windows.

Usuários do AD no local: como criar um login do Windows

É possível usar um usuário do AD local para criar um login do Windows no Cloud SQL para SQL Server.

Como exemplo, é possível se conectar usando o SQL Server Management Studio (SMSS) em execução em uma VM do Windows hospedada na nuvem privada virtual (VPC, na sigla em inglês) do projeto do Google Cloud.

Para a autenticação do Windows neste contexto, o Cloud SQL para SQL Server é compatível apenas com o protocolo Kerberos. Para a autenticação do Windows baseada no Kerberos, o cliente precisa resolver o nome DNS do AD local e do Microsoft AD gerenciado.

Configurar confiança unilateral ou bidirecional

Primeiramente, decida se usará uma relação de confiança unidirecional ou bidirecional.

Em seguida, siga as instruções para estabelecer a confiança entre o domínio do AD local e o gerenciado do Microsoft AD.

Configurar uma VM do Windows e criar um login do Windows

Depois de estabelecer a confiança entre o domínio do AD no local e o domínio gerenciado do Microsoft AD, conclua as etapas a seguir. Por exemplo, estas etapas usam o SQL Server Management Studio (SSMS), em execução em uma VM do Windows, hospedado na VPC do projeto do Google Cloud:

1. Crie uma VM do Windows.
   • Crie uma VM com uma versão do Windows compatível com o Microsoft AD gerenciado.
   • Crie a VM no projeto que hospeda seu domínio do Microsoft AD gerenciado. Se houver uma VPC compartilhada que seja uma rede autorizada, você também poderá criar a VM em qualquer um de seus projetos de serviço.
   • Crie a VM em uma rede VPC que seja uma rede autorizada do domínio Microsoft AD gerenciado e que tenha configurado o acesso a serviços particulares para o Cloud SQL.
2. Vincule a VM do Windows ao domínio do Microsoft AD gerenciado.
3. Instale o SSMS na VM do Windows.
4. Resolva o domínio local na rede VPC.
   • Na rede autorizada em que a VM do Windows está em execução, ative a resolução de DNS local usando as etapas na página Resolver consultas para objetos do AD não gerenciado da Microsoft. As etapas nessa página são pré-requisitos para que a autenticação do Windows baseada no Kerberos funcione para usuários locais.

5. Crie um login do Windows para um usuário local.

   • Siga as instruções CRIAR LOGIN para criar um login do Windows para um usuário local. Por exemplo, especifique um comando semelhante ao seguinte:

   CREATE LOGIN [DOMAIN_NAME\USER_NAME] FROM WINDOWS
   

6. Faça login na instância do Cloud SQL para SQL Server usando as instruções específicas do aplicativo para fazer login em um usuário local. Por exemplo, se você estiver usando o SQL Server Management Studio, consulte estas instruções.

Resolver problemas relacionados a um usuário do AD no local

Se ocorrer um problema durante o login em uma instância do Cloud SQL para SQL Server, execute estas verificações:

• Verifique as configurações de firewall da rede local e da VPC autorizada pelo projeto. Basta usar as instruções para criar uma confiança com um domínio local.
• Verifique o roteamento de sufixo de nome para a relação de confiança local.
• Verifique se é possível executar essas operações de resolução de DNS na VM do Windows que está executando o SSMS:
  • nslookup fqdn-for-managed-ad-domain
  • nslookup fqdn-for-on-premises-ad-domain
  • nslookup fqdn-for-cloud-sql-server-instance

Dicas

• Uma instância com IP público é compatível, desde que ela também tenha um IP particular. O IP particular precisa estar ativado para a instância. Depois, é possível usar o IP público ou particular para se conectar à instância, desde que ambos estejam disponíveis.
• Antes de criar uma instância, incluindo uma instância de substituição, analise o seguinte conforme necessário:
  • Saiba como usar o IP particular
  • Configurar IP público
• O Terraform é compatível.
• Se você receber um dos erros a seguir, confirme se atendeu a todos os pré-requisitos de integração:
  • "Conta de serviço por produto, por projeto não encontrada"
  • "Permissão insuficiente para integrar ao serviço gerenciado para o domínio do Microsoft Active Directory"
• Se você receber o erro "Domínio não encontrado", verifique se o nome de domínio que diferencia maiúsculas de minúsculas está correto.
• Se a autenticação do Windows falhar em um domínio conectado por uma relação de confiança, verifique se a autenticação do Windows funciona para um usuário de um domínio gerenciado. Em caso afirmativo, faça o seguinte:
  1. Verifique se você usou um nome DNS. Os endereços IP não são compatíveis com os domínios conectados usando uma relação de confiança.
  2. Certifique-se de que você seguiu todas as etapas para criar uma confiança com um domínio local, incluindo a abertura de todas as portas de firewall.
  3. Valide a confiança.
  4. Verifique se a direção da confiança permite que os usuários do domínio (conectados por um relacionamento de confiança) façam a autenticação no domínio gerenciado.
  5. Verifique se o roteamento do sufixo de nome está definido no domínio que está conectado por meio de uma relação de confiança.
  6. Verifique se a confiança funciona sem usar o Cloud SQL para SQL Server:
     1. Crie uma VM do Windows.
     2. Vincule-a ao domínio do Microsoft AD gerenciado.
     3. Tente executar, por exemplo, o Bloco de Notas como um usuário pelo domínio conectado por meio de uma relação de confiança.
  7. Reinicie a VM do cliente e teste novamente a Autenticação do Windows.
• Você pode tentar criar um login do SQL Server, mas receberá o seguinte erro: "Domínio/nome do usuário ou grupo do Windows NT não encontrado. Verifique o nome novamente". Isso pode ter ocorrido porque os grupos locais de domínios não são compatíveis. Se aplicável, use grupos globais ou universais.
• Quando emitidas por um usuário de um domínio conectado por uma relação de confiança, as consultas do SQL Server podem resultar no seguinte erro: "Não foi possível obter informações sobre o grupo/usuário do Windows NT". Esse erro poderá ocorrer, por exemplo, se você estiver criando logins de domínios conectados por meio de um relacionamento de confiança. O erro também poderá ocorrer se você conceder privilégios a logins de domínios conectados por meio de um relacionamento de confiança. Nesses casos, repetir a operação costuma funcionar. Se a nova tentativa falhar, feche a conexão e abra uma nova.

• Se você receber o erro "Não foi possível conseguir informações sobre o grupo/usuário do Windows NT", verifique a conectividade de rede com domínios locais usando o arquivo de registros active_directory.log disponível no Cloud Logging sobre a instância do Cloud SQL para SQL Server. Esse arquivo contém os seguintes diagnósticos sobre alterações de conectividade no domínio local:

  • Domínios locais confiáveis pela instância do Cloud SQL para SQL Server. Por exemplo, o registro a seguir mostra a mudança de domínios não confiáveis para dois novos domínios confiáveis com os respectivos nomes do NetBIOS, ONPREM e CHILD:

    2023-06-12 20:55:09.975 Detected change in trusted onprem domains: Previously trusted onprem domains: []. Current trusted onprem domains: [ONPREM CHILD]

    Se um domínio no local não estiver listado ou estiver registrado como não confiável, verifique se a confiança existe com o domínio do AD gerenciado e está validada. Se houver uma confiança unidirecional entre o domínio do AD gerenciado e o domínio local, talvez outros domínios locais confiáveis pelo domínio local não estejam visíveis.
  • Domínios locais acessíveis e inacessíveis usando um ping comum na instância do Cloud SQL para SQL Server. Por exemplo, o registro a seguir mostra a mudança de nenhum domínio acessível para dois novos domínios acessíveis, onprem.com e 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]

    Se um domínio não estiver listado nos registros de acessibilidade, o domínio precisará primeiro ser registrado como confiável. Caso contrário, ele não será verificado quanto à acessibilidade. Sempre há um peering de VPC entre um projeto com instâncias locais e projetos do Google Cloud. Ter sequer um peering de VPC a mais introduz uma conexão de peering transitiva, o que não é compatível com o Cloud SQL. Em vez disso, recomendamos que você use um túnel de VPN para conectar um domínio local ao Cloud SQL. Deve haver no máximo uma conexão de peering entre o projeto local e o projeto do Google Cloud com as instâncias do Cloud SQL para SQL Server.
  • Pings de chamada de procedimento remoto da Microsoft (MSRPC) bem-sucedidos e malsucedidos para domínios locais da instância do Cloud SQL para SQL Server. Por exemplo, o registro a seguir mostra a mudança de não haver domínios passíveis de ping de MSRPC para dois novos domínios passíveis de ping de MSRPC, ONPREM e CHILD:

    2023-06-12 20:55:10.664 Detected change in MSRPC pingable domains: Previously pingable onprem domains: []. Current pingable onprem domains: [ONPREM CHILD]

    Os pings de MSRPC são incluídos como diagnósticos extras e podem não funcionar em algumas configurações. Ainda é possível verificar a conectividade do domínio local usando os dois primeiros diagnósticos.

• Se as consultas do SQL Server resultarem no erro "O login é de um domínio não confiável", os endereços IP não são compatíveis com usuários de domínios conectados por uma relação de confiança. Além disso, as seguintes ações podem resolver esse problema:

  • Se um endereço IP for usado para conectar usuários de um domínio gerenciado, siga estas instruções.
  • Evite usar proxies e sempre use o mesmo nome DNS para se conectar ao Cloud SQL para SQL Server, conforme visto no Console do Google Cloud.
  • Limpe os tíquetes do Kerberos existentes. O erro acima poderia ocorrer se você tivesse um cliente conectado recentemente a uma instância do Cloud SQL para SQL Server e a instância fosse interrompida e iniciada. Outra possibilidade de ocorrer o erro seria se a Autenticação do Windows fosse desativada e reativada para a instância do Cloud SQL para SQL Server. Se o cliente usar o cache de credenciais do Windows, bloqueie e desbloqueie a estação de trabalho do cliente ou execute klist purge.

• Uma tentativa de ativar a autenticação do Windows pode resultar no erro "Esta instância precisa de uma data de criação mais recente para aceitar o Serviço gerenciado para o Microsoft Active Directory". Lembre-se das seguintes informações sobre esse erro:

  • No Cloud SQL, se uma instância do Cloud SQL para SQL Server tiver sido criada em 12 de março de 2021 ou antes, ela não poderá ser integrada ao Microsoft AD gerenciado.
  • Em alguns casos, se você criar uma instância do Cloud SQL para SQL Server sem ativar o Microsoft AD gerenciado no processo, poderá encontrar o mesmo erro. Depois de analisar as outras dicas desta seção, crie uma nova instância, ativando o Microsoft AD gerenciado no momento em que você criar a instância.

• Uma tentativa de criar uma instância do Cloud SQL para SQL Server pode resultar no erro "Esta instância não é compatível com o serviço gerenciado do Microsoft Active Directory". Se você receber esse erro, talvez o projeto não seja compatível. Tente usar um projeto diferente

• Se uma instância tiver problemas contínuos com a autenticação do Windows (independentemente de a instância ter sido atualizada recentemente), tente desvincular o domínio do Active Directory gerenciado e, em seguida, vincule-o novamente. Para isso, use o procedimento de atualização para desvincular e vincular o domínio na sequência. Isso não remove nenhum usuário ou login autenticado pelo Windows existente nos seus bancos de dados. No entanto, a remoção da Autenticação do Windows faz com que uma instância reinicie.

• Use a ferramenta de diagnóstico do AD para solucionar problemas de configuração do AD com seu domínio local e as instâncias do Cloud SQL para SQL Server no console do Google Cloud.

Resolver problemas

Clique nos links da tabela para ver detalhes:

A seguir

• Confirme se você leu toda a página de visão geral, que inclui limitações e recursos não compatíveis. Essa página também inclui links para outros documentos.