Le 4/8/13 7:08 PM, Kiran Ayyagari a écrit :
But that means we will have to put this flag in any entries...> On Mon, Apr 8, 2013 at 10:00 PM, Emmanuel Lécharny <firstname.lastname@example.org>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
IMO, in a future version, it would be way better to define an
administrativePoint to handle that.