directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Arnaud Marcelot ...@marcelot.net>
Subject Re: SearchBaseDN, Kerberos, SASL and password hashing...
Date Tue, 09 Apr 2013 12:16:30 GMT

On 9 avr. 2013, at 14:13, Emmanuel Lécharny <elecharny@gmail.com> wrote:

> Le 4/9/13 2:02 PM, Pierre-Arnaud Marcelot a écrit :
>> Hi Emmanuel,
>> 
>> On 8 avr. 2013, at 18:30, Emmanuel Lécharny <elecharny@gmail.com> wrote:
>> 
>>> Hi guys,
>>> 
>>> currently, there are two parts of the server that requires to know where
>>> the user entry should be read from. We use the searchBaseDN, which is
>>> configured in the ads-searchbasedn in the LDAPserver entry.
>>> 
>>> So we just have one single place where we tell the server what is the
>>> place in the DIT to look for users.
>> Actually, we have two...
>> Our configuration object classes (structural) for 'ads-ldapServer' and 'ads-kdcServer'
both extends the 'ads-dsBasedServer' object class (abstract) which contains the 'ads-searchBaseDN'
attribute type as an optional attribute.
> 
> Right, right, my bad. That solve one of my issues.
>> 
>> So, we can have two different search base DNs depending on which server we're looking,
either the LDAP or the KDC server.
>> They can have the same value but not necessarily.
>> 
>>> The pb is that if you activate the Kerberos server, then you have to
>>> activate the hashPassword interceptor that will hash all the
>>> userPassword values, no matter what. This will interfer with the users
>>> that are authenticated using the Simple auth (but we can put them in
>>> some different place if needed), but more important, the SASL authent
>>> using CRAM-MD5 or DIGEST-MD5 are using the same searchBaseDN, except
>>> they *need* the clear text password...
>> Again, here, I don't think the PasswordHashingInterceptor is only used by the KDC
server.
> ATm, it is. The interceptor just filters entries which has a
> userPassword AT, regardless their position in the tree and the
> searchBaseDN parameter.
>> You may want to activate it without the KDC Server, just to make sure the passwords
used to authenticate users via LDAP (SASL or not) are stored as hashed values and not in cleartext.
> 
> Yes, it would be a good idea, as soon as we can do that but still have
> DIGEST and CRAM MD5 SASL auth working. This is not possible atm.
> 
>> 
>>> So how can we solve this ? I suggest we use a list of searchBaseDNs in
>>> the hashPassword interceptor configuration, and that it only hashes the
>>> userPassword for the entries stored under those places.
>> Rather than repeating again the configuration of a "search base DN" on a third component,
I tend to agree with Kiran's proposal.
>> Having it hash the password of any user except if the user entry is a descendant
of a branch that is in an exclusion list.
>> 
>> Or maybe we need both attributes... (Sometimes we need want to include, sometimes
we want to exclude...)
>> An attribute to set the branches where hashing needs to happen and another to set
the branches where hashing should NOT happen.
>> And if none of these attributes are present, then the interceptor should hash all
passwords...
>> 
>> I really don't know which solution is best here...
> 
> IMO, the best solution is a bit more complex, but way more flexible :
> use the administrative model to handle this. It will allow us to define
> not only a position in the DIT, but also a filter and a scope that will
> be applied to the selected entries.
> 
> Obviously, it won't be ready for 2.0 :)
> 
> ATM, here is what I suggest :
> - make the hash password interceptor use the kerberos SearchBaseDN

But what if we don't have a KDC server defined but still want passwords to be stored as hashed
values and enabled the PasswordHashingInterceptor for that purpose?

Regards,
Pierre-Arnaud


> Everything else will remain as is. We can improve the way it works when
> 2.0 is out.
> 
> wdyt ?
> 
> 
> -- 
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com 
> 


Mime
View raw message