This guide presents best practices for running Active Directory on Google Cloud.The guide focuses on practices that are either specific to Google Cloud orof particular importance when deploying Active Directory on Google Cloud.Consider the guide to be complementary to the generalbest practicesfor 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 decidewhich domain and forest architecture to use. If you already use ActiveDirectory, you also have to decide whether and how to integrate the twoenvironments.

Which design fits your situation best depends on a number of factors, includingthe design of your on-premises network, how on-premises andGoogle Cloud resources are going to interact, as well as yourrequirements for availability and administrative autonomy. Refer to ourpatterns for using Active Directory in a hybridenvironment to see how these factors must determine yourdesign.

If you want tomaintain a trust boundary betweenGoogle Cloud and your on-premises environment, consider implementingtheresource forest pattern. In this pattern, you deploy aseparate forest on Google Cloud and use a one-way forest trust tointegrate the Google Cloud forest with your existing on-premises ActiveDirectory forest.

Separate testing and production

Depending on your use of Active Directory, it might be necessary to performfrequent changes in Active Directory during the development and testing ofapplications. Developers might need to be able to create and modifyActiveDirectory accounts, change groupmemberships if applications use groups to handle authorization, or join andremove computers.

To prevent development and testing work from impacting production workloads orhampering the security of your deployment, consider deploying a separate ActiveDirectory domain or forest for development and testing.

Having a separate development and testing domain or forest also allows you toverify administrative changes before applying them to production. Examples ofsuch changes include experimenting with group policies, testing automationscripts, or potentially risky actions such as raising a forest's functionallevel.

Set up Cloud Identity federation in addition to deploying Active Directory on Google Cloud

Deploying Active Directory on Google Cloud allows you to manage WindowsVMs on Google Cloud, can enable users to log in to Windows VMs usingtheir existing user accounts, and supportsapplications that rely on Kerberos,NTLM, or LDAP for authentication.

However, to use theGoogle Cloud console,thegcloud command-linetool, or other Google and Google Cloud tools, you have toauthenticate with a Google identity. Deploying Active Directory on Google Cloud istherefore not a replacement forfederating your existing Active Directory withGoogle Cloud if you are intending to use Active Directoryas your leading system for managing users.

For example, if you deploy a separate forest on Google Cloud, then youcan set up federation against your on-premises Active Directory as illustratedby the following diagram. Users with accounts in the on-premises ActiveDirectory can then use tools that require a Google identity as well as yourapplications that rely on Active Directory for authentication.

If you instead decide toextend your existing forest ordomain to Google Cloud, then you also have the option to use domaincontrollers and AD FS servers deployed on Google Cloud to set up the federation.

Federation also allows you to enforce acommon lifecycle for Googleaccounts and Active Directory Accounts, so that when you disable a user accountin your on-premises Active Directory, the corresponding Google user is alsosuspended.

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 domaincontrollers into a Shared VPC network. Using a Shared VPC network has multipleadvantages:

• Each application that might require Active Directory access can potentiallybe deployed into a separate project. Using separate projects helps isolateresources and allows you to manage access individually.

• You can use adedicated project for Active Directorydomain controllers, which allows you fine-grained control over which of yourusers can access related Google Cloud resources.

• Shared VPC networks allow you to centralize IP address management andfirewall configuration, which helps ensuring consistency across multipleprojects.

As VPCs are aglobal resource, you can use the same Shared VPC networkacross multiple regions.

Do not expose domain controllers externally

To reduce the attack surface of Active Directory, avoid assigning external IPaddresses to domain controllers.

Because VM instances without external IP addresses do not have internet accessby default, you need to take additional steps to ensure that Windows activationand Windows updates are not impaired on domain controllers.

To support Windows activation, enablePrivate Google Access on the subnetthat you plan to deploy domain controllers in, and ensure that the VM instancescan accesskms.windows.googlecloud.com. This allows activation tooccur without direct internet access.

