[33234] in Kerberos
Wrong principal in request
daemon@ATHENA.MIT.EDU (Jaap Winius)
Fri Feb 25 18:37:43 2011
Message-ID: <20110226003732.20542h08tqyobu4g@bitis.umrk.nl>
Date: Sat, 26 Feb 2011 00:37:32 +0100
From: Jaap Winius <jwinius@umrk.nl>
To: kerberos@mit.edu
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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 Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
