As I wrote about a few months ago, you can build a seamless email experience with the Workspace ONE SEG powered by Kerberos. One area that I am focused on is building things at the enterprise level. VMware’s supported design for the Secure Email Gateway with KCD leaves some things to be desired. I am proud to announce a newly-architected implementation to bring resiliency to your kerberos authentication.

This will be a short and simple explanation showing how it’s designed today and how you can bring it to a new level. We’ll cover how the existing SEG design works, what it does on the backend, and how you can manipulate it to your advantage.

Configuring your SEG for Kerberos Constrained Delegation

Today, in your Workspace ONE UEM console, you go into Configuration > Advanced to setup your Kerberos configuration on your UAG. As you can see below, you add your SPN, service account credentials, and domain/domain controller mappings for Kerberos. It’s pretty simple, your domain goes in CAPS and the domain controller must match that domain e.g. synterex.com must have a synterex.com domain controller.

What the Secure Email Gateway Does Under the Covers

Once you configure your KCD settings, you restart the SEG service and it will create a KRB5.conf file. The KRB5.conf is basically a machine’s kerberos configuration file which tells the client what to do.

Additionally, it also builds a client certificate trust store for validating the chain of certificate that are presented to the UAG/SEG for client certificate authentication. These certificates live in /opt/vmware/docker/seg/container/config/ssl-certs/installer-trusted-certs inside of the truststore.jks.

In a future release, we will finally be able to put multiple trust certificates so companies with multiple CAs can support this with the steps below:

1. Export the complete certificate chain
2. Copy the certificates to /opt/vmware/docker/seg/container/config/ssl-certs folder
3. Navigate to the config folder of the SEG directory and edit config.json file.
4. Modify the clientCertTrustStorePath and the clientCertTrustStorePasscode fields in config.json as 
Example:
"clientCertTrustStorePath": "config/ssl-certs/CA01.pem,config/ssl-certs/CA02.pem"
"clientCertTrustStorePasscode": ""
5. Save the changes and start the SEG service

Those are the only items that I want to highlight, but the SEG does much more now like using custom config to setup Java, etc, but that’s not the focus of this article.

What’s wrong with how the SEG does it today?

So, it looks great and nice and fancy, but is it really? So let’s discuss what it actually did to the Kerberos config.

As you can see below, it creates the Kerberos Realm for Synterex.com, but what does the other things mean?

• The KDC tag is the name of a host that runs a KDC in that realm. You can also add a port number if you wanted to here.
• The Admin_Server is the name of the master kerberos server, which lets your machine talk to the kadmin server for your realm
• The Default_Domain is the domain name needed to produce a full hostname when you want translate principal names. All servers in the realm are assumed to be in the domain mentioned in this tag.

So, you are asking yourself “what’s wrong with this?” The answer is this configuration is a single point-of-failure for your SEG’s kerberos authentication. So, when a DC is down so are your users basically. So, let’s discuss how to fix it!

The Fix!

I went down several paths trying to design a way to make this more robust. The solution is to use kerberos how it is intended. Kerberos supports the ability to specify multiple KDCs in your KRB5.conf file as you can see below:

This design allows kerberos to continue being functional when one server goes down. Once you make a manual change to your KRB5.conf file, you must modify the application.properties file to make sure your SEG does not override the change you made on service restarts:

My experience and testing with this has been very positive, but I’m sure it will continue to be a work-in-progress. This is just a simple life hack for those who are leveraging a SEG with KCD for On-Premise Exchange environments.

Final Thoughts

The current architecture of the SEG is well-built, but we can always do better. I know many companies might be okay with a single point-of-failure for KDC authentication, but I am NOT. This small manipulation is a bit of manual work, but the rewards are so huge.

SEG with KCD is an extremely powerful tool and with evolution it can make us near invincible. No technology is infallible, but we must continue to push toward greatness. On-Premise doesn’t mean trash, it just means we do things a bit differently.