Featured Post

Using VMware's Horizon Performance Tracker For Rudimentary Blast Optimization

Recently updated for Horizon 7.10, the  VMware Blast Extreme Optimization Guide  focuses on, "two key configurable components: the tran...

Sunday, March 7, 2021

A Quick And Easy Win Along The Path To Zero Trust: Workspace ONE's Certificate Authentication For Windows 10 And macOS

I was recently introduced to an elegant solution for enabling certificate authentication on Windows 10 and macOS devices through VMware's Workspace ONE.   By leveraging WS1 UEM's built in certificate authority WS1 admins benefit from a self-contained, entirely cloud based, end to end solution for both certificate authentication and distribution.  It provides an efficient and wieldy means for enforcing cert auth in modern management use cases, enabling a significant leap forward on the journey to Zero Trust.  While the required steps are a bit advanced, with the right expertise and access requirements, they can be easily implemented in less than an hour.   Once completed, Horizon desktops or apps, SAML federated apps,  or the Workspace ONE portal itself can benefit from certificate authentication on Windows 10 or macOS.  


In and of itself certificate based authentication improves security while simplifying access for users.  More notably, in the context of Workspace ONE modern management it lays the ground work for leveraging WS1 UEM's device compliance policies.  Conditional access based on device compliance ensures that apps integrated with WS1 are only accessed from devices that have earned our trust through WS1 enrollment and compliance, regardless of network location.  Trust is earned and verified at an on-going basis as device posture is regularly incorporated into conditional access policies applied to protected apps.  As a result, clear progress along the path to Zero Trust is achieved given that a guiding principal of Zero Trust adoption is the need for continuous authentication and authorization of endpoint devices.   



















Very arguably the proliferation of mobile devices has played a major role in forcing traditional IT shops to embrace Zero Trust principals and adoption.  Fortunately, capabilities developed supporting these devices within the enterprise are easily extended to Windows 10 and macOS through WS1.  Conditional access based on device compliance is a prime example of this.  For nearly half a decade this feature has been wildly popular among AirWatch customers supporting iOS and Android devices.  As a result, it's a very mature and proven capability that modern managed devices stand to benefit from.  Just as with mobile devices, UEM admins can define proper security posture for Win10 devices and macOS devices, then control access to apps accordingly. 

























When WS1 UEM device compliance policies are leveraged by WS1 Access policies, trust is constantly earned, as WS1 regularly monitors the posture of the underlying device. A device that is suitable for access today may be rejected tomorrow should it fail to maintain security posture defined and enforced through WS1 UEM.  For example, an enforced requirement could be for devices to be both enrolled and and running anti-virus in order for them to gain access to Office 365. 


To further progress across the Zero Trust spectrum we can additionally inform conditional access policies with Risk Scores from Workspace ONE Intelligence.   These Risk Scores not only factor in user behavior across enterprise devices, but can also incorporate insights from Carbon Black.  

Regardless of whether you own WS1 Intelligence or not, the path to Zero Trust through WS1 modern management can begin with a very accessible and easy to implement process for enforcing certificate authentication.  Considering the required effort versus the impact of this solution, the juice is definitely worth the squeeze.  It shifts Zero Trust away from a lofty theoretical concept to something well within reach using mature and proven Workspace ONE capabilities.  


The Recipe 


I was introduced to this recipe while training on support of Zero Trust with Workspace ONE.  Though I'd love to simply share that course curriculum directly in this post it would be morally dubious to say the least.  Fortunately, I found publicly available guidance that's damn near identical to what I received in my training.   This guidance is called, "Windows 10 Certificate Single Sign On Using An AirWatch Certificate authority."  Further, while scouring the internet for additional information I happened upon this personal blog post, "Workspace ONE - Windows And macOS Certificate."  It's a lovely post, completely in line with the training I received, while also providing guidance on macOS.

Since folks can already access these resources for step by step specifics, here I'm simply going to present an outline of the recipe while calling out some highlights. 

Implementing Certificate Auth On Workspace ONE:
  • Export issuer certificate from UEM
  • Enable Certificate Authentication on WS1
    • Upload issuer certificate from UEM
    • Enable Cert Auth On Appropriate IDPs
  • Create SCEP User Based Profiles on UEM
  • Create Conditional Access Policies 
  • Disable certificate prompts

