Vista geral do Active Directory gerido pelo cliente (CMAD)

Esta página contém informações a rever antes de iniciar uma integração. Depois de rever as seguintes informações, incluindo as limitações, consulte o artigo Use o Active Directory gerido pelo cliente.

Pode integrar o Cloud SQL para SQL Server com o Microsoft Active Directory gerido pelo cliente (também denominado AD gerido pelo cliente [CMAD]).

A autenticação, a autorização e muito mais estão disponíveis através da CMAD. Por exemplo, juntar uma instância a um domínio CMAD permite-lhe iniciar sessão através da autenticação do Windows com uma identidade baseada no AD. A integração do Cloud SQL para SQL Server com um domínio do AD tem a vantagem adicional da integração com os seus domínios do AD no local. Google Cloud

Antes de começar

Pode fazer a integração com o CMAD, adicionando suporte para a autenticação do Windows a uma instância. No entanto, antes da integração, o seguinte é necessário para o seu Google Cloud projeto:

  • Para que a autenticação funcione, as suas instâncias do Cloud SQL têm de ter conetividade de rede com todos os domínios do Active Directory relevantes. Isto inclui o domínio principal ao qual a instância se junta, bem como quaisquer domínios fidedignos ou subordinados que contenham utilizadores que precisem de aceder ao Cloud SQL para SQL Server. Para ativar esta funcionalidade, certifique-se de que as seguintes portas (TCP e UDP) estão abertas entre as suas instâncias do Cloud SQL e todos os controladores de domínio: 53, 88, 135, 389, 445, 464, 3268, 3269 e 49152 a 65535.
  • Tem de criar uma unidade organizacional (UO) para armazenar todos os objetos de integração relacionados.
    • Nesta UO, também precisa de uma conta de administrador com as seguintes autorizações:
      • Crie objetos de computador
      • Elimine objetos de computador
      • Crie objetos User
      • Elimine objetos User
      • Escrever todas as propriedades
      • Repor palavra-passe
      • Tempo de bloqueio de leitura, tempo de bloqueio de escrita
    • Também recomendamos que conceda autorizações a esta conta de administrador para gerir registos DNS, por exemplo, adicionando-a ao grupo DnsAdmins.

      Se não conceder estas autorizações, a integração continua a ser bem-sucedida. No entanto, a ligação à sua instância requer que crie manualmente os registos de DNS necessários, conforme descrito em Estabeleça ligação a uma instância com um utilizador.

      Em alternativa, pode estabelecer ligação através do endereço IP da instância, que tem limitações e não funciona para ligações de domínios fidedignos.

  • Tem de armazenar as suas credenciais de administrador num segredo do Secret Manager, usando o seguinte formato JSON: 
        {
      "credentials": [
        {
          "validAfterUTC": "VALID_AFTER_UTC_VALUE",
          "administratorLogin": "ADMINISTRATOR_LOGIN_VALUE_1",
          "administratorPassword": "ADMINISTRATOR_PASSWORD_VALUE_1"
        },
        {
          "validAfterUTC": "VALID_AFTER_UTC_VALUE_2",
          "administratorLogin": "ADMINISTRATOR_LOGIN_VALUE_2",
          "administratorPassword": "ADMINISTRATOR_PASSWORD_VALUE_2"
        }
      ]
    }

    Substitua o seguinte:

    • VALID_AFTER_UTC_VALUE_1: o primeiro valor UTC que quer usar, fornecido no formato YYYY-MM-DDThh:mm:ssZ. Um exemplo pode ser 2099-07-01T10:30:00Z.
    • ADMINISTRATOR_LOGIN_VALUE_1: o primeiro início de sessão de administrador que quer usar, como myadmin. Não inclua o nome de domínio no valor. As entradas semelhantes a myadmin@my-domain-name.com não são suportadas.
    • ADMINISTRATOR_PASSWORD_VALUE_1: a palavra-passe do administrador.
    • VALID_AFTER_UTC_VALUE_2: o segundo valor UTC que quer usar, fornecido no formato YYYY-MM-DDThh:mm:ssZ. Um exemplo pode ser 2099-07-01T10:30:00Z.
    • ADMINISTRATOR_LOGIN_VALUE_2: o início de sessão do segundo administrador que quer usar, como myadmin2. Da mesma forma, não inclua o nome do domínio no valor. As entradas semelhantes a myadmin2@my-domain-name.com não são suportadas.
    • ADMINISTRATOR_PASSWORD_VALUE_2: a palavra-passe do segundo administrador.

    Este ficheiro pode conter várias entradas de credenciais para mitigar problemas com a propagação lenta ou para acomodar rotações planeadas e antecipadas.

    O campo validAfterUTC é opcional. Se não for especificado, assume-se que as credenciais são sempre válidas. Recomendamos que mantenha estas credenciais permanentemente disponíveis no Secret Manager e use a automatização para atualizar a palavra-passe se rodar as credenciais.

    Embora possa eliminar o segredo após a criação da instância, tenha em atenção que as operações futuras, como a clonagem ou a adição de uma réplica de leitura, farão com que a nova instância não seja associada ao domínio.

    Além disso, a eliminação da instância original deixa objetos órfãos, como a conta do computador, no CMAD.

  • Ter uma lista de endereços IP do servidor DNS para o seu Active Directory gerido pelo cliente, que são normalmente os seus controladores de domínio. Recomendamos a utilização de endereços IP estáticos para estes servidores.
  • Atribua contas de serviço por produto e por projeto.

