Windows Server Group Policy Creation for PEAP EAP-TLS

An 802.1X supplicant is a software component or client that resides on a device (such as a computer, smartphone, or IoT device) and is responsible for initiating and managing the authentication process in an 802.1X network. The supplicant communicates with the network’s authenticator (typically a switch or wireless access point) and the authentication server (such as a RADIUS/ISE server) to provide credentials, such as a username and password or a digital certificate, to verify the device’s identity before granting it access to the network. The supplicant is key in securing network access by ensuring that only authenticated and authorized devices can connect. Most operating systems – Windows, macOS, Linux, Android, and iOS – have supplicant software that can be configured.

Active Directory Group Policy Objects (GPOs) allow administrators to centrally manage and enforce security settings across all devices within a domain, ensuring consistent and secure network access. For 802.1X, configuring supplicants is essential. Manually configuring 802.1X settings on each device would be time-consuming and prone to errors, especially in large environments. This is where GPOs come into play.

Using GPOs, administrators can automate the deployment of 802.1X settings to all domain-joined devices. This includes configuring network authentication settings, specifying the use of certificates, and enforcing particular authentication methods such as EAP-TLS. By doing so, GPOs ensure that every device adheres to the required security policies without requiring individual configuration, thus enhancing security and reducing the likelihood of misconfigurations that could lead to network vulnerabilities.

This is where we will create our group policy to push down to our clients. The idea is to automatically configure the 802.1x supplicant settings and auto-enroll the certificates to users and computers via GPO to standardize security while making it as transparent to the end user as possible. Little things, such as pushing the 801.2. SSID information and enabling the users to auto-connect to the SSID when in range go a long way toward a positive user experience. Ideally, the users should never know ISE is there authenticating and authorizing their corporate-owned endpoints and acting as the gatekeeper between them and the rest of the network UNLESS a policy is violated.

Go to your Start menu and open Group Policy Management.

In the Group Policy Management window, you have several options you can proceed with:

1. You can right-click the domain and choose Create GPO for this domain and link it here… to create a new domain-wide policy. This is acceptable for a lab, but might not be where you want to start with your production environment.
2. Right-click the Default Domain Policy and choose Edit to edit the default domain policy. Again, this might be acceptable for a lab, but it is not usually where you start in a production environment.
3. You can right-click a specific OU or test OU under the domain and choose Create GPO for this domain and link it here…. You can set up a test OU for this in Active Directory Users and Computers and move test users/computers to this OU for your initial testing.

For this post, I’ll use the Default Domain Policy.

The Group Policy Management Editor window should open. This is where we will make our policy changes.

We will configure the computer settings first.

Navigate to Computer Configuration>Policies>Windows Settings>Security Services>Public Key Policies and double-click on Certificate Services Client – Auto-Enrollment.

Change the setting to Enable from the drop-down. This will enable computers to auto-enroll using the computer certificate template we previously created.

Check the boxes for Renew expired certificates, update pending certificates, and remove revoked certificates and Update certificates that use certificate templates.

Click Ok to close this window

The next thing I like to do is configure the 802.1x settings for our domain PCs’ wired and wireless NICs. As stated before, these settings will ideally be transparent to the user while reducing your administrative overhead so you don’t have to configure every NIC for every endpoint manually. By configuring it in your group policy, your domain computers will know which SSIDs to connect to, how to authenticate when connecting on wired or wireless, which credentials to use, what EAP type, certificates issued to endpoints, etc.

Navigate to Computer Configuration>Windows Settings>Security Settings>Wired Network and right-click on the white space in the right pane.

Choose Create a New Wired Network Policy. This will open the New Wired Network Policy Properties box.

You can name your policy whatever you want, and you should ensure that the Use Windows Wired Auto Config service for clients box is checked.

On the Security tab, we will select the authentication methods. Windows 11 supports the following EAP authentication methods natively:

• EAP-TLS
• EAP-SIM
• EAP-TTLS
• EAP-AKA
• PEAP
• PEAP-MSCHAPv2
• PEAP-EAP-TLS
• TEAP
• EAP-AKA’

Some methods are more secure than others. EAP-TLS (certificate-based authentication) was once considered the gold standard, but TEAP can authenticate both user and computer simultaneously using certificates. This is something that EAP-TLS cannot natively do without TEAP as the outer method. PEAP-MSCHAPv2 is one of the most deployed EAP methods for simplicity. If you want to do PEAP-MSCHAPv2, that EAP method will have ISE check the username/password while EAP-TLS checks the certificate issued.

On the Security tab, ensure that the Enable use of IEEE 802.1X authentication for network access box is checked.

From the Authentication Mode drop-down, ensure that User or Computer authentication is chosen.

From the Select a network authentication method drop-down, choose Microsoft: Protected EAP (PEAP).

Click on the Properties button to the right of it.

In the Properties dialog box, check the boxes next to your root certifies under the Trusted Root Certificate Authorities header. The name of the CA Root certificates will vary depending on whatever you named your domain.

Under the Select Authentication Method drop-down, we will select our inner method since we selected the outer method as PEAP. Choose Smart Card or Other Certificate from the available options.

Click on the Configure… button next to it.

The Smart Card or Other Certificate Properties box should pop up.

Check the boxes next to your root certificates again and click OK to save your settings.

Do the same for the rest of the boxes you have open in relation to the Wired Dot1x properties.

