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 🙂

Happy New Year – 2024 here we go

I have been the worst at making updates in 2023, hopefully I can make a change on that in 2024. What has caused the drought? Family, acquisition and in general just a lot of change.

2023 started out throwing my family a curve ball – unexpectedly my wife got pregnant and we had our 3rd son in October. With the pregnancy of my twin boys my wife was very incapacitated due to nausea and the likes. It wasn’t as bad this time but suddenly we had to adjust to a new situation of becoming a family of 5.

Also in 2023 the company I worked for – Lytzen IT – was acquired by NetNordic Group and merged with NetNordic Denmark here locally. That ment the first part of 2023 wnet by with preparing to complete the merger in June as well as then adapting to all the new systems, processes, people etc. It is still a process but we’ll get there 🙂

I have maintained my job area for now still focusing heavily on our managed VMware platforms both on-prem at customers and in our datacenters. This meas maintaining and developing our platforms to support general purpose servers, VDA/VDI, UC and NFV workloads. We are still processing through removing the last Hyperflex platforms – in light of Cisco’s new partnership with Nutanix and the subsequent axing of Hyperflex – thank god!

But on the subject of acquisitions the elephant in the room is still the closing of Broadcom/VMware deal. A LOT of info is pouring out and we as Cloud Provider Partners are still trying to digest the info and a lot is still missing. The next quarter is going to be crazy and I am both excited to see what it brings to the table and a bit frightened of what will come if it.

The simplifications to product portfolia to limit sprawl look great and the idea of bundling all products in different tiers is great, makes consuming Aria Operations and vSAN a lot simpler. But at the same time I fear that our prices as cloud providers will increase from likely being forced into VCF and the associated products.

But I am guessing – despite the Partner call last week we still know to little what the changes for us are going to be so better just sit back and wait 🙂

This coming year will be focused on doing major upgrades to our platform. Deploying new clusters, removing old, new data center networks and more. A lot of very complex and interesting projects in the pipeline. Look forward to deploying even more VMware 🙂