UPDATE 12/22/2019 - Please see this post for a more up to date and more functionaly guide. It is good to read this first, before doing the other one however to get a better understanding of our initial decisions.
In this writeup, I will go over the configuration settings that I used, and worked with Airwatch/Workspace ONE Professional Services and Support to get Airwatch up and working within ThousandEyes. Initially, before writing this guide (which I have admittedly been putting off for a while - since May when we did our deployment of the service), the documents that were available on VMware’s website, were mostly incorrect. This might have been fixed, however I have not gone back to validate any of their documentation. Once we spend the time to do this, I will update either this page, or create a new posting.
ThousandEyes has not yet made the transition to a full cloud based Directory System, we are still using Active Directory On-Premise. However, all systems that have been deployed going from 2019 - forward, need to or should be setup in a compatible way so that when we make the full cloud transition, it is seamless. As such, we assume here that you have or are using:
We actually tried using VMware’s Identity Manager to perform SAML, but at the time, the directions did not allow configuration after following the guides provided by Okta or VMware. Because they said this was the easier way, and unfortunately when asking them - they wouldn’t bother helping us with the correct way. In addition, originally their documentation that was listed here, was incredibly wrong. It seems like in the time that I have taken to put off writing this guide, they have updated their documentation to show the correct way to connect Okta as an LDAP service.
Documentation listed here, gives you a proper configuration guide. However, at the time of originally writing this guide, the documetation was incorrect and did not work.
With that said, I would also highly recommmend to ignore this guide, it is outdated for newer versions of Workspace One.
So with this in mind, let me explain how ThousandEyes did this:
Setting this portion up is quite easy with the way that the support team and consultant recommended. Unfortunately, the easy way is not the best way, and you should be able to get assistance from support easily on how to do this. However, this is how ThousandEyes has performed this:
To edit any of the settings for a currently working directory, just replace the strings that are in capital letters below with yours.
1 2 3 4 5 6 7 8 <code>Directory Type: Other LDAP Server: YOURDOMAINHERE.ldap.okta.com Encryption Type: SSL Verify SSL Certificate: Check the box Bind Authentication Type: Basic Bind User Name: uid=YOURSUPERUSERHERE,dc=YOURDOMAINHERE,dc=okta,dc=com Bind Password: YOURSECRETHERE Domain: YOURDOMAINHERE.okta.com</code>
This should allow you to verify or test the connection below. Once the LDAP Settings are working, move on to the User tab.
Because we want to integrate this with Azure later on, and Active Directory, we need to map some of our existing attributes from Active Directory and push them into Okta.
First, go here: https://YOURDOMAIN-admin.okta.com/admin/universaldirectory and select the Profile button located below
Click the add attribute button
Use the the following settings for the Attributes
Now, lets go to Active Directory’s mapping, select your domain to setup the mapping push. You want to push from the Active Directory Domain to Okta.
Setting up the users panel
While VMware’s documentation states to use mail=, I found that for the ease of the employee, using their shorthand account name is far easier for the experience - specifically for macOS. With Windows, this change may cause problems.
Drop the advanced menu down and select the following features
We came to the conclusion of using the following settings for the advanced section of the user system
The reasons for these attributes being used are based directly on the attributes that are listed in Profile attributes in Okta, as well, as the ldapsearch tool based on the information below:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 ldapsearch -H ldaps://thousandeyes.ldap.okta.com -b "dc=thousandeyes,dc=okta,dc=com" -D "email@example.com,dc=thousandeyes,dc=okta,dc=com" -W -x "(sn=Doer)" # extended LDIF # # LDAPv3 # base <dc=thousandeyes,dc=okta,dc=com> with scope subtree # filter: (sn=Doer) # requesting: ALL # # firstname.lastname@example.org, users, thousandeyes.okta.com dn: email@example.com,ou=users,dc=thousandeyes,dc=okta,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson uid: firstname.lastname@example.org uniqueIdentifier: REMOVINGFROMHERE organizationalStatus: ACTIVE givenName: Andrew sn: Doer cn: Andrew Doer mail: email@example.com mail: firstname.lastname@example.org AD_ObjectGUID: REMOVINGFROMHERE sAMAccountName: atesting title: IT Tester department: Engineering # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1
When we look at this, we see there are a few differences in Okta’s LDAP directories compared to Active Directory. So those adjustments are made into the above attributes. A few of these attribute changes are not mentioned in VMware’s documentations.
With groups, we came to the conclusion that the following attributes were required for use within Airwatch:
Unfortunately, even with this setup - Airwatch does not support importing users from the groups itself. While this might be an issue only we have, I have not found a way around getting the users imported - even with the proper settings. While we have opened up a support ticket for this (and even had confirmation in the past that this was a bug), 6 months later it is still not fixed. See the Room for Improvements section for a feature request using VMware’s new feature request option.
Create a custom SAML Application in Okta.
Attach a photo if you would like, however, this application will mainly be hidden in the application dashboard. Go ahead and click next.
Below you will see a heavily redacted SAML setup. Sorry, but as these are all private links, I can’t post them. However, I have
However, you will see a modified version of the links below where you can change the wording that is in all capital letters.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Single Sign On URL: https://YOURDSSERVERHERE.awmdm.com/IdentityService/SAML/AssertionService.ashx?binding=HttpPost Requestable SSO URLs, Index https://YOURDSSERVERHERE.awmdm.com/IdentityService/SAML/AssertionService.ashx, 2 https://YOURDSSERVERHERE.awmdm.com/MyDevice/SAML/AssertionService.ashx, 5 https://YOURDSSERVERHERE.awmdm.com/DeviceManagement/SAML/AssertionService.ashx, 8 https://YOURCNSERVERHERE.awmdm.com/AirWatch/SAML/AssertionService.ashx, 11 https://YOURDSSERVERHERE.awmdm.com/Catalog/SAML/AssertionService.ashx, 14 Audience URI: SOMETHINGHERE Attribute Statements Name, NameFormat, Value uid, Unspecified, user.login objectGUID, Unspecified, user.AD_ObjectGUID uniqueIdentifier, Unspecified, user.getInternalProperty("id")
You might be curious about the last piece here. This is a pretty way to use the Okta Expression Language to get the uniqueidentifier property that we were using previously as a way to send the string without it being an visible attribute to the user.
Download the metadata file that is generated.
Becuase Airwatch in this way only provides SAML when initiated from the software layer. Because of this, we will be creating a bookmark application to directly go to the URL that allows for SAML login provided by the Group ID within the instance.
From there, simply add a photo, my recommendation would be to use this photo:
Go to Enterprise Integrations > Directory Services > SAML. Take the Metadata file generated and upload it to the Import Identity Provider Settings area.
The fields should populate like so.
From here, you should be ready to go with logging into the Bookmark application you made.
There are various problems with this integration, and even when setting up with proserv, this did not come out the way I would have liked.