Use o Microsoft AD gerido com o Cloud SQL

Esta página descreve as formas de usar o Cloud SQL para:

  • Integre com o serviço gerido para o Microsoft Active Directory (também denominado Microsoft AD gerido).
  • Associe-se a uma instância com um utilizador do AD.

Uma instância do Cloud SQL integrada com o Microsoft AD gerido suporta a autenticação do Windows, além da autenticação SQL.

Antes de começar

  1. Na Google Cloud consola, selecione o nome do projeto.
  2. Certifique-se de que a faturação está ativada para o seu Google Cloud projeto. Saiba como confirmar se a faturação está ativada para o seu projeto.
  3. Instale e inicialize a CLI gcloud.
  4. Certifique-se de que tem a função Cloud SQL Admin na sua conta de utilizador. Aceda à página IAM.
  5. Reveja os pré-requisitos para a integração.

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

Pode integrar com o Microsoft AD gerido durante a criação de instâncias, o que permite a autenticação do Windows para a instância. Para fazer a integração, escolhe um domínio para a instância aderir. Se a associação a um domínio falhar, a criação da instância falha.

Em preparação para criar uma instância com a autenticação do Windows, reveja as sugestões e as limitações e alternativas.

É suportada uma instância com IP público, desde que também tenha um IP privado; o IP privado tem de estar ativado para a instância. Em seguida, pode optar por usar o IP público ou o IP privado para estabelecer ligação à instância, desde que ambos estejam disponíveis.

Seguem-se as opções para criar uma instância integrada com o Managed Microsoft AD.

Consola

  1. Na Google Cloud consola, aceda à página Instâncias do Cloud SQL.

    Aceda a Instâncias do Cloud SQL

  2. Clique em Criar instância.
  3. Clique em Escolher SQL Server.
  4. Introduza um nome para a instância. Não inclua informações confidenciais nem de identificação pessoal no nome da instância, uma vez que é visível externamente. Não tem de incluir o ID do projeto no nome da instância. Esta é criada automaticamente quando adequado (por exemplo, nos ficheiros de registo).
  5. Introduza a palavra-passe do utilizador . 'sqlserver'
  6. Defina a região da sua instância. Consulte as práticas recomendadas para a integração com o Microsoft AD gerido.
  7. Na secção Opções de configuração, defina as opções pretendidas (mas aguarde até ao passo seguinte para as opções de autenticação).
  8. Clique em Autenticação. O menu pendente para associar um domínio do Active Directory gerido apresenta todos os domínios do Microsoft AD geridos que foram adicionados anteriormente no seu projeto.
  9. No menu pendente para aderir a um domínio do Active Directory gerido, selecione um domínio.
  10. Quando terminar de selecionar as opções de configuração, clique em Criar. O Cloud SQL cria automaticamente uma conta de serviço por produto e por projeto para si. Se a conta não tiver a função adequada, é-lhe pedido que conceda a função managedidentities.sqlintegrator.

gcloud

O comando seguinte cria uma instância integrada com o Microsoft AD gerido e, por isso, está ativada para a autenticação do Windows. Para ver informações acerca do comando básico para criar uma instância, consulte Criar instâncias.

Especifique um parâmetro de --active-directory-domain=DOMAIN no comando gcloud. Por exemplo, especifique o seguinte: --active-directory-domain=ad.mydomain.com

Segue-se um protótipo do comando 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 criar uma instância integrada com o Managed Microsoft AD, use um recurso do 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

Através da API REST, pode criar uma instância integrada com o Managed Microsoft AD. Especifique um domínio, como subdomain.mydomain.com, para o campo domain, conforme mostrado neste protótipo de um pedido:

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

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

Pode atualizar o domínio de uma instância existente, alterando ou adicionando um domínio.

Para informações gerais sobre a atualização de uma instância, consulte o artigo Editar instâncias.

Se uma instância estiver atualmente associada a um domínio do AD gerido, a instância é inicialmente desassociada desse domínio antes de ser associada ao novo domínio. Se a atualização falhar, a instância pode deixar de estar associada a qualquer domínio.

Consola

  1. Na Google Cloud consola, aceda à página Instâncias do Cloud SQL.

    Aceda a Instâncias do Cloud SQL

  2. Para abrir a página Vista geral de uma instância, clique no nome da instância.
  3. Clique em Edit.
  4. Clique em Autenticação. O menu pendente Associar a um domínio do Active Directory apresenta os domínios do Microsoft AD geridos que foram adicionados anteriormente no seu projeto.
  5. No menu pendente para associar um domínio do Active Directory gerido, selecione um novo domínio (de substituição) para a sua instância.
  6. Clique em Guardar para aplicar as alterações.