After following the above steps, you'll have the basic use of certificate authentication available across your modern management use cases for Windows 10 and macOS.  You can mandate certificate authentication for access to your WS1 portal, or on a more granular level, make certificate authentication a requirement for specific applications using conditional access policies.  


Major Steps


What really helps simplify the whole strategy is leveraging the built-in CA of your Workspace ONE UEM tenant.   Assuming your WS1 UEM tenant is already integrated with WS1 Access, navigate to Groups & Settings->All Settings->System->Enterprise Integration->Workspace ONE Access->Configuration.   If Workspace ONE UEM certificate provisioning isn't already enabled, then enable it.  Then export the issuer certificate.  
















Next, you're going to scoot on over to your WS1 Access administrator console, navigating to, "Authentication Methods," under, "Identity And Access Management."  Here you're going to enable the, "Certificate (cloud deployment)," method, uploading the issuer certificate just obtained from the WS1 UEM console.  


















You'll need to ensure the Certificate (cloud deployment) authentication method is enabled for your Built-in identity provider or any other relevant IDP configured for your environment, the same you would for any other authentication method.  After that you need to configure your SCEP payloads to distribute and manage certs on your endpoint devices.   These are going to be user based profiles for Win10 and macOS devices.  



















With Certificate authentication enabled and certs getting distributed through SCEP, a final step is configuring the enforcement of this authentication method through conditional access policies. 


Creating Your Conditional Access Policies 


When it comes to configuring conditional access policies a main consideration is whether you're going to combine certificate authentication with device compliance policies. If you just want any enrolled devices to have access, regardless of device posture, you can simply select Certificate (cloud deployment) as the primary auth method, along with any fall backs. Otherwise, if you want to predicate successful certificate auth on compliance with UEM device compliance policies, then choose to combine cert auth with device compliance.   



















In the sample above, compliant devices will gain access to the application through certificate auth, while non-compliant devices will fall back to 2FA with VMware verify.  Devices not enrolled in WS1 UEM or not assigned the proper SCEP policy won't have access at all.  It's an example of where you might go with things if you wanted tighter security.  Along those lines, if you wanted to layer WS1 Intelligence on top of this model, you might go with something like this:















In the example above, Risk Scores are incorporated into your conditional access policies, allowing us to adjust authentication requirements with analysis from Workspace ONE Intelligence.  If a device is compliant and the user has a healthy risk score, they'll have a smooth access experience logging in.  However, if their device meets compliance requirements but the user has a poor risk score, they'll be forced to provide a 2nd factor of authentication with VMware Verify.   

For a nice overview of conditional access policies here's some enablement I recently collaborated with some colleagues on called, "WS1 Access Series Episode 2 Office 365 Integrations And Conditional Access." In the video I spend about 25 minutes reviewing conditional access policies and device compliance.  Further, if you're interested in getting deeper on the subject, I highly recommend this comprehensive and fairly new post, "Workspace ONE Access: Best Practices In Policy Management."


Removing The Certificate Prompt



While the visible certificate prompts at login are useful for initial setup and troubleshooting, long term it's more desirable to have cert selection automated.  Fortunately, there are ways to achieve this on both Win10 and macOS devices across various browsers. 


Windows 10 Certificate Prompts

On Windows 10 devices, when leveraging Chrome for WS1 Access it's all about the
AutoSelectCertificateForUrls Chrome policy. To take this feature out for a very quick test spin you can create the registry edit manually by first adding the key:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\AutoSelectCertificateForUrls

Then, create a string value of 1, with the catch all syntax of:

{"pattern":"[*.]","filter":{}}










You could fine tune this syntax with something a bit more specific, for example: 

{"pattern":"https://cas-aws.vmwareidentity.com/","filter":{}}

For the Microsoft Edge browser, not surprisingly, we have a very similar process for handling the certificate prompts.  Essentially, we have the same pattern format for catching the cert, just under a different key.   

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge\AutoSelectCertificateForUrls

