[39266] in Kerberos
Re: How to view KVNO on slave
daemon@ATHENA.MIT.EDU (Mike via Kerberos)
Thu Oct 12 09:03:49 2023
Message-ID: <3f50f1bc-0188-e015-ca0c-23c987d6042d@csits.net>
Date: Thu, 12 Oct 2023 14:01:30 +0100
MIME-Version: 1.0
Content-Language: en-GB
To: Russ Allbery <eagle@eyrie.org>, Mike via Kerberos <kerberos@mit.edu>
In-Reply-To: <87wmvyv1nv.fsf@hope.eyrie.org>
From: Mike via Kerberos <kerberos@mit.edu>
Reply-To: Mike <kerberos@norgie.net>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: kerberos-bounces@mit.edu
On 07/10/2023 17:27, Russ Allbery wrote:
> Mike via Kerberos <kerberos@mit.edu> writes:
>
>> I'm surmising that the issue might be that the service principle may not
>> have replicated corerctly to the slave server, which is used by the
>> Apache host. I can see the ticket details on the master using
>> kadmin.local and getprinc and I can see the keytab info using ktutil.
>> My question is this: How does one view the KVNO in the Slave DB? I
>> imaine it's probably available via kdb5_util dump but unfortunatly I
>> have not found any documents explaining the fields in the dump.
>
> You can use kadmin.local on the slave the same way that you use it on the
> master, I'm fairly sure. It's been a while since I've done this, but I'm
> pretty sure the database is the same and the tool doesn't have any idea
> whether you're running it on a master or a slave.
>
> I would expect you to get replication errors if there was a replication
> problem. If you're only doing incremental replication and you think
> something may have gone wrong, you can always do a full replication, which
> guarantees that the slave is identical to the master.
>
Hi Russ,
Thanks for the info. You were indeed correct, kadmin.local can be used
on the slave DB. It's not installed by default on Debian, at least, as
it comes as part of the kadmin package. I installed it and saw that the
KVNO is up to date.
I eventually happened upon the answer in the kdc.log on the master. It
was a DNS mix up. The web server has two DNS names
server.zone.example.com and server.example.com. The service principal
was HTTP/server.zone.example.com and the log was complaining about not
being able to find a service principal for HTTP/server.example.com. So
I created one, added it to the keytab and things started working again!
It was simple in the end, trouble is I'd been concentrating on the
logging of the slave server and the web server neither of which recorded
anything helpful.
The only weird thing is that it also (I later found out) affected
another web server in the same way but has been working for years. It
wasn't until I rekeyed the service principal that the problem seemed to
arise. I guess that part will remain a mystery. It is now fixed
however and I thank you again for your assistance.
Kind regards,
Mike.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