gcloud

Segue-se um protótipo de um comando para atualizar uma instância existente. O comando adiciona ou substitui um domínio. Transmita --active-directory-domain=DOMAIN para o comando da seguinte forma:

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

REST

Através da API REST, pode atualizar uma instância existente. Especifique um domínio, como subdomain.mydomain.com, no campo domain. Segue-se um protótipo de um pedido:

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

Integre com um domínio do AD gerido num projeto diferente

Pode integrar a sua instância com um domínio do Microsoft AD gerido que esteja num projeto diferente.

Ao planear a integração, reveja as restrições.

Ative a interligação de domínios

Antes de avançar com os passos nas secções abaixo, ative a interligação de domínios para que o seu domínio esteja disponível para todos os projetos necessários com instâncias do Cloud SQL para SQL Server.

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

`gcloud active-directory peerings list`

Para mais informações, consulte o artigo Liste as interligações de domínios.

O comando gcloud active-directory peerings list requer a autorização managedidentities.peerings.list. As seguintes funções têm esta autorização:

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

Para mais informações, consulte o artigo Controlo de acesso com a IAM.

Criar uma conta de serviço

Repita estes passos para cada projeto que contenha uma instância do Cloud SQL para SQL Server que pretenda integrar.

  1. Reveja as informações gerais para criar 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 a função managedidentities.sqlintegrator no projeto com a instância do Microsoft AD gerida. Especifique o ID do projeto que contém a instância do Managed Microsoft AD:

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

Ative a autenticação do Windows entre projetos

Pode fazer a integração com um domínio do AD num projeto diferente através de gcloud comandos ou da API REST do Cloud SQL. Em qualquer dos casos, tem de especificar o nome do recurso de domínio completo.

Especifique o nome completo do recurso de domínio quando uma instância do Cloud SQL para SQL Server é criada ou atualizada. São suportados dois formatos:

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

Segue-se um exemplo com gcloud:

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

Se usar um nome de recurso de domínio curto (como DOMAIN_NAME), o sistema assume que o seu domínio do Microsoft AD gerido está no mesmo projeto que as suas instâncias do Cloud SQL para SQL Server.

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

Se estiver a fazer a integração com um domínio do AD gerido num projeto diferente, aplicam-se as seguintes restrições:

  • Até 10 redes com instâncias do Cloud SQL para SQL Server podem partilhar uma instância do Microsoft AD gerida localizada num projeto diferente.
  • A consola Google Cloud só suporta instâncias do Microsoft AD geridas localizadas no mesmo projeto. Em vez de usar a Google Cloud consola, pode fazer a integração através de comandos gcloud ou da API REST do Cloud SQL.
  • Se forem usados os VPC Service Controls, as instâncias do Cloud SQL para SQL Server e uma instância do Microsoft AD gerida têm de estar localizadas no mesmo perímetro.

Além disso, se uma instância estiver integrada com um domínio do AD gerido num projeto diferente, o nome de domínio totalmente qualificado (FQDN) apresentado na consolaGoogle Cloud pode ser impreciso para essa instância. Especificamente, na página Vista geral dessa instância, em Estabelecer ligação a esta instância, os FQDNs podem conter strings separadas por barras invertidas, que pode ignorar. Por exemplo, um FQDN incorreto pode ser apresentado como:

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

Nesse caso, o FQDN preciso é: 

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

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

Pode remover a autenticação do Windows e, por conseguinte, uma integração do Microsoft AD gerido de uma instância existente.

Consola

  1. Na Google Cloud consola, aceda à página Instâncias do Cloud SQL.

    Aceda a Instâncias do Cloud SQL

  2. Para abrir a página Vista geral de uma instância, clique no nome da instância.
  3. Clique em Edit.
  4. Clique em Autenticação. O menu pendente para associar um domínio do Active Directory gerido apresenta os domínios do Microsoft AD geridos que foram adicionados anteriormente no seu projeto.
  5. No menu pendente, selecione Nenhum domínio/Aderir mais tarde para a sua instância.
  6. Leia a mensagem sobre o reinício da instância e clique em Fechar.
  7. Clique em Guardar para aplicar as alterações.

gcloud

