[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

[     Resending this because of a failed delivery - mail to big.    ]
[ Attachement is at http://www.bayour.com/slapd-master_20040728.txt ]

Quoting "Pierangelo Masarati" <ando@sys-net.it>:

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

Tried the CVS version. The problem reported here is fixed (i.e. ldapwhoami
works), but now I can't search the database! The master:slapd is still a
(released) 2.2.14 though...

----- s n i p -----
ida:~# ldapwhoami -H ldapi://%2fvar%2frun%2fldapi
SASL/GSSAPI authentication started
SASL username: turbo@REALM
SASL installing layers
ida:~# ldapsearch -LLL -H ldapi://%2fvar%2frun%2fldapi uid=turbo
SASL/GSSAPI authentication started
SASL username: turbo@REALM
SASL installing layers
Server is unwilling to perform (53)
Additional information: unauthenticated bind (DN with no password) disallowed
----- s n i p -----

Running master:slapd in debug mode will give me TWO connections.
The first as the uid=proxy user:
  1. authenticates as uid=proxy
  2. search for krb5PrincipalName=turbo@REALM
     a. SEARCH access to krb5PrincipalName requested
     b. READ access to [entry],uid,cn,sn, requested
     c. AUTH access to OpenLDAPaci requested
     d. READ access to (every single additional attribute defined
        in my object).
  3. Returns the correct DN

The second connection with my DN which fails almost directly
with 'unauthenticated bind (DN with no password) disallowed'.

Point 2a is what I got in/from the 2.2.14 released version, but 2[b-d]
is new and (from what I can tell) completely redundant/unnecessary.

[ UPDATE: It seems that downgrading again didn't change anything. Same
[         error message.

Included are my log with slapd running with '-d 3560' (8+32+64+128+256+1024+2048)
which was the closest debug level I could find which didn't dump the whole
connection in HEX (which is a nightmare to sanitise :).

Also, I'm trying to submit an ITS, but it won't accept it:      

----- s n i p -----
   The system encountered a fatal error

After command: MAIL FROM: <turbo@bayour.com>

Received: 451 4.1.8 Domain of sender address turbo@bayour.com does not resolve

   The last error code was: Unknown error: 0
----- s n i p -----

The ITS I'm trying to submit is the following:

----- s n i p -----
Running 'slapd -d -1' gives me the following:
reading config file /etc/ldap/slapd.conf
line 2 (allow bind_v2)
line 21 (loglevel       2176    # Parsing errors + ACL)
/etc/ldap/slapd.conf: line 21: unable to parse level "#" in "loglevel <level> [...]"

Line 21 looks like this:
loglevel                2176    # Parsing errors + ACL

Removing everything after the the number '6' will make slapd start up:
loglevel               2176

I was upgrading from released 2.2.14.
----- s n i p -----