Hi folks, The subject above is part of an error that I was seeing in the syslog of my site's MIT Kerberos 1.8.3 master server (Debian squeeze):
slapd[26423]: SASL [conn=1256] Failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Wrong principal in request) slapd[26423]: conn=1256 op=0 RESULT tag=97 err=49 text=SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context This rather vague error was my own fault. I started with a working system -- one master and two slaves -- all of which use OpenLDAP 2.4.23 for their back-ends and replication, but then decided to alter these servers somewhat to add more LDAP client functionality. I'm no longer sure exactly what I changed, but it was a mistake. Soon afterwards the OpenLDAP consumer servers stopped replicating and the above SASL and GSSAPI errors appeared on the master/provider server every time the slave/consumer servers attempted to make contact (syncrepl). To fix things I tried to recreate various key tables, after which I attempted to recreate the principals for them as well. When that didn't work, I tried testing the connections with krb5-rsh. The results indicated that the hosts that I was trying to contact were not in the Kerberos database at all (even though it would not say which hosts I was trying to contact). Yet, I was certain that the names of the principals I was using -- ldap/<FQDN>@REALM -- matched the FQDNs of the hosts. A solution suggested itself when I noticed that krb5-rsh did work between hosts with a "host/<FQDN>@REALM" principal. So, I made extra ones of these principals for each of the three Kerberos/LDAP servers with their keys added to the local key table files. It seemed totally redundant, but it worked and things were back to normal. The question is, why? Finally, I tested the system to make sure all of these changes were really necessary. I did this by first removing the new host/<FQDN>@REALM principals and matching keys for the slave/consumer servers, restarting all three servers to test connectivity, and then doing the same after removing the new host principal and keys for the master/provider. Mysteriously, it continued to work (and still does) as though nothing had ever been the matter. Does anyone have an explanation for what was going on here? Cheers, Jaap ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
