Workspace ONE and Azure AD: Part 1

Opening

Often times when working with customers, I get the impression that there is a strong sense of confusion when discussing the integration of a platform such as Microsoft 365 with 3rd party ecosystems. After all, an investment in M365 comes with many features and functions, so where do platforms like Workspace ONE fit in? My friends, welcome to my day job and one true passion in life. Remember the saying, “do what you love and you’ll never work a day in your life.”

This mini-series is aimed at breaking down the often encountered silos so that you can articulate and deliver a best-in-class end user experience using the analogous functions from two best-in-class platforms: Workspace ONE and Azure AD. We’ll briefly cover the major use cases of stitching these two ecosystems together, and why this fabric is critical to adoption and value realization.

Note to reader: The scope of this mini-series will be limited to what you are capable of doing with these platforms today. The partnership announcement will most certainly have a positive impact on the below, and as such, I will keep this series updated with references and configuration items as they evolve.

The What and The Why

It’s always good to measure twice and cut once; software is no exception. Most of my customers like to start a Workspace ONE design with the knobs and switches that could be turned on and off. However, I’ve found it highly effective to begin with a well-crafted use case matrix that succinctly identifies the personas consuming the platform and the manner in which they will consume it. Let’s put some functional purpose behinds those knobs and switches.

Use Cases

So let’s define our “customer”; that is, the people who will consume the platform. Here’s the most common personas I’ve encountered in the wild:

Knowledge Worker

This is your everyday, 9-5 associate. Most likely a “desk” employee interacting with collaboration services, productivity and business applications

Sales Associate

Road warriors who primarily access collaboration services and sensitive sales ERPs from mobile devices

Developers

Associates who are focusing on using readily available toolsets to create new products and services for the business. Typically operating in a DevOps model

Team Members

Field-based “deskless” associates who are typically consuming event-driven data, such as benefits enrollment, paycheck remittance and other HR related systems from personal and/or shared kiosk devices

Power Users

A mix of the above, but mostly select business unit users and IT engineers who are continuously testing new functionality within the EUC platforms targeted to rollout to the population at large

Now that we have a foundational understanding of who our customers are, we can start to think about how they would use our platforms to consume information. Surprise, these common personas also render common use cases:

Mobile-First Applications

Most business roles today consume apps and data from a mobile device in some form or fashion. The user experience should lend itself to that form factor

Collaboration Services and Productivity Suites

The vast majority of the user population will be mail enabled and leverage productivity tools to generate and consume business content

Self-Service Device On-boarding

Allowing users to bring their own device and/or choose their own device shortens the runway to productivity and lowers the cost of administrative provisioning

Single Sign-On

Users who prove they are who they say they are should be conditionally relevant across the enterprise app ecosystem, both mobile and otherwise

Perimeter Resource Availability

Users won’t always be on the network; securely delivering mission critical applications to the field in a mobile-first, unified medium is paramount to a modern transactional experience for both your customer and the end user

Licensing Value Adds

This is where we start mapping use cases to value propositions. The dichotomy between something like SDDC and Workspace ONE licensing is derived from one key element: the end user. We need to validate that features and functions have a specific purpose before making an investment to protect from lack of adoption.

Staying with the post theme, I’m only going to cover a non-exhaustive list of Workspace ONE and M365 value adds. You’ll find some callouts in the architecture about how you could layer in 3rd party IdPs, etc, but that is out of scope for this already lengthy post.

Microsoft 365 E3
  1. Collab and Productivity Suite
  2. Mobile Office App MAM
  3. Conditional Access
  4. Information Protection

Workspace ONE Advanced
  1. Unified App Catalog
  2. One-Touch SSO
  3. Unified Endpoint Mgmt
  4. UEM Device Compliance

Architecture

Time for the fun part: sketch the architecture. We know by this point what the end user wants delivered, and we know which solutions we want to implement to achieve that outcome. This is generally the activity that begins highlighting the intricacies of these platforms.

To avoid muddying the waters, I’m only going to focus on one of three architectures that I typically draw for customers when architecting Workspace ONE with Azure AD. Understand that regardless of which IdP is primary (Workspace ONE Access, PING, Okta, Azure AD), the below diagram is accommodating to all of the above.

So what all is going on here? Let’s first identify the components and breakdown what role each is playing:

  1. End Users (Devices) – These are the ‘customers’ we defined earlier. They are personal and corporate devices out in the wild consuming enterprise data
  2. Office 365 – The collaboration services, unified communication and productivity engine
  3. Azure Active Directory – The identity engine for all things Azure, including Office 365. Keep in mind, this is not configurable; Azure AD is the exclusive claims provider for all services rendered out of the Azure ecosystem
  4. Workspace ONE Access (formerly known as VMware Identity Manager) – This is the identity engine for all things Workspace ONE, and is federated with Azure AD as the AuthN claims provider in this architecture
  5. SaaS Apps (Across the top) – These are the various services that a user could consume, and in this architecture, are primarily federated with Azure AD as the IdP (more to come on this in a moment)

The key callouts I highlight when presenting this architecture are end user experience (point of consumption), federation of the platforms and federation of the applications. Take notice that the end users begin consuming various services and applications by first launching the Workspace ONE app catalog, regardless of the federated architecture. The value add from this flow is that our users can go to one location, the Unified App Catalog, to consume any application or resource across the landscape.

For example, although Salesforce is federated with Azure AD in the above, the user can consume this resource from a desktop, browser or mobile device from Workspace ONE. This provides a key advantage over catalog sprawl, and enables the end user to quickly find a tool to perform a value-add task. Lastly, this experience is tailored to the point of consumption in real time. If on an iOS or Android device, the catalog renders a Salesforce mobile application for download rather than a browser-based experience. This directly enables our Mobile-First Application use case above, and is something our Sales Associate would likely find very appealing.

