Imaging Windows 10 Devices for Workspace ONE - Part 2: Creating, Capturing and Deploying a Reference Image

Now that you have a WDS environment that can complete some basic task sequences and deploy images, to make this much more useful we need to create a reference image that has (some or all of) our Workspace ONE UEM Windows 10 apps in it. We also want it to automatially enrol into Workspace ONE UEM for the end users.

I know that we normally talk about "not having an SOE" but seeing you're here you must have a use case for it, however lets make it as simple and lean as possible!

Some of the steps below are a bit out of the ordinary for a default WDS environment task sequence so please read carefully.

Imaging Windows 10 Devices for Workspace ONE - Part 1: Installing Windows Deployment Services

Full disclose straight up - this is a long one.

I often get asked that once we remove SCCM from a customer's environment and provide full Modern Management with Workspace ONE, how do we image machines? Well, you can obviously just use what comes on the PC and enroll it then remove whatever you don't want. There's also Dell Factory Provisioning which allows you to provide the configuration and have the Dell Factory apply the image and have to directly sent ready to be used (GREAT by the way). What about if you're not using Dell? What about if the hard disk fails and needs to be replaced?

That's what I'm going to answer.

How to build your Workspace ONE Sandbox

Workspace ONE is incredibly powerful. But with so many features and functions, its no wonder people can get lost when working out where to start on configuring it to test with your scenarios in your environment.

As part of VMware Testdrive, other than getting access to a pre-configured testing environment and walkthroughs you also get a full fledged trial environment we refer to as a Sandbox.


This has all the capabilities of Workspace ONE where you can integrate it with all services to test it in your environment with real users and real devices.

So, this is where this guide comes in. Even I struggle to explain or give a place for my customers to go for all they need to get started. I'll add to the below information over time but this will be enough to get you started with Workspace ONE as part of a pilot or proof of concept.

Configuring Mobile SSO for iOS Devices in Workspace ONE

One of big differentiators we have with Workspace ONE is ability to use MobileSSO to drastically improve security and the user experience.

MobileSSO with Workspace ONE leverages certificates deployed to devices to seamlessly sign the user into the Workspace ONE Intelligent Hub and any federated SaaS services.

This solution requires both Workspace ONE UEM (to deploy and manage the lifecycle of the certificates) and Workspace ONE Access (to challenge the device for the certificate and authenticate the user). On iOS MobileSSO technically uses Kerberos by validating the certificate on the device and generating a Kerberos token the device can then present back for authentication.

In this post I'll discuss how to configure Workspace ONE Access for iOS MobileSSO and how to create a profile in Workspace ONE UEM to deploy the required certificate and approve the domains and applications that can use it.

Enabling Password (Cloud Deployment) Auth Method in Workspace ONE Access

In our current configuration, when we try to authenticate as a user in Workspace ONE Access it will probably fail. This is because we don't have an authentication method available to users that is able to authentication successfully.

The simplest way to do this is to enable Password (cloud deployment) so that our users are able to authenticate with their Active Directory credentials using the Identity Manager Connector we installed and configured. What's great about this method is that its outbound meaning that a user authentication request never comes inbound so there's no inbound firewall rules.

Let's look at how to configure this authentication method and set up our default access policy to use it.

Integrating Workspace ONE UEM and Workspace ONE Access

So you've got your Airwatch Cloud Connector installed and configured and you have your Identity Manager Connector installed and configured, but right now Workspace ONE UEM and Workspace ONE Access are not talking to each other.

We need to configure this integration so that we can start enrolling devices, using Workspace ONE Intelligent Hub, Unified App Catalog and Mobile SSO.

Luckily, this process is pretty straight foward. The wizard that does this integration works well and does all the heavy lifting.

Lets check out the process.

Installing Airwatch Cloud Connector and Configuring Directory Services in Workspace ONE UEM

Welcome to the first installment to my end-to-end lab and Testdrive Sandbox configuration series.

In this post we'll look at installing the Airwatch Cloud Connector (ACC) and integrating with your On-Premises Active Directory.

I do get asked this a bit as to why you would use the ACC and Active Directory if you're using SAML authentication with either Identity Manager/AzureAD/Okta etc. Although in this article I won't cover SAML integration I'll point out why we still recommend full directory integration.

Firstly, it allows users to authenticate securely with their directory credentials. It also pre-populates all the required user metadata in the console (email address, UPN, immutableID, phone number etc.). Using SAML without directory integration would mean the user gets created in Workspace ONE UEM using SAML JIT therefore it won't bring in the rest of those attributes. The other main reason we recommend using this is so that Administrators can use Active Directory groups for Assignment Groups in Workspace ONE UEM. As an example, you could assign a policy or application to your HR Department if that group exists in AD. If you don't have these groups, you would need to manually go into the Workspace ONE Console and assign the configurations to those users one by one.

The ACC also facilitates integration with On-Premises Certificate Authorities, Syslog servers and SMTP services (amongst other things)

So, back to the actual configuration.

Using Google Cloud Identity Secure LDAP with Workspace ONE

Most of my posts on my blog here have been about how to integrate other Identity Solutions with Workspace ONE.  However, the thing that all of these typically had in common was that they were synchronised with an On-Premises Active Directory.

