Wrong principal in request

[Jaap Winius]

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