Thanks for everyone's help. I don't want users passwords stored in clear text in the directory, so I've set the password-hash back to SSHA. Even when it was stored in cleartext, the passwords were base64 encoded and freeradius wasn't seeing that as a match. Since I only need the clear text passwords for machines for MAC-auth via freeradius, I just went ahead and created another schema attribute in our private OID space called userClearPassword, stored the password (MAC address) in that attribute and then on the freeradius server, mapped that attribute to userPassword for the instance that is doing MAC-auth. This keeps my directory users passwords in a good, secure encryption, and allows my switches to MAC-auth against the cleartext passwords via freeradius. My other radius systems use Web-auth but they are using PAP so the encrypted passwords stored in the directory are fine. Thanks again! Tom Leach
On 06/24/2010 09:19 AM, masarati@aero.polimi.it wrote:
Is the 'password-hash' configuration function a server-wide setting only
Yes.
or can it be set to different values for separate databases?
No.
I'm trying to add MAC-auth RADIUS functionality to my LDAP server (openldap-2.4.21) and I need to store the password for the MAC addresses in cleartext. I also use the LDAP server for user login which I don't want to keep in cleartext. So, my thought was to have 'password-hash {SSHA}' for the users database, and 'password-hash {CLEARTEXT}' for the RADIUS database, but it appears that it's a global so I'm pretty sure this won't work.
Also, how do I verify that the passwords are stored in cleartext? On a test server, I've created just the radius database with a global 'password-hash {CLEARTEXT}', I have the following ldif file that I add with: ldapadd -x -W -v -D 'cn=Manager,o=radius' -f mac.ldif -h ldap_server
Contents of mac.ldif: dn:uid=001e68d08ff9,o=radius uid: 001e68d08ff9 cn: 001e68d08ff9 userPassword: {cleartext}001e68d08ff9 objectClass: top objectClass: radiusProfile objectClass: radiusObjectProfile
but when I use ldapsearch or slapcat to dump the database, the userPassword line looks to be hashed. ldap_server# slapcat dn: o=radius o: radius objectClass: top objectClass: organization structuralObjectClass: organization entryUUID: 97ab4273-42ae-4b41-9100-a8106bf766bf creatorsName: cn=Manager,o=radius createTimestamp: 20100618220235Z entryCSN: 20100618220235.020635Z#000000#000#000000 modifiersName: cn=Manager,o=radius modifyTimestamp: 20100618220235Z
dn: uid=001e68d08ff9,o=radius uid: 001e68d08ff9 cn: 001e68d08ff9 userPassword:: e2NsZWFydGV4dH0wMDFlNjhkMDhmZjk=This is the base64 encoding of "{cleartext}001e68d08ff9"
Please note that slapd will hold what you store in it. password-hash only hashes passwords that are written by the password modify extended operation (RFC3062). So if you write passwords using an add or a modify operation, it will be stored as it is provided.
p.