On Wed, Feb 16 2022 at 19:58:27 -0600, Matt Zagrabelny scribbled in "Re: unexpected failure for GSS Pg server": > On Tue, Feb 8, 2022 at 5:03 PM Dameon Wagner <dameon.wag...@it.ox.ac.uk> > wrote: > > > > > Armed with that information, the most likely solution would be to > > extract a fresh keytab (using either the kadmin "ktadd" subcommand, or > > the handy `k5srvutil` command). > > > > Thanks for the detailed instructions, Dameon! > > Do you know why performing the ktadd increases the kvno? I believe that is > what tripped me up. I thought I was just "re-exporting" the key from the > KDC.
Always happy to help :) The default behaviour of "ktadd" has always been to increment the kvno of the principal, as it's effectively a password change (though using a random key instead). If you are in the position of really really needing to export a keytab with the existing key(s) in it, you can, on the master KDC host, use the `kadmin.local` command. Once there, you can run the "ktadd" subcommand as before, but with the additional "-norandkey" option (which I believe is only available via `kadmin.local`). The downside of this though is that you're then responsible for securely transferring the keytab to the remote host that ultimately needs it. > > > > It may appear a bit old, but the O'Reilly book is still a classic > > resource for becoming familiar with Kerberos and how it functions. > > > > Ha! Yup! That book is in the office and I have been WFH for the last two > years. :/ I'm in the same boat, so know the feeling well. Thankfully have my own copy at arms reach. Back in the office soon though (which will be rather strange), with a more extensive library available :) Cheers. Dameon. -- ><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <>< Dr. Dameon Wagner, Unix Platform Services IT Services, University of Oxford ><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <>< ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
