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" <[EMAIL PROTECTED]> Subj: Re: errant SASL/GSSAPI setup? Date: Thu 31 Aug 2006 21:05 Size: 920 bytes To: Quanah Gibson-Mount <[EMAIL PROTECTED]> cc: "Allan E. Johannesen" <[EMAIL PROTECTED]>, [email protected] 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 <[EMAIL PROTECTED]> 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"
