You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lécharny <el...@gmail.com> on 2013/04/08 18:30:48 UTC
SearchBaseDN, Kerberos, SASL and password hashing...
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)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: SearchBaseDN, Kerberos, SASL and password hashing...
Posted by Kiran Ayyagari <ka...@apache.org>.
On Mon, Apr 8, 2013 at 10:44 PM, Emmanuel Lécharny <el...@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
Re: SearchBaseDN, Kerberos, SASL and password hashing...
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 4/8/13 7:08 PM, Kiran Ayyagari a écrit :
> On Mon, Apr 8, 2013 at 10:00 PM, Emmanuel Lécharny <el...@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...
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
Re: SearchBaseDN, Kerberos, SASL and password hashing...
Posted by Kiran Ayyagari <ka...@apache.org>.
On Mon, Apr 8, 2013 at 10:00 PM, Emmanuel Lécharny <el...@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
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
--
Kiran Ayyagari
http://keydap.com
Re: SearchBaseDN, Kerberos, SASL and password hashing...
Posted by Kiran Ayyagari <ka...@apache.org>.
On Tue, Apr 9, 2013 at 6:56 PM, Emmanuel Lécharny <el...@gmail.com>wrote:
> Le 4/9/13 2:16 PM, Pierre-Arnaud Marcelot a écrit :
> > On 9 avr. 2013, at 14:13, Emmanuel Lécharny <el...@gmail.com> wrote:
> >
> >> 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?
>
> Anyway, there is a big problem : we don't have access to the
> KerberosServer instance nor to the LdapServer instance from the
> interceptor, so there is no way we can get the searchBaseDn...
>
>
> let us not interfere with the searchBaseDn semantics instead add a config
parameter(as mentioned in my earlier mail)
in hashing interceptor to white list a set of containers that need to be
excluded from the hashing operation.
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
--
Kiran Ayyagari
http://keydap.com
Re: SearchBaseDN, Kerberos, SASL and password hashing...
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 4/9/13 2:16 PM, Pierre-Arnaud Marcelot a écrit :
> On 9 avr. 2013, at 14:13, Emmanuel Lécharny <el...@gmail.com> wrote:
>
>> 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?
Anyway, there is a big problem : we don't have access to the
KerberosServer instance nor to the LdapServer instance from the
interceptor, so there is no way we can get the searchBaseDn...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: SearchBaseDN, Kerberos, SASL and password hashing...
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
On 9 avr. 2013, at 14:13, Emmanuel Lécharny <el...@gmail.com> 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 <el...@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.
>> 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
>
Re: SearchBaseDN, Kerberos, SASL and password hashing...
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 4/9/13 2:02 PM, Pierre-Arnaud Marcelot a écrit :
> Hi Emmanuel,
>
> On 8 avr. 2013, at 18:30, Emmanuel Lécharny <el...@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.
> 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
Re: SearchBaseDN, Kerberos, SASL and password hashing...
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
Hi Emmanuel,
On 8 avr. 2013, at 18:30, Emmanuel Lécharny <el...@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.
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
>