Nick's IT Blog

There are a lot of good posts and documents on how to setup Kerberos on your Connectors to function appropriately with Workspace ONE Access. However, many of them are inaccurate when it comes to load balancing your Connectors for Kerberos. Load balancing is the only way to ensure your Kerberos authentication mechanism is highly available and distributed.

In order to prepare for Kerberos, you must either 1) ensure the service account you initially used for running the Connector service is a domain account and can add/modify users, or 2) run the setupKerberos.bat script as noted in this KB article. This script essentially generates a user account with the same name as the connector, maps the appropriate SPNs, and stores all of the relevant information securely in a local keytab file. Everything is logged in the krb5-setup file.

Note: if the initial account used for the service had the appropriate permissions, you should not need to do this. Just check and see if the user account matching the Connector name was created in AD. The Connector UPN should be HTTP/connector-fqdn@domain and is auto-configured by the script. For example, here is what it looks like if I configured my nick-mgmt1.nick.local Connector for Kerberos:

Ensure Kerberos is enabled on each Connector:

Go to your Workspace ONE Access IdP associated with your domain:

Scroll down to IdP Hostname and type in one of your Connectors. Note that we will rinse and repeat each one to ensure Kerberos is good across all of them.

Under I&AM > Policies, change your access policy so that Kerberos is the primary auth mechanism for your test machine.

In order for Kerberos to work with various browsers, you must follow these instructions. Of note: Chromium Edge ONLY honors the Intranet zone for Kerberos. If your Connectors are in Trusted Sites, use this GPO to whitelist your domain for pass-through. You can get Chromium Edge ADMX templates here under Get Policy Files:

After you configure your browsers for integrated auth, attempt to authenticate to Workspace ONE Access. One of four things will happen:

1. You will get redirected to the Connector configured in your IdP, Kerberos will succeed, and you will be signed into Access successfully.
2. The browser will prompt you for credentials using its built-in web challenge prompt. If you authenticate using domain\username successfully and get passed into Access, Kerberos is working but your browser is misconfigured, or you are not authenticating with a domain user/machine. Ensure you are following the browser Kerberos configuration guide correctly.
3. Kerberos flat-out fails and you are denied access, unless you have a fallback method defined in your policy. If so, you are taken to the fallback method.
4. You are prompted for a login like #2, but then #3 happens. If so, likely your browser is misconfigured AND Kerberos is failing.

If #2 happens, check your browser settings and ensure integrated auth is setup correctly. If #3 or 4 happens, Kerberos is likely misconfigured. Typically the easiest way to correct this is to delete the SPN user account and re-run the setupKerberos.bat file. Check for any errors in the krb5-setup log. If all goes well in the setup, check your Connector logs:

If you see anything in the Connector log about NTLM being utilized, your browser is likely trying NTLM instead of Kerberos. This is almost always due to the SPN not correctly matching the FQDN of the Connector. Another possible error is this one, typically for the same reason:

(Mechanism level: Invalid argument (400) – Cannot find key of appropriate type to decrypt AP REP – RC4 with HMAC)

Now, if Kerberos did successfully work, go back to your IdP hostname configured in your Workspace ONE Access IdP and set the IdP hostname to the second connector. Test Kerberos. Rinse and repeat until each Connector has been successfully tested, as it makes troubleshooting way easier before we get into load balancing.

To enable load balancing, the easiest way is to create a L4/443 VIP (no SSL termination) and have a certificate deployed to your connectors with the following names:

1. Load-balanced VIP name in the common name + SAN
2. Each Connector FQDN in the Subject Alternative Names

Once you have your certificates deployed on the Connectors, go back to your IdP and set the hostname to your load-balanced VIP name. Here my VIP is wsoauth.nick.local:

Now, this next part is where most folks make a mistake. Go to your Kerberos adapter for each Connector. Select Enable Redirect and set the Redirect Host Name to the Connector’s own FQDN – not the VIP! Why?

If you put the load-balanced VIP here in the Redirect Host Name, here is what happens:

1. You attempt to authenticate via Kerberos. Your WSO IdP sends you to the VIP configured in the IdP. In my case, wsoauth.nick.local.
2. The Connector sees the Redirect Host Name is already in use by the browser and does not redirect again. Kerberos is attempted against the VIP, wsoauth.nick.local.
3. There is no SPN matching wsoauth.nick.local – Kerberos fails!

Now, here’s what it looks like if you do it correctly and set the Redirect Host Name to the Connector itself:

1. You attempt to authenticate via Kerberos. Your WSO IdP sends you to the VIP configured in the IdP. In my case, wsoauth.nick.local.
2. The Connector redirects you back to itself, in my case nick-mgmt1.nick.local. Kerberos is then attempted against the Connector, nick-mgmt1.nick.local.
3. There is a valid SPN matching nick-mgmt1.nick.local and Kerberos succeeds!

Conclusion

I hope this post helps in configuring Kerberos in a highly available manner in Workspace ONE Access. I have found quite a few mistakes out there where folks configure the Redirect Host Name back to the VIP, and it all goes south from there. Enjoy!