This guide presents best practices for running Active Directory on Google Cloud. The guide focuses on practices that are either specific to Google Cloud or of particular importance when deploying Active Directory on Google Cloud. Consider the guide to be complementary to the general best practices for securing Active Directory published by Microsoft.
Architecture
The following sections detail best practices related to architecture.
Use the architecture pattern that best fits your requirements
To deploy Active Directory on Google Cloud, you first have to decide which domain and forest architecture to use. If you already use Active Directory, you also have to decide whether and how to integrate the two environments.
Which design fits your situation best depends on a number of factors, including the design of your on-premises network, how on-premises and Google Cloud resources are going to interact, as well as your requirements for availability and administrative autonomy. Refer to our patterns for using Active Directory in a hybrid environment to see how these factors must determine your design.
If you want to maintain a trust boundary between Google Cloud and your on-premises environment, consider implementing the resource forest pattern. In this pattern, you deploy a separate forest on Google Cloud and use a one-way forest trust to integrate the Google Cloud forest with your existing on-premises Active Directory forest.
Separate testing and production
Depending on your use of Active Directory, it might be necessary to perform frequent changes in Active Directory during the development and testing of applications. Developers might need to be able to create and modify Active Directory accounts, change group memberships if applications use groups to handle authorization, or join and remove computers.
To prevent development and testing work from impacting production workloads or hampering the security of your deployment, consider deploying a separate Active Directory domain or forest for development and testing.
Having a separate development and testing domain or forest also allows you to verify administrative changes before applying them to production. Examples of such changes include experimenting with group policies, testing automation scripts, or potentially risky actions such as raising a forest's functional level.
Set up Cloud Identity federation in addition to deploying Active Directory on Google Cloud
Deploying Active Directory on Google Cloud allows you to manage Windows VMs on Google Cloud, can enable users to log in to Windows VMs using their existing user accounts, and supports applications that rely on Kerberos, NTLM, or LDAP for authentication.
However, to use the Google Cloud console, the gcloud command-line
tool, or other Google and Google Cloud tools, you have to
authenticate with a Google identity. Deploying Active Directory on Google Cloud is
therefore not a replacement for federating your existing Active Directory with
Google Cloud if you are intending to use Active Directory
as your leading system for managing users.
For example, if you deploy a separate forest on Google Cloud, then you can set up federation against your on-premises Active Directory as illustrated by the following diagram. Users with accounts in the on-premises Active Directory can then use tools that require a Google identity as well as your applications that rely on Active Directory for authentication.
If you instead decide to extend your existing forest or domain to Google Cloud, then you also have the option to use domain controllers and AD FS servers deployed on Google Cloud to set up the federation.
Federation also allows you to enforce a common lifecycle for Google accounts and Active Directory Accounts, so that when you disable a user account in your on-premises Active Directory, the corresponding Google user is also suspended.
Networking
The following section details best practices related to networking.
Deploy Active Directory into a Shared VPC network
To allow Active Directory to be used across multiple projects, deploy domain controllers into a Shared VPC network. Using a Shared VPC network has multiple advantages:
Each application that might require Active Directory access can potentially be deployed into a separate project. Using separate projects helps isolate resources and allows you to manage access individually.
You can use a dedicated project for Active Directory domain controllers, which allows you fine-grained control over which of your users can access related Google Cloud resources.
Shared VPC networks allow you to centralize IP address management and firewall configuration, which helps ensuring consistency across multiple projects.
As VPCs are a global resource, you can use the same Shared VPC network across multiple regions.
Do not expose domain controllers externally
To reduce the attack surface of Active Directory, avoid assigning external IP addresses to domain controllers.
Because VM instances without external IP addresses do not have internet access by default, you need to take additional steps to ensure that Windows activation and Windows updates are not impaired on domain controllers.
To support Windows activation, enable Private Google Access on the subnet that you plan to deploy domain controllers in, and ensure that the VM instances can access kms.windows.googlecloud.com. This allows activation to occur without direct internet access.
There are multiple options to support Windows updates:
If you have an on-premises WSUS server, you can configure hybrid connectivity and configure your domain controllers to use the WSUS server as the source for updates.
You can enable internet access via a NAT gateway by deploying Cloud NAT.
If you have set up hybrid connectivity, you can also route outbound traffic via an on-premises NAT gateway or proxy server.
Reserve static IP addresses for domain controllers in advance
Because domain controllers serve as DNS servers, they need to be assigned an IP address that does not change. To achieve that, configure static internal IP addresses for the domain controller VMs.
When you reserve an IP address, the default behavior is that an unused address is chosen automatically. To ensure that IP addresses of domain controllers are easy to memorize, reserve an internal static IP address.
On the domain controllers, set the IP address of the network adapter to the same address. Although this step is optional, it prevents Active Directory from emitting warning messages indicating that the IP address of the machine might still be dynamically assigned.
Deploy domain controllers across multiple zones
To increase availability, deploy at least two domain controllers and distribute them over multiple zones. Because subnets and IP addresses are not tied to a zone, you can deploy all domain controllers into a single subnet.
If you plan to deploy workloads across multiple regions, consider deploying domain controllers in each relevant region. Because subnets are a regional resource, deploying into an extra region will require an additional subnet.
Create one site per region
When a client tries to locate a domain controller, it will first look for a domain controller in the Active Directory site that corresponds to the client's IP address. If no domain controller is available in this site, the client will proceed and attempt to locate a domain controller in a different site.
You can take advantage of this behavior by creating a separate site for each region you deploy domain controllers or domain clients in. Clients will then automatically prefer using domain controllers located in the same region, which can help reduce latency and outbound data transfer cost between regions.
If you have clients in regions that do not have a domain controller, you can influence which domain controllers these clients choose by adjusting site link costs to reflect geographic closeness of regions and enabling the Try Next Closest Site setting.
Using multiple sites influences replication behavior between domain controllers. One downside of using multiple sites can be that replication between sites occurs less frequently than intra-site replication.
However, you can't create Active Directory sites in Managed Microsoft AD because Managed Microsoft AD doesn't support Active Directory Sites and Services feature.
Use Cloud DNS private forwarding zones
When you create a new VM instance in Compute Engine, the operating system will be preconfigured to use a default DNS server which provides access to internal DNS and public DNS.
Before you can join a machine to an Active Directory domain, you have to ensure that the machine is able to resolve the DNS records managed by Active Directory. The default DNS server that Compute Engine configures for a VM instance provides access to internal DNS and public DNS, but will not be able to resolve DNS names managed by Active Directory.
Create a private DNS forwarding zone in Cloud DNS to allow clients to resolve DNS records managed by Active Directory. Configure the zone to forward queries that match your Active Directory domain to your domain controllers.
Using a private DNS forwarding zone has multiple advantages over configuring clients to directly use your Active Directory domain controllers as DNS servers:
You do not need to adjust the networking configuration of VM instances. This simplifies the process of creating new VMs.
When you promote or demote a domain controller, you only need to update the configuration of the private DNS forwarding zone and do not need to modify any client settings.
VM instances still have access to internal DNS.
Any DNS records that do not match your Active Directory domain will be handled by Cloud DNS, reducing the load on your domain controllers.
If you use multiple domains, create a separate private DNS forwarding zone for each Active Directory domain.
Cloud DNS private forwarding zones are scoped to a single VPC. If you use multiple VPCs connected using peering, then you can expose the private forwarding zones to other VPCs by configuring DNS peering.
You still have to manually configure DNS settings on domain controllers. Use
127.0.0.1 as the primary DNS server and, optionally, use the IP address of another domain
controller as the secondary DNS server. For more information, see
Recommended DNS settings and alternate options.
Hybrid Connectivity
The following section details best practices related to hybrid connectivity.
Use DNS inbound forwarding to resolve Google Cloud DNS names from on-premises
Clients in your on-premises network might need to be able to resolve the DNS names of resources deployed on Google Cloud. If you extend your forest or deploy a resource forest on Google Cloud, then use DNS inbound forwarding to allow on-premises clients to look up DNS records for resources deployed on Google Cloud. To use inbound forwarding, create a DNS server policy to allocate an inbound forwarder IP address and make this address accessible to the on-premises network.
If the DNS domain used on Google Cloud (for example, cloud.example.com) is a subdomain
of the DNS domain used on-premises (for example, example.com), then set up DNS
delegation. Create an NS record in the on-premises domain that points to the
inbound forwarder IP address. The NS record causes clients attempting to look
up a DNS name in the Google Cloud-hosted domain to be redirected to the
inbound forwarder IP address.
If the DNS domains used on Google Cloud and your on-premises Active
Directory are different (for example, cloud.example.com and
corp.example.com), then configure conditional DNS forwarding in your
on-premises domains and use the inbound forwarder IP address as the target. When
requested to resolve a DNS name in the Google Cloud-hosted domain,
on-premises domain controllers will forward the quest to the inbound forwarder
IP address.
When using inbound DNS forward, make sure your firewalls are configured appropriately.
DNS inbound forwarding is not required if you extend your existing domain to Active Directory. In this scenario, all DNS records of the domain are automatically replicated across Google Cloud and your on-premises environment and made available for lookup in both environments.
Use DNS outbound forwarding to resolve on-premises DNS names from Google Cloud
Clients running on Google Cloud might need to be able to resolve the names of resources deployed on-premises. If you extend your forest or deploy a resource forest on Google Cloud, then create a private forwarding zone in Cloud DNS to forward DNS queries for your on-premises domains to your on-premises DNS servers.
When using outbound DNS forwarding, make sure your firewalls are configured appropriately.
DNS outbound forwarding is not required if you extend your existing domain to Active Directory. In this scenario, all DNS records of the domain are automatically replicated across Google Cloud and your on-premises environment, and made available for lookup in both environments.
Use VPN tunnels to secure LDAP traffic
Active Directory makes extensive use of the LDAP protocol. Unlike most other protocols used by Active Directory, LDAP is not encrypted by default.
Google Cloud ensures that traffic between virtual machines is encrypted, so using unencrypted LDAP within your VPC is acceptable. If you connect your VPC to an on-premises network, ensure that LDAP traffic is only exchanged over trusted channels.
If you use Cloud VPN to connect Google Cloud and your on-premises network, then traffic is automatically encrypted using IPSec between Google Cloud and your on-premises VPN endpoint.
Cloud Interconnect and Partner Interconnect do not provide encryption. To ensure secure communication, establish a VPN tunnel over the Interconnect connection by using a VPN appliance from the Google Cloud Marketplace.
Use selective authentication and AES for forest trusts
When creating a trust relationship between Active Directory forests, prefer forest trusts over external trusts and take advantage of the following features to improve security:
Enable selective authentication on outbound trusts in the resource forest. Selective authentication ensures that users from the organizational forest cannot access resources in the resource forest unless explicitly granted permission.
Enable enforcement for forest boundary for Kerberos full delegation on inbound trusts in the organizational forest. This feature helps prevent privilege escalation attacks by disallowing resources in the resource forest to request Ticket Granting Tickets (TGTs) from users in the organizational forest.
Enable the The other domain supports Kerberos AES encryption option when creating trusts. This option ensures that tickets are used for cross-forest authentication are encrypted using AES instead of the less secure RC4 algorithm.
Security
The following section details best practices related to security.
Avoid Google Cloud security interfering with Active Directory security
Active Directory gives you fine-grained control over which users are allowed to access which resources. When machines are deployed as VM instances in Compute Engine and users have access to the underlying Google Cloud project, you have to consider additional paths that might allow a user to access a machine:
A project member that has been assigned the Compute Instance Admin role in a Google Cloud project can use the password reset functionality to create local administrator accounts. Local administrator accounts pose a threat to the security of your Active Directory domain as they can be used to undermine group policies or to install malicious software that might capture domain credentials of other logged on users.
By adding a startup script, a privileged project member can inject malicious code into a VM that is executed as
nt authority\systemthe next time the machine is rebooted.By using the serial console, a privileged project member can also access the Windows Special Administration Console (SAC). Windows considers logons via the SAC as local logons. The SAC can therefore be misused to evade policies which deny logons via RDP, but miss denying local logons.
A privileged project member can use the SAC to issue a
crashdumpcommand, which can cause a memory dump to be written to disk. Such a memory dump might include sensitive information and credentials.By mounting the persistent disk to a different VM or using snapshots, a privileged project member might be able to access disk contents, potentially including memory dumps, from machines the user otherwise would not have the permission to log on to.
When using Managed Microsoft AD, you are better protected against these additional access paths by default. The service does not permit privileged users in your project to reset the Domain Administrator password, run startup scripts, or access the serial console on the AD domain controller VMs.
To further mitigate these risks, make sure that the IAM permissions of projects containing domain-joined VM instances are managed on a least-privilege basis. You can further reduce risk by the user of organization policies, group policies, and shielded VMs:
Use an organizational policy to disable serial port access.
Apply a group policy that prevents the creation of local administrator accounts by disabling the account manager. Define an INI Files preference in your group policy (Computer Configuration > Preferences > Windows Settings > Ini Files) to apply the following setting:
- Action: Update
- File Path:
C:\Program Files\Google\Compute Engine\instance_configs.cfg - Section Name:
accountManager - Property Name:
disable - Property Value:
true
Apply a group policy that removes any local administrator accounts from VM instances. Use the Local Users and Groups functionality (Computer Configuration > Preferences > Control Panel Settings > Local Users and Groups) to remove group membership from the Administrators group and other sensitive groups.
Consider using shielded VMs in combination with BitLocker disk encryption to avoid persistent disk or snapshots from being readable by unauthorized users.
Avoid Active Directory security interfering with Google Cloud security
In an Active Directory domain, machines trust domain controllers to handle authentication and authorization on their behalf. Unless restricted by group policy, a machine's local security policy, or selective authentication, a user that has successfully proven their identity to one of the domain controllers is allowed to log on to any machine in the domain.
The ability for Active Directory users to log on to any machine might enable attackers to perform lateral movements within a domain. Such lateral movements can lead to escalations of privilege if some VM instances are exempted from firewall restrictions or use Google Cloud service accounts: The credentials of a service account are accessible to all processes and users on a VM instance. Any user that can use Active Directory to log on to a machine can therefore access these service account credentials to gain access to any Google Cloud resources that the service account is granted access to.
When setting up Managed Microsoft AD, the service creates a group to make it easy to allow specific users the ability to RDP into domain-joined VMs.
To reduce the risk of lateral movements, organize users into administrative tiers and use the Deny access to this computer from the network and Deny logon through Remote Desktop Services group policies to restrict access to your VMs based on tier level.
In a resource forest topology, take additional advantage of selective authentication to further restrict the set of users from other forests that are allowed to log on to your VMs. You can simplify managing selective authentication permissions by aligning Google Cloud and Active Directory resource structures: If Active Directory organizational units map to Google Cloud projects, you can grant users the right to authenticate on a level that matches a Google Cloud project.
In cases where neither selective authentication nor group policies are applicable, create a separate service account, export the service account keys, save them to the VM instance's local disk or a file share, and protect them using an NTFS ACL so that only authorized Active Directory users are able to read and use the keys.
Use dedicated projects for domain controllers
Domain controllers player a crucial role in the security of an Active Directory domain and a compromise of a single domain controller can result in the compromise of your entire Active Directory forest.
To limit the risk of unauthorized access, use a separate Google Cloud project to deploy domain controllers and grant access to this project on a least-privilege basis. When creating the project, be aware that some permissions might be inherited from parent folders. To avoid inadvertently granting access through inheritance, consider creating the project outside of your usual folder hierarchy.
When configuring IAM policies for the project, pay particular attention to restricting access to VM instances, the persistent disks that contain the ntds.dit database, as well as any storage locations that might contain backups.
In addition to using IAM policies to limit access to the project, protect the project against accidental deletion.
Use separate VMs and projects for managing Active Directory
To manage Active Directory, you need to be able to use tools such as Active Directory Users and Computers or the Active Directory Administrative Center. These tools require you to log on using a privileged domain account, which makes the machine you run these tools on an attractive target for credential theft or keylogging.
To minimize the risk of an attacker obtaining privileged domain credentials, use dedicated VM instances for domain administration and handle such management VMs like privileged access workstations:
Use group policies to ensure that only a select subset of users have the right to log on to management VMs. If you implemented tiered administration, this group of users corresponds to Tier 0.
Similar to domain controllers, administrative VMs can be put at risk by project members creating local administrator accounts, logging on via the serial console, or tampering with their persistent disks. To limit the risk of unauthorized access, use a separate Google Cloud project for administrative VMs and grant access to this project on a least-privilege basis.
If you plan to access administrative VMs from an on-premises network by using hybrid connectivity, then deploy administrative VMs into a dedicated VPC subnet. A subnet dedicated to management VMs allows you to better distinguish between administrative VMs and other VMs when configuring your on-premises firewalls. If you use a Shared VPC, use subnet-level permissions to ensure that only privileged administrators are allowed to deploy VM instances into the management subnet. This practice helps ensure that if on-premises firewalls apply different rules for management VMs than for other VMs, users cannot evade firewall rules by placing non-management VMs into the management subnet.
Additionally, consider restricting the group policy that manages logon restrictions for management VMs to the management subnet. This practice enforces alignment between logon restrictions (based on a group policy) and firewall rules (based on subnet/IP address).
In addition to using IAM policies to limit access to the project, protect the project against accidental deletion.
Use firewall rules to secure domain controllers and servers
Domain controllers expose a number of services, including LDAP, DNS, Kerberos, and RPC. Depending on your use cases, VMs deployed on Google Cloud, as well as machines running on-premises, might need access to different subsets of these services in order to take advantage of Active Directory.
When using Managed Microsoft AD, the AD domain controllers are deployed in a dedicated tenant project. The network that hosts the AD domain controllers is automatically protected with hardened AD-specific firewall rules.
To reduce the attack surface of domain controllers and your VMs, use firewalls to disallow any network communication that is not strictly required. Refer to our guide on using Active Directory across firewalls for details on which firewall configurations are necessary to access Active Directory from within your VPC or from on-premises networks.
Organize Active Directory resources and users into administrative tiers
Some machines in an Active Directory forest are more critical to the overall security of Active Directory than others. Domain controllers and administrative VMs are two examples of machines that are particularly critical and therefore particularly sensitive to potential attacks.
To identify the criticality of each of your machines, use a taxonomy of tiers. While the right number of tiers depends on your specific setup, you can start by distringuishing between three tiers:
Tier 0 (Highly critical): This tier includes all machines that are critical to the security of your Active Directory forest. Once a single tier 0 machine is compromised, you must assume your entire forest to be compromised.
Tier 1 (Critical): This tier includes the majority of servers in your environment, including application servers and database servers. A compromised tier 1 server might have a substantial business impact, but does not pose an immediate threat to the entire forest.
Tier 2 (Normal): This tier includes workstations or other general-purpose machines. A compromise of a tier 2 machine is expected to have limited impact on business and overall security.
Although the immediate impact of a compromised tier 2 machine might seem limited, there is a risk of knock-on effects: When a user who has administrative access to tier 0 or tier 1 machines is lured to log on to a compromised tier 2 machine, they might fall victim to a keylogger or other forms of credential theft. The captured credentials might then be used to attack machines of higher tiers, causing the overall impact to escalate.
To avoid such knock-on effects, make sure to not only categorize machines, but also user accounts, and constrain which set of machines these users have access to:
Tier 0 (Highly critical): Users that have access to tier 0 machines.
Tier 1 (Critical): Users that have access to tier 1 machines.
Tier 2 (Normal): Users that have access to tier 2 machines.
Use the following table as a guideline for which users ought to have access to which resources:
| Group | Tier | Domain access | Tier 0 computer access | Tier 1 computer access | Tier 2 computer access |
|---|---|---|---|---|---|
| Active Directory administrators | 0 | Administrator | Limited user | Blocked | Blocked |
| Management server administrators | 0 | Limited user | Administrator | Blocked | Blocked |
| Server administrators | 1 | Limited user | Blocked | Administrator | Blocked |
| VDI workstation administrators | 2 | Limited user | Blocked | Blocked | Administrator |
| VDI workstation users | 2 | Limited user | Blocked | Blocked | Limited user |
Refer to the Microsoft documentation for further details and best practices on implementing an administrative tier model in Active Directory.
When you use the administrative tier model in your Active Directory forest, make sure that the integrity of it is not undermined by forest trust relationships. If the trusted forest also applies a tiered administration model, use selective authentication to ensure that users from the trusted forest are only allowed to access resources within the same tier:
If the trusted forest does not implement tiered administration, map the trusted forest to a certain tier and use selective authentication to ensure that users from the trusted forest are only allowed to access resources of that particular tier.
Using VPC Service Controls and Private Google Access for on-premises hosts
Managed Microsoft AD APIs allow resetting the administrator password and performing other sensitive operations. For critical production deployments, we recommend enabling VPC Service Controls and using Private Google Access for on-premises hosts to increase security.
Management
The following section details best practices related to management of Active Directory.
Align Google Cloud and Active Directory resource structures
When you deploy a new Active Directory domain or forest on Google Cloud, you have to define an organizational unit (OU) structure to organize your resources with your Active Directory domain. Rather than designing an entirely new structure or applying the structure you use in your on-premises environment, create an OU structure that is aligned with your Google Cloud resource hierarchy:
If you use a tiered administration model, the top-level OUs must reflect your administrative tiers.
For each tier, create OUs for users and groups. If you are planning to manage a large number of users and groups, create sub-OUs as appropriate.
For each tier, create a
ProjectsOU and create sub-OUs for each Google Cloud project that contains Active Directory resources. Use the project-specific sub-OU to manage computer accounts, service accounts, or other Active Directory resources that correspond to Google Cloud resources of the respective project. Make sure that there is a 1:1 mapping between OUs and projects.
The following diagram shows an example hierarchy that follows these principles:
If the number of projects that contain Active Directory resources is moderate,
then you can create a flat OU structure under the Projects OU. If you expect
to manage a large number of projects and you have designed your
Google Cloud resource hierarchy to use multiple levels of folders, then
consider reflecting this folder structure underneath the Projects OU.
Aligning your Active Directory OU structure and Google Cloud resource hierarchy has several advantages:
When you delegate administrative permissions to a Google Cloud project by using IAM policies, then you might also need to grant project users certain privileges in Active Directory. For example, Compute Engine administrators might need to be able to join machines to the domain under a certain OU. Aligning OUs and Google Cloud projects enables you to grant such permissions on the same level of granularity in Active Directory as in Google Cloud.
If you plan to use group policy objects (GPOs) to manage computers, then an OU structure that reflects the Google Cloud resource hierarchy helps you ensure that GPOs are applied consistently to all VMs of a given project or folder.
If you use a cross-forest trust with conditional authentication, then you can use the OUs that correspond to Google Cloud projects to grant the Allowed to authenticate permission on a per-project basis.
When you delete a project in Google Cloud, you can simply delete the associated OU, reducing the risk of leaving stale resources in your directory.
If you feel your OU structure needs to deviate from your project structure, then this might be an indication that your project structure is too fine-grained or too coarse-grained.
Use Google time servers
Kerberos authentication relies on time stamps as part of its protocol. For authentication to succeed, the clocks of the client and server machine must synchronize within a certain margin. By default, Active Directory allows no more than 5 minutes of difference.
In an on-premises Active Directory environment, the following are the default configuration for synchronizing time:
- Domain-joined machines synchronize their time with a domain controller.
- Domain controllers synchronize their time with their domain's PDC emulator.
- PDC emulators of all domains synchronize their time with the PDC emulator of the forest root domain.
In this configuration, the PDC emulator of the forest root domain is the ultimate source of time for Active Directory, and it's common to configure this machine to use an external NTP server as time source.
On Compute Engine, the default configuration for Windows VMs is to use the metadata server
(metadata.google.internal) as NTP server, which in turn relies on Google's
NTP servers to obtain the correct time. Joining a VM to an
Active Directory domain doesn't change this default configuration.
Keep the Compute Engine's default configuration unless your forest root domain's PDC emulator is deployed outside of Google Cloud.
If your PDC emulator is deployed outside of Google Cloud, configure
it to use time.google.com as NTP source.
Alternatively, you can restore the default Active Directory behavior of synchronizing
time with the PDC emulator by reconfiguring Compute Engine VMs to use
the DOMHIER NTP source
and configuring firewall rules to permit inbound NTP traffic (UDP/123) to your
domain controllers.
Consolidate and monitor audit logs
When you deploy Active Directory on Google Cloud, the security of your Active Directory forest and your Google Cloud projects are tied to another: Suspicious activity in Active Directory and Windows might endanger the security of some other resources in the same manner as suspicious activity in Google Cloud might put your Active Directory at risk.
Consistent audit logs are an important tool to identify threats or misconfiguration early and enable you to reconstruct and examine past activity. Cloud Audit Logging allows you to capture and analyze admin activity logs and data access logs. Similarly, you can use firewall rules logging and VPC flow logs to analyze networking traffic. These platform services are unaware of any security-related events taking place in Active Directory, however. To establish a consistent audit trail that covers both platform-related audit events and Active Directory-related audit events, install the Cloud Logging agent on domain controllers and domain-joined machines to export Windows security event logs to Cloud Logging.
By default, the Windows security event log might not capture all the events you need for your auditing purposes. Refer to the Microsoft recommendations on configuring audit policies and monitoring Active Directory for signs of compromise to ensure you capture all relevant audit events.
When dealing with a large volume of events, it is easy to miss critical events. To avoid missing critical events, create logs-based metrics for events that might be particularly critical or suspicious and consider configuring alerts to notify you when the rate of events changes or exceeds acceptable thresholds.
What's next
Find out which pattern for using Active Directory in a hybrid environment suits your situation best.
Learn how you can configure Active Directory for VMs to automatically join a domain.
Try out other Google Cloud features for yourself. See our tutorials.