John Dennis wrote: > 1) is the userPassword attribute defined in $RADDB/ldap.attrmap ? > By default it isn't (I've never understood why it isn't)
This goes back to 0.x. The ldap module used to do authentication itself, and handled passwords via C code. In 2.1, this is deprecated. > You should have > a line in that file which looks like this: > > checkItem Cleartext-Password userPassword This will be in 2.2, and the old functionality will be removed. > Also, it's a good idea to understand what the ldap.attrmap is doing. > > 2) There may be ACL's (access control lists) set on sensitive data like > passwords in your ldap server. Usually the default is to only return > password attributes to the owner of the data and the administrator. If > you do a search for your own password it will probably succeed because > you're the owner of that password, but when freeradius does the search > it won't succeed because it's neither the owner nor the administrator. > That's why it's important when testing with ldapsearch to bind the same > way as the ldap module binds. You may need to modify the password ACL on > your ldap server to permit freeradius access to passwords. This could be in the FAQ, or on the Wiki. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html