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