Crie e configure uma conta de serviço

Para criar uma conta de serviço com as autorizações necessárias, verifique o seguinte:

Para criar uma conta de serviço com a CLI gcloud, execute o seguinte comando:

  gcloud beta services identity create --service=sqladmin.googleapis.com 

      --project=PROJECT_ID

Esse comando devolve um nome de conta de serviço no seguinte formato:

  service-PROJECT_ID@gcp-sa-cloud-sql.iam.gserviceaccount.com

Segue-se um exemplo de um nome de conta de serviço:

  service-333445@gcp-sa-cloud-sql.iam.gserviceaccount.com

Para conceder a autorização necessária para a integração, execute o seguinte comando:

  gcloud iam roles create secretIamPolicyManager --project=PROJECT_ID 

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

Em seguida, execute o seguinte comando:

  gcloud secrets add-iam-policy-binding ADCredentials --project="722300452883" 

    --member="serviceAccount:service-SQL_PROJECT_NUMBER@gcp-sa-cloud-sql.iam.gserviceaccount.com" 

    --role="projects/PROJECT-ID/roles/secretIamPolicyManager"

Para mais informações, consulte gcloud beta services identity create.

Práticas recomendadas para a integração com o CMAD

Quando fizer a integração com o CMAD, recomendamos que conclua os seguintes passos.

Pré-requisitos para a integração

Use a ferramenta de diagnóstico do Active Directory 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. Ignore os passos relacionados com o Serviço gerido para o Microsoft Active Directory.

Topologias para integração com o CMAD

O Cloud SQL para SQL Server não suporta grupos locais de domínio. No entanto, estão disponíveis as seguintes alternativas:

  • Adicione grupos globais ou inícios de sessão de utilizadores individuais diretamente no SQL Server.
  • Use grupos universais se todos os grupos e utilizadores pertencerem à mesma floresta.

O Cloud SQL para SQL Server não suporta grupos locais de domínio como inícios de sessão. Para conceder autorizações a utilizadores do domínio, tem de usar grupos globais ou universais, conforme descrito nesta secção.

Opção 1: adicione contas de utilizador e grupos como inícios de sessão no SQL Server

Se tiver vários domínios, em várias florestas, e tiver vários grupos globais, pode adicionar todas as contas de utilizador individuais e os grupos globais e universais diretamente como inícios de sessão no SQL Server. Como exemplo da Opção 1, veja o diagrama seguinte:

Topologia CMAD, opção 1.

Opção 2: defina um grupo universal num dos seus domínios

