Hi,
I need to define a secondary password attribute and I¹m not sure what to enter in the schema. Is the syntax oid exclusively for searching and therefore, can I omit it (I¹m not going to be searching on the password)? Or is the synoid also used for defining how the attribute is stored? So far, what I have is:
attributetype ( 1.3.6.1.4.1.6459.10.2.213 NAME 'tempPassword' DESC 'Temporary password used for resets only' EQUALITY ?? SYNTAX ?? SINGLE-VALUE )
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.
Thanks, Rob
Rob Tanner UNIX Services Manager Linfield College, McMinnville Oregon
Hi,
Le 02/09/2010 23:51, Rob Tanner a écrit :
Hi,
I need to define a secondary password attribute and I’m not sure what to enter in the schema. Is the syntax oid exclusively for searching and therefore, can I omit it (I’m not going to be searching on the password)? Or is the synoid also used for defining how the attribute is stored?
The syntax defines the type of an attribute, ie what is valid data to be stored in it. It is obligatory in an attribute definition.
The 'EQUALITY', 'ORDERING' and 'SUBSTR' rules define which types of searches can be performed on the attribute. If you don't want to allow searches with a filter like (tempPassword=JHJDSQAJREXNR==) then don't include an EQUALITY rule.
So far, what I have is:
attributetype ( 1.3.6.1.4.1.6459.10.2.213 NAME 'tempPassword' DESC 'Temporary password used for resets only' EQUALITY ?? SYNTAX ?? SINGLE-VALUE )
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...
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.
Jonathan
Hi Jonathan,
On 9/3/10 6:35 AM, "Jonathan CLARKE" jonathan.clarke@normation.com wrote:
The syntax defines the type of an attribute, ie what is valid data to be stored in it. It is obligatory in an attribute definition.
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?
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.
Thanks, Rob
Rob Tanner UNIX Services Manager Linfield College, McMinnville Oregon
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
Rob Tanner wrote:
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?
1. Use a decent schema browser to examine the whole subschema subentry. This will also contain schema descriptions hard-coded in slapd (or its overlays).
2. userPassword is declared with OctetString (OID 1.3.6.1.4.1.1466.115.121.1.40). However if in your case you expect the password to be in clear-text and only contain strings you could type on a keyboard then DirectoryString (OID 1.3.6.1.4.1.1466.115.121.1.15) might be more appropriate.
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.
IMO that's bad practice. When doing a password reset you should set a random value in userPassword together with password expiration attribute (slapo-ppolicy).
Ciao, Michael.
Michael Ströder wrote:
- Use a decent schema browser to examine the whole subschema subentry. This
will also contain schema descriptions hard-coded in slapd (or its overlays).
As an example:
http://demo.web2ldap.de:1760/web2ldap/oid?ldap://ldap.uninett.no/dc=uninett,...
Type userPassword in the input field and press [Search]. You can also do wild-card searches with for example *pass* or pwd*.
Ciao, Michael.
On Friday, 3 September 2010 19:26:05 Michael Ströder wrote:
IMO that's bad practice. When doing a password reset you should set a random value in userPassword together with password expiration attribute (slapo-ppolicy).
IMHO, the correct attribute to set would have been pwdReset, but unfortunately there is no way to enforce users to reset their passwords in applications that don't support ppolicy (as users won't get locked out if they just keep using the temporary password).
I think I sent feedback to Howard on the new ppolicy draft about this ...
Regards, Buchan
Buchan Milne wrote:
On Friday, 3 September 2010 19:26:05 Michael Ströder wrote:
IMO that's bad practice. When doing a password reset you should set a random value in userPassword together with password expiration attribute (slapo-ppolicy).
IMHO, the correct attribute to set would have been pwdReset, but unfortunately there is no way to enforce users to reset their passwords in applications that don't support ppolicy (as users won't get locked out if they just keep using the temporary password).
I think I sent feedback to Howard on the new ppolicy draft about this ...
The original poster wrote about a custom web-based password app anyway. So this would not be a problem in his case.
Additionally the password expiration should be set to a reasonable short time-frame. Just in case someone intercepts the password reset message with the temporary password.
Ciao, Michael.
openldap-technical@openldap.org
-
Buchan Milne -
Jonathan CLARKE -
Michael Ströder -
Rob Tanner