Overview of Managed Microsoft AD in Cloud SQL Stay organized with collections Save and categorize content based on your preferences.
You can integrate Cloud SQL for SQL Server with Managed Service for Microsoft Active Directory (also calledManaged Microsoft AD).
This page contains information to review before you start an integration.After reviewing the following information, including thelimitations, seeUsing Cloud SQL with Managed Microsoft AD.
Advantages of integrating with Managed Microsoft AD
Authentication, authorization, and more are available throughManaged Microsoft AD.For example, joining an instance to a Managed Microsoft AD domainlets you to sign in using Windows Authentication with an AD-based identity.
Integrating Cloud SQL for SQL Server with an AD domain has the additionaladvantage of Cloud integration with your on-premises AD domains.
Prerequisites for integration
Note: Only instances created after March 12, 2021,are supported. If you try to join an instance to a domain and it fails, checkthe instance creation date.You can integrate with Managed Microsoft AD,adding support for Windows Authenticationto an instance. However, before integrating, the following are required for yourGoogle Cloud project:
- A Managed Microsoft AD domain. For information about setting up adomain, seeCreate a domain.
- On-premises AD domains require a managed AD trust. SeeCreating a one-way trustandUse an on-premises AD user to create a Windows login to Cloud SQL.
- A Per-Product, Per-Project Service account, as described in the followingsections; seeCreating a service account.
Create and configure a service account
Note: To create a service account with the requiredpermissions, you must have theresourcemanager.projects.setIamPolicypermission. This permission is included in the Project Owner, Project IAM Admin,and Organization Administrator roles. You also must enable the Cloud SQLAdmin API.You need a Per-Product, Per-Project Service account for each project that youplan to integrate with Managed Microsoft AD. Usegcloud or the Console tocreate the account at the project level. The Per-Product, Per-Project Serviceaccount should be granted themanagedidentities.sqlintegrator role on theproject. For additional information, seegcloud projects set-iam-policy.
If you are using the Google Cloud console, then Cloud SQL automatically creates aservice account for you, and prompts you to grant themanagedidentities.sqlintegrator role.
To create a service account withgcloud, run the following command:
gcloudbetaservicesidentitycreate--service=sqladmin.googleapis.com\--project=PROJECT_NUMBER
That command returns a service account name in the following format:
service-PROJECT_NUMBER@gcp-sa-cloud-sql.iam.gserviceaccount.comHere is an example of a service account name:
service-333445@gcp-sa-cloud-sql.iam.gserviceaccount.com
Granting the necessary permission for integration requires existing permissions.For the required permissions, seeRequired permissions.
To grant the necessary permission for integration, run the following command. Ifyour Managed Microsoft AD is in a different project,AD_PROJECT_ID should be the one containing theManaged Service for Microsoft Active Directory instance, while the service account'sSQL_PROJECT_NUMBER should be the one containing the SQLServer instance:
gcloudprojectsadd-iam-policy-bindingAD_PROJECT_ID\--member=serviceAccount:service-SQL_PROJECT_NUMBER@gcp-sa-cloud-sql.iam.gserviceaccount.com\--role=roles/managedidentities.sqlintegrator
Also seegcloud beta services identity create.
Best practices for integrating with Managed Microsoft AD
When you plan an integration, review the following:
- Prerequisites for integration
- Integrating with a managed AD domain in a different project
- Managed Microsoft AD documentation
- Deploy domain controllers in additional regions
- Use the AD diagnosis toolto troubleshoot AD setup issues with your on-premises domain and Cloud SQL for SQL Serverinstances in Google Cloud console.
Having a SQL Server instance and a managed AD instance in the same region offersthe lowest network latency and the best performance. Thus, when possible,set up a SQL Server instance and an AD instance in the same region.Additionally, whether or not you set them up in the same region, set up aprimary and a backup region for higher availability.
Topologies for integrating with Managed Microsoft AD
Cloud SQL for SQL Server doesn't support domain local groups. However, you can:
- Add global groups or individual user logins directly in SQL Server
- Use universal groups when all groups and users belong to the same forest
If domain local groups were supported,individual user accounts, and global and universal groups, could be added aschildren of a domain local group (that guards access to SQL Server). This wouldenable you to add a domain local group as a SQL Server login. InCloud SQL for SQL Server, you can enable similar capabilities, as describedin this section.
Option 1: Add user accounts and groups as logins to SQL Server
If you have multiple domains, in multiple forests, and you havemultiple global groups, you can add all of the individual user accounts,and the global and universal groups, directly as logins to SQL Server. Asan example of Option 1, see the following diagram:

