Companies come in all shapes and sizes, but the small/medium business (SMB) customer can often be overlooked. Part of the issue is that people don’t know their options and those options can be challenging to deploy. Another challenge SMBs deal with is limited On-Premise infrastructure. They would ideally prefer to deploy technologies leveraging current investments like Office 365. Today, we will explore that use case: “Can we build a truly cloud-centric solution for Workspace ONE powered by Azure Active Directory?”

What Problem are we Trying to Solve?

One of the major issues we are trying to solve is Workspace ONE UEM’s dependency on the AirWatch Cloud Connector. Many people don’t have the staff to support another server nor the physical space. The Cloud Connector provides a number of technologies, such as LDAP integration, SysLog, SMTP, and much more. We are going to show you how we extended our Azure Active Directory and Office 365 environment to solve this issue with ease.

Extending Azure Active Directory for your Workspace ONE Deployment

We looked at a number of different options to make this work. You need to consider that as a small business we cannot afford some of the solutions that your typical enterprise may try. These are some of the crazy ideas we tried:

• Port Forwarding between our On-Premise DC and Azure to migrate the Domain Controllers (REALLY BAD IDEA)
• VPN Gateways inside of Azure (Too difficult and we lacked the requisite hardware)
• Straight Rebuild of our entire domain inside of Azure (Far too complicated and the user impact would be real)

We settled on a solution, that we feel is robust and effective. Let’s talk about Azure AD Domain Services.

What is Azure AD Domain Services?

Azure AD Domain Services is a really interesting idea. The jist is this solution will take your Azure AD objects you are already syncing into Office 365 and build a cloud-enabled domain for certain technologies. It’s definitely limited, but it is a great fit for a Workspace ONE deployment.

There are a number of great features you get with Azure AD DS:

• Secure LDAP Server
• Ability to Domain Join VMs built in Azure to your Domain
• Certificate Services (if you build the VM in your Azure environment)
• Highly Available
• NTLM and Kerberos Support
• Supports VMware Horizon on Azure

We aren’t going to go too deep on Azure AD DS, but it certainly has some limitations, but we can really use it in a powerful way with Workspace ONE UEM. Let’s discuss how to build it.

Building your Azure AD DS Environment

The actual build isn’t too bad. You want to log into Azure and click “Add” under Azure AD Domain Services.

From here, you will basically just step through your build and input the proper fields as seen below. I’m going to only highlight a few small areas as I’m not going to rebuild the domain:

• DNS Domain Name should match your verified domain in Azure e.g. synterex.com.
• Review the article here to determine what SKU you need. Most smaller companies can probably survive on standard, but you might need Enterprise.
• Forest Type focuses on whether you want to build a forest for users or for resources e.g. apps. For our use case, we will focus on a user forest

The actual environment will take awhile to build so you should come back later once that has actually finished. It’s a super easy build. While this is going on, you just want to make sure you already have Azure AD Connect configured for password hash synchronization. Most people probably will, but you want to confirm. You may need to change your password afterwards to use the new domain as a user, but Microsoft provides some nice instructions:

• Instructions for cloud-only user accounts
• Instructions for synced user accounts

Securing your Azure AD DS Environment for Workspace ONE

The first thing you will want to do is lockdown your environment to the Workspace ONE UEM SaaS Data Center ranges. This will let LDAP be possible and secures your directory. You start by going into the “Network Security Group” from the “Properties” menu of your Azure AD DS instance.

You will then add an inbound security rule as you can see below to allow LDAP 389/636 from Workspace ONE to Azure. Don’t forget to set a high priority:

You should also setup notifications if you run into any domain issues from the notifications tab.

One other thing you will want to do is create a user account for LDAP that you will use later on for the LDAP integration. Once you create it, you should go into “Role Assignments” and gran the “User Access Administrator” role to it. It’s good to note that the access is scoped to the resource:

Setting up Secure LDAP with Azure AD DS

The setup for LDAPs is pretty easy. You will need to enable Secure LDAP and allow access over the internet (don’t worry that security group will protect you).

The big thing is your SSL certificate. You are going to need to buy a wildcard certificate for your domain through a public provider e.g. Comodo or GoDaddy. Those can run you 300ish per year, but there’s no way around that without having a secure tunnel between Azure and your On-Premise environment. Potentially, you could build out a Azure AD-DS powered CA to avoid this, but that is something we haven’t tested at this point.

Another item you will need to address is creating a public DNS record for your LDAPs server e.g. ldap.synterex.com that points to the IP for your Secure LDAP server:

The last item you will need to cover once all of this is complete is changing the password of your LDAP service account so it can actually authenticate. Once done, you should be able to connect via LDP to the new hostname of your LDAP server. The key for authentication is domain, username, and password. Do not put the email address as the user name. Next, let’s setup a SMTP Connector before checking out the Workspace ONE side.

Setting up the SMTP Connector for Workspace ONE UEM

This portion is mostly straight forward once you understand how it works. Basically, you will create an account for SMTP and setup a Connector to allow SMTP traffic to flow. You access that in the Exchange Admin Center > Mail Flow > Connectors and put in those same IP addresses from earlier to let this all work.

We can now move onto the Workspace ONE side of the house and show how this works.

Setting up Workspace ONE UEM with Azure AD DS

Luckily, you’re done with all of the hard work and can do things like you would normally. You go into Enterprise Integration > Directory Services and configure your setup as you can see below:

Once you set this up, you just pick an AD group to sync users from and it will sync those user accounts down into Workspace ONE, which is very exciting. You take it up a level by extending the work you did to Workspace ONE Access with Active Directory user sync down to Workspace ONE Access. With this, you have now also avoided needing an Access Connector since your directory is deployed via Workspace ONE UEM for users and groups.

The last part is the SMTP setup, which is easy after the work you already did as you can see below. I do things a bit more fun because I create a SMTP user account and then delegate access to my IT Communications Group, but if done correctly works like a charm.

Final Thoughts

This was a particularly fun project because we got a good look at a new service that most people aren’t using in Azure AD Domain Services and extend it into Workspace ONE UEM for a comprehensive SMB solution. The one thing that you could add into this is a Certificate Authority hosted in Azure domain-joined to Azure AD DS to deploy certificates to users in Workspace ONE, but otherwise we have a great solution here. You could even potentially use Azure Monitor for SysLog from Workspace ONE, but that could be overkill at a small business.

This use case that I built for a small company of 50 users is a very compelling idea that lets you slim down and operate efficiently. I think things like this will continue to evolve as we need to cut costs and deliver solutions that work smarter and provide huge value to our users.