Se os seus domínios estiverem na mesma floresta, pode definir um grupo universal num dos seus domínios. Em seguida, pode adicionar todas as contas de utilizadores individuais e os grupos globais e universais como filhos desse grupo universal definido e adicionar o grupo universal definido como um início de sessão do SQL Server. Como exemplo da Opção 2, veja o diagrama seguinte:

Topologia CMAD, opção 2.

Limitações e alternativas

Aplicam-se as seguintes limitações quando faz a integração com o CMAD:

  • As instâncias do Cloud SQL para SQL Server que usam o Private Service Connect (PSC) para conectividade privada não são suportadas. Em alternativa, use o acesso a serviços privados (PSA).
  • Os grupos locais de domínio não são suportados, mas pode adicionar grupos globais ou inícios de sessão de utilizadores individuais diretamente no SQL Server. Em alternativa, pode usar grupos universais quando todos os grupos e utilizadores pertencem à mesma floresta.
  • Se existirem domínios fidedignos adicionais e planear aceder a instâncias do SQL Server com nomes de utilizador a partir daí, têm de ser ligados através de uma relação de confiança bidirecional. As relações de confiança unidirecionais e externas não são suportadas.
  • Em geral, aos novos utilizadores criados através da Google Cloud consola é atribuída a função CustomerDbRootRole, que tem esta função de base de dados fixa do SQL Server Agent: SQLAgentUserRole. No entanto, não é possível conceder esta função aos utilizadores criados diretamente através do SQL Server, como os utilizadores CMAD, nem usar o SQL Server Agent, porque a base de dados MSDB onde esta função tem de ser concedida está protegida.
  • Os nomes do domínio totalmente qualificados (FQDNs) não são suportados pelo SQL Server. Por conseguinte, use nomes de domínio (nomes abreviados) em vez de FQDNs quando criar inícios de sessão do SQL Server. Por exemplo, se o nome do domínio for ad.mydomain.com, crie inícios de sessão do SQL Server para ad\user, em vez de para ad.mydomain.com\user.
  • Para aceder a instâncias do SQL Server, use sempre FQDNs. Por exemplo, pode usar um FQDN semelhante a private.myinstance.us-central1.myproject.cloudsql.mydomain.com. Os nomes NetBIOS não são suportados, nem os diminutivos se os sufixos DNS forem omitidos.
  • Não é possível gerir os inícios de sessão do SQL Server baseados em utilizadores e grupos do Active Directory a partir da Google Cloud consola.
  • A autenticação do Windows não funciona com uma confiança externa. O erro devolvido pode ser o seguinte: 
      "The target principal name is incorrect. Cannot generate SSPI context."
    Além disso, no que diz respeito às recomendações da Microsoft, use uma confiança de floresta em vez de uma confiança externa para a autenticação Kerberos.
  • É sempre usada a versão mais recente do segredo. O segredo tem de estar ativo e não pode ser destruído.

Pontos finais do Active Directory e ligações TLS

Se estiver a usar a autenticação do Windows e quiser estabelecer uma ligação TLS sem confiar no certificado do servidor, tem de rodar os certificados depois de a autenticação do Windows estar ativada na instância.

Se a ligação falhar e um dos seus certificados tiver sido criado antes de 15 de março de 2025, tem de rodar novamente o certificado do servidor e tentar estabelecer a ligação novamente.

Não suportado para integração

As seguintes funcionalidades não são suportadas quando se integram com o CMAD:

  • Grupos locais de domínio.
  • Autenticação NTLM.
  • Inicie sessão com um endereço IP de domínios ligados através de uma relação de confiança.
  • Instâncias com nomes longos (mais de 63 carateres).

Monitorização

Pode usar a seguinte métrica para monitorizar o estado e o bom funcionamento do CMAD:

cloudsql.googleapis.com/database/active_directory/domain_reachable

Esta métrica indica se o CMAD é acessível a partir da instância do Cloud SQL. É uma ferramenta útil para ajudar a resolver problemas de rede:

cloudsql.googleapis.com/database/active_directory/instance_available

O que se segue?