Domain controllers operated by Managed Service for Microsoft Active Directory expose a number of services, including LDAP, DNS, Kerberos, and RPC. Depending on your use cases, Virtual Machines (VMs) deployed on Google Cloud, as well as machines running on-premises, might need access to these services to take advantage of Active Directory.
To reduce the attack surface of domain controllers and VMs, you should use firewalls to disallow any network communication that is not strictly required. This article describes how to configure firewalls to accommodate common Active Directory use cases while disallowing other network communication.
Logon versus authentication
While the terms logon and authentication are often used interchangeably, they have different meanings in the context of Windows security. Logon describes the process that occurs on the system a user is gaining access to. In contrast, authentication is performed by the computer on which the user's account resides.
When you use a local account to log on to a machine, both logon and authentication are handled by the target machine. In an Active Directory environment, it is more common to use a domain user to log on. In that case, the logon is handled by the target machine, while authentication is performed by a domain controller.
To authenticate, a client can use either Kerberos or NTLM . Once a client authenticates, the target machine needs to process the logon. Depending on the logon type the client requested, this might require additional interaction with domain controllers using protocols such as Kerberos, NTLM, LDAP , RPC , or SMB .
Because authenticating and processing logons require different protocols, it is helpful to distinguish between the two concepts when identifying the right firewall configuration.
Common use cases
The following sections describe common use cases for accessing Managed Microsoft AD and show which firewall rules you need to configure for each use case.
If you don't plan to integrate Managed Microsoft AD with an on-premises Active Directory, you only need to read the first section of this article, Accessing Managed Microsoft AD from within your VPC. If you intend to create a trust relationship between Managed Microsoft AD and an on-premises Active Directory, the entire article applies.
You can use firewall rule logs to analyze if additional ports might be required. Because the implied deny ingress rule has logging disabled, you must first create a custom, low-priority firewall rule that denies all ingress traffic, but has firewall logging enabled. With this rule in place, any failed connection attempt causes a log entry to be published to Stackdriver. As firewall rules can produce a significant volume of logs, consider disabling firewall logging again once you have completed your analysis.
Accessing Managed Microsoft AD from within your VPC
When you use the default network to deploy Managed Microsoft AD, no further configuration is required to enable VMs in the VPC to access Active Directory.
If you have customized your VPC configuration or firewall rules, you must ensure your firewall configuration still permits communication with Managed Microsoft AD. The following sections describe firewall rules you might need to create.
Domain name resolution
When a VM attempts to resolve a DNS name, it does not directly query a domain controller. Instead, the DNS query is sent to the metadata server, which is the default DNS server configured for Compute Engine VMs. The metadata server then forwards the query to a Cloud DNS private DNS forwarding zone created by Managed Microsoft AD. This forwarding zone then forwards the query to the appropriate domain controller.
You do not need to configure any firewall rules to enable this use case. Communication to Cloud DNS is always permitted for VMs in a VPC and Managed Microsoft AD allows forwarded DNS requests from Cloud DNS Cloud DNS by default.
Authenticating to a VM using Kerberos
A user that has logged in to one VM might require access to a service provided by a different VM. For example, a user might attempt to open a RDP connection, access a file share, or access an HTTP resource that requires authentication.
To allow a user to authenticate to the server VM using Kerberos, the client VM has to obtain an appropriate Kerberos ticket from one of the Managed Microsoft AD controllers first.
To enable VMs to authenticate to another by using Kerberos, the following communication needs to be permitted by firewall rules:
| Action | From | To | Protocols | |
|---|---|---|---|---|
| 1 | Allow | Client VM | Managed Microsoft AD subnet |
Kerberos (UDP/88, TCP/88) LDAP (UDP/389, TCP/389) |
| 2 | Allow | Client VM | Server VM | Protocol used to access VM, such as HTTP (TCP/80, TCP/443) or RDP (TCP/3389) |
| 3 | Allow | Server VM | Managed Microsoft AD subnet | See processing logons. |
Authenticating to a VM using NTLM
Although Windows prefers Kerberos over NTLM in most cases, clients might occasionally need to fall back to using NTLM for authentication. NTLM relies on pass-through authentication , and therefore requires the server to communicate with one of the Managed Microsoft AD domain controllers to authenticate the user.
To enable VMs to authenticate other VMs using NTLM, the following communication needs to be permitted by firewall rules:
| Action | From | To | Protocols | |
|---|---|---|---|---|
| 1 | Allow | Client VM | Server VM | Protocol used to access VM, such as HTTP (TCP/80, TCP/443) or RDP (TCP/3389) |
| 2 | Allow | Client VM | Managed Microsoft AD subnet | See processing logons. |
Domain joining and processing logons
To operate as a domain member and process logons from users, a machine needs to be able to interact with Active Directory. The exact set of protocols used depends on the logon type that individual clients request. To support all common scenarios, you should permit the following combination of protocols.
| Action | From | To | Protocols | |
|---|---|---|---|---|
| 1 | Allow | Server VM | Managed Microsoft AD subnet |
Kerberos (UDP/88, TCP/88) NTP (UDP/123) RPC (TCP/135, TCP/49152-65535) LDAP (UDP/389, TCP/389) SMB (UDP/445, TCP/445) LDAP GC (TCP/3268) |
Additionally, depending on your exact use case, you might also want to permit the following protocols:
| Action | From | To | Protocols | |
|---|---|---|---|---|
| 1 | Allow | Server VM | Managed Microsoft AD subnet |
Kerberos password change (UDP/464, TCP/464) Secure LDAP (TCP/636, TCP/3269) |
Administering Managed Microsoft AD
You must use a domain-joined VM to manage Managed Microsoft AD. To use tools such as Active Directory Administrative Center on this VM, the VM must also be able to access the Active Directory Web Services exposed by Managed Microsoft AD domain controllers.
| Action | From | To | Protocols | |
|---|---|---|---|---|
| 1 | Allow | Admin VM | Managed Microsoft AD subnet | AD Web Services (TCP/9389) |
Connecting Managed Microsoft AD to an on-premises Active Directory
To connect Managed Microsoft AD to an on-premises Active Directory, you have to create a trust relationship between forests. Additionally, you should enable DNS name resolution between Google Cloud and your on-premises environment.