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.
The main “magic” that made this possible was an Open-Source proxying application called STunnel which allows us to proxy authentication and LDAP lookups to Google from our Connector services. What this really means is that STunnel connects to Google Secure LDAP using the SSL certificates it requires, then Workspace ONE talks to the STunnel services which proxies the request on to Google.
Enough about that, lets get on with configuring it.
What we’ll need is a Windows VM (yes STunnel works on Linux, but the Workspace ONE Connectors don’t). I’d recommend a Server OS not Windows 10 as I had some DNS challenges with Windows 10, but it did work. This can be running anywhere (Google Cloud, AWS, On-Prem, Azure etc.) as long as its always powered on and has internet access. This will be used to install STunnel, the Airwatch Cloud Connector as well as the Identity Manager Connector services.
In this article, I’m going to build the VM in Google Cloud. I’ll also show the install process of STunnel, Airwatch Cloud Connector and the Identity Manager Connector.
Let’s create a VM in Google Cloud Console (https://console.cloud.google.com)
SKIP AHEAD IF YOU’RE USING A VM SOMEWHERE ELSE – HOSTING THIS IN GOOGLE CLOUD IS NOT REQUIRED.
Go to Compute Engine
Create a VM (or import if you’re advanced!)
You can fill out the form with information thats relevant to your deployment, but it needs to be a Windows Server OS with Desktop Experience. Also make sure you select the right networking configuration.
It will now build the VM. You just need to Set the Windows Password so you can log in to it. Change the admin username and password then connect to it via RDP and you’re ready to deploy!
Now the VM is running, you can install STunnel. Just download and install the Windows Version.
You’ll get an error when you first install it, so go in and delete out all the example connections. Paste in
[ldap]
client = yes
accept = 127.0.0.1:1636
connect = ldap.google.com:636
cert = ldap-client.crt
key = ldap-client.key
The certificates here need to live in C:Program Files (x86)stunnelconfig
To get these certificates, we need to some Google Config.
Go to your Google Admin Console and then to Apps -> LDAP
We now want to go to ADD CLIENT
Give it a name, and some whatever access rights you need and select ADD LDAP CLIENT
It will automatically generate a cert and key. Download this, unzip it, and rename them to ldap-client.crt and ldap-client.key and paste them into C:Program Files (x86)stunnelconfig
The last thing you need to do here is turn the LDAP Client on. Go into the Client Configuration settings and change Service Status to ON.
OK so I lied a little bit – there is one more thing to do. In the LDAP Client configuration, go to Authentication and Generate New Access Credentials.
Save these details to use later!
Now you can install the Airwatch Cloud Connector and Identity Manager Connector. I am not showing the full activation process for the connection between your Connector and Workspace ONE Access. You can see how to do that here.
NOTE: Because this VM isn’t on a domain or have a proper I had to put an entry into the hosts file so that it resolves to stunnel.googleldap.local – this is because Identity Manager Connector needs a resolvable FQDN to install.
Here’s a video of the install process.
Now that STunnel is installed and configured, and our Connectors are installed, we need to now configure the LDAP settings in both Workspace ONE UEM and Workspace ONE Access.
Go to your Workspace ONE UEM environment, then to Settings -> System -> Enterprise Integration ->Directory
(skip the wizard and configure manually)
Set the Directory Type to “OTHER LDAP”
Set the Server to 127.0.0.1 (this is what STunnel Service is listening on)
Set the Port to 1636 (this what you set in the STunnel configuration)
Bind Authentication is BASIC and the username and password are the Access Credentials you generated above.
IMPORTANT: In the Domain Section, make sure you set this to be blank
Now, under the User tab. You need to change the following settings.
BaseDN: This will be whatever your domain in Google is:
Eg. my domain is bnelab.prl.net.au so my BaseDN is dc=bnelab,dc=prl,dc=net,dc=au
You also need to set the User Search Filter to be (&(objectClass=person)(uid={EnrollmentUser}))
Next you need to change the Attributes under the Advanced section. Rather than list them out, make sure yours match what I’ve listed in mine.
You should also do the same comparative settings under the Group tab.
So you can now import your users from Google LDAP in Workspace ONE UEM!
Now, lets do the configuration for Workspace ONE Access.
Go to your admin portal on your Identity Manager tenant. Then go to Identity & Access Management, Manage and Add Directory
Give it a name (any name)
You’ll see the connector in the drop down that you installed (same server name as STunnel)
Set your Directory Search attribute to uid
Server Host and Port is the same as above 127.0.0.1 and port 1636
Scroll down to the bottom to Bind User Details
Set the Base DN to what you configured in Workspace ONE UEM.
Now, for Bind User DN needs to be a distinguished name of a valid user. I’m just using a normal user, but you can create any basic user. You don’t need admin rights for Bind.
Leave a Reply