Para remover uma instância de um domínio, removendo assim a autenticação do Windows, use um valor em branco para o domínio. Ou seja, no comando, use um valor em branco para o parâmetro --active-directory-domain, da seguinte forma:

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

REST

Através da API REST, pode remover uma instância de um domínio. Especifique um valor em branco no campo domain, da seguinte forma:

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

Associar-se a uma instância com um utilizador

Para o Cloud SQL para SQL Server, o utilizador predefinido é sqlserver.

Depois de integrar uma instância com o Microsoft AD gerido, pode estabelecer ligação à instância com o utilizador sqlserver, da seguinte forma:

  1. Crie um início de sessão do SQL Server com base num utilizador ou num grupo do Windows, da seguinte forma:

    CREATE LOGIN [domain\user_or_group] FROM WINDOWS

  2. Inicie sessão na instância com a autenticação do Windows e o nome DNS da instância. Seguem-se exemplos de nomes DNS de instâncias a especificar:

    • Para estabelecer ligação através de IP privado: 

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

    • Para se ligar através de IP público: 

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

    • Para estabelecer ligação através do proxy Auth do Cloud SQL (consulte também abaixo): 

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

    Se usar o endereço IP da instância, tem de configurar os clientes Kerberos para suportarem nomes de anfitriões IP. O Cloud SQL não suporta inícios de sessão de domínios associados através de uma relação de confiança.

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

Pode usar o proxy Auth do Cloud SQL com a sua integração do Microsoft AD gerido.

Antes de começar, reveja:

Passos para a autenticação do Windows

Para obter informações gerais sobre como iniciar o proxy Auth do Cloud SQL, consulte o artigo Inicie o proxy Auth do Cloud SQL.

Para a autenticação do Windows, tem de executar o proxy Auth do Cloud SQL na porta 1433. Para mapear uma entrada de nome principal do serviço (SPN) predefinida para um endereço do proxy Auth do Cloud SQL, use:

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

Execute o proxy Auth do Cloud SQL localmente

Se executar o proxy Auth do Cloud SQL localmente, use o ficheiro hosts para mapear o seguinte para 127.0.0.1:

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

Por exemplo, pode adicionar o seguinte ao ficheiro hosts (por exemplo, para c:\windows\system32\drivers\etc\hosts):

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

Nesse exemplo, pode executar o proxy Auth do Cloud SQL com este comando e torná-lo disponível em 127.0.0.1:1433:

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

Execute o proxy Auth do Cloud SQL não localmente

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

Especificamente, se um anfitrião não local for, por exemplo, MyOtherHost, pode adicionar o seguinte ao ficheiro hosts:

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

Resolução de problemas de alternativa NTLM em clientes

Se usar a autenticação do Windows e um endereço IP de instância para iniciar sessão numa instância, tem de configurar um cliente Kerberos para suportar nomes de anfitriões IP.

O Cloud SQL não suporta a autenticação NTLM, mas alguns clientes Kerberos podem tentar recorrer a ela. Conforme abordado nesta secção, se tentar estabelecer ligação com o SQL Server Management Studio (SSMS) e ocorrer a seguinte mensagem de erro, 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)

NTLM é um conjunto de protocolos de segurança da Microsoft para autenticação. Veja também os motivos da alternativa NTLM.

Validação de uma alternativa NTLM para um cliente Windows

No Windows, para verificar se uma alternativa NTLM causou um erro:

  1. Inicie sessão com as credenciais no local pretendidas (não use "Executar como…").
  2. Abra uma linha de comandos.
  3. Corrida klist purge.
  4. No SSMS, tente estabelecer ligação ao SQL Server com a autenticação do Windows.
  5. Execute o comando klist e verifique se foi emitido um pedido para "MSSQLSvc/<address>:1433 @ domain".
  6. Se não existir esse pedido, a alternativa NTLM é a causa provável do erro.
  7. Se existir um registo desse tipo, verifique se o controlador do SQL Server não aplica a autenticação NTLM. Verifique também se a autenticação NTLM é aplicada através da Política de Grupo.

Validação de uma alternativa NTLM para um cliente Linux

No Ubuntu 16.04, para verificar se uma alternativa NTLM causou um erro, siga os passos nesta secção. Os passos são semelhantes aos de outras distribuições do Linux.

Configure a autenticação Kerberos

  1. Configure um cliente Kerberos:

    sudo apt-get install krb5-user

  2. Quando lhe for pedido o domínio predefinido, introduza um nome de domínio no local em letras maiúsculas.

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

