Featured Post

Wrapping VMware's Workspace ONE Security Around G Suite Consumption

Recently I helped design an integration between G Suite (Google Workspace) and VMware's Workspace ONE.  A key objective of the design is...

Thursday, June 17, 2021

Ruthless Automation With Workspace ONE Intelligence










A common description of Workspace ONE Intelligence goes like this: it allows you to aggregate, correlate and automate. While this is accurate, I'd like to reverse the order, emphasizing the solution allows you to automate, targeting this automation based on data aggregated in the Intelligence cloud.  WS1 Intelligence enables ruthless automation and that truly distinguishes it as solution.   It provides the ability to trigger automated responses across iOS, Android, Win10 and macOS devices anywhere in the world.   We can finely tune and customize these actions within a WS1 UEM environment and, further, potentially extend this automation to any 3rd party solution that supports a REST API.   

This post begins by exploring the built-in automation capabilities of WS1 Intelligence for WS1 UEM, Slack, and ServiceNow.  Through Intelligence, "Workflows," actions across these environments can be chained together to formulate a wholistic response to targeted incidents or state changes.   Next, this article will review how custom connectors not only allow us to finely tune these triggered responses, but also extend the reach of Intelligence automation to 3rd party SaaS apps that support a REST API.   To that purpose I'll explore the use of Postman in the creation of these custom connectors, using ServiceNow as a model. Finally, I'll circle back to the data within Intelligence that triggers this glorious and ruthless automation. 


Built-In Automation For WS1 UEM


Common tasks executed through the WS1 UEM console can be automated through WS1 Intelligence.  Out of the box there are 28 built-in actions for UEM available within the Intelligence Workflows, anything from removing apps or profiles to enterprise and device wipes. Further, as a catch all, there's the option to TAG devices, which opens up the possibility to achieve anything normally accessible through policies and smart groups.  Below is a partial screen shot of the UEM automations built-in to Intelligence.  The official documentation enumerates these 28 options under the section, "Automations For Workspace ONE Intelligence." 


















For those familiar with Workspace ONE UEM, another way to think of Inteligence is as an advancement of device compliance policies. Through device compliance policies we've always had the ability to trigger a handful of actions based on a handful of device properties.  A compliance engine drives the enforcement of, "closed-loop workflows where a user can have resources after becoming compliant again."   While device compliance policies are great at enforcing compliance, again, they're narrowly focused on a handful of device properties and actions. 







Compliance policies are still relevant, however, in terms of pure range of actions, Intelligence takes automation to the next level, allowing folks to automate pretty much anything that can be done from the UEM console.  Further, these actions can be triggered by an extensive range of attributes collected in the Intelligence cloud, with hundreds of UEM gathered device traits to choose from, let alone information gathered from Sensors or Trust Network partners.   











So along with a wider range of actions we also gain the ability to drive this automation with information from the Intelligence data lake.   Further, these actions can transcend the WS1 environment, extending to 3rd party apps that support REST APIs, starting with the built-in connectors for ServiceNow and Slack. 


Built-In Connectors For ServiceNow And Slack 













Along with WS1 UEM, there's built-in actions for ServiceNow and Slack.  For ServiceNow there's options to create incidents and tickets, while for Slack you can send messages to channels and users.  Enabling these integrations is simply a matter of adding base URLs and credentials to preconfigured connectors, so existing ServiceNow and Slack customers can quickly extend WS1 Intelligence goodness to these solutions.   As you leverage these built-in automations within, "Workflows," there's options to populate fields with relevant variables from WS1 Intelligence, as illustrated in the image below.  
















For a wonderful overview of enabling these built-in connectors check out this video in Tech Zone, VMware Workspace ONE Intelligence: Connectors - Feature Walk Through. It not only reviews the process of authorizing these connectors but also introduces WS1 Intelligence Workflows, the mechanism for defining automated responses to changes within your environment.


Chaining Automations Together With Workflows 


Through WS1 Intelligence Workflows IT departments define automated responses to events within their Workspace ONE environments.  These can include actions through UEM, ServiceNow, Slack and any 3rd party solution they've developed a custom connector for.  Workflows not only streamline responses and resolutions but also enable proactive remediation before a user has been impacted by challenges.  For example, consider a situation where someone is running low on disk space.  Instead of having a user slowly experience performance degradation Intelligence can proactively trigger a series of actions. 
















In the example above, when a device has less than 2 gigabits of storage the user is sent an email notification through WS1, a ticket is automatically created in ServiceNow, and a message is sent to the IT team through Microsoft Teams.  This not only saves time for staff but also spares the user from performance degradation.   The video below includes a demonstration of Workflows and also provides a general overview of integration options between Workspace ONE and ServiceNow.


The integration with Teams in the video above was made possible by a sample custom connector that interacts with a Microsoft REST API.   It's a great example of the extensibility made possible by custom connectors. 


Sample Custom Connectors