There are multiple options to support Windows updates:

• If you have an on-premisesWSUS server, you can configurehybridconnectivity and configure your domain controllers touse the WSUS server as the source for updates.

• You can enable internet access via a NAT gateway by deployingCloudNAT.

• If you have set up hybrid connectivity, you can also route outbound trafficvia 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 IPaddressthat does not change. To achieve that,configure static internal IPaddresses for the domain controller VMs.

When you reserve an IP address, the default behavior is that an unused addressis chosen automatically. To ensure that IP addresses of domain controllers areeasy to memorize,reserve an internal static IP address.

On the domain controllers, set the IP address of the network adapter to the sameaddress. Although this step is optional, it prevents Active Directory fromemitting warning messages indicating that the IP address of the machine mightstill be dynamically assigned.

Deploy domain controllers across multiple zones

To increase availability, deploy at least two domain controllers anddistributethem over multiple zones. Becausesubnets and IP addresses are not tied to a zone, you can deploy all domaincontrollers into a single subnet.

If you plan to deploy workloads across multiple regions, consider deployingdomain controllers in each relevant region. Becausesubnets are a regionalresource, deploying into anextra region will require an additional subnet.

Create one site per region

When aclient tries to locate a domain controller, it will firstlook for a domain controller in theActive Directory site thatcorresponds to the client's IP address. If no domain controller is available inthis site, the client will proceed and attempt to locate a domain controller ina different site.

You can take advantage of this behavior by creating a separate site for eachregion you deploy domain controllers or domain clients in. Clients will thenautomatically prefer using domain controllers located in the same region, whichcan help reduce latency andoutbound data transfer cost between regions.

If you have clients in regions that do not have a domain controller, you caninfluence which domain controllers these clients choose by adjustingsite linkcosts to reflect geographic closeness of regions and enabling theTry Next Closest Site setting.

Using multiple sites influences replication behavior between domain controllers.One downside of using multiple sites can be that replication between sitesoccursless frequently than intra-site replication.

However, you can't create Active Directory sites in Managed Microsoft ADbecause Managed Microsoft AD doesn't support Active Directory Sites andServices feature.

Use Cloud DNS private forwarding zones

When you create a new VM instance in Compute Engine, the operating system willbe preconfigured to use a default DNS server which provides access tointernalDNS and public DNS.

Before you can join a machine to an Active Directory domain, you have to ensurethat 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 providesaccess tointernal DNS and public DNS, but will not be able toresolve DNS names managed by Active Directory.

Create aprivate DNS forwarding zone in Cloud DNS to allowclients to resolve DNS records managed by Active Directory. Configure the zoneto forward queries that match your Active Directory domain to your domaincontrollers.

Using a private DNS forwarding zone has multiple advantages over configuringclients to directly use your Active Directory domain controllers as DNS servers:

• You do not need to adjust the networking configuration of VM instances. Thissimplifies the process of creating new VMs.

• When you promote or demote a domain controller, you only need to update theconfiguration of the private DNS forwarding zone and do not need to modifyany client settings.

• VM instances still have access tointernal DNS.

• Any DNS records that do not match your Active Directory domain will behandled by Cloud DNS, reducing the load on your domain controllers.

If you use multiple domains, create a separate private DNS forwarding zone foreach Active Directory domain.

Cloud DNS private forwarding zones are scoped to a single VPC. If you usemultiple VPCs connected usingpeering, then you can expose theprivate forwarding zones to other VPCs by configuringDNSpeering.

You still have to manually configure DNS settings on domain controllers. Use127.0.0.1 as the primary DNS server and, optionally, use the IP address of another domaincontroller as the secondary DNS server. For more information, seeRecommended 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 DNSnames of resources deployed on Google Cloud. If youextend yourforest or deploy aresource forest onGoogle Cloud, then use DNS inbound forwarding to allow on-premises clientsto look up DNS records for resources deployed on Google Cloud. To use inbound forwarding,create aDNS server policy to allocate aninbound forwarder IP address and make this address accessible to the on-premisesnetwork.

