Le 03/09/2010 18:07, Rob Tanner a écrit :
The attribute will be SHA encrypted digest encoded as Base64 (same as the standard userPassword attribute). Any guidance on the schema definition would be most appreciated.
The online OpenLDAP Admin Guide has quite a bit of good information on defining schemas, including common syntaxes:
http://www.openldap.org/doc/admin24/schema.html#Attribute%20Type%20Specifica...
ion
When I'm adding an attribute to my private schema and I'm not sure of the syntax OID, I look for a similar attribute in the schema included in the openLDAP distribution. The problem is that 'userPassword' is apparently defined by the software since I can't find it in any of the schema. If I encode the 'tempPassword' exactly the same as I encode 'userPassword', I'm guessing that what I'm writing is basically an octet string. Am I right?
userPassword is indeed defined in so-called "system schema". You can see it's definition either by querying a running OpenLDAP server for it (ldapsearch -b "cn=subschema" -s base attributeTypes or Apache Directory Studio and other GUIs have a nice interface for this), or as a comment in the core.schema file distributed with OpenLDAP.
Here it is:
#attributetype ( 2.5.4.35 NAME 'userPassword' # DESC 'RFC2256/2307: password of user' # EQUALITY octetStringMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
So, yes, it is an octet string.
Also, I note that while you can define an attribute that's named tempPassword, it will not be used by OpenLDAP for authentication. 'userPassword' is a special case. Similar behaviour could be achieved by writing an overlay, though, if that's what you want.
That's its the entire purpose. A number of systems and services authenticate to the ldap server. When users fail to take note of the expiry notices they're getting in their email and allow their password to expire and, O by the way, don’t remember their own answers to the security questions, the support desk will assign them a temporary password that the password manager (a webapp) knows how to read. Using the ‘tempPassword’ attribute that I’m going to create means that they will have access to nothing except the password manager until they reset the password. And, O by the way, have to create a new set of security questions that just maybe they’ll remember the answers to 6 months down the line when they again ignore the expiry notices.
Hey, you sound a little annoyed at people forgetting their security questions ;-)
I understand your requirements, I'm just pointing out that your password manager webapp actually must read the contents of tempPassword and does the SHA hashing itself to compare passwords. OpenLDAP won't accept passwords to check against another attribute than tempPassword (unless modified via an overlay).
As a side note, if this is for the case when users have an expired password and must reset it, by the support desk assigning a temporary password, why not just put that password in userPassword, and set a flag which basically means "User can only log in to change password"? OpenLDAP ACLs can easily forbid authentication if such a flag is set, for example, unless access is done via the password manager webapp. Just a thought.
Regards, Jonathan