On Mon, Apr 8, 2013 at 10:44 PM, Emmanuel Lécharny <elecharny@gmail.com> wrote:
Le 4/8/13 7:08 PM, Kiran Ayyagari a écrit :
> On Mon, Apr 8, 2013 at 10:00 PM, 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.
>> 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...
>> 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.
>> wdyt ? (see https://issues.apache.org/jira/browse/DIRSERVER-1819 too)
>> +1 but with a slight modification, instead of defining this attribute as a
> set of "search base"s
> it would be good to define as "do not hash the passwords under these DNs"
> something like ads-disableHashingUnderDn multi valued attribute
> if this attribute is absent all entries' passwords will be hashed

But that means we will have to put this flag in any entries...

no, in the hashing interceptor alone, so that the interceptor skips hashing if an entry is a child of any of these
IMO, in a future version, it would be way better to define an
administrativePoint to handle that.

Emmanuel Lécharny

Kiran Ayyagari