Le 4/8/13 7:08 PM, Kiran Ayyagari a écrit : > On Mon, Apr 8, 2013 at 10:00 PM, Emmanuel Lécharny <[email protected]>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... IMO, in a future version, it would be way better to define an administrativePoint to handle that. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
