We have an existing set of RHEL8 servers running the 2.4.x version of OpenLDAP - we can't upgrade to the latest version due to other dependencies.
I'm trying to solve a problem where we want to use our 2FA authentication (which is OTP based on RADIUS) with some devices and applications that don't support RADIUS at all, but they *do* support LDAP authentication.
I've read about using the SASL, but since that requires replacing the userPassword attribute for each user it won't work as I have to do this without breaking straight username/password binds for users.
I looked into using overlays to create a new OU of users that was a translucent overlay of the existing ou=People (something like ou=rPeople), but searching this list archive and others says that won't work as I can't overlay/rewrite the userPassword attribute ? Is that correct?
I'm trying to avoid duplicating the entire directory to new servers or even duplicating the existing ou=People structure just to create a new 'userPassword' attribute that can be used for SASL.
--On Monday, March 17, 2025 10:28 AM -0400 BuzzSaw Code buzzsaw.code@gmail.com wrote:
We have an existing set of RHEL8 servers running the 2.4.x version of OpenLDAP - we can't upgrade to the latest version due to other dependencies.
I'm trying to solve a problem where we want to use our 2FA authentication (which is OTP based on RADIUS) with some devices and applications that don't support RADIUS at all, but they *do* support LDAP authentication.
I've read about using the SASL, but since that requires replacing the userPassword attribute for each user it won't work as I have to do this without breaking straight username/password binds for users.
If you're talking about SASL pass through authentication, yes. If you're talking about normal SASL mechanisms like cert auth, Kerberos, etc, that is not correct. What is it that you think "SASL" (whatever that means) will solve as a problem?
--Quanah
On Mar 19, 2025, at 12:12, Quanah Gibson-Mount quanah@fast-mail.org wrote:
--On Monday, March 17, 2025 10:28 AM -0400 BuzzSaw Code buzzsaw.code@gmail.com wrote:
We have an existing set of RHEL8 servers running the 2.4.x version of OpenLDAP - we can't upgrade to the latest version due to other dependencies.
I'm trying to solve a problem where we want to use our 2FA authentication (which is OTP based on RADIUS) with some devices and applications that don't support RADIUS at all, but they *do* support LDAP authentication.
I've read about using the SASL, but since that requires replacing the userPassword attribute for each user it won't work as I have to do this without breaking straight username/password binds for users.
If you're talking about SASL pass through authentication, yes. If you're talking about normal SASL mechanisms like cert auth, Kerberos, etc, that is not correct. What is it that you think "SASL" (whatever that means) will solve as a problem?
--Quanah
I’m talking about pass through authentication that uses saslauthd.
It solves the problem I tried to describe - I want to use our RADIUS based 2FA system for authentication (Yubikey) with systems that don’t support RADIUS but do support LDAP authentication.
I can pass the username/password supplied in the LDAP bind request to RADIUS utilizing saslauthd.
But I want to do this in a way that maintains the standard username/password binds as we have some systems where we don’t want to enforce 2FA.
Rather than create a whole new LDAP infrastructure for this, I’d hoped to user an overlay to create a new rPeople ou that was a translucent overlay of the People ou, except for userPassword which would contain the required information to trigger pass through authentication.
It would be even better if we could offer pass through authentication or not based on the IP/host name of the source for the bind attempt.
If that’s not possible with openldap then we’ll look into alternatives.
On Wed, Mar 19, 2025 at 1:00 PM Craig Huckabee buzzsaw.code@gmail.com wrote:
On Mar 19, 2025, at 12:12, Quanah Gibson-Mount quanah@fast-mail.org wrote:
--On Monday, March 17, 2025 10:28 AM -0400 BuzzSaw Code buzzsaw.code@gmail.com wrote:
We have an existing set of RHEL8 servers running the 2.4.x version of OpenLDAP - we can't upgrade to the latest version due to other dependencies.
I'm trying to solve a problem where we want to use our 2FA authentication (which is OTP based on RADIUS) with some devices and applications that don't support RADIUS at all, but they *do* support LDAP authentication.
I've read about using the SASL, but since that requires replacing the userPassword attribute for each user it won't work as I have to do this without breaking straight username/password binds for users.
If you're talking about SASL pass through authentication, yes. If you're talking about normal SASL mechanisms like cert auth, Kerberos, etc, that is not correct. What is it that you think "SASL" (whatever that means) will solve as a problem?
I’m talking about pass through authentication that uses saslauthd.
It solves the problem I tried to describe - I want to use our RADIUS based 2FA system for authentication (Yubikey) with systems that don’t support RADIUS but do support LDAP authentication.
Off-topic (or maybe related): it took me quite some time to find a developer oriented discussion list for YubiKeys. If you need one, it is located at fido-dev Google Group, https://groups.google.com/a/fidoalliance.org/g/fido-dev.
(I'm especially interested in using YubiKeys and leveraging the public/private key crypto parts from FIDO2 and WebAuthn protocols for non-web based applications).
I can pass the username/password supplied in the LDAP bind request to RADIUS utilizing saslauthd.
But I want to do this in a way that maintains the standard username/password binds as we have some systems where we don’t want to enforce 2FA.
Rather than create a whole new LDAP infrastructure for this, I’d hoped to user an overlay to create a new rPeople ou that was a translucent overlay of the People ou, except for userPassword which would contain the required information to trigger pass through authentication.
It would be even better if we could offer pass through authentication or not based on the IP/host name of the source for the bind attempt.
If that’s not possible with openldap then we’ll look into alternatives.
Jeff
On Wed, Mar 19, 2025 at 12:43:09PM -0400, Craig Huckabee wrote:
I’m talking about pass through authentication that uses saslauthd.
It solves the problem I tried to describe - I want to use our RADIUS based 2FA system for authentication (Yubikey) with systems that don’t support RADIUS but do support LDAP authentication.
I can pass the username/password supplied in the LDAP bind request to RADIUS utilizing saslauthd.
But I want to do this in a way that maintains the standard username/password binds as we have some systems where we don’t want to enforce 2FA.
Rather than create a whole new LDAP infrastructure for this, I’d hoped to user an overlay to create a new rPeople ou that was a translucent overlay of the People ou, except for userPassword which would contain the required information to trigger pass through authentication.
It would be even better if we could offer pass through authentication or not based on the IP/host name of the source for the bind attempt.
If that’s not possible with openldap then we’ll look into alternatives.
Hi Craig, in you only need to be able to say "keep processing this Bind as usual" vs. "I'll do it myself for this user and give you a result here and now", the sock overlay plus custom code that OpenLDAP talks to might be a way out at least in the short term. It also gives you all the connection context you've mentioned if configured appropriately.
Don't think you have a way to read the DB data this way, that's only available to actual code overlays/slapi that run inside the slapd process. Not that our slapi interface is being actively tested, it might have bit-rotted slightly and you won't get 2.4 code updates from the project anymore.
Regards,
openldap-technical@openldap.org
-
BuzzSaw Code -
Craig Huckabee
-
Jeffrey Walton -
Ondřej Kuzník -
Quanah Gibson-Mount