Le 4/9/13 2:02 PM, Pierre-Arnaud Marcelot a écrit : > 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.
Right, right, my bad. That solve one of my issues. > > 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. ATm, it is. The interceptor just filters entries which has a userPassword AT, regardless their position in the tree and the searchBaseDN parameter. > 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. Yes, it would be a good idea, as soon as we can do that but still have DIGEST and CRAM MD5 SASL auth working. This is not possible atm. > >> 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... IMO, the best solution is a bit more complex, but way more flexible : use the administrative model to handle this. It will allow us to define not only a position in the DIT, but also a filter and a scope that will be applied to the selected entries. Obviously, it won't be ready for 2.0 :) ATM, here is what I suggest : - make the hash password interceptor use the kerberos SearchBaseDN Everything else will remain as is. We can improve the way it works when 2.0 is out. wdyt ? -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
