Windows Firewall Part 5: Bootstrapping Kerberos via Certificate Authentication

Part 5 of this series will go over how to utilize certificate authentication to make services available from anywhere, without the need of a traditional VPN. Up to this point, firewall policies have been configured for all endpoints, and some services have been configured to require authentication via Kerberos. This however poses a problem in the current configuration. Everything is currently tied back to being able to authenticate via Kerberos.

The specific blocker is computer Kerberos authentication. From an external viewpoint, there’s a need to be able to authenticate to a Domain Controller to obtain Kerberos tickets, but this is currently not possible, since the necessary ports are only open to the internal network. This is where the power of certificate authentication comes into play. By using computer certificate authentication to create secure communication channels to a domain controller, Kerberos tickets for computer and user accounts can be acquired, and access to further services is possible. It’s essentially a “mini VPN” for every connection, with “automatic split tunnel” based on defined rules.

Configuring Secure DC Firewall Rules

First, create a new set of firewall rules for Domain Controllers to require authentication, and Connection Security Rules to define the desired authentication. Going back to my example DC firewall policy, I’ve chosen to move the “any” rules for DHCP and DNS to their own policy, to make the next part easier. In the end, I will have 3 distinct GPOs for DC firewall rules: Client (Any), Client (Internal), and Client (Secure).

Create a new GPO for the secure rules to be configured in, and create the rules by copying the existing rules with the following PowerShell commands.

The above commands will copy all of the existing rules to the new GPO, changing the rule names in the process, update their display names to append “(Secure)” to them, configure authentication as required, and set the remote address to Any.

Configuring DC Connection Security Rules

Next, create two Connection Security Rules to define when authentication is requested and required. In a new or existing policy linked to the Domain Controllers OU, add a new custom Connection Security Rule, with endpoint 2 defined as all internal address ranges.

Configure this rule to request inbound and outbound authentication, with a custom authentication method consisting of only computer certificate authentication, chained to an internal root CA.

Leave Protocol and Ports as default, as well as Profile, and give it a useful name such as “Request Auth (Internal)”.

Repeat this same process for the second rule, except configure it to require inbound and outbound authentication, and scoped to any IP addresses. This will be the resulting configuration.

Configuring Client Connection Security Rules

Next, configure a Connection Security Rule for clients to request authentication to DCs using a computer certificate.

• Rule Name: “DC – Request Auth from Any”
  • Endpoint 1: Any
  • Endpoint 2: Domain Controller IP addresses
  • Authentication Mode: Request inbound and outbound
  • Authentication Method: Custom (computer certificate)
  • Endpoint 1 port: any
  • Endpoint 2 port: any

The resulting policy should be as follows (note the already existing rule configured previously):

Testing/Verification

Now that the necessary firewall and connection security rules have been created, it’s time to test the configuration. After issuing a gpupdate on all Domain Controllers and verifying the Connection Security Rules are in place via the firewall management console (wf.msc), first log in to a client while connected to the internal network. In this example, I’ll also run a gpupdate on the client, browse to each DC, and test connecting to the web server I previously secured access to.

As seen in the above screenshot, I was able to connect to each DC with certificate authentication, and the web server with computer and user Kerberos authentication. Since the DC client rule is configured to request authentication from anywhere, this is expected behavior. Now, I’ll move my test client to an “external” IP range, where the DC rule will require auth, and perform the same tests.

The results look the same, as expected. The local address this time is 172.30.1.208, which is outside my internal range defined in the normal firewall rules, so authentication was required for all connections. Since I was able to establish secure connections to the DCs, I was able to obtain both computer and user Kerberos tickets to be able to authenticate to the server web server and access it.

From here, any other server that is configured with secure firewall rules and connection security rules, along with corresponding client side connection rules, are now internet-accessible! From a security standpoint, even though services are internet-accessible, connections cannot be completed unless the correct authentication can be provided. This can be tested by attempting to access resources externally from a workgroup client; since authentication is required, and the necessary credential isn’t present, nor configured for use, connection attempts will simply be dropped.

Summary

At this point, the ability to connect to a domain controller from anywhere using certificate authentication has been configured, enabling the ability to obtain Kerberos tickets, which can be used to access further resources. A “split rule” configuration has been utilized, where each service is defined with 2 rules; one normal rule for “internal” access, and one secure rule for access from anywhere. Since the Windows firewall uses “best-match” when deciding to allow or deny traffic, this configuration will allow inter-op with clients not able to perform the necessary authentication while on premises, such as macOS or Linux endpoint, and also allow authenticated connections from off premises from devices that support it. While the ability to use an application such as WireGuard to authenticate via certificate from macOS/Linux is possible, it is beyond the scope of this series.