This works well, but what happens when a customer has no On-Premises AD or is trying to get away from using one?

About a year ago, Google Announced their Cloud Identity Premium product which included a preview of LDAP connectivity. I played around with it then and it was good but for our purposes I could never get it to work - it requires the client service to use certificates to authenticate which is something that Workspace ONE doesn't support.

Recently a few customers have been asking whether there was ways to use Google Directories within Workspace ONE other than Just-In-Time provisioning and seeing that Secure LDAP from Google was now Generally Available globally it thought I'd give it another look.

Turns out I was able to get it to work! Read on to work out how, with some help from my colleagues, I was able to get it all integrated.

Installing Identity Manager Connector and Configuring Directory Services in Workspace ONE Access

In this article we're going to talk about installing the VMware Identity Manager Connector in your environment to allow you connect to your On-Premises Active Directory. This connector also has a few other purposes like additional inbound authentication methods and the ability to synchronise Horizon Applications and Desktops.

We're just going to talk go through installation and configuring synchronisation with Active Directory in this article. I'll cover the rest in a later post.

Using Azure AD B2B Guest Accounts in VMware Identity Manager

Creating and managing the lifecycle of user accounts for users outside your organisation painful. Whether they are for contractors or external vendors, the time in creating these resetting passwords and then deprovisioning them is very time consuming - let alone the security implications if the accounts aren't removed.




A little while ago I was introduced to Azure AD Guest Accounts by a colleague. Guest Accounts are part of the Azure Active Directory Business to Business (B2B) capability where you can invite users from another Organisation's Azure Active Directory to have access to resources in yours. This means that if you have a Cloud Application federated with your Azure Tenant, you can simply invite their account and once they accept they can log in with their existing credentials and gain access.

This sounded great. But what I realised was that we were able to leverage this for using Guest Accounts in VMware Identity Manager. When using Azure Active Directory as a 3rd Party IDP in Identity Manager, you can invite a user to your Directory and they can log into Identity Manager and access the portal and any SaaS Applications you assign. You don't need to manage their account - if they forget their password its done at their Company's end, and you can even enforce additional Multifactor Authentication.

The requirements for Guest Accounts in Identity Manager are:

• Your ‘Organisation’ must be using Azure Active Directory (doesn’t require Premium).
• The ‘Guest’ account you are inviting must be an Azure AD account from another directory or be a Microsoft Account.
• The ‘Service’ you’re entitling the Guest User to must have an account with a valid SAML attribute/NameID format. You can also use JIT to provision accounts into this service as well.
• You need to have configured Azure Active Directory as a 3rd Party IDP in Identity Manager.

Let's go through how this all fits together.

What is Just-In-Time Provisioning?

Managing user accounts and identities is pretty a pretty tedious task.
One of the biggest benefits we talk about with Single Sign On and SAML authentication is the
ability Airwatch Workspace ONE UEM etc.) a user account needs to exist in that service for the user to sign in to.
to federate services to Identity Manager, but in order for a user to be able to sign into those services (Salesforce,

With any Identity Provider -  Identity Manager, Azure AD, Google IDP etc. -  typically those user accounts are synchronised with an On-Premises directory. If you're not synchronising those from another directory using some form of sync tool, you are manually creating those either via bulk upload, or even worse, manually typing them in.

The same requirement exists when you're using a cloud service. A user cannot log in with an account. Something somewhere is the source of truth of all user's identities, but having multiple sync tools out there syncing user accounts is not great. Wouldn't it be great if there was an easier way?

This is where Just-In-Time (JIT) provisioning comes in.

Azure Active Directory as a 3rd Party IDP in VMware Identity Manager

For my very first (technical) post I wanted to start with a bang.

As I mentioned in my introduction, I am Subject Matter Expert (herein and forever referred to as SME to save on typing) in VMware Identity Manager (vIDM) and all the things that come along with it. This along with my enjoyment of tinkering, integrating and playing with things, I talk about Identity and Authentication a lot with my customers and the one thing that keeps coming up a lot is how can they integrate vIDM with Azure Active Directory. Whether customers are actually using AAD or not is a different story, but it seems that everyone is at least looking at it. 

I'm not going to get on my soapbox about how Azure Active Directory is not a replacement for Microsoft Active Directory Domain Services (yet), but I will outline the steps required below to integrate vIDM and Azure AD and allow users to authenticate with the AAD credentials.

Why do they want to do this? There could be a few reasons:

• They want to use Microsoft Risk Based/Conditional Access Policies.
• Their SaaS Applications are federated with Azure AD and don't want to change this to vIDM.
• Because they can (just like I wanted to prove).

VMware Identity Manager is a great product and can do all kinds of things that Azure AD doesn't, but I think it's important to point out how we can use the best available for the customer's requirements.

Anyway enough justification, in the steps below I'll show you how to do it.

Adding Azure AD as a Third-Party IDP in Identity Manager

This is a straight forward process. In your Azure Portal you need to create an 'Enterprise Application' (your Identity Manager Tenant) and then add Azure AD as a third-party IDP in Identity Manager.

1. Login to your Azure Portal https://portal.azure.com and select Azure Active Directory.

2. Find 'Enterprise Applications' in the list under Manage and then 'New Application'.