Federation and Graph API are the key integration points between the two platforms. SAMLP or WS-Fed/Trust are what extend Workspace ONE Access functions into Azure AD, and Graph API allows Workspace ONE UEM to publish App Protection policies and revoke refresh tokens. The below walkthrough demonstrates how to configure both integrations. Keep in mind that although a federated domain in Azure AD is a requirement, Workspace ONE is only fulfilling the AuthN component of AuthN/AuthZ flows for all things Azure.

The final callout is around where enterprise applications are federated. In the architecture above, I have demonstrated that applications are federated with Azure AD. There are cosmetic reasons why you might choose to do this, and although you can federate applications directly with Workspace ONE Access as an IdP, I find it common that most customers choose to federate with Ping, Okta or Azure AD as primary. In any case, the point is that no matter where the federation exists, the user experience always begins with the Workspace ONE Unified App Catalog.

The How

We’ve spent quite a bit of time up to this point defining who our customer is (the persona), how the customer will use these platforms, which platform we should invest in and how we stitch the platforms together as one fabric. Now it’s time to wrap up this post with a simple walkthrough that sets the foundation for on-boarding new use cases. As indicated in the title, this will be a multi-part post. Subsequent posts will be much more concise and focus on the technical steps to create an “any app, any device, at any time” platform that can address everything we’ve defined here.

Prerequisites

  1. Functional Workspace ONE SaaS environment
    • Workspace ONE UEM Tenant
    • Workspace ONE Access Tenant
    • Integration between both tenants
      • Mobile SSO, Device Compliance, Hub Services
    • Directory Services with Active Directory for both environments
  2. Functional Microsoft 365 environment
    • Azure AD with AD Connect
    • At least 1 ‘Managed’ domain in the tenant
    • Office 365 (Mail, OneDrive, etc)
  3. Administrative access to all of the above
  4. Licensing I am using for this walkthrough
    • Office 365 Business Essentials
    • Enterprise Mobility and Security E3
    • Workspace ONE Advanced

Note: I won’t have an opportunity to cover configuration items like Mobile SSO in this series; however, I will highlight where functions such as this are critical to enabling our use cases above.

Federation

This is the key integration between Workspace ONE Access and Azure AD. First, we should create the ‘Office 365 with Provisioning’ application in Workspace ONE Access from the cloud app catalog:

Next, populate your tenant name and an issuer string (more on this value in a later step). Replace ‘example.com’ with your actual domain namespace in Azure AD:

If you are using a source anchor value other than objectGUID, be sure to update that value with the synced attribute from AD in Workspace ONE Access. Otherwise, you can skip this step:

Press ‘Next’ twice, then ‘Save and Assign’. Select a set of users and/or groups to entitle the application. If following the reference architecture above, you’ll want to select ‘ALL USERS’ for this screen:

To complete the federation, the following PowerShell Cmdlet should be run against the ‘example.com’ domain above that you defined in the Access app configuration. Be careful; this command will federate Workspace ONE Access as the primary IdP for the domain in Azure AD. This is absolutely intended for the integration, but does have impact on O365 clients and end user authentication:

Note: values in {braces} should be altered to your custom identifier. ‘DomainName’ and ‘Issuer’ should match what was configured above in the Access app configuration. Login to Office 365 via Connect-MsolService and execute:

Set-MsolDomainAuthentication
–DomainName {example.com}
–Authentication Federated
–IssuerUri {example.com}
-FederationBrandName {Mycompany}, Inc.
-PassiveLogOnUri https://{tenant}.vmwareidentity.com:443/SAAS/API/1.0/POST/sso
-LogOffUri https://login.microsoftonline.com/logout.srf
-ActiveLogOnUri https://{tenant}.vmwareidentity.com:443/SAAS/auth/wsfed/active/logon
-MetadataExchangeUri https://{tenant}.vmwareidentity.com/SAAS/auth/wsfed/services/mex
-SigningCertificate {Base64_Access_Signing_Certificate}

For additional details on the federation activity, please see this document.

Graph API

This configuration is necessary to enable Windows 10 enrollment and Azure Token Revocation, both of which will be covered in future posts. For now, let’s configure the integration as a prerequisite for subsequent use cases.

Login to the Azure Admin Center and select the ‘Azure Active Directory’ blade form the left panel. Choose the ‘Mobility (MDM and MAM)’:

Click ‘Add application’ and select the ‘AirWatch by VMware’ application:

In a separate tab, open your Workspace ONE UEM Admin Console and from your customer OG (or where Directory Services is integrated) navigate to ‘Groups and Settings -> All Settings -> System -> Enterprise Integration -> Directory Services’. Choose ‘Enabled’ for ‘Use Azure AD for Identity Services’:

Copy the two values indicated in the above screenshot, return to the Azure Admin Center tab you have open, and paste them into the corresponding fields documented in ‘Where in AAD do I paste this info?’:

Note: Be sure to also set ‘MDM user scope’ to ‘All’.

Return to your Workspace ONE UEM Admin Console tab and input the remaining values before pressing ‘Save’. If you need assistance with where these values come from in Azure AD, click on the ‘How To Obtain Tenant Info’ link:

Scroll down to press ‘Save’. This completes the integration configuration.

The Outcome: Part 1

By now, you should have a solid understanding of the business context surrounding an investment in these two platforms. With Workspace ONE and Azure AD now integrated using Graph API and WS-Fed, we are ready to enable our first set of use cases in the following posts.

In Part 2, we’ll dive deep into creating a unified experience for our end users to consume enterprise resources from.

Tags: , , , , ,