Visão geral do Active Directory gerenciado pelo cliente (CMAD)

Analise as informações desta página antes de iniciar uma integração. Depois de analisar as informações a seguir, incluindo as limitações, consulte Usar o Active Directory gerenciado pelo cliente.

É possível integrar o Cloud SQL para SQL Server com o Microsoft Active Directory gerenciado pelo cliente (também conhecido como AD gerenciado pelo cliente (CMAD)).

Autenticação, autorização e outros recursos estão disponíveis pelo CMAD. Por exemplo, mesclar uma instância a um domínio do CMAD permite que você faça login usando a autenticação do Windows com uma identidade baseada no AD. A integração do Cloud SQL para SQL Server a um domínio do AD tem a vantagem adicional da integração do Google Cloud com os domínios do AD no local.

Antes de começar

É possível integrar ao CMAD, adicionando suporte para autenticação do Windows a uma instância. No entanto, antes da integração, os itens a seguir são obrigatórios para o projetoGoogle Cloud :

  • Para que a autenticação funcione, as instâncias do Cloud SQL precisam ter conectividade de rede com todos os domínios relevantes do Active Directory. Isso inclui o domínio principal a que a instância se associa, bem como todos os domínios confiáveis ou filhos que contêm usuários que precisam acessar o Cloud SQL para SQL Server. Para ativar isso, verifique se as seguintes portas (TCP e UDP) estão abertas entre as instâncias do Cloud SQL e todos os controladores de domínio: 53, 88, 135, 389, 445, 464, 3268, 3269 e 49152 a 65535.
  • É necessário criar uma unidade organizacional (UO) para armazenar todos os objetos de integração relacionados.
    • Nessa UO, você também precisa de uma conta de administrador com as seguintes permissões:
      • Criar objetos de computador
      • Excluir objetos de computador
      • Criar objetos de usuário
      • Excluir objetos de usuário
      • Gravar todas as propriedades
      • Redefinir senha
      • Tempo de bloqueio de leitura, tempo de bloqueio de gravação
    • Também recomendamos conceder a essa conta de administrador permissões para gerenciar registros DNS, por exemplo, adicionando-a ao grupo DnsAdmins.

      Se você não conceder essas permissões, a integração ainda será concluída. No entanto, para se conectar à instância, você precisa criar manualmente os registros DNS necessários, conforme descrito em Conectar-se a uma instância com um usuário.

      A alternativa é se conectar usando o endereço IP da instância, que tem limitações e não funciona para conexões de domínios confiáveis.

  • Você precisa armazenar as credenciais de administrador em um secret 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:

    • VALID_AFTER_UTC_VALUE_1: o primeiro valor UTC que você quer usar, fornecido no formato YYYY-MM-DDThh:mm:ssZ. Por exemplo, 2099-07-01T10:30:00Z.
    • ADMINISTRATOR_LOGIN_VALUE_1: o primeiro login de administrador que você quer usar, como myadmin. Não inclua o nome de domínio no valor. Entradas semelhantes a myadmin@my-domain-name.com não são aceitas.
    • ADMINISTRATOR_PASSWORD_VALUE_1: a senha do administrador.
    • VALID_AFTER_UTC_VALUE_2: o segundo valor UTC que você quer usar, fornecido no formato YYYY-MM-DDThh:mm:ssZ. Por exemplo, 2099-07-01T10:30:00Z.
    • ADMINISTRATOR_LOGIN_VALUE_2: o login do segundo administrador que você quer usar, como myadmin2. Da mesma forma, não inclua o nome de domínio no valor. Entradas semelhantes a myadmin2@my-domain-name.com não são aceitas.
    • ADMINISTRATOR_PASSWORD_VALUE_2: a senha do segundo administrador.

    Esse arquivo pode conter várias entradas de credenciais para reduzir problemas com propagação lenta ou para acomodar rotações planejadas e antecipadas.

    O campo validAfterUTC é opcional. Se não for especificado, vamos considerar que as credenciais são sempre válidas. Recomendamos manter essas credenciais permanentemente disponíveis no Secret Manager e usar a automação para atualizar a senha se você fizer a rotação das credenciais.

    Embora seja possível excluir o secret após a criação da instância, saiba que operações futuras, como clonagem ou 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, excluir a instância original vai deixar objetos órfãos, como a conta do computador, no CMAD.

  • Tenha uma lista de endereços IP do servidor DNS para o Active Directory gerenciado pelo cliente, que geralmente são os controladores de domínio. Recomendamos o uso de endereços IP estáticos para esses servidores.
  • Atribua contas de serviço por produto e por projeto.

Criar e configurar uma conta de serviço

Para criar uma conta de serviço com as permissõ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 retorna um nome de conta de serviço no seguinte formato:

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

Veja um exemplo de nome de conta de serviço:

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

Para conceder a permissão necessária à 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 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 integração com o CMAD