For more specifics check out the official Microsoft documentation for AutoSelectCertificateForUrls.   Below is a screenshot from my own lab. 












Finally, when it comes to IE, there's an easy to use option from internet settings. You can navigate to Security Settings under Internet Options, then enable the policy, "Don't prompt for client certificate selection when only one certificate exists." 























Getting These Win 10 Settings Pushed Out Through UEM


To get these registry settings automatically pushed out to your endpoint devices, if your Win10 endpoints are domain joined, you could always turn to AD GPO settings for Edge and Google Chrome. Here’s a screenshot from my lab:



While using AD GPO’s is certainly an option, it doesn’t feel very modern management-ish, does it? A lot of us turn to modern management to break away from dependency on AD domains, so finding an alternative for delivering these settings through UEM is more desirable. Fortunately, when it comes to migrating away from AD GPOs to WS1 UEM delivery, there’s like 17 ways to skin that cat. One option is to leverage Workspace ONE Baselines to deliver the GPO settings through a Custom Baseline. In my own lab this started by exporting the GPO using the Group Policy Management tool. Then, after zipping up this backup, I uploaded it to a Custom Baseline.


























Then, for extra credit I went ahead and added the option for configuring cert selection on Internet Explorer. (The backed up GPO already included settings from Chrome and Edge.)













After pushing this Baseline out to my Win10 endpoints I was in business and had the desired behavior.   

Again, because we're talking about Windows 10 and WS1 UEM, there's a lot of ways to approach getting these settings pushed out.  For instance, there's this option for pushing out registry settings with a custom profile.  Also, there's this post on pushing out these setting via a reg file and UEM's product provisioning capabilities.  Hell, you could even use AirLift to export your Google Chrome GPOs to a custom profile.   Along those lines, using CSPs to configure Chrome settings is detailed in this older article, Windows 10 - Chrome ADMX.  


macOS Certificate Prompts

To rid yourself of certificate prompts on macOS for Safari we can use the Identity Preference option in the SCEP profile.  By entering in the CAS URL, we can have the cert automatically selected when it comes times for cert authentication.  


For more details on this Identity Preference setting check out the official macOS Device Management Guide.   

When it comes to disabling certificate prompts for Google Chrome, once again, it's all about the AutoSelectCertificateForUrls Chrome policy.  For macOS, this can be configured through a custom payload.  Below is an example from my own lab:


For additional guidance on this macOS policy, you can check out VMware's guidance in this TechZone article, Managing Identity Preferences To Streamline Single Sign-On For macOS.   

East Bound And Down!!!!!


During my recent training it became clear that Zero Trust is a worthy goal and destination, though the march towards it probably wont be fun or glorious.   For most organizations it's not going to be a straight path but rather a series of bursts and stalls, as immediate needs are balanced with long term security objectives.  Further, most organizations will never quite be completely, "there."  That said, there's definitely examples of progress, with Workspace ONE certificate authentication being one of them. It's a clear win, a successful battle, in the long drawn out war that is Zero Trust adoption.  Further, it's a quick win.   To a dorcus malorkus such as myself, it feels swashbuckling, folksie, edgy and, most notably, wildly effective.  When implementing the process for the first time I felt like Jerry Reed in Smokey And The Bandit, barreling across the Zero Trust spectrum with blinding efficiency.

 

Adding A 3rd Party CA Later On 


One of my favorite aspects of this recipe is that it leverages Workspace ONE's built-in CA.  Overall, this makes the entire solution much more accessible and easy to wrap your head around.   When you start talking about 3rd party CA's, a lot of times, folks eyes begin to glaze over as hope drains away.  Pulling off an integration between WS1 Access, WS1 UEM and your various endpoint devices is already daunting enough.   Throw in a 3rd party CA that an WS1 admin probably doesn't have control of and things can get overwhelming.   All that said, I've had brainier folks tell me there's scenarios where using a 3rd party CA is more flexible and appropriate for production.  If that sounds like your situation, you can always start off with the basic recipe called out in this post, then move on to a 3rd party CA when you're ready.   Steveidm details what the process could look like in the article, "Setting Up A 3rd Party CA With Workspace ONE In Your Lab Environment." 

No comments:

Post a Comment