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 abaixo, 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]

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] deve ser o que contém a instância do Microsoft AD gerenciado, enquanto que [SQL_PROJECT_NUMBER] da conta de serviço deve 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