Windows Credential Guard Deployment

What is Windows Credential Guard?

Windows Defender Credential Guard uses virtualization-based security to isolate secrets so that only privileged system software can access them. Unauthorized access to these secrets can lead to credential theft attacks. Windows Defender Credential Guard prevents these attacks by protecting NTLM (New Technology LAN Manager) password hashes, Kerberos Ticket Granting Tickets, and credentials stored by applications as domain credentials.

Why are we deploying it?

Security is always something that must be at the forefront of IT and with the constant attacks that are happening and the new solutions that are created, we look to improve our security posture. Michelin has always planned to deploy Credential Guard as it was part of our initial Windows 10 deployment strategy. Due to infrastructure blockers, we delayed this deployment as they needed to be addressed first. Our corporate Wi-Fi was the first piece we needed to address as it used an authentication method, MS-CHAPv2, that is incompatible with Credential Guard. As Credential Guard isolates user/device credentials in the virtual encrypted space, it blocks the MS-CHAPv2 authentication from accessing them, which is why we needed to modify our authentication methods for the network. Also, within Michelin, we started deploying 802.1x authentication protocol on the wired network which was also using the same blocking authentication method. This brought us to the point that we needed to address both wired and wireless connections before enabling Credential Guard.

Our Solution

The NET team provided the solution to move to a certificate-based authentication using EAP-TLS. We also had to determine how we would deploy and manage the certificates at the device level. We were already using MEM (Microsoft Endpoint Management, also known as Intune) to deploy certificates for our mobile devices, so it made sense to also use it for our PC devices. Due to security requirements, we needed to maintain separation between our mobile devices and PCs as our PCs need to connect to our corporate network while the mobile devices only connect to specific segments. This meant creating a new certificate chain for the PCs to provide the separation.

NDES and PKI (Public Key Infrastructure) Solution Overview

To deliver the device certificates (PCs) we set up another instance of SCEP (Simple Certificate Enrollment Protocol) alongside our SCEP deployment for our mobile devices (phones and tablets). MEM manages the certificate deployment of the SCEP certificates. The diagram below shows the basic certificate flow of SCEP using MEM.

MEM SCEP Workflow - High-level Overview
Reference: Intune SCEP workflow – [High-Level Overview]

1. The public key cert of the Enterprise CA needs to be exported with which a Trusted Certificate profile is created in MEM.
2. The Trusted Certificate profile is deployed to the managed device to establish PKI trust.
3. SCEP profile is configured in MEM and deployed to the managed device.
4. Managed device prepares a Certificate Signing Request (CSR) as per the information in the received SCEP profile and makes the certificate request to the specified SCEP URL. (This is the proxy URL configured in the SCEP profile)
5. Azure App Proxy forwards the request to the actual SCEP endpoint – NDES server
6. Upon receiving the request, NDES leverages the Intune Certificate Connector to check the request validity
7. For a valid request, NDES goes ahead and makes an on-behalf request to the CA for the certificate with the information as retrieved from the Certificate Signing Request (CSR)
8. CA generates the certificate key package and sends it back to NDES. NDES notifies successful cert enrolment status to MEM via the Intune Certificate Connector.
9. NDES sends the certificate key package to the requestor (managed device).

Our Challenges

Our Windows PCs are hybrid-joined devices, which are joined to our on-prem AD (Active Directory) and cloud AAD (Azure Active Directory). They are also co-managed using SCCM (System Center Configuration Manager) and MEM. We are also slowly moving the workloads from SCCM to MEM which means managing the devices from MEM. As the certificates are managed by MEM, we also wanted it to manage the network policies. This is where the challenge begins. The current network policies were being managed by AD and the migration of these policies from AD to MEM without disrupting the users became impossible. First, we tried using the “MDMWinsOverGP”. This did not work for us since we have some customized network settings, and the policy effectively would not work on the customized settings.

The final solution we came up with became very complex. We had to convert our current GPOs (Group Policy Objects) to GPPs (Group Policy Preference). This changes the network settings from persistent to non-persistent settings as the authentication configuration did not change. From this, we can push the MEM network settings to the devices to change the actual protocols needed to support certificate-based authentication. Again, the goal was to do this without disrupting the users, and of course, changing them multiple times did cause user impact. The real challenge here is the migration from AD to MEM policies for the critical policies you do not want the device to be without. Policy conflicts become an issue and we have found, as I already mentioned above, the “MDMWinsOverGP” ends up not working for most of the policies we currently are using. Here is the high-level steps we performed.

Step 1, deploy the needed certificates for the new network protocols we are moving to.

Step 2, converting GPO to GPP policies as mentioned. After some time to allow the policies to deploy we move to step 3.

Step 3, deploy MEM network policies to overwrite the on-prem policies so we would be managing the new policies from the cloud.

Step 4, our final step, deploy Credential Guard policies from MEM.

Another challenge we needed to address was the devices in our estate that were misconfigured and not in the proper state for Credential Guard. Due to a configuration error, we found over 10,000 devices in our estate that were either not configured with UEFI BIOS or Secure Boot was not enabled. Both of these BIOS settings are prerequisites to enable Credential Guard. We continue to address these devices but most of them have been resolved. We deployed through SCCM scripts to update the settings to the proper configuration, but this required a lot of testing to make sure we did not make matters worse as BIOS settings can be challenging over the many models we manage. Some of the oldest devices we have determined we will just refresh as the end of life is near and the BIOS requires manual a touch which is obviously more work, and the replacement needs to happen anyway.

Summary

In our overall strategy, we wanted to deploy Credential Guard and move closer to managing our devices from the cloud. The migration from on-prem policies to the cloud using MEM is complex and the discussions with Microsoft did not provide a lot of details on how to achieve what we were trying to accomplish. In my opinion, the simplest solution would be to design and build new devices fully cloud-based and migrate away from the on-prem world but since we are not quite ready for that, we are taking the harder route. We are achieving the goal of deploying Credential Guard and moving one step closer to managing from the cloud.