Ao fazer a integração com o CMAD, recomendamos concluir as etapas a seguir.

Pré-requisitos para integração

Use a ferramenta de diagnóstico do Active Directory 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 . Pule as etapas relacionadas ao Serviço gerenciado para Microsoft Active Directory.

Topologias para integração com o CMAD

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

  • Adicione grupos globais ou logins de usuários individuais diretamente no SQL Server.
  • Use grupos universais se todos os grupos e usuários pertencerem à mesma floresta.

O Cloud SQL para SQL Server não aceita grupos locais de domínio como logins. Para conceder permissões a usuários do domínio, use grupos globais ou universais, conforme descrito nesta seção.

Opção 1: adicionar contas de usuários e grupos como logins no SQL Server

Se você tiver vários domínios em várias florestas e vários grupos globais, é possível adicionar todas as contas de usuário individuais e os grupos globais e universais diretamente como logins ao SQL Server. Como exemplo da opção 1, consulte o diagrama a seguir:

Topologia do CMAD, opção 1.

Opção 2: definir um grupo universal em um dos domínios

Se os domínios estiverem na mesma floresta, é possível definir um grupo universal em um deles. Em seguida, adicione todas as contas de usuário individuais e os grupos globais e universais como filhos desse grupo universal definido, além de adicionar o grupo universal definido como um login do SQL Server. Como exemplo da opção 2, consulte o diagrama a seguir:

Topologia do CMAD, opção 2.

Limitações e alternativas

As limitações a seguir se aplicam ao fazer a integração com o CMAD:

  • Não há suporte para instâncias do Cloud SQL para SQL Server que usam o Private Service Connect (PSC) para conectividade particular. Em vez disso, use o acesso a serviços particulares (PSA).
  • Grupos locais de domínio não são compatíveis, mas é possível adicionar grupos globais ou logins de usuários individuais diretamente no SQL Server. Também é possível usar grupos universais quando todos os grupos e usuários pertencem à mesma floresta.
  • Se houver outros domínios confiáveis e você planeja acessar instâncias do SQL Server com nomes de usuário deles, eles precisam estar conectados por uma confiança bidirecional. Confianças unidirecionais e externas não são compatíveis.
  • Em geral, os novos usuários criados pelo console do Google Cloud recebem o papel CustomerDbRootRole, que tem este papel de banco de dados fixo do SQL Server Agent: SQLAgentUserRole. No entanto, os usuários criados diretamente pelo SQL Server, como usuários do CMAD, não podem receber esse papel nem usar o SQL Server Agent, porque o banco de dados MSDB em que esse papel precisa ser concedido está protegido.
  • Os nomes de domínio totalmente qualificados (FQDNs, na sigla em inglês) não são compatíveis com o SQL Server. Portanto, use nomes de domínio (nomes curtos), em vez de FQDNs, ao criar logins do SQL Server. Por exemplo, se o nome de domínio for ad.mydomain.com, crie logins do SQL Server para ad\user, em vez de para ad.mydomain.com\user.
  • Para acessar instâncias do SQL Server, sempre use FQDNs. Por exemplo, é possível usar um FQDN semelhante a private.myinstance.us-central1.myproject.cloudsql.mydomain.com. Os nomes do Netbios não são compatíveis, nem os nomes curtos, se os sufixos DNS forem omitidos.
  • Os logins do SQL Server baseados em usuários e grupos do Active Directory não podem ser gerenciados no console Google Cloud .
  • A Autenticação do Windows não vai funcionar com uma confiança externa. O erro retornado pode ser o seguinte: 
      "The target principal name is incorrect. Cannot generate SSPI context."
    Além disso, de acordo com as recomendações da Microsoft, use uma confiança de floresta em vez de uma confiança externa para a autenticação Kerberos.
  • A versão mais recente do secret é sempre usada. O secret precisa estar ativo e não pode ser destruído.

Endpoints do Active Directory e conexões TLS

Se você estiver usando a autenticação do Windows e quiser estabelecer uma conexão TLS sem confiar no certificado do servidor, gire os certificados depois que a autenticação do Windows for ativada na instância.

Se a conexão falhar e um dos seus certificados tiver sido criado antes de 15 de março de 2025, gire o certificado do servidor novamente e tente se conectar de novo.

Sem suporte para integração

Os recursos a seguir não são compatíveis com a integração com o CMAD:

  • Grupos de domínio local.
  • Autenticação NTLM
  • Faça login com um endereço IP de domínios conectados por uma relação de confiança.
  • Instâncias com nomes longos (mais de 63 caracteres).

Monitoramento

Use a seguinte métrica para monitorar o status e a integridade do CMAD:

cloudsql.googleapis.com/database/active_directory/domain_reachable

Essa métrica informa se o CMAD está acessível na instância do Cloud SQL. É uma ferramenta útil para ajudar a resolver problemas de rede:

cloudsql.googleapis.com/database/active_directory/instance_available

A seguir