If the DNS domain used on Google Cloud (for example,cloud.example.com) is a subdomainof the DNS domain used on-premises (for example,example.com), then set up DNSdelegation. Create anNS record in the on-premises domain that points to theinbound forwarder IP address. TheNS record causes clients attempting to lookup a DNS name in the Google Cloud-hosted domain to be redirected to theinbound forwarder IP address.

If the DNS domains used on Google Cloud and your on-premises ActiveDirectory are different (for example,cloud.example.com andcorp.example.com), then configure conditional DNS forwarding in youron-premises domains and use the inbound forwarder IP address as the target. Whenrequested to resolve a DNS name in the Google Cloud-hosted domain,on-premises domain controllers will forward the quest to the inbound forwarderIP address.

When using inbound DNS forward, make sure your firewalls areconfiguredappropriately.

DNS inbound forwarding is not required if youextend your existingdomain to Active Directory. In this scenario, all DNS records ofthe domain are automatically replicated across Google Cloud and youron-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 namesof resources deployed on-premises. If youextend your forest ordeploy aresource forest on Google Cloud, then create aprivate forwarding zone in Cloud DNS toforward DNS queries for your on-premises domains to your on-premises DNSservers.

When using outbound DNS forwarding, make sure your firewalls areconfiguredappropriately.

DNS outbound forwarding is not required if youextend your existingdomain to Active Directory. In this scenario, all DNS records ofthe domain are automatically replicated across Google Cloud and youron-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 otherprotocols used by Active Directory, LDAP is not encrypted by default.

Google Cloud ensures that trafficbetween virtual machinesis encrypted, so using unencrypted LDAP within your VPC is acceptable. If youconnect your VPC to an on-premises network, ensure that LDAPtraffic is only exchanged over trusted channels.

If you useCloud VPN to connect Google Cloud and youron-premises network, then traffic is automatically encrypted using IPSec betweenGoogle Cloud and your on-premises VPN endpoint.

Cloud Interconnect andPartnerInterconnectdo not provide encryption. To ensuresecure communication, establish a VPN tunnel over the Interconnect connection by using aVPN appliance from theGoogle Cloud Marketplace.

Use selective authentication and AES for forest trusts

When creating a trust relationship between Active Directory forests,preferforest trusts over external trusts and take advantage ofthe following features to improve security:

• Enableselective authentication on outboundtrusts in the resource forest. Selective authentication ensures that usersfrom the organizational forest cannot access resources in the resourceforest unless explicitly granted permission.

• Enableenforcement for forest boundary for Kerberos fulldelegation on inbound trusts in the organizationalforest. This feature helps prevent privilege escalation attacks bydisallowing resources in the resource forest to request Ticket GrantingTickets (TGTs) from users in the organizational forest.

• Enable theThe other domain supports Kerberos AES encryption option whencreating trusts. This option ensures that tickets are used for cross-forestauthentication are encrypted using AES instead of the less secure RC4algorithm.

• A project member that has been assigned theCompute InstanceAdmin role in a Google Cloud project can use thepassword resetfunctionality to create local administrator accounts. Localadministrator accounts pose a threat to the security of your ActiveDirectory domain as they can be used to undermine group policies or toinstall malicious software that might capture domain credentials of otherlogged on users.

• By adding astartup script, a privileged project membercan inject malicious code into a VM that is executed asntauthority\system the next time the machine is rebooted.

• By using theserial console, a privileged project membercan also access the Windows Special Administration Console (SAC). Windowsconsiders logons via the SAC as local logons. The SAC can therefore bemisused to evade policies which deny logons via RDP, but miss denying locallogons.

• A privileged project member can use the SAC to issue acrashdump command,which can cause a memory dump to be written to disk. Such a memory dumpmight include sensitive information and credentials.

