> On Mar 19, 2025, at 12:12, Quanah Gibson-Mount <[email protected]> wrote:
>
>
>
> --On Monday, March 17, 2025 10:28 AM -0400 BuzzSaw Code
> <[email protected]> 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.
