Windows Firewall Part 6: Azure AD Joined Clients

At this point, it’s now possible to make any/all services available from anywhere utilizing certificate authentication to Domain Controllers, obtaining computer and user Kerberos tickets, and further authenticate to other services. This now poses a new problem in the modern-managed world: Azure AD joined clients. Up until now, all client testing has been done from either a traditional domain-joined client, or a hybrid Azure AD joined client, so the computer account was able to obtain a Kerberos ticket. This isn’t possible from a Azure AD joined client; there’s no computer identity in AD to issue a ticket for.

In the current configuration, this isn’t an issue when an AADJ device is connected to the internal network, since authentication is not currently required, user Kerberos tickets can still be obtained, and resource access can continue as usual. From the external perspective, authentication to a DC is possible, but everywhere else is still using computer Kerberos authentication as part of IPSec main mode negotiation.

The solution here is to replace the use of computer Kerberos authentication with certificate authentication across all endpoints. Then, a configuration policy in Intune wlll be used to enroll a computer certificate on AADJ clients via the Intune Certificate Connector, and IPSec on AADJ clients will be configured PowerShell.

Updating the Domain IPSec Configuration

First, the domain-wide IPSec configuration policy previously created needs to be updated to utilize computer certificate authentication by default. Begin by editing this policy, and go back to Windows Firewall properties, IPSec Settings, and Customize IPSec Defaults. Under Authentication, select Advanced, click Customize, and add a new first authentication method.

In this example, I’ve selected “Computer certificate from this certification authority”, and specified my internal root CA in which a certificate must be chained from in order to be used for authentication. After clicking OK, I will then move this to be first in the list of choices.

Eventually, I will remove the Computer Kerberos option, as it will no longer be necessary, but for now, I will leave both to ensure that existing configurations will continue to function.

After making the above change, and running a gpupdate on the DCs, the apps server, and the client, I can verify functionality by again testing access to the apps server, and see that it changed to using computer certificate authentication as the first authentication method.

Note: The above was a test to the apps server from a HAADJ client on the “external” network. That gpupdate I ran to get the new IPSec configuration? Also completed successfully from the “external” network. Pretty neat, isn’t it?

Azure AD Joined Certificate Enrollment

In order to utilize certificate authentication on AADJ clients, first create a configuration profile in Intune to enroll a certificate via the Intune Certificate Connector. In Microsoft Endpoint Manager, create a new profile for Windows 10 and later, using the PKCS template.

Next, configure the profile as follows:

• Renewal threshold: 20%
• Validity period: 1 year
• Key storage provider: TPM KSP if present, otherwise software KSP
• CA: <Issuing CA FQDN>
• CA Name: <Issuing CA Name>
• Certificate template name: <Certificate Template Name>
• Certificate type: device
• Subject name format: CN={{DeviceName}}
• Subject alternative name: URI: CN={{DeviceName}}

Above is an example configuration used in my lab. (Yes, my single tier enterprise root CA is running on a Domain Controller. Don’t judge me, it’s a lab!)

Next, assign this profile to a defined set of devices (in my lab, I’m using All Devices, this isn’t typical of a production environment), review the configuration, and create it.

Azure AD Joined Trusted Certificate Profile

Next, create a Trusted Certificate configuration profile in order to import the internal root CA certificate onto AADJ clients. Similar to above, create another Windows 10 and later profile using Templates, this time choosing Trusted Certificate. Name it “Trusted Root Certificate”, upload the cer file for the root CA, and select the computer certificate store – Root. Again, in my example, I’ll assign it to All Devices, and save the configuration.

In a production environment, a second profile will most likely need to be created to import an intermediate CA certificate to the correct store as well. In my lab, I’m running a single tier enterprise root CA, so this step is not necessary here.

AAD Client IPSec Configuration

Now, IPSec needs to be configured on the AADJ client. Since these settings are not exposed natively via Intune configuration profiles, they’ll need to configured via PowerShell. The below code, also on my GitHub, is a example starting point that functions similarly to the configuration I’ve previously used on domain-joined endpoints via Group Policy.

Walking though the above code step by step…

• Lines 4-5 configures the default main mode crypto set using the same configuration defined in the domain IPSec configuration policy.
• Lines 8-10 configures the default quick mode crypto set using the same configuration defined in the domain IPSec configuration policy.
• Lines 13-14 configure the default phase 1 auth set to use computer certificate authentication chained to my lab root CA.
• Lines 17-18 configure a named phase 2 auth set to use user Kerberos authentication
• Line 23 defines a Connection Security Rule to request authentication via the default phase 1 auth set of computer certificate. No phase 2 auth set is defined in this rule, which means the default is used. Since I did not configure the default phase 2 auth set, it is left unused.
• Line 26 defines a Connection Security Rule to request computer certificate and user Kerberos authentication to connect to my ConfigMgr server via TCP port 445.
• Line 29 defines a Connection Security Rule to request computer certificate and user Kerberos authentication to connect to my Apps server via TCP port 8080.

For now, I am running this script directly on an Azure AD joined client to configure the IPSec policy. In the future, this can be converted into a Proactive Remediation for deployment across all AADJ clients and for ease of future changes.

Testing/Verification

After running the above script on my AADJ test client on an external network, I’ve rebooted it, and signed in again, and ran the following to verify connectivity.

As seen above, I’ve successfully connected to my DCs and app server, all utilizing authenticated connections, from an external network, including verifying that user Kerberos authentication is working to the secured app server previously configured.

Summary

At this point, the utilization of certificate authentication has been expanded to Azure AD joined clients, to allow access to on-premises resources without a traditional VPN. Provided that all of the necessary server and client side rules have been configured, any and all resources should now be accessible from a modern-managed client, utilizing certificate and user Kerberos authentication, and user authorization as necessary for services that need to further secured.