LDAP based 2FA login for vSphere

Today I want to share an overview of a thing that I realized last year and tested out. We have a few Linux environments based on Centos/AlmaLinux – RHEL clones. In these environments we utilize FreeIPA as an authentication provider because it provides a great set of features and control similar to those one would find in Active Directory.

One feature in particular that I found interesting is the feature of using 2FA in Kerberos and LDAP as well as centralizing the distribution of SSH public keys for easier keybased logins. One evening I got the idea formulating in my head – maybe we could get vSphere to use FreeIPA as an LDAP source and utilize 2FA based on OTP. This could be done because the way FreeIPA does LDAP logins with IPA is to append the OTP token after the password thus not prompting for an additional step that vSphere would otherwise not know how to handle.

Please note that the following is not officially supported by VMware. LDAP is only supported with OpenLdap and Active Directory. The supported method of getting 2FA on vSphere is using Federation.

Now to make this work – we need to start out with a FreeIPA domain controller. I won’t go into details about this but rather refer to Linode’s excellent guide on installing it. After this you should add a user and add an OTP token to it via the webinterface. This is pretty straight forward to do. Finally once the OTP token has added you need to force the user to use the OTP token which can be toggled on the user’s settings page by an admin. The option is called “Two factor authentication (password + OTP)”.

You could try and add the LDAP source to vSphere now but it would fail because the LDAP tree is not identical to either Active Director or OpenLDAP – we can however fix that.

My initial find was this older guide on how to do it manually. It gave me an understanding on how this was supposed to work and made it easier to understand this – again older but functional – guide from FreeIPA.

The key thing here is we are not using FreeIPA’s default schema but rather it’s Compatability schema feature. This presents an alternate combination of attributes on objects that is more inline with how vSphere expects OpenLDAP to perform.

Step 1 is modifying the user objects to include objectclass “inetOrgPerson” and the attribute “sn”. We can modify the compatability view using the following ldif – note this is copy pasted from the FreeIPA guide but with correct indentation and line breaks as this is not clear from the guide and from hard learning is VERY important

dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config
changetype: modify
add: schema-compat-entry-attribute
schema-compat-entry-attribute: objectclass=inetOrgPerson
add: schema-compat-entry-attribute
schema-compat-entry-attribute: sn=%{sn}

Save this as vsphere_usermod.ldif on your FreeIPA controllers (you need to apply the schema modification to all controllers in the domain). Next step is to modify groups to include the objectclass “groupOfUniqueNames” and the attribute “uniqueNames”. This is done with the following ldif – again copied and broken up correctly from the guide!:

dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config
changetype: modify
add: schema-compat-entry-attribute
schema-compat-entry-attribute: objectclass=groupOfUniqueNames
add: schema-compat-entry-attribute
schema-compat-entry-attribute: uniqueMember=%mregsub("%{member}","^(.*)accounts(.*)","%1compat%2")

Both ldifs start with a simple adding of an objectclass identifier putting that additional attribute on all users and groups respectively.For users the second part binds the “sn” attribute in the compatibility view with the “sn” attribute in FreeIPA’s default schema. For groups it is a bit more complicated. Here we need to make sure that groups are updated correctly otherwise the attribute would only account for the users at the time of applying the ldif. This is done by making “uniqueMember” an function called “mregsub” basically gets all the accounts in FreeIPA schema attribute “member” and add them to “uniqueMember”.

With these two ldifs prepared you simply apply the commands below to apply the schema change – remember, this needs to be run on all controllers:

ldapmodify -x -D "cn=Directory Manager" -f vsphere_groupmod.ldif -W -v
ldapmodify -x -D "cn=Directory Manager" -f vsphere_usermod.ldif -W -v

You will be prompted for the Directory Manager password to apply. Now the schema is updated. New a special note from the guide here is that for FreeIPA 4.0 and newer you need to allow the “Read User Compat Tree” and “Read Group Compat Tree” permissions to also read the newly added attributes “sn” and “uniquemember”. This is done with the following commands:

ipa permission-mod "System: Read User Compat Tree" --includedattrs=sn
ipa permission-mod "System: Read Group Compat Tree" --includedattrs=uniquemember

Now the FreeIPA directory functions almost like OpenLDAP and enough so that we can add it as an OpenLDAP source in vSphere using the following basics:

Identity Source Type: Open LDAP
Identity Source Name: <what ever you like>
Base dn for users: cn=users,cn=compat,dc=<sub>,dc=<domain>,dc=<tld>
Base dn for users: cn=groups,cn=compat,dc=<sub>,dc=<domain>,dc=<tld>
Domain name: <sub.domain.tld>
Domain alias: <empty>
Username: uid=<dedicateduser>,cn=users,cn=accounts,dc=<sub>,dc=<domain>,dc=<tld>
Password: <password>
Primary server URL: ldaps://<dc1.sub.domain.tld>
Secondary server URL: ldaps://<dc2.sub.domain.tld>
CA certificate: <can be downloaded from frontpage of FreeIPA webpage>

Note that I expect you to be able to replace everything in <> to their correct values for your setup. If tcp port 636 is open from vCenter to the FreeIPA servers you should get a succesful message of adding the source and you can now add permissions to users and groups from FreeIPA 🙂

And to top it all of, if you add permissions to a user that has 2FA enabled this user is now forced to use password+otp in the password field on the login page.

Again this is not officially supported but it is a simple way of getting 2FA on your setup without complicated federation. Bonus is that you can also utilize FreeIPA for DNS zones allowing you to deploy homelabs without having to deploy Windows for AD/DNS.

I hope this can be useful for someone 🙂

Leave a Reply

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