directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <kayyag...@apache.org>
Subject Re: SearchBaseDN, Kerberos, SASL and password hashing...
Date Mon, 08 Apr 2013 17:20:35 GMT
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
DNs

> 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
>
>


-- 
Kiran Ayyagari
http://keydap.com

Mime
View raw message