ERROR: No "known good" password
FreeRADIUS 'No known good password': nothing to check against
The log lines:
(3) pap: WARNING: No "known good" password found for the user.
(3) pap: WARNING: Authentication will fail unless a "known good" password is availableWhat it actually means: FreeRADIUS reached the authentication stage holding the user’s submitted password, but with nothing to compare it against. No module in the authorize phase produced a Cleartext-Password, NT-Password, or other control attribute for this user. Authentication cannot succeed no matter what the user types; the problem is entirely server/backend-side.
Follow the authorize section: it names the culprit
Scroll up in the radiusd -X output to the authorize {} section for this request. You’re looking for which module was supposed to supply the password, and why it didn’t:
1. No module matched the user at all
- users file: the entry doesn’t match (typo in the name, wrong
DEFAULTordering, or a preceding entry withFall-Through = noswallowing it). The debug showsfiles:lines. Did any entry match? - SQL: the query ran but returned zero rows. The debug prints the exact SQL executed. Copy it and run it by hand against the database. Nine times out of ten the username stored differs from the one sent (case, domain prefix, realm suffix).
- LDAP: the search found no entry, or found it but didn’t map a password attribute. Check the
ldap:debug lines for the search filter and what attributes came back.
2. A password came back in a format the auth method can’t use
Subtler: the backend did return a password, but as an incompatible hash. The compatibility matrix is unforgiving:
| Stored format | PAP | MSCHAPv2 (PEAP inner) |
|---|---|---|
| Cleartext | ✔ | ✔ |
| NT hash | ✔ | ✔ |
| SSHA / SHA / MD5 / crypt / bcrypt | ✔ | ✘ never |
If your directory stores SSHA (as it should for security) and clients use PEAP-MSCHAPv2, this warning is structural. See the MSCHAPv2 write-up for the escape routes (ntlm_auth against AD, TTLS-PAP, or EAP-TLS).
3. The password attribute exists but under the wrong name
In SQL schemas: the radcheck row says Password instead of Cleartext-Password (an ancient schema convention), or the operator is = where := is needed. In LDAP: the mapping in mods-available/ldap doesn’t include the attribute your directory actually uses.
The five-minute check
grep the debug for what the authorize phase produced: if you never see a Cleartext-Password or NT-Password control attribute being added for the user, the backend lookup is your bug. Fix the entry/query/mapping, not the client.