Hi,

FreeRADIUS does that automatically... IF it receives a password in the Access-Request. If it doesn't receive a password in the Access-Request, what you want to do is impossible.

See the web page for more explanations.

A bit clearer now. So you're saying that I should use: radtest testuser {SHA}... <radiusserver> 0 <secret> instead of radtest testuser <clear-text password> <radiusserver> 0 <secret> for testing? --mel

Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Alan DeKok wrote:

password to the server. The server looks up the user in a database, and (perhaps) finds a SHA hashed password. The server then SHA hashes the password supplied by the client, and compares it to the SHA password from the database.

In that case, something is *really* wrong with my setup and I have no idea why. I can only authenticate if the password in OpenLDAP is cleartext, but never if it's hashed. debug output, radiud.conf (modules ldap section), sites-enable/default follows. ### debug ### rad_recv: Access-Request packet from host 127.0.0.1 port 62806, id=99, length=57 User-Name = "user1" User-Password = "abc123" NAS-IP-Address = 127.0.0.1 NAS-Port = 0 +- entering group authorize ++[preprocess] returns ok rlm_ldap: - authorize rlm_ldap: performing user authorization for user1 expand: (uid=%u) -> (uid=user1) expand: dc=---,dc=edu,dc=my -> dc=---,dc=edu,dc=my rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: attempting LDAP reconnection rlm_ldap: (re)connect to 127.0.0.1:389, authentication 0 rlm_ldap: bind as cn=Manager,dc=---,dc=edu,dc=my/### to 127.0.0.1:389 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: performing search in dc=---,dc=edu,dc=my, with filter (uid=user1) rlm_ldap: checking if remote access for user1 is allowed by radiusFilterId rlm_ldap: Added SHA1-Password = iEPX+SQWIR3p67lj/0zigSWTKHg= in check items rlm_ldap: looking for check items in directory... rlm_ldap: LDAP attribute userPassword as RADIUS attribute User-Password == "{SHA}iEPX+SQWIR3p67lj/0zigSWTKHg=" rlm_ldap: looking for reply items in directory... rlm_ldap: LDAP attribute radiusFilterId as RADIUS attribute Filter-Id = "1 " rlm_ldap: user user1 authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 ++[ldap] returns ok ++[chap] returns noop ++[mschap] returns noop rlm_realm: No '@' in User-Name = "user1", looking up realm NULL rlm_realm: No such realm "NULL" ++[suffix] returns noop rlm_eap: No EAP-Message, not doing EAP ++[eap] returns noop !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!! Replacing User-Password in config items with Cleartext-Password. !!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!! Please update your configuration so that the "known good" !!! !!! clear text password is in Cleartext-Password, and not in User-Password. !!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! auth: type Local auth: user supplied User-Password does NOT match local User-Password auth: Failed to validate the user. Login incorrect: [user1/abc123] (from client localhost port 0) Found Post-Auth-Type Reject +- entering group REJECT expand: %{User-Name} -> user1 attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Sending Access-Reject of id 99 to 127.0.0.1 port 62806 Finished request 0. ### radiusd.conf ### modules { pap { auto_header = yes } chap { authtype = CHAP } pam { pam_auth = radiusd } unix { } $INCLUDE eap.conf mschap { authtype = MS-CHAP use_mppe = yes require_encryption = yes require_strong = yes } ldap { server = "127.0.0.1" identity = "cn=Manager,dc=iiu,dc=edu,dc=my" password = alamak basedn = "dc=iiu,dc=edu,dc=my" base_filter = "(objectclass=radiusprofile)" access_attr = "radiusFilterId" authtype = ldap ldap_connections_number = 5 timeout = 20 timelimit = 15 net_timeout = 10 tls { } dictionary_mapping = ${confdir}/ldap.attrmap edir_account_policy_check = yes set_auth_type = yes auto_header = yes password_header = "{SHA}" password_attribute = userPassword } ### sites-enabled/default ### authorize { preprocess ldap chap mschap suffix eap #files } authenticate { Auth-Type PAP { pap } Auth-Type MS-CHAP { mschap } eap } preacct { preprocess acct_unique suffix } accounting { detail unix radutmp attr_filter.accounting_response } session { radutmp } post-auth { Post-Auth-Type REJECT { attr_filter.access_reject } } pre-proxy { } post-proxy { eap }

Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

mel wrote:

In that case, something is *really* wrong with my setup and I have no idea why. I can only authenticate if the password in OpenLDAP is cleartext, but never if it's hashed. debug output, radiud.conf (modules ldap section), sites-enable/default follows.

You have edited the configuration to break it. Don't do that. Again, almost all of the answers here are assuming that you're starting from the default configuration. If you're going to massively edit it and then ask "why is it broken", the answer is simple: your edits broke it.

rlm_ldap: Added SHA1-Password = iEPX+SQWIR3p67lj/0zigSWTKHg= in check items rlm_ldap: looking for check items in directory... rlm_ldap: LDAP attribute userPassword as RADIUS attribute User-Password == "{SHA}iEPX+SQWIR3p67lj/0zigSWTKHg="

Note that you are adding the SHA password *twice*. This isn't necessary. In this case, it looks like you've edited ldap.attrmap to map userPassword to User-Password. ...

++[eap] returns noop

And no "pap" module.

auth: type Local auth: user supplied User-Password does NOT match local User-Password

Because it's comparing the {sha}... stuff to the User-Password in the Access-Request. And it's only doing that because you deleted the PAP module from the "authorize" section. ...

### sites-enabled/default ###

authorize { preprocess ldap chap mschap suffix eap #files }

See? You edited that. A lot. And broke it. See the DEBUGGING section of "man radiusd". It explains how to modify the default *working* configuration to something that works on your local site. In this case, I'll bet that all you have to do is: 1) start with the default configuration 2) enable && configure the LDAP module 3) verify that it works. I have *no* idea why so many people install the server, and *immediately* start mangling the default configuration. All of the documentation says DON'T DO THAT. Yet every week, there's someone who does exactly that, and then wonders why the server doesn't work. It's like there's some magic documentation out there that says "randomly change things, and ignore all of the documentation that comes with the server, and all of the advice on the mailing list." I don't know where that magic documentation exists, but it must exist... because a lot of people seem to be reading it. Alan DeKok.