Re: Defining a password attributetype

[Jonathan CLARKE <jonathan.clarke@normation.com>]

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%20Specificat
> > > 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
--
==========================================
Jonathan CLARKE
------------------------------------------
Normation
44 rue Cauchy, 94110 Arcueil, France
------------------------------------------
Telephone:  +33 (0)1 83 62 26 96
------------------------------------------
Web:        http://www.normation.com/
==========================================