Estabeleça ligação com a autenticação do Windows

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

Motivos para o recuo do NTLM

A alternativa ao NTLM é uma configuração incorreta do cliente que pode estar associada às seguintes condições:

  • Por predefinição, o Windows não tenta a autenticação Kerberos para um anfitrião se o nome do anfitrião for um endereço IP. Para ativar a autenticação Kerberos a partir do domínio gerido, experimente o método descrito na documentação da Microsoft. Este método não funciona com credenciais no local quando tem de usar FQDNs.
  • A autenticação Kerberos através de relações de confiança externas não funciona. Em alternativa, use relações de confiança entre florestas, conforme descrito aqui.
  • A autenticação Kerberos requer o encaminhamento do sufixo do nome para permitir a localização de serviços noutra floresta. Experimente o método descrito aqui.
  • A autenticação Kerberos não funciona se não existir um SPN registado para o serviço. Use apenas FQDNs ou endereços IP que obtém da Google Cloud consola para estabelecer ligação com a autenticação do Windows.

Utilizadores do AD no local: criar um início de sessão do Windows

Pode usar um utilizador do AD no local para criar um início de sessão do Windows no Cloud SQL para SQL Server.

Por exemplo, pode estabelecer ligação através do SQL Server Management Studio (SMSS) executado numa VM do Windows alojada na nuvem privada virtual (VPC) do seu projeto. Google Cloud

Para a autenticação do Windows neste contexto, o Cloud SQL para SQL Server só suporta o protocolo Kerberos. Para a autenticação do Windows baseada no Kerberos, o cliente tem de resolver o nome DNS do AD no local e do AD gerido da Microsoft.

Configure uma confiança unidirecional ou bidirecional

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

Depois, siga as instruções para estabelecer confiança entre o domínio do AD no local e o domínio do AD gerido da Microsoft.

Configure uma VM do Windows e crie um início de sessão do Windows

Depois de estabelecer uma relação de confiança entre o domínio do AD no local e o domínio do Microsoft AD gerido, conclua os seguintes passos. Por exemplo, para fins de demonstração, estes passos usam o SQL Server Management Studio (SSMS), executado numa VM do Windows, alojado na VPC do seu Google Cloud projeto:

  1. Crie uma VM do Windows.
    • Crie uma VM com uma versão do Windows suportada pelo Managed Microsoft AD.
    • Crie a VM no projeto que aloja o seu domínio do Microsoft AD gerido. Se existir uma VPC partilhada que seja uma rede autorizada, também pode criar a VM em qualquer um dos respetivos projetos de serviço.
    • Crie a VM numa rede VPC que seja uma rede autorizada do domínio do Microsoft AD gerido e tenha configurado o acesso privado ao serviço para o Cloud SQL.
  2. Associe a VM do Windows ao domínio do Microsoft AD gerido.
  3. Instale o SSMS na VM do Windows.
  4. Resolva o domínio no local na rede VPC.
    • A partir da rede autorizada na qual a VM do Windows está a ser executada, ative a resolução de DNS no local através dos passos na página Resolva consultas para objetos do Microsoft AD não geridos. Os passos nessa página são pré-requisitos para que a autenticação do Windows baseada em Kerberos funcione para utilizadores no local.

  5. Crie um início de sessão do Windows para um utilizador no local.

    CREATE LOGIN [DOMAIN_NAME\USER_NAME] FROM WINDOWS

  6. Inicie sessão na sua instância do Cloud SQL para SQL Server através das instruções específicas da aplicação para iniciar sessão como utilizador no local. Por exemplo, se estiver a usar o SQL Server Management Studio, consulte estas instruções.

Se ocorrer um problema durante um início de sessão numa instância do Cloud SQL para SQL Server, faça estas verificações:

  • Valide as configurações da firewall da rede no local e da VPC autorizada pelo projeto através das instruções para criar uma relação de confiança com um domínio no local.
  • Valide o Encaminhamento de sufixos de nomes para a relação de confiança no local.
  • Verifique se consegue realizar estas operações de resolução de DNS a partir da VM do Windows que está a executar o SSMS:
    • nslookup fqdn-for-managed-ad-domain
    • nslookup fqdn-for-on-premises-ad-domain
    • nslookup fqdn-for-cloud-sql-server-instance

