Kerberos authentication in Workspace ONE Access allows users to skip explicit logon when connecting from domain-joined company-owned devices within the enterprise network. The last condition is important because for Kerberos, Access does a SAML redirect to the connector, which normally wouldn’t (and most certainly shouldn’t) be reachable from the outside.
The problem
Despite running on a Windows Server, the IDM connector is not a Windows application but a Java (Tomcat) one so it doesn’t rely on built-in Windows mechanisms for delegating Kerberos. Instead, it uses a typical krb5 configuration with a KEYTAB file. This file is associated with a specially crafted user, the creation of which VMware sort of automated. Their preferred method is to run the connector service under a user account with permission to create users in AD and assign SPNs to them. I don’t know of any organisation that is big enough to be able to buy Workspace ONE that would allow this to happen. Remediation is offered in form of a batch file that, in turn, will call a PowerShell script:
Carl Stalhood also describes this process in his vIDM walk-through: https://www.carlstalhood.com/vmware-identity-manager/#kerb
There are several problems both with the user (no descriptive attrributes pointing to what the user is for, for instance) and the script itself (I’ll get to those in a second). The biggest problem, though, is that the configuration that is created automatically will not work against any other domain than the one your connector machine is a member of. (I’ve seen cases where the auto-created configuration didn’t work against the connector’s own domain either, but that is another story.)
If you are in a position to create a separate connector for each domain and place it in its intended domain, you should absolutely do so – it’s your best chance at getting this configuration to work in the way VMware intended it to. If, however, there are restrictions as to where Workspace ONE infrastructure should be placed, you will probably experience the following:
- Script runs without issue, provided you are logged on with an account that is both local admin on the connector machine and has the right to create a user in its domain including mapping SPNs to that user
- A user with a name identical to the machine name of the connector gets created in the default container for new users
- Kerberos auth from the foreign domain doesn’t work and you fall back to other authentication methods, if any
- In the connector log (the default path is „C:\VMware\VMwareIdentityManager\Connector\opt\vmware\horizon\workspace\logs\connector.log“) you find entries pointing to a suitable principal not being found in the KEYTAB.
What needs to happen
The resolution is actually pretty straightforward: Both the KEYTAB file and the AD user need to contain principals from the realm(s) users will be authenticating against! The target realms (none of which needs to equal the connector’s own domain) are contained in the krb5.conf file once Kerberos configuration was done on the Access appliance and pushed down to the connector. Unfortunately, this cannot be done after the original VMware script has run, since you need to know the password of the new user for the ktpass.exe commands.
Argument trouble
Once the realm/principal question is resolved, the Kerberos error in the logs may change to something to the effect of ‚Invalid argument‘. To mitigate this, a default TKT encryption type needs to be set in the krb5.conf:
default_tkt_enctypes=arcfour-hmac-md5
The script
I wrote a script that
- takes the target realms form the krb5.conf file
- creates a user with various helpful properties populated
- assigns all the necessary SPNs
- provides verbose logging
- updates the Kerberos configuration
It is published on the Gallery: https://www.powershellgallery.com/packages/New-WSOneKerberosPrincipal The project page for the script is here: https://metabpa.org/projects/various-scripts/ws1-kerberos/
Happy authenticating!
Antworten