• By mounting the persistent disk to a different VM or using snapshots, aprivileged project member might be able to access disk contents, potentiallyincluding memory dumps, from machines the user otherwise would not have thepermission to log on to.

When using Managed Microsoft AD, you are better protected against theseadditional access paths by default. The service does not permit privileged usersin 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 projectscontaining domain-joined VM instances are managed on a least-privilege basis.You can further reduce risk by the user of organization policies, grouppolicies, and shielded VMs:

• Use anorganizational policy to disable serial port access.

• Apply a group policy that prevents the creation of local administratoraccounts by disabling theaccount manager. Define anINI 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 VMinstances. Use theLocal Users and Groups functionality (ComputerConfiguration > Preferences > Control Panel Settings > Local Users andGroups) to remove group membership from theAdministrators group andother sensitive groups.

• Consider using shielded VMs in combination with BitLocker disk encryption toavoid persistent disk or snapshots from being readable by unauthorizedusers.

Avoid Active Directory security interfering with Google Cloud security

In an Active Directory domain, machines trust domain controllers to handleauthentication and authorization on their behalf. Unless restricted by grouppolicy, a machine's local security policy, or selective authentication, a userthat has successfully proven their identity to one of the domain controllers isallowed to log on to any machine in the domain.

The ability for Active Directory users to log on to any machine might enableattackers to perform lateral movements within a domain. Such lateral movementscan lead to escalations of privilege if some VM instances are exempted fromfirewall restrictions or use Google Cloudserviceaccounts: The credentials of aservice account are accessible to all processes and users on a VM instance. Anyuser that can use Active Directory to log on to a machine can therefore accessthese service account credentials to gain access to any Google Cloudresources that the service account is granted access to.

When setting up Managed Microsoft AD, the service creates a group tomake it easy to allow specific users the ability to RDP into domain-joined VMs.

To reduce the risk of lateral movements,organize users into administrativetiers and use theDeny access to this computer from thenetwork andDeny logon through Remote Desktop Services group policies torestrict access to your VMs based on tier level.

In aresource forest topology, take additional advantage ofselective authentication to further restrict theset of users from other forests that are allowed to log on to your VMs. You cansimplify managing selective authentication permissions by aligningGoogle Cloud and Active Directory resource structures: IfActive Directory organizational units map to Google Cloud projects, youcan grant users the right to authenticate on a level that matches aGoogle Cloud project.

In cases where neither selective authentication nor group policies areapplicable, create a separate service account, export theservice accountkeys, 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 Directoryusers are able to read and use the keys.

To limit the risk of unauthorized access, use a separate Google Cloud projectto deploy domain controllers and grant access to this project on aleast-privilege basis. When creating the project, be aware that some permissionsmight be inherited fromparent folders. To avoid inadvertentlygranting access through inheritance, consider creating the project outside ofyour usualfolder hierarchy.

When configuring IAM policies for the project, pay particular attention torestricting access to VM instances, the persistent disks that contain thentds.dit database, as well as any storage locations that might containbackups.

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 asActiveDirectory Users and Computers or theActive Directory Administrative Center.These tools require you to log on using a privileged domain account, which makesthe machine you run these tools on an attractive target for credential theft orkeylogging.

To minimize the risk of an attacker obtaining privileged domain credentials, usededicated VM instances for domain administration and handle such management VMslikeprivileged access workstations:

• Use group policies to ensure that only a select subset of users have theright 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 byproject memberscreating local administrator accounts,logging on via theserial console, or tampering with theirpersistent disks. To limit the risk of unauthorized access, use a separateGoogle Cloud project for administrative VMs and grant access tothis project on a least-privilege basis.

