Visão geral do Microsoft AD gerenciado no Cloud SQL

Integre o Cloud SQL para SQL Server com o serviço gerenciado para o Microsoft Active Directory (também conhecido como Microsoft AD gerenciado).

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 Como usar o Cloud SQL com o Microsoft AD gerenciado.

Vantagens da integração com o Microsoft AD gerenciado

Autenticação, autorização e outros recursos estão disponíveis por meio do Microsoft AD gerenciado. Por exemplo, mesclar uma instância a um domínio do Microsoft AD gerenciado 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 Cloud com os domínios do AD no local.

Pré-requisitos para integração

É possível integrar ao Microsoft AD gerenciado, 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 projeto do Google Cloud:

Criar e configurar uma conta de serviço

Você precisa de uma conta de serviço por produto e por projeto para cada projeto que planeja integrar ao Microsoft AD gerenciado. Use gcloud ou o Console para criar a conta no nível do projeto. A conta de serviço por produto e por projeto deve receber o papel managedidentities.sqlintegrator no projeto. Para mais informações, consulte gcloud projects set-iam-policy.

Se você estiver usando o Console do Google Cloud, o Cloud SQL criará uma conta de serviço automaticamente e solicitará que você conceda o papel managedidentities.sqlintegrator.

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

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

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

    service-PROJECT_NUMBER@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

Conceder a permissão necessária para a integração requer permissões existentes. Para saber mais sobre as permissões necessárias, consulte Permissões necessárias.

Para conceder a permissão necessária à integração, execute o seguinte comando. Se o Microsoft AD gerenciado estiver em um projeto diferente, AD_PROJECT_ID será o que contém a instância do serviço gerenciado para o Microsoft Active Directory, enquanto SQL_PROJECT_NUMBER da conta de serviço será o que contém a instância do SQL Server:

gcloud projects add-iam-policy-binding AD_PROJECT_ID \
--member=serviceAccount:service-SQL_PROJECT_NUMBER@gcp-sa-cloud-sql.iam.gserviceaccount.com \
--role=roles/managedidentities.sqlintegrator

Consulte também gcloud beta services identity create.

Práticas recomendadas para a integração com o Microsoft AD gerenciado

Ao planejar uma integração, revise o seguinte:

Ter uma instância do SQL Server e uma instância do AD gerenciado na mesma região oferece a menor latência de rede e o melhor desempenho. Assim, quando possível, configure uma instância do SQL Server e uma instância do AD na mesma região. Além disso, mesmo que você não as tenha configurado na mesma região, configure uma região principal e uma de backup para maior disponibilidade.

Topologias para integração com o Microsoft AD gerenciado

O Cloud SQL para SQL Server não é compatível com grupos locais de domínio. No entanto, é possível:

  • adicionar grupos globais ou logins de usuários individuais diretamente no SQL Server;
  • usar grupos universais quando todos os grupos e usuários pertencerem à mesma floresta.

Se grupos locais de domínio fossem compatíveis, contas de usuário individuais e grupos globais e universais poderiam ser adicionados como filhos de um grupo local de domínio (que protege o acesso ao SQL Server). Isso permitiria que você adicionasse um grupo local de domínio como um login do SQL Server. No Cloud SQL para SQL Server, é possível ativar uma funcionalidade semelhante, 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 AD, 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 AD, opção 2.

Limitações e alternativas

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

  • 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.
  • 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 gerenciados do Microsoft AD, não podem receber esse papel ou usam o SQL Server Agent, porque o banco de dados MSDB em que esse papel precisa ser concedido é protegido.
  • Algumas operações restritas podem resultar no seguinte erro: "Não foi possível receber informações sobre o grupo/usuário do Windows NT". Um exemplo desse tipo de operação restrita é a criação de logins por usuários de domínios conectados por uma relação de confiança. Outro exemplo é a concessão de privilégios a usuários de domínios conectados por uma relação de confiança. Nesses casos, a repetição da operação geralmente é bem-sucedida. Se a nova tentativa falhar, feche a conexão e abra uma nova.
  • Os nomes de domínio totalmente qualificados (FQDNs, na sigla em inglês) não são compatíveis com o SQL Server no Windows. 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 serã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 do Google Cloud.
  • No Cloud SQL, se uma instância do SQL Server tiver sido criada em, ou antes, de 12 de março de 2021, ela não poderá ser integrada ao Microsoft AD gerenciado.
  • A Autenticação do Windows não vai funcionar com uma confiança externa. Pode ocorrer o seguinte erro: "O nome principal do destino está incorreto. Não é possível gerar contexto SSP." 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.

Sem suporte para integração

Os recursos a seguir não são compatíveis com a integração com o Microsoft AD gerenciado:

  • Grupos de domínio local.
  • Como descartar logins do SQL Server por usuários de domínios conectados por uma relação de confiança. É possível realizar essa operação com um usuário do domínio gerenciado ou com o login do sqlserver.
  • 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).

A seguir