change in behavior of pam passthrough

[Charles Hedrick]

We use the ds389 pam passthrough, so that applications can authenticate with our ldap server and external radius authentication will work. (Almost all of our users have passwords stored on the University's active directory system. We run a radius proxy that does LDAP authentication to Active Directory.)

There seems to be a change in behavior of the plugin between redhat 9 and 10.

Our configuration is

dsconf CS-RUTGERS-EDU plugin pam-pass-through-auth config default set --fallback TRUE --secure FALSE --filter "(ipatokenradiusconfiglink=*)" --id-attr ipatokenradiususername --id_map_method ENTRY

That causes ds389 to use PAM when users are set to external radius authentication. PAM is set to use pam_radius to talk to our proxy.

My understanding is that the filter is intended to cause the entry to apply only to users with ipatokenradiudconfiglink set. In fact it appears to apply to everyone, but to fail for users without ipatokenradiusconfiglink set. In the previous version fallback was false. In this release fallback has to be true. For everyone without ipatokenradiusconfiglink set we get a log message

ERR - pam_passthru-plugin - do_one_pam_auth - Bind DN [uid=lXXX,cn=users,cn=accounts,dc=cs,dc=rutgers,dc=edu] is invalid or not found

Watching network traffic, radius is only consulted for users with ipatokenradiusconfiglink, which of course is correct. So the only symptom is the log messages. In principle, however, it could cause logins to accept an old password where a user has changed from a local password to external radius.

ds389 is 3.2.0-9.el10_2

[Charles Hedrick]

> We use the ds389 pam passthrough, so that applications can authenticate with our ldap server and external 
> radius authentication will work. (Almost all of our users have passwords stored on the University's active 
> directory system. We run a radius proxy that does LDAP authentication to Active Directory.)
> There seems to be a change in behavior of the plugin between redhat 9 and 10.
> Our configuration is
> dsconf CS-RUTGERS-EDU plugin pam-pass-through-auth config default set --fallback TRUE --secure FALSE --filter "(ipatokenradiusconfiglink=*)" --id-attr ipatokenradiususername --id_map_method ENTRY
> That causes ds389 to use PAM when users are set to external radius authentication. PAM is set to use pam_radius 
> to talk to our proxy.
> My understanding is that the filter is intended to cause the entry to apply only to users with 
> ipatokenradiudconfiglink set. In fact it appears to apply to everyone, but to fail for users without 
> ipatokenradiusconfiglink set. In the previous version fallback was false. In this release fallback has to be true. For 
> everyone without ipatokenradiusconfiglink set we get a log message
> ERR - pam_passthru-plugin - do_one_pam_auth - Bind DN [uid=lXXX,cn=users,cn=accounts,dc=cs,dc=rutgers,dc=edu] is invalid or not found
> Watching network traffic, radius is only consulted for users with ipatokenradiusconfiglink, which of course is 
> correct. So the only symptom is the log messages. In principle, however, it could cause logins to accept an old 
> password where a user has changed from a local password to external radius.
> ds389 is 3.2.0-9.el10_2

This behavior does not seem to occur on a system with pamFilter: (ipatokenradiusconfiglink=*) applied to the top level dn: cn=PAM Pass Through Auth,cn=plugins,cn=config

If this is intentional, then dsconf needs to supply a way to set it up, and documentation needs to explain why it's needed.

--
_______________________________________________
FreeIPA-users mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/[e-mail]...
Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[Viktor Ashirov]

On Fri, Aug 28, 2026 at 7:13 PM Charles Hedrick via FreeIPA-users <
[e-mail]> wrote:
> > We use the ds389 pam passthrough, so that applications can authenticate
>
> with our ldap server and external
> > radius authentication will work. (Almost all of our users have passwords
>
> stored on the University's active
> > directory system. We run a radius proxy that does LDAP authentication to
>
> Active Directory.)
> > There seems to be a change in behavior of the plugin between redhat 9
>
> and 10.
> > Our configuration is
> > dsconf CS-RUTGERS-EDU plugin pam-pass-through-auth config default set
>
> --fallback TRUE --secure FALSE --filter "(ipatokenradiusconfiglink=*)"
> --id-attr ipatokenradiususername --id_map_method ENTRY
> > That causes ds389 to use PAM when users are set to external radius
>
> authentication. PAM is set to use pam_radius
> > to talk to our proxy.
> > My understanding is that the filter is intended to cause the entry to
>
> apply only to users with
> > ipatokenradiudconfiglink set. In fact it appears to apply to everyone,
>
> but to fail for users without
> > ipatokenradiusconfiglink set. In the previous version fallback was
>
> false. In this release fallback has to be true. For
> > everyone without ipatokenradiusconfiglink set we get a log message
> > ERR - pam_passthru-plugin - do_one_pam_auth - Bind DN
>
> [uid=lXXX,cn=users,cn=accounts,dc=cs,dc=rutgers,dc=edu] is invalid or not
> found
> > Watching network traffic, radius is only consulted for users with
>
> ipatokenradiusconfiglink, which of course is
> > correct. So the only symptom is the log messages. In principle, however,
>
> it could cause logins to accept an old
> > password where a user has changed from a local password to external
>
> radius.
> > ds389 is 3.2.0-9.el10_2
>
> This behavior does not seem to occur on a system with pamFilter:
> (ipatokenradiusconfiglink=*) applied to the top level dn: cn=PAM Pass
> Through Auth,cn=plugins,cn=config
>
> If this is intentional, then dsconf needs to supply a way to set it up,
> and documentation needs to explain why it's needed.

This sounds like a bug, it might be related to a recent code refactoring:
https://github.com/389ds/389-ds-base/issues/6810.

Please open a ticket
https://github.com/389ds/389-ds-base/issues/new?template=bug_report.md

Thanks.

[Charles Hedrick]

> > We use the ds389 pam passthrough, so that applications can authenticate with our ldap server and external
> > radius authentication will work. (Almost all of our users have passwords stored on the University's active
> > directory system. We run a radius proxy that does LDAP authentication to Active Directory.)
> > There seems to be a change in behavior of the plugin between redhat 9 and 10.
> > Our configuration is
> > dsconf CS-RUTGERS-EDU plugin pam-pass-through-auth config default set --fallback TRUE --secure FALSE --filter "(ipatokenradiusconfiglink=*)" --id-attr ipatokenradiususername --id_map_method ENTRY
> > That causes ds389 to use PAM when users are set to external radius authentication. PAM is set to use pam_radius
> > to talk to our proxy.
> > My understanding is that the filter is intended to cause the entry to apply only to users with
> > ipatokenradiudconfiglink set. In fact it appears to apply to everyone, but to fail for users without
> > ipatokenradiusconfiglink set. In the previous version fallback was false. In this release fallback has to be true. For
> > everyone without ipatokenradiusconfiglink set we get a log message
> > ERR - pam_passthru-plugin - do_one_pam_auth - Bind DN [uid=lXXX,cn=users,cn=accounts,dc=cs,dc=rutgers,dc=edu] is invalid or not found
> > > Watching network traffic, radius is only consulted for users with ipatokenradiusconfiglink, which of course is
> >
> > correct. So the only symptom is the log messages. In principle, however, it could cause logins to accept an old
> > password where a user has changed from a local password to external radius.
> > ds389 is 3.2.0-9.el10_2
> > This behavior does not seem to occur on a system with pamFilter: (ipatokenradiusconfiglink=*) applied to the top level >> dn: cn=PAM Pass Through Auth,cn=plugins,cn=config
> > If this is intentional, then dsconf needs to supply a way to set it up, and documentation needs to explain why it's needed.
> This sounds like a bug, it might be related to a recent code refactoring: https://github.com/389ds/389-ds-base/issues/6810.
> Please open a ticket https://github.com/389ds/389-ds-base/issues/new?template=bug_report.md

Since I have Redhat support, I opened a ticket with them. I believe I found the cause. The code that looks
for a matching configuration entry tries all entries against the filter. If they all fail, it uses the default
configuration, if it exists. That effectively means that putting a filter on the default entry has no effect.

I deleted the default entry and added an entry just like it with a different name. Things seem to work.
It's hard to know whether this is a bug, since there doesn't seem to be up to date documentation.

I will open a ticket upstream.

[Rob Crittenden]

On 8/28/26 1:02 PM, Charles Hedrick via FreeIPA-users wrote:
> We use the ds389 pam passthrough, so that applications can authenticate with our ldap server and external radius authentication will work. (Almost all of our users have passwords stored on the University's active directory system. We run a radius proxy that does LDAP authentication to Active Directory.)
>
> There seems to be a change in behavior of the plugin between redhat 9 and 10.
>
> Our configuration is
>
> dsconf CS-RUTGERS-EDU plugin pam-pass-through-auth config default set --fallback TRUE --secure FALSE --filter "(ipatokenradiusconfiglink=*)" --id-attr ipatokenradiususername --id_map_method ENTRY
>
> That causes ds389 to use PAM when users are set to external radius authentication. PAM is set to use pam_radius to talk to our proxy.
>
> My understanding is that the filter is intended to cause the entry to apply only to users with ipatokenradiudconfiglink set. In fact it appears to apply to everyone, but to fail for users without ipatokenradiusconfiglink set. In the previous version fallback was false. In this release fallback has to be true. For everyone without ipatokenradiusconfiglink set we get a log message
>
> ERR - pam_passthru-plugin - do_one_pam_auth - Bind DN [uid=lXXX,cn=users,cn=accounts,dc=cs,dc=rutgers,dc=edu] is invalid or not found
>
> Watching network traffic, radius is only consulted for users with ipatokenradiusconfiglink, which of course is correct. So the only symptom is the log messages. In principle, however, it could cause logins to accept an old password where a user has changed from a local password to external radius.
>
> ds389 is 3.2.0-9.el10_2

Call me surprised that I actually wrote an IPA design on this a few 
years ago.

I'm not a reliable narrator as I don't really remember writing this. 
AFAICT it was never integrated into IPA.

So not to pass the buck but I'd recommend you pass this question along 
to the 389 team. They are the ones that own the plugin. It's very 
possible that something changed.

cheers

rob