Hi Emmanuel, On 8 avr. 2013, at 18:30, 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. 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. 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. 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. > 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... Regards, Pierre-Arnaud > wdyt ? (see https://issues.apache.org/jira/browse/DIRSERVER-1819 too) > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com >