Similar to the built-in connectors for Salesforce and ServiceNow, you can create custom connectors for other 3rd party applications that support REST APIs. In a nutshell, if you can execute a task in a 3rd party app with a single request through Postman there's potential to automate that process through WS1 Intelligence.  Sample custom connectors are available from the VMware Sample Exchange, under the description, Workspace ONE Intelligence Custom Connector Samples.  These sample json files,  collections that have been exported from Postman, can be directly imported into WS1 Intelligence to integrate with solutions like Jira, Salesforce and Remedy.   For instance, the messaging to Microsoft Teams shown in the demo video above is achieved through a direct import of one of these samples.   






While you can import these samples directly into WS1 Intelligence as is, you can also import them into Postman to take them for a test spin or tweak them out according to your needs. 









Postman, a REST Client that allows you to easily develop and test out REST API calls, is what Workspace ONE Intelligence itself uses behind the scenes to execute actions defined for connectors. Fortunately, the free version of Postman available at postman.com has all the features you need to create your own custom connectors. There's an excellent overview of the tool at https://learning.postman.com/, though I'm also quite fond of this short and concise ServiceNow oriented post in ServiceNow Communities. Given the ubiquity of REST APIs throughout the Horizon and Workspace ONE stack it's a nifty tool to have lying around. 


Creating Your Own Custom Connector 

Creating your own custom connector begins with developing calls to the 3rd party solution's APIs through Postman.  Once you have a request successfully tested you perform an export from Postman to a JSON file that's imported into Intelligence.  After the import's complete you'll have access to the call within the Intelligence Workflows interface.  Further details are provided in Workspace ONE Intelligence Custom Connector Samples and within the official guide under the section, Custom Connectors.  To illustrate the whole process from start to finish the following is an example customization for ServiceNow.  

Below is a request to ServiceNow that will create a new task under, "Service Catalog."  It's based off of ServiceNow's Table API and it's sc_task action for adding catalog task records.   Accordingly, within Postman I've entered in the proper URL for this call along with parameters and authorization.  











When this request is successfully sent a new task is created within ServiceNow.  With the logic validated and tested you can begin the export process by saving this successful response as an example. 



Also, be sure to add the header, Content-Type: application/json, or else the import process into WS1 Intelligence will fail.  


Finally, with the collection selected in the Postman interface choose export and go with Collection v2.1 as the export type. 














Next, you want to take this JSON and import it into WS1 Intelligence. From within the Intelligence console navigate to Integrations --> Workflow Connectors.   Click on the option, "Add Custom Connector."  You'll be prompted for a custom connector name, as well as for a base URL and authorization for ServiceNow.   Once you provide this information you'll have an option to import the JSON that's been exported from Postman.   























After a successful import you'll see the imported action.  You can also test out the imported action as part of the import process. 














Going forward you'll have this action to choose from when developing Workflows within WS1 Intelligence.
 


















To recap, if you can automate a task in a 3rd party app with a single request through Postman, there's potential to automate that process within WS1 Intelligence. That's not to say you can do anything and everything available in the 3rd party app's REST APIs. You're restricted to a single request, quick outbound calls without any kind of back and forth or chaining of request, so your mileage may very. However, a good friend of mine pointed out that a lot of times the 3rd party applications offer customizations of their services that allows you to push this trickier logic over for them to handle. A great example of this are the options in ServiceNow to create custom APIs.


ServiceNow Options 

A few features of ServiceNow in particular make it well suited for integration with Workspace ONE Intelligence. To begin with there's the ability to create custom REST APIs and web services.  Earlier I mentioned that WS1 Intelligence is limited to leveraging single calls from Postman, without the ability to chain multiple calls in a collection.  Well, we can fill in the gap by creating custom services in ServiceNow, allowing for the handling of complex logic on the ServiceNow side of the equation.  A wonderful example of this is detailed in the blog post, "WS1 And ServiceNow," by David Pacold.  In this post David offers a recipe for populating ServiceNow with device asset information from WS1 by creating a system web service in ServiceNow that's fed asset information from a WS1 Intelligence connector.   

Another benefit to ServiceNow adoption is its REST API explorer.   This utility, built right into ServiceNow console, facilitates the exploration and testing of REST API calls.  It provides the ability to test calls in real time while providing guard rails, if you will, as you explore the APIs functionality.  For example, to explore the Table API demonstrated in the previous section, you can open REST API explorer and select the api from an easy to use drop down menu.  Then, after choosing the REST operation type, it guides you through the different parameters that can be used by the API call.  












Further, after selecting the parameters, you can test out the call directly from the utility with the results displayed at the bottom.  If the results are desirable, you can copy the syntax of the command directly from explorer into the body of your request within Postman.    

Given the convenience the REST API explorer offers, a clear path forward when working with ServiceNow is: 

REST API Explorer —> Postman —> Collection_Export.json —> Custom_Connector