Dicas

  • É suportada uma instância com IP público, desde que também tenha um IP privado. O IP privado tem de estar ativado para a instância. Em seguida, pode optar por usar o IP público ou o IP privado para estabelecer ligação à instância, desde que ambos estejam disponíveis.
  • Antes de criar uma instância, inclusive como instância de substituição, reveja o seguinte, conforme necessário:
  • O Terraform é suportado.
  • Se receber um dos seguintes erros, confirme que cumpriu todos os pré-requisitos para a integração:
    • "Não foi encontrada a conta de serviço por produto e por projeto"
    • "Permissão insuficiente para integrar com o domínio do Managed Service for Microsoft Active Directory"
  • Se receber o erro "Domain not found" (Domínio não encontrado), verifique se o nome do domínio sensível a maiúsculas e minúsculas está correto.
  • Se a autenticação do Windows falhar a partir de um domínio ligado através de uma relação de confiança, verifique se a autenticação do Windows funciona para um utilizador de um domínio gerido. Se o fizer, então:
    1. Verifique se usou um nome DNS. Os endereços IP não são suportados a partir de domínios ligados através de uma relação de confiança.
    2. Certifique-se de que seguiu todos os passos para criar uma relação de confiança com um domínio no local, incluindo a abertura de todas as portas da firewall.
    3. Valide a confiança.
    4. Verifique se a direção da confiança permite que os utilizadores do domínio (ligado através de uma relação de confiança) se autentiquem no domínio gerido.
    5. Verifique se o encaminhamento do sufixo do nome está definido no domínio que está ligado através 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. Associe-o ao domínio do Microsoft AD gerido.
      3. Tente executar, por exemplo, o Bloco de notas como utilizador do domínio que está ligado através de uma relação de confiança.
    7. Reinicie a VM do cliente e volte a testar a autenticação do Windows.
  • Pode tentar criar um início de sessão do SQL Server, mas, em seguida, recebe o seguinte erro: "Windows NT user or group domain\name not found. Verifique novamente o nome". Isto pode ter ocorrido porque os grupos locais do domínio não são suportados. Se aplicável, use grupos globais ou universais em alternativa.
  • Quando emitidas por um utilizador de um domínio ligado através de 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/utilizador do Windows NT". Este erro pode ocorrer, por exemplo, se estiver a criar inícios de sessão a partir de domínios ligados através de uma relação de confiança. O erro também pode ocorrer se estiver a conceder privilégios a inícios de sessão de domínios ligados através de uma relação de confiança. Nestes casos, a repetição da operação costuma ter êxito. Se a nova tentativa falhar, feche a ligação e abra uma nova ligação.

  • Se receber o erro "Não foi possível obter informações sobre o grupo/utilizador do Windows NT", verifique a conetividade de rede com domínios no local através do ficheiro de registo active_directory.log disponível no Cloud Logging para a instância do Cloud SQL para SQL Server. Este ficheiro contém os seguintes diagnósticos relativos a alterações de conetividade ao domínio no local:

    • Domínios no local fidedignos pela instância do Cloud SQL para SQL Server. Por exemplo, o registo seguinte mostra a alteração de nenhum domínio fidedigno para dois novos domínios fidedignos como os respetivos nomes 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 registado como não fidedigno, verifique se a fidedignidade existe com o domínio do AD gerido e se é validada. Se existir uma confiança unidirecional entre o domínio do AD gerido e o domínio no local, outros domínios no local fidedignos do domínio no local podem não estar visíveis.
    • Domínios no local acessíveis e inacessíveis através de um ping normal a partir da instância do Cloud SQL para SQL Server. Por exemplo, o seguinte registo mostra a alteração 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 registos de acessibilidade, certifique-se de que é registado primeiro como um domínio fidedigno. Caso contrário, não é verificada a acessibilidade. Temos sempre uma interligação de VPC entre um projeto com instâncias no local e Google Cloud projetos. Ter mais um intercâmbio de VPC introduz uma ligação de intercâmbio transitivo, que o Cloud SQL não suporta. Em alternativa, recomendamos que use um túnel VPN para ligar um domínio no local ao Cloud SQL. Deve existir, no máximo, uma ligação de peering entre o projeto no local e o projeto Google Cloud com as instâncias do Cloud SQL para SQL Server.
    • Pings de chamadas de procedimentos remotos da Microsoft (MSRPC) bem-sucedidos e sem êxito para domínios no local a partir da instância do Cloud SQL para SQL Server. Por exemplo, o registo seguinte mostra a alteração de não ter domínios acessíveis por ping MSRPC para ter dois novos domínios acessíveis por ping 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 MSRPC estão incluídos como diagnósticos adicionais e podem não funcionar em algumas configurações. Ainda pode validar a conetividade do domínio no local através dos dois primeiros diagnósticos.

  • Se as consultas do SQL Server resultarem no erro "O início de sessão é de um domínio não fidedigno", tenha em atenção que os endereços IP não são suportados para utilizadores de domínios ligados através de uma relação de confiança. Além disso, as seguintes ações podem resolver este problema:

    • Se um endereço IP for usado para ligar utilizadores a partir de um domínio gerido, siga estas instruções.
    • Evite usar proxies e use sempre o mesmo nome DNS para estabelecer ligação ao Cloud SQL para SQL Server, tal como vê o nome na Google Cloud consola.
    • Elimine as permissões Kerberos existentes. O erro acima pode ocorrer se tiver um cliente que tenha sido recentemente ligado a uma instância do Cloud SQL para SQL Server e a instância tiver sido parada e iniciada. Em alternativa, o erro pode ocorrer se a autenticação do Windows tiver sido desativada e, em seguida, reativada para a instância do Cloud SQL para SQL Server. Se o cliente usar a 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 suportar o serviço gerido para o Microsoft Active Directory". Tenha em atenção o seguinte acerca deste erro:

    • No Cloud SQL, se uma instância do Cloud SQL para SQL Server tiver sido criada a 12 de março de 2021 ou antes, não pode ser integrada com o Microsoft AD gerido.
    • Em determinados casos, se criar uma instância do Cloud SQL para SQL Server e não ativar o Managed Microsoft AD no momento da criação, pode receber o mesmo erro. Depois de rever as outras sugestões nesta secção, crie uma nova instância, ativando o Microsoft AD gerido no momento em que cria 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 suporta o serviço gerido para o Microsoft Active Directory". Se receber este erro, o projeto pode não ser suportado. Experimente 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), experimente desassociar o domínio do Active Directory gerido e, em seguida, voltar a associá-lo. Para tal, use o procedimento de atualização para anular a associação e, em seguida, voltar a associar o domínio. Esta ação não remove utilizadores autenticados pelo Windows nem inícios de sessão existentes nas suas bases de dados. No entanto, a remoção da autenticação do Windows faz com que uma instância seja reiniciada.

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

