Pode integrar o Cloud SQL para SQL Server com o serviço gerido para o Microsoft Active Directory (também denominado Microsoft AD gerido).
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 Usar o Cloud SQL com o Microsoft AD gerido.
Vantagens da integração com o Managed Microsoft AD
A autenticação, a autorização e muito mais estão disponíveis através do Microsoft AD gerido. Por exemplo, associar uma instância a um domínio do Microsoft AD gerido 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 na nuvem com os seus domínios do AD no local.
Pré-requisitos para a integração
Pode fazer a integração com o Microsoft AD gerido, 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:
- Um domínio do Microsoft AD gerido. Para obter informações sobre como configurar um domínio, consulte o artigo Crie um domínio.
- Os domínios do AD no local requerem uma relação de confiança do AD gerida. Consulte os artigos Criar uma confiança unidirecional e Usar um utilizador do AD no local para criar um início de sessão do Windows no Cloud SQL.
- Uma conta de serviço por produto e por projeto, conforme descrito nas secções seguintes; consulte o artigo Criar uma conta de serviço.
Crie e configure uma conta de serviço
Precisa de uma conta de serviço por produto e por projeto para cada projeto que planeia integrar com o Managed Microsoft AD. Use gcloud
ou a consola para criar a conta ao nível do projeto. A conta de serviço por produto e por projeto deve receber a função managedidentities.sqlintegrator
no projeto. Para mais informações, consulte o artigo
gcloud projects set-iam-policy.
Se estiver a usar a Google Cloud consola, o Cloud SQL cria automaticamente uma conta de serviço para si e pede-lhe que conceda a função managedidentities.sqlintegrator
.
Para criar uma conta de serviço com o gcloud
, execute o seguinte comando:
gcloud beta services identity create --service=sqladmin.googleapis.com \ --project=PROJECT_NUMBER
Esse comando devolve um nome de conta de serviço no seguinte formato:
service-PROJECT_NUMBER
@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
A concessão da autorização necessária para a integração requer autorizações existentes. Para ver as autorizações necessárias, consulte o artigo Autorizações necessárias.
Para conceder a autorização necessária para a integração, execute o seguinte comando. Se o seu Managed Microsoft AD estiver num projeto diferente, AD_PROJECT_ID
deve ser o projeto que contém a instância do Managed Service for Microsoft Active Directory, enquanto o projeto SQL_PROJECT_NUMBER
da conta de serviço deve ser o projeto 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 o artigo gcloud beta services identity create.
Práticas recomendadas para a integração com o Microsoft AD gerido
Quando planear uma integração, reveja o seguinte:
- Pré-requisitos para a integração
- Integração com um domínio do AD gerido num projeto diferente
- Documentação do Microsoft AD gerido
- Implemente controladores de domínio em regiões adicionais
- Use a ferramenta de diagnóstico do AD 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.
Ter uma instância do SQL Server e uma instância do AD gerida na mesma região oferece a latência de rede mais baixa 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, quer as configure ou não na mesma região, configure uma região principal e uma região alternativa para maior disponibilidade.
Topologias para integração com o Microsoft AD gerido
O Cloud SQL para SQL Server não suporta grupos locais de domínio. No entanto, pode:
- Adicione grupos globais ou inícios de sessão de utilizadores individuais diretamente no SQL Server
- Use grupos universais quando todos os grupos e utilizadores pertencerem à mesma floresta
Se os grupos locais de domínio fossem suportados, as contas de utilizadores individuais e os grupos globais e universais poderiam ser adicionados como filhos de um grupo local de domínio (que protege o acesso ao SQL Server). Isto permite-lhe adicionar um grupo local de domínio como início de sessão do SQL Server. No Cloud SQL para SQL Server, pode ativar capacidades semelhantes, 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:
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 utilizador 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:
Limitações e alternativas
Aplicam-se as seguintes limitações quando se faz a integração com o Microsoft AD gerido:
- Os grupos locais do 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.
- 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 do Microsoft AD gerido, nem estes podem usar o SQL Server Agent, porque a base de dados MSDB onde esta função tem de ser concedida está protegida. - Algumas operações restritas podem resultar no seguinte erro: "Não foi possível obter informações sobre o grupo/utilizador do Windows NT". Um exemplo deste tipo de operação restrita é a criação de inícios de sessão por utilizadores de domínios que estão ligados através de uma relação de confiança. Outro exemplo é a concessão de privilégios a utilizadores de domínios ligados através de uma relação de confiança. Nestes casos, tentar novamente a operação costuma ter êxito. Se a repetição falhar, feche a ligação e abra uma nova ligação.
- Os nomes do domínio totalmente qualificados (FQDNs) não são suportados pelo SQL Server no Windows. 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 paraad\user
, em vez de paraad.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. - Os inícios de sessão do SQL Server baseados em utilizadores e grupos do Active Directory não podem ser geridos a partir da consola Google Cloud .
- No Cloud SQL, se uma instância do SQL Server tiver sido criada a 12 de março de 2021 ou antes, não pode ser integrada com o Microsoft AD gerido.
- A autenticação do Windows não funciona com uma relação de confiança externa. O erro pode ser o seguinte: "O nome principal de destino está incorreto. Não é possível gerar o contexto SSPI." 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.
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 faz a integração com o Microsoft AD gerido:
- Grupos locais de domínio.
- Eliminar inícios de sessão do SQL Server por utilizadores de domínios ligados através de uma relação de confiança. Pode realizar esta operação com um utilizador do seu domínio gerido ou através do início de sessão do
sqlserver
. - 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).
O que se segue?
- Reveja o Início rápido para criar um domínio do Microsoft AD gerido.
- Prepare-se para criar uma instância integrada do Cloud SQL.
- Saiba como criar uma relação de confiança entre domínios no local e um domínio do Microsoft AD gerido.
- Reveja como ver instâncias integradas.