With a well documented Rest API, a Rest API Explorer, and various options for creating custom services, ServiceNow is an ideal candidate for WS1 Intelligence integration.  Fortunately, while ServiceNow provides a stellar example of what's possible, very arguably other 3rd party solutions will offer similar advantages.  The question of, "what can we automate in 3rd party solutions using WS1 Intelligence," boils down to, "well, what kind of REST APIs are available from these 3rd party solutions and what kinds of customizations do they support?"  Further there's the question of, "well, how comfortable and familiar are you with working with the REST API's of these 3rd party vendors?"  If the answer is, "very," well, there's a lot of potential for creating rich automations an integrations between Intelligence and that 3rd party app. 


Okay, Now Let’s Talk About Data


Now that it's clear what type of automation is possible and at stake, lets talk about driving this automation with data from Intelligence.  If there's a single theme or thesis for this entire post, it's this: we leverage data from WS1 Intelligence to drive and trigger glorious and ruthless automation.  Exploring Widgets within dashboards makes this clear. 















To illustrate, say you want to target an automation against a specific set of windows 10 devices. You might start with a simple widget that filters out devices from your environment by focusing on enrolled windows 10 devices that have checked in within the last 28 days.



















Now, you have a very simple widget that targets these active Windows 10 machines.  If you wanted to target all these devices you could view the widget, click the automate button, then pick and choose from the automated actions.   However, if you wanted to narrow the results down, you could could leverage the group by function within the widget to subdivide the displayed results by a wide range of options.   














For instance, by choosing to group by encryption status, I have broken down the results into 2 sets of active Win10 machines, those encrypted and those that are not.   





















As I click through this visualization, perhaps drilling down into the unencrypted devices, again, I have the option to associate automations with this subset of the original query.   



























So the widgets give us a useful way to absorb the data in a more visual way, shifting away from one dimensional reporting.  Further as you crawl through the data you can add automations along the way.  To my mind, this is a wonderful example of not only the data made available intelligence, but ways in which the solution allows us to sift through the data and finely target automation.  


Sources Of Information For The WS1 Intelligence Data Lake


With automation driven by information from the Intelligence data lake a natural question to ask is, "well, just what information is in there?"  Out of the box there's a boat load coming from several datasources, as detailed in the TechZone article, "Workspace ONE Intelligence Architecture."  From WS1 UEM alone there's over 200+ data points last I counted.   Then there's WS1 Access for any applications integrated with the Workspace ONE portal through SAML.  For any internally developed apps that have the Workspace ONE Intelligence SDK embedded there's additional app analytics made available from the solution formerly know as Aptelligent.  Further, there's Common Vulnerabilities and Exposures (CVE) and Common Vulnerability Exposure System (CVSS) information pulled in on a daily basis about Windows 10 and macOS.  Finally, there's the extensibility afforded through Sensors, allowing you to pull custom information from Win10 and macOS using scripts.  Once collected, this information then becomes viewable and actionable form the WS1 Intelligence console, complementing the already extensive device information provided by UEM.   



















Also, as depicted in the drawing above, we can populate Intelligence with threat information collected by security partners of the Trust Network.   This Trust Network partnership currently includes about a dozen partners, though Carbon Black is arguably the crown jewel.  Carbon Black can provide next generation antivirus protection and insight across both Windows 10 and macOS.  As with the rest of the data ingested by intelligence, this threat data can be used to drive automation through Intelligence, starting with WS1 UEM itself but also extending to any other enabled connectors. 











While I think WS1 Intelligence has potential to benefit most use cases, to my mind, modern management is where it shines brightest.   As someone who got clobbered by one worm after another throughout the 2000's, the ability to trigger a coordinated response to threat detection alone is extremely compelling.  The range of visibility across modern managed devices is impressive as well.   When you take the normal visibility offered through UEM, then enhance it with Sensors and Carbon Black, you're getting an awful lot of insight and perspective.  If security is top of mind for Win10 and macOS users this stack is hard to beat. 


Conclusion 

Over the last couple years I've slowly been won over by WS1 Intelligence.  I must admit, initially, I was a little bit cynical about the solution.   The earlier marketing material sounded to me like to the INXS song, Mediate. "It does everything that ends with, 'ate'! "  In my snarkier moments, I'd compare it to a Don King promotion.  "You will aggregate, correlate, automate then absolutely fustigate your IT challenges!!!  I don't care if your name is Kate or Nate!  It will be the greatest data lake that no one can imitate!  If you are into endpoint management it is your fate!!!"

However, the acquisition of Carbon Black, the introduction of Sensors and increased relevance of modern management have made WS1 Intelligence advantages much more obvious.  Increasing SaaS adoption and the introduction of custom connectors have also enhanced its overall appeal.  The ability to automate ruthlessly across managed devices and SaaS landscape is a downright intoxicating proposition that speaks to the souls of most techies I know.   We live for this stuff. 








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."