On 9 avr. 2013, at 14:13, Emmanuel Lécharny <[email protected]> wrote:
> 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 But what if we don't have a KDC server defined but still want passwords to be stored as hashed values and enabled the PasswordHashingInterceptor for that purpose? Regards, Pierre-Arnaud > 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 >
