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

MySQL | PostgreSQL | SQL Server

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.

Integre o Cloud SQL para SQL Server com o Microsoft Active Directory gerenciado pelo cliente (também conhecido como AD gerenciado pelo cliente ou CMAD).

A autenticação, a autorização e muito mais 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 Google Cloud integração 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 seguintes itens são necessários para o seu Google Cloud projeto:

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 ao qual a instância se une, 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, também é necessário delegar as seguintes permissões à conta de administrador:
  - Gerenciar objetos de computador (criar objeto/excluir objeto/modificar propriedades do objeto)
  - Gerenciar objetos de usuário (criar objeto/excluir objeto/modificar propriedades do objeto)
- Também recomendamos conceder permissões de conta de administrador para gerenciar registros DNS, por exemplo, adicionando-a ao grupo DnsAdmins.
  Se você não conceder essas permissões, a integração ainda será bem-sucedida. No entanto, para se conectar à instância, será necessário 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.
É necessário armazenar as credenciais de administrador em um Secret Manager secret, 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. Um exemplo pode ser 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. Um exemplo pode ser 2099-07-01T10:30:00Z.
- ADMINISTRATOR_LOGIN_VALUE_2: o segundo login de 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 atenuar problemas com propagação lenta ou para acomodar rotações planejadas e antecipadas.

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

Embora seja possível excluir o secret após a criação da instância, esteja ciente de 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 unida ao domínio.

Além disso, a exclusão da instância original 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 normalmente 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:

É necessário ativar a API Cloud SQL Admin.
Você precisa ter as seguintes permissões:
Você precisa de uma conta de serviço por produto e por projeto para cada projeto que planeja integrar ao CMAD. Use a CLI gcloud para criar a conta no nível do projeto. A conta de serviço por produto e por projeto precisa receber as permissões secretmanager.secrets.getIamPolicy e secretmanager.secrets.setIamPolicy para o secret criado na etapa anterior. Para mais informações, consulte Permissões do Secret Manager.

Recomendamos criar uma função personalizada com as permissões necessárias.

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 integrar 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 instances in Google Cloud console. Pule as etapas relacionadas ao serviço gerenciado do 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 é compatível com grupos locais de domínio como logins. Para conceder permissões a usuários de 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 tiver 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 dos domínios. Em seguida, adicione todas as contas de usuário individual 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 seguintes limitações se aplicam ao integrar com o CMAD:

As instâncias do Cloud SQL para SQL Server que usam o Private Service Connect (PSC) para conectividade particular não são aceitas. Use o Acesso a serviços particulares (PSA, na sigla em inglês).
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 ser conectados por uma confiança bidirecional. Confianças unidirecionais e externas não são aceitas.
Em geral, os novos usuários criados pelo Google Cloud consolerecebem o CustomerDbRootRole papel, 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 os usuários do CMAD, não podem receber esse papel ou 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 aceitos pelo 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, você poderia usar um FQDN semelhante a private.myinstance.us-central1.myproject.cloudsql.mydomain.com. Os nomes do Netbios não serão aceitos, 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 peloconsol. 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, será necessário girar os certificados depois que a Autenticação do Windows for ativada na instância.

Se a conexão falhar e um dos certificados tiver sido criado antes de 15 de março de 2025, será necessário girar o certificado do servidor novamente e tentar a conexão de novo.

Sem suporte para integração

Os seguintes recursos não são aceitos ao integrar 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

É possível usar 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 pode ser acessado pela instância do Cloud SQL. É uma ferramenta útil para ajudar a solucionar problemas de rede:

cloudsql.googleapis.com/database/active_directory/instance_available