Option 2: Define a universal group in one of your domains
If your domains are in the same forest, you can define a universalgroup in one of your domains. Then you can add all of the individual useraccounts, and the global and universal groups, as children of that defineduniversal group, and add the defined universal group as a SQL Server login. Asan example of Option 2, see the following diagram:

Limitations and alternatives
Note: For information related to this section, seeUnsupported for integration.The following limitations apply when integrating with Managed Microsoft AD:
- Domain local groups are not supported, butyou can add global groups or individual user logins directly in SQL Server.Alternatively, you can use universal groups when all groups and users belongto the same forest.
- In general, new users created through the Google Cloud console are assigned the
CustomerDbRootRolerole, which has thisSQL Server Agent fixed database role:SQLAgentUserRole. However, users created through SQL Server directly, suchas Managed Microsoft AD users, cannot be granted this role, or use SQLServer Agent, because the MSDB database where this role must be grantedis protected. - Some restricted operations may result in the following error: "Could notobtain information about Windows NT group/user". One example of this type ofrestricted operation is creating logins by users from domains that areconnected through a trust relationship. Another example is grantingprivileges to users from domains that are connected through a trustrelationship. In these cases, retrying the operation is often successful. Ifretrying fails, close the connection and open a new connection.
- Fully qualified domain names (FQDNs) aren't supported by SQL Server onWindows. Therefore, use domain names (short names), rather than FQDNs, whenyou create SQL Server logins. For example, if your domain name is
ad.mydomain.com, then create SQL Server logins forad\user, rather thanforad.mydomain.com\user. - To access SQL Server instances, always use FQDNs. For example, you coulduse an FQDN similar to
private.myinstance.us-central1.myproject.cloudsql.mydomain.com. Netbiosnames aren't supported, nor are any short names if DNS suffixes are omitted. - SQL Server logins based on Active Directory users and groups cannot bemanaged from the Google Cloud console.
- In Cloud SQL, if a SQL Server instance was created on or beforeMarch 12, 2021, it cannot be integrated with Managed Microsoft AD.
- Windows Authentication won't work with an external trust. The errormight be the following: "The target principal name is incorrect.Cannot generate SSPI context." Additionally, as related toMicrosoft's recommendations,use a forest trust instead of an external trust for Kerberos authentication.
Active Directory endpoints and TLS connections
If you're using Windows Authentication and you want to establish a TLS connectionwithout trusting the server certificate, you must rotate the certificates afterWindows Authentication is enabled on the instance.
If the connection fails and one of your certificates was created before March 15,2025, you must rotate theserver certificateagain and try the connection again.
Unsupported for integration
Note: For alternatives to some unsupportedoperations, seeLimitations and alternatives.The following features are unsupported when integrating withManaged Microsoft AD:
- Domain local groups.
- Dropping SQL Server logins by users from domains that are connected througha trust relationship. You can do this operation with a user from yourmanaged domain, or through the
sqlserverlogin. - NTLM authentication.
- Login with an IP address from domains connected through a trustrelationship.
- Instances with long names (more than 63 characters).
What's next
- Review theQuickstart for creating a Managed Microsoft AD domain.
- Prepare tocreate an integrated Cloud SQL instance.
- Learn how tocreate a trust relationship between on-premises domains and aManaged Microsoft AD domain.
- Review how toview integrated instances.
Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2026-02-19 UTC.