Note: If the 802.1x default timers for the supplicant need to be changed, click the Advanced button in the Properties box. This will open the Advanced Security Settings dialog box, allowing us to tune the 802.1x timers and settings. I rarely have to change these settings in most deployments, but knowing where this can be configured in the GPO is still important.

The Wired Autoconfig service is needed for wired 802.1x to work. By default, it is not enabled by default on Windows devices. The easiest way to enable this on all the domain-joined Windows machines is to use the GPO to set it.

Navigate to Computer Configuration>Policies>Windows Settings>Security Settings>System Settings and double-click on the Wired Autoconfig option.

Check the Define this policy setting box and choose the radio button for Automatic.

Click Ok to close this dialogue box.

Next, we will configure the wireless settings in our group policy. They are very similar to the wired settings but with some minor changes.

Navigate to Computer Configuration>Policies>Windows Settings>Security Settings>Wireless Network (IEEE 802.11) Policy. 

Right-click on the white space in the right pane and select Create a New Wireless Network Policy from the drop-down.

This will open up a New Wireless Policy Properties box. You can name this policy whatever you’d like. In my example below, I named my policy SecurityLabWireless Policy.

Under Connect to available networks in the order of profiles listed below box, click Add and choose Infrastructure

The New Profile Properties box will open.

I typically like to name the profile something that makes sense, such as the SSID name.

Under the Network Names(s) (SSID) field, you must put the EXACT case-sensitive name of the SSID you want your clients to connect to and click Add.

Optionally, you may check the boxes below to connect automatically if they are in range, enhancing the user experience since the user won’t need to connect manually.

On the Security tab for this profile, we will be configuring it just like we did with the Wired policy.

Ensure that the Authentication mode is set to User or Computer authentication, which should be the default.

Choose Microsoft: Protected EAP (PEAP) from the drop-down and click on Properties button next to it.

Check the boxes next to the Root CA’s certificates

For the Authentication Method, choose Smart Card or other certificate from the drop-down.

Click the Configure… button right next to the Authentication Method.

On the Smart Card or Other Certificate Properties box, check the Root CA certificates and click Ok to save.

Click Ok on the Protected EAP Properties to close that window as well.

Note: If the 802.1x default timers for the supplicant need to be changed, click on the Advanced button in the New Profile Properties box. This will open the Advanced Security Settings dialog box, allowing us to tune the 802.1x timers and settings. I rarely find myself having to make changes to these settings in most deployments, but it is still important to know where this can be configured in the GPO.

Click Ok to close all the dialog boxes to save your changes.

Next, we will configure the user settings in the GPO.

Navigate to User Configuration>Windows Settings>Public Key Policies and double-click on Certificate Services Client – Auto Enrollment.

Change the setting to Enable from the drop-down. This will enable computers to auto-enroll using the computer certificate template we previously created.

Check the boxes for Renew expired certificates, update pending certificates, and remove revoked certificates and Update certificates that use certificate templates.

Click Ok to close this window.

This will enable auto-enrollment for user certificates when a user logs into a domain PC.

After making your changes, click Ok to close the dialog box.

Close the Group Policy Management Editor.

If you created a new GPO, you can right-click it in the Group Policy Manager and choose Enforced to start enforcing the GPO.

After configuring your GPO, your connected domain computers should refresh their Group Policy every 90 minutes. Alternatively, you may also open a command prompt on a domain-joined computer and issue the gpupdate /force command to force an immediate refresh of the Group Policy.

After the Group Policy is updated, you can check to see if the certificates were issued with the following steps:

1. Go to the Start menu
2. Type in mmc and press enter to open a Microsoft Management Console
3. From the File menu of the MMC, choose Add/Remove Snap-in…
4. From the Add or Remove Snap-ins menu, click on Certificates and click Add.
5. Choose My user account from the dialog box.
6. Click Add again
7. Choose Computer account from the dialog box.
8. Click Ok to close the Add or Remove Snap-ins dialog box.
9. Navigate to Certificates – Current User>Personal>Certificates to ensure that a user certificate was issued from the AD Certificate Authority
10. Navigate to Certificates (Local Computer)>Personal>Certificates to ensure that a computer certificate was issued from the AD Certificate Authority.
11. Close the MMC
12. Open the Network and Sharing Center on your computer
13. Click on the link for Change adapter settings
14. Right-click on the wired network adapter and choose Properties
15. From the Properties dialog box, select the Authentication tab
16. Your supplicant settings here should match what you configured for the Wired 802.1x policy you configured in the GPO

Your Group Policy Object was correctly applied if the above matches your expectations.

Another way to check to see if your certificates are being issued is to open up Certification Authority again, you should be able to see the issued certificates under the Issued Certificates folder.

If you find yourself not having certificate issues, some reasonable troubleshooting steps are:

• Check the Failed Requests folder in Certification Authority
• Check to make sure that the GPO is being pushed to the local machine by doing an RSOP
• Check the permissions on your certificate template to ensure your Domain User and Domain Computer groups have Read, Enroll, and Autoenroll permissions for the appropriate certificate templates. Also, make sure that other certificate templates do not have the same auto-enroll permissions (pxGrid)

The next thing I like to do after this is to ensure that my Certificate Web Enrollment Page is working. Open the browser on a computer attached to the local network or on your Windows Server, and navigate to https://AD-Server-IP/certsrv to ensure you get the following page.