LDAP Search failed due to ldap filter mismatch -> then information "no known good password found for the user"
Hi, last week we have had the problem that FR (3.0.15) Authentications were failing for a user account which was missing a specific LDAP attribute queried by a custom-defined LDAP filter in /freeradius/ldap. A quick LDAP query showed that the filtered attribute was indeed missing. It was kind of confusing to us that the Radius Debug Log contained the information "no known good password found for the user" after the information "LDAP Search Returned no results". The information "LDAP Search Returned no results" was helpful (better would be the more specific information "no ldap filter match" as the account did exist in LDAP - just not for FR as the filter did not match). It's logical that there is no good password if no user is found - but in my eyes it's a kind of misleading information which could easily lead to the wrong conclusion there must be a problem with the password. I recommend to leave this out if the LDAP search is failing altogether: (6020) Thu Sep 27 16:04:11 2018: Debug: ldap: Waiting for search result... (6020) Thu Sep 27 16:04:11 2018: Debug: ldap: Search returned no results (6020) Thu Sep 27 16:04:11 2018: Debug: [ldap] = notfound (6020) Thu Sep 27 16:04:11 2018: Debug: reply_log: EXPAND /var/log/freeradius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/reply-detail-%Y%m%d (6020) Thu Sep 27 16:04:11 2018: Debug: reply_log: --> /var/log/freeradius/radacct/10.33.6.2/reply-detail-20180927<https://deref-gmx.net/mail/client/J4EPcINdIf4/dereferrer/?redirectUrl=http%3A%2F%2F10.33.6.2%2Freply-detail-20180927> (6020) Thu Sep 27 16:04:11 2018: Debug: reply_log: /var/log/freeradius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/reply-detail-%Y%m%d expands to /var/log/freeradius/radacct/10.33.6.2/reply-detail-20180927<https://deref-gmx.net/mail/client/J4EPcINdIf4/dereferrer/?redirectUrl=http%3A%2F%2F10.33.6.2%2Freply-detail-20180927> (6020) Thu Sep 27 16:04:11 2018: Debug: reply_log: EXPAND %t (6020) Thu Sep 27 16:04:11 2018: Debug: reply_log: --> Thu Sep 27 16:04:11 2018 (6020) Thu Sep 27 16:04:11 2018: Debug: [reply_log] = ok (6020) Thu Sep 27 16:04:11 2018: WARNING: pap: No "known good" password found for the user. Not setting Auth-Type (6020) Thu Sep 27 16:04:11 2018: WARNING: pap: Authentication will fail unless a "known good" password is available Thanks, Thorsten
On Mon, 2018-10-01 at 09:00 +0000, Thorsten Fritsch wrote:
It's logical that there is no good password if no user is found - but in my eyes it's a kind of misleading information which could easily lead to the wrong conclusion there must be a problem with the password. I recommend to leave this out if the LDAP search is failing altogether:
The LDAP message comes from the LDAP module. The "no known good password" message comes from the PAP module. Neither module knows anything about any of the modules that come before or after it, and the PAP module could have been supplied a password from many other modules. So for example you run rlm_ldap, then rlm_sql, then rlm_files to try and find a password, then rlm_pap to check the password. rlm_pap can use a password that any of the previous modules found. If there isn't a password, there's not much it can do apart from say "I can't find a password". -- Matthew
last week we have had the problem that FR (3.0.15) Authentications were failing for a user account which was missing a specific LDAP attribute queried by a custom-defined LDAP filter in /freeradius/ldap. A quick LDAP query showed that the filtered attribute was indeed missing. It was kind of confusing to us that the Radius Debug Log contained the information "no known good password found for the user" after the information "LDAP Search Returned no results".
The information "LDAP Search Returned no results" was helpful (better would be the more specific information "no ldap filter match" as the account did exist in LDAP - just not for FR as the filter did not match).
FreeRADIUS has no idea whether user.base_dn points to an object or is just the starting point for a search. There's various heuristics we could use to figure that out but in all cases it'd require a search query without filters just to see if user object exists. We're not going to run a second search just to produce marginally better debugging output.
It's logical that there is no good password if no user is found - but in my eyes it's a kind of misleading information which could easily lead to the wrong conclusion there must be a problem with the password. I recommend to leave this out if the LDAP search is failing altogether:
With very few exceptions the modules are independent silos of information. The PAP module has absolutely no idea what operations the LDAP module performed. It just knows that the policy the administrator created hasn't furnished it with a "known good" password which is can compare the user submitted credentials againstt. If you don't want the extra messages, don't call the pap module if the LDAP module can't find the user... i.e. authorize { ... ldap if (notfound) { reject } pap } The FreeRADIUS policies aren't static, they're meant to be modified, if you don't like the output, change the policies... -Arran
Hi guys, I understand. Thanks for your reply - that's fine. Cheers, Thorsten -----Original Message----- From: Freeradius-Devel [mailto:freeradius-devel-bounces+thorsten.fritsch=unibas.ch@lists.freeradius.org] On Behalf Of Arran Cudbard-Bell Sent: Montag, 1. Oktober 2018 11:30 To: FreeRadius developers mailing list <freeradius-devel@lists.freeradius.org> Subject: Re: LDAP Search failed due to ldap filter mismatch -> then information "no known good password found for the user"
last week we have had the problem that FR (3.0.15) Authentications were failing for a user account which was missing a specific LDAP attribute queried by a custom-defined LDAP filter in /freeradius/ldap. A quick LDAP query showed that the filtered attribute was indeed missing. It was kind of confusing to us that the Radius Debug Log contained the information "no known good password found for the user" after the information "LDAP Search Returned no results".
The information "LDAP Search Returned no results" was helpful (better would be the more specific information "no ldap filter match" as the account did exist in LDAP - just not for FR as the filter did not match).
FreeRADIUS has no idea whether user.base_dn points to an object or is just the starting point for a search. There's various heuristics we could use to figure that out but in all cases it'd require a search query without filters just to see if user object exists. We're not going to run a second search just to produce marginally better debugging output.
It's logical that there is no good password if no user is found - but in my eyes it's a kind of misleading information which could easily lead to the wrong conclusion there must be a problem with the password. I recommend to leave this out if the LDAP search is failing altogether:
With very few exceptions the modules are independent silos of information. The PAP module has absolutely no idea what operations the LDAP module performed. It just knows that the policy the administrator created hasn't furnished it with a "known good" password which is can compare the user submitted credentials againstt. If you don't want the extra messages, don't call the pap module if the LDAP module can't find the user... i.e. authorize { ... ldap if (notfound) { reject } pap } The FreeRADIUS policies aren't static, they're meant to be modified, if you don't like the output, change the policies... -Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
participants (3)
-
Arran Cudbard-Bell -
Matthew Newton -
Thorsten Fritsch