Resolver problemas

Clique nos links na tabela para ver detalhes:

Para este erro… O problema pode ser... Experimente isto…
Per-product, per-project service account not found. O nome da conta de serviço está incorreto. Na página Contas de serviço, certifique-se de que criou uma conta de serviço para o projeto de utilizador correto.
Insufficient permission to integrate with Managed Service for Microsoft Active Directory domain. A função managedidentities.sqlintegrator está em falta na conta de serviço. Na página IAM e administrador, adicione a função managedidentities.sqlintegrator à sua conta de serviço.
Domain not found. O domínio não existe ou foi introduzido incorretamente. Certifique-se de que o nome do domínio está correto. É sensível a maiúsculas e minúsculas.
The domain is busy with another operation. Please retry. Outra instância do Cloud SQL está a executar uma operação no mesmo domínio do Active Directory gerido. Repita a operação. Se estiver a fazer um lote de atualizações a instâncias do Cloud SQL ligadas ao mesmo domínio, limite o número de atualizações feitas em 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. Não foi possível efetuar as atualizações necessárias no domínio do Active Directory gerido. Se tiver problemas com a autenticação do Windows, pode tentar sair do domínio do Active Directory gerido e, em seguida, voltar a aderir. Para tal, use o procedimento de atualização para anular a associação e, em seguida, voltar a associar o domínio. Ao fazê-lo, não remove os utilizadores autenticados no Windows nem os inícios de sessão existentes nas suas bases de dados. No entanto, a remoção da autenticação do Windows faz com que uma instância seja reiniciada.
This instance would need a more recent creation date to support Managed Service for Microsoft Active Directory. No Cloud SQL, se uma instância do Cloud SQL para SQL Server tiver sido criada a 12 de março de 2021 ou antes, não pode ser integrada com o Microsoft AD gerido. Experimente a operação numa instância criada após 12 de março de 2021.

O que se segue?

  • Confirme que reviu totalmente a página de vista geral, que inclui limitações e funcionalidades não suportadas. Essa página também inclui links para documentação adicional.