If you plan to access administrative VMs from an on-premises network by usinghybrid connectivity, then deploy administrative VMs intoa dedicated VPC subnet. A subnet dedicated to management VMs allows you tobetter distinguish between administrative VMs and other VMs when configuringyour on-premises firewalls. If you use aShared VPC, usesubnet-level permissions to ensure that only privilegedadministrators are allowed to deploy VM instances into the management subnet.This practice helps ensure that if on-premises firewalls apply different rulesfor management VMs than for other VMs, users cannot evade firewall rules byplacing non-management VMs into the management subnet.

Additionally, consider restricting the group policy that manages logonrestrictions for management VMs to the management subnet. This practice enforcesalignment between logon restrictions (based on a group policy) and firewallrules (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, aswell as machines running on-premises, might need access to different subsets ofthese services in order to take advantage of Active Directory.

When using Managed Microsoft AD, the AD domain controllers are deployed in adedicated tenant project. The network that hosts the AD domain controllers isautomatically protected with hardened AD-specific firewall rules.

To reduce the attack surface of domain controllers and your VMs, usefirewalls to disallow any network communication that is not strictly required.Refer to our guide onusing Active Directory across firewallsfor details on which firewall configurations are necessary to access ActiveDirectory 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 overallsecurity of Active Directory than others.Domaincontrollers andadministrative VMs are twoexamples of machines that are particularly critical and therefore particularlysensitive 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 bydistringuishing between three tiers:

• Tier 0 (Highly critical): This tier includes all machines that arecritical to the security of your Active Directory forest. Once a single tier0 machine is compromised, you must assume your entire forest to becompromised.

• Tier 1 (Critical): This tier includes the majority of servers in yourenvironment, including application servers and database servers. Acompromised tier 1 server might have a substantial business impact, but doesnot pose an immediate threat to the entire forest.

• Tier 2 (Normal): This tier includes workstations or othergeneral-purpose machines. A compromise of a tier 2 machine is expected tohave limited impact on business and overall security.

Although the immediate impact of a compromised tier 2 machine might seemlimited, there is a risk of knock-on effects: When a user who has administrativeaccess to tier 0 or tier 1 machines is lured to log on to a compromised tier 2machine, they might fall victim to a keylogger or other forms of credentialtheft. The captured credentials might then be used to attack machines of highertiers, causing the overall impact to escalate.

To avoid such knock-on effects, make sure to not only categorize machines, butalso user accounts, and constrain which set of machines these users have accessto:

• 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 towhich resources:

Refer to theMicrosoft documentation for further details and bestpractices on implementing an administrative tier model in Active Directory.

When you use the administrative tier model in your Active Directory forest, makesure that the integrity of it is not undermined by forest trust relationships.If the trusted forest also applies a tiered administration model, useselectiveauthentication to ensure that users from the trustedforest are only allowed to access resources within the same tier:

If the trusted forest does not implement tiered administration, map the trustedforest to a certain tier and useselectiveauthentication to ensure that users from the trustedforest 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 andperforming other sensitive operations. For critical production deployments, werecommend enablingVPC Service Controls andusingPrivate Google Accessfor on-premises hosts to increase security.

Management

The following section details best practices related to management of ActiveDirectory.

Align Google Cloud and Active Directory resource structures

When you deploy a new Active Directory domain or forest onGoogle Cloud, you have to define an organizational unit (OU) structureto organize your resources with your Active Directory domain. Rather thandesigning an entirely new structure or applying the structure you use in youron-premises environment, create an OU structure that is aligned with yourGoogle Cloud resource hierarchy:

• If you use atiered administration model, thetop-level OUs must reflect your administrative tiers.

• For each tier, create OUs for users and groups. If you are planning tomanage a large number of users and groups, create sub-OUs as appropriate.

• For each tier, create aProjects OU and create sub-OUs for eachGoogle Cloud project that contains Active Directory resources. Usethe project-specific sub-OU to manage computer accounts, service accounts,or other Active Directory resources that correspond to Google Cloudresources of the respective project. Make sure that there is a 1:1 mappingbetween 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 theProjects OU. If you expectto manage a large number of projects and you have designed yourGoogle Cloud resource hierarchy to use multiple levels of folders, thenconsider reflecting this folder structure underneath theProjects OU.

Aligning your Active Directory OU structure and Google Cloud resourcehierarchy has several advantages:

• When you delegate administrative permissions to a Google Cloud projectby using IAM policies, then you might also need to grant projectusers certain privileges in Active Directory. For example,Compute Engineadministrators might need to be able to join machines to thedomain under a certain OU. Aligning OUs and Google Cloud projectsenables you to grant such permissions on the same level of granularity inActive Directory as in Google Cloud.

• If you plan to use group policy objects (GPOs) to manage computers, then anOU structure that reflects the Google Cloud resource hierarchyhelps you ensure that GPOs are applied consistently to all VMs of a givenproject or folder.

• If you use a cross-forest trust with conditional authentication, then youcan use the OUs that correspond to Google Cloud projects to grant theAllowed toauthenticate permission on a per-project basis.

• When you delete a project in Google Cloud, you can simply deletethe associated OU, reducing the risk of leaving stale resources in yourdirectory.

If you feel your OU structure needs to deviate from your project structure, thenthis might be an indication that your project structure is too fine-grained ortoo coarse-grained.

Use Google time servers

Kerberos authentication relies on time stamps as part of its protocol. Forauthentication to succeed, the clocks of the client and server machine mustsynchronize within a certain margin. By default, Active Directory allows nomore than5 minutes of difference.

In an on-premises Active Directory environment, the following are the defaultconfiguration for synchronizing time:

• Domain-joined machines synchronize their time with a domain controller.
• Domain controllers synchronize their time with their domain'sPDC emulator.
• PDC emulators of all domains synchronize their time with the PDC emulatorof the forest root domain.

In this configuration, the PDC emulator of the forest root domain is theultimate source of time for Active Directory, and it's common to configure thismachine 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 turnrelies on Google'sNTP servers to obtain the correct time. Joining a VM to anActive Directory domain doesn't change this default configuration.

Keep the Compute Engine's default configuration unless your forest root domain'sPDC emulator is deployed outside of Google Cloud.

If your PDC emulator is deployed outside of Google Cloud,configureit to usetime.google.com as NTP source.Alternatively, you can restore the default Active Directory behavior of synchronizingtime with the PDC emulator by reconfiguring Compute Engine VMs to usetheDOMHIER NTP source and configuring firewall rules to permit inbound NTP traffic (UDP/123) to yourdomain controllers.

Consolidate and monitor audit logs

When you deploy Active Directory on Google Cloud, the security of yourActive Directory forest and your Google Cloud projects are tied toanother: Suspicious activity in Active Directory and Windows mightendanger thesecurity of some other resources in the same manner assuspicious activity in Google Cloud mightput your Active Directory atrisk.

Consistent audit logs are an important tool to identify threats ormisconfiguration early and enable you to reconstruct and examine past activity.Cloud Audit Logging allows you to capture and analyzeadminactivity logs anddata access logs. Similarly, youcan usefirewall rules logging andVPC flow logs toanalyze networking traffic. These platform services are unaware of anysecurity-related events taking place in Active Directory, however. To establisha consistent audit trail that covers both platform-related audit events andActive Directory-related audit events, install theCloud Loggingagent on domain controllers and domain-joined machines to exportWindows security event logs to Cloud Logging.

By default, the Windows security event log might not capture all the events youneed for your auditing purposes. Refer to the Microsoft recommendations onconfiguringaudit policies andmonitoring Active Directory forsigns 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, createlogs-based metrics forevents that might beparticularly critical or suspicious andconsiderconfiguring alerts to notify you when the rate of eventschanges or exceeds acceptable thresholds.

What's next

• Find out whichpattern for using Active Directory in a hybridenvironment suits your situation best.

• Learn how you canconfigure Active Directory for VMs to automatically join a domain.

• Try out other Google Cloud features for yourself. See ourtutorials.