I'm seeing the following message in our slapd error log generally (but not always) once a day:
[31/Oct/2015:15:40:20 -0600] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Ticket expired)) errno 2 (No such file or directory) [31/Oct/2015:15:40:20 -0600] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -2 (Local error) [31/Oct/2015:15:40:26 -0600] NSMMReplicationPlugin - agmt="cn=meToipa1.nwra.com" (ipa1:389): Replication bind with GSSAPI auth resumed
I'm guess that there is a kerberos ticket involved in replication that expires every 24 hours and that it is not renewed automatically, but only after receiving a replication error. I would really like to see this done pre-emptively so that these errors are not a regular occurrence. I use logwatch to monitor the slapd error log looking for errors like this that might indicate a problem. Having this occur normally is a real pain.
Would GSSproxy help this case?
Are you asking me? I have no idea and don't know anything about GSSproxy.
Replying to [comment:2 orion]:
That was a general question. But you can probably check it yourself. What you would need to do is to install gssproxy https://fedorahosted.org/gss-proxy/ and configure it and make DS use it via an environment variable. More details are described here https://fedorahosted.org/gss-proxy/wiki/NFS and here https://fedorahosted.org/gss-proxy/wiki/Apache on how it can be configured. Gerneral idea is to delegate all GSSAPI operations to this daemon. As a side effect of this you get an automatic ticket renewal that will lead to not having failure and thus the message.
This is really a bug in 389-ds. It is a bit more verbose than it needs to be when it sees an expired ticket. It is similarly verbose on startup.
And yes, GSSProxy would probably help in this case if you wanted to quiet the messages. I don't know if anyone has tested 389-ds with GSSProxy though.
I agree it is too verbose (SLAPI_FATAL) for slapi_ldap_bind/slapd_ldap_sasl_interactive_bind but there is no real good level to log this transient failure. Also the returned ldap error code is not sufficient for diagnose: Local error.
On repl_connection side, it would be acceptable to log it only when replication loglevel is set.
I confirm that slapi_ldap_bind/slapd_ldap_sasl_interactive_bind are not presented in the external plugin guide. There is no requirement on the logging level of these msg. Now they can be useful for diagnose and I do not see what other log level to use.
This ticket should cover implementation from IPA side. It is not a priority and therefore moving to future releases.
DS ticket: https://fedorahosted.org/389/ticket/48346
Metadata Update from @orion: - Issue assigned to someone - Issue set to the milestone: Future Releases
The associated DS ticket is marked as fixed. I'm going to mark this fixed as well since there isn't anything to do on the IPA side.
Metadata Update from @rcritten: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.