Re: errant SASL/GSSAPI setup?

[<simon@sxw.org.uk>]

If you're using MIT Kerberos, I strongly suspect that the problem you're seeing is due to the behaviour of its GSSAPI library. With MIT's implementation a gssapi context is only valid for the lifetime of the initiator's credential. So, when your clients credentials expire, the security context also expires, and the client and server both start failing to decrypt each others packets. We first noticed this problem because slapd would crash when the decryption failure occurred - this problem no longer exists - but MIT Kerberos's behaviour has not changed.

Just renewing your credentials won't help, as the new credentials will only be used when establishing a new security context, which only happens when a new connection is opened.

Simon.

-----Original Message-----

From:  "Allan E. Johannesen" <aej@WPI.EDU>
Subj:  Re: errant SASL/GSSAPI setup?
Date:  Thu 31 Aug 2006 21:05
Size:  920 bytes
To:  Quanah Gibson-Mount <quanah@stanford.edu>
cc:  "Allan E. Johannesen" <aej@WPI.EDU>, openldap-software@OpenLDAP.org

First, as the subject has always said, I figure I've done something odd.
However, I don't know what that is.

>>>>> "quanah" == Quanah Gibson-Mount <quanah@stanford.edu> writes:

quanah> Do you have some type of limits set on the master for connections?  If
quanah> you do, you need to bypass those for your replicas repliation DN with
quanah> the "limits" command in the master's slapd.conf.

No, I didn't have an explicit limit for it.  In my ignorance didn't think the
root DN was limited.

I've installed a limit and I'll run another test.

However, why does it time out when the ticket expires, whether that's 4 minutes
or 10 hours?

Also, is this the error I'd see if a limit ran out?

SASL [conn=0] Failure: GSSAPI Error: The context has expired (No error)
sb_sasl_write: failed to encode packet: generic failure
ldap_write: want=11172 error=Input/output error
ber_flush failed errno=5 reason="Input/output error"