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

[Turbo Fredriksson <turbo@bayour.com>]

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...


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...
-- 
Ft. Bragg [Hello to all my fans in domestic surveillance] Uzi Nazi
ammonium NORAD president Legion of Doom NSA Delta Force KGB Kennedy
security Rule Psix CIA
[See http://www.aclu.org/echelonwatch/index.html for more about this]