Steps to migrate Secure Email Gateway (SEG) configured with Kerberos Constrained Delegation (KCD) from Classic Platform to the V2 Platform

Disclaimer: This post was made possible by Steve Marcolla, Application Support Engineer at VMware AirWatch. His insight and suggestion into this migration are very much appreciated!

I recently finished migrating my SEG classic to V2, and of course, I documented the steps via the post below for the benefit of the AirWatch community.

Steps to migrate Secure Email Gateway (SEG) from Classic Platform to the V2 Platform

If you have Kerberos Constrained Delegation (KCD) implemented with your SEG, the steps should be more or less the same with a few key differences to remember.

While chapter 5 of the Kerberos Constrained Delegation Authentication for SEG V2 guide describes the steps needed to upgrade from classic to V2, in my opinion, it’s far from complete. VMware technical support (not Steve Marcolla) even advised me to acquire professional services to ensure this upgrade is successful.

SEGupgrade1.jpg

Technical support (again not Steve Marcolla) also refers me to the link below, but I am quite certain this won’t work for SEG configured with KCD as the later has a different set of requirement.

Best Practices When Migrating from SEG Classic to SEG v2

You may also want to review the link below as well to fully understand the changes with SEG V2.

Changes to KCD Deployments for SEG V2

SEGupgrade2.jpg

Here’s a better screenshot of the Advanced Configuration.

SEGV2-KCD1.png

Now come the comments and suggestions from Steve Marcolla:

“Same steps. Thankfully the SEG config handles the setup for KCD, so no need to look for IIS settings to configure. You would need to make sure though that you have KCD enabled in the SEG MEM Config and advanced settings as appropriate before you download the installer so that it downloads the KCD package with the installer!”

“And yeah KCD can be daunting. Thankfully SEG V2 makes it a little easier.

Pretty much a good heuristic for the account(s) requirements are:

  • If you have multiple CAS servers, you need to use an ASA account to represent the CAS array (even if exchange version is 2016 where there’s no longer the idea of a CAS array).
  • If SEG is not on the same domain as the Domain Controller (and Exchange), then you need a service account on the domain controller’s domain to use to reach out to the domain controller to grab the Kerberos tokens.

The other most-handy tests are the connections from SEG to DC and back over port 88, and from SEG to CA and back over port 80 (and SEG to CRL over 80), and SEG to Exchange and back over 443.

Then all the fun with making sure the service accounts and SPNs are set up properly, the authentication settings in IIS on Exchange, etc.

Certainly lots of fun… really more of a test in patience than anything else haha.”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.