Re: slapd-{ldap,meta} && authentication

["Pierangelo Masarati" <ando@sys-net.it>]

Sorry for not replying to your previous email, I'm still reading the log
and it'll take some time before I can work on that (say next weekend).

> Quoting Turbo Fredriksson <turbo@bayour.com>:
>
>> This morning I did it like this (it's just a workaround - I don't like
>> it
>> just 'for the sake of it' :). It's the closest thing I can think of that
>> doesn't
>> open up the whole database for an attacker. It CAN I guess, but I can't
>> think
>> of a _real_ way to exploit it yet...
>>
>> Created a proxy user - 'uid=proxy,...' - which only have SEARCH access
>> to the
>> 'authentication attributes' (userPassword, krb5PrincipalName, mail and
>> mailAlternateAddress) that are used one way or the other.
>
> This seems to only work 'for a while' - I'm currently trying to figure out
> why.
>
> My current guess is that it's caching to much/little/long...
>
> I think I can successfully recreate the problem:
>
>         1. Start master:slapd
>         2. Start proxy:slapd -h ldapi://%2fvar%2frun%2fldapi
>         3. proxy:ldapwhoami -H ldapi://%2fvar%2frun%2fldapi
>            -> will give me the correct DN
>         4. Stop master:slapd
>         5. proxy:ldapwhoami -H ldapi://%2fvar%2frun%2fldapi
>            -> will give me a cn=auth DN
>         6. Start master:slapd
>         7. proxy:ldapwhoami -H ldapi://%2fvar%2frun%2fldapi
>            -> will give me a cn=auth DN
>
> Point 7 is wrong! This is where caching takes place somehow.
> If I don't restart proxy:slapd, it will NEVER give me the
> correct DN!
> Running master:slapd in debug mode (in point 6) shows that
> it will never get an ACCEPT from slave:slapd in point 7...

The reason is quite simple, I think: some part of the operation, and
significantly all the bind-related stuff, is not cached at all (for many
reasons, including security).  back-ldap, at some point, was made able to
share and reuse connections that were anonymous or run as "rootdn";
unfortunately, if the master goes down, the shared connection is not
cleared, so subsequent connections fail.  This is fixed in HEAD (ITS#3217)
and is about to be released with 2.2.15; if you want to try, you can check
out OPENLDAP_REL_ENG_2_2 (with a LOT of more fixes, see the ITS with
"Release" status!).  Or, to avoid this problem, while testing never stop
the master alone, always restart all the system.

>
>
> To make sure it doesn't read the file cache (overlay), I
> disabled that part, but still no go. There doesn't seem to
> be any equivalence of the 'dncache-ttl' which is availible
> to back-meta, so I don't know (without resorting to the code)
> how long it caches...

That's something completely different, I wouldn't mind about that
"dncache-*" stuff; it's only used by back-meta to help guessing what
target can satisfy a request in case there are ambiguities (e.g. the odd
case of different targets serving exactly the same naming context, which
is the reason we developed back-meta, since that couldn't be done
elsewhere).

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497