kadmin not working after server migration, but kdc works

[Wouter Verhelst]

Hi Greg,

On Tue, Sep 20, 2022 at 11:43:40AM -0400, Greg Hudson wrote:
> On 9/20/22 10:19, Wouter Verhelst wrote:
> > I can log in to the server; "kinit" works just fine. However, kadmind
> > refuses to start, and when I run "kadmin.local", I get:
> > 
> > root at lounge ~ # kadmin.local
> > Authenticating as principal root/admin at GREP.BE with password.
> > kadmin.local: Required parameters in kdc.conf missing while initializing kadmin.local interface
> 
> This is one of our worst error messages (see
> https://krbdev.mit.edu/rt/Ticket/Display.html?id=8247 ).

Yeah, no kidding. I actually looked at the source a while ago to try and
figure out what was happening, but no luck; the location where the error
message is printed has absolutely no link anymore with the location
where the error occurs...

> From experience, this probably means you have a single-DES enctype
> listed in supported_enctypes and are using release 1.18.  (In 1.17 or
> previous the enctype would be recognized; in 1.19 or later the library
> would ignore the enctype rather than failing out.)  Remove the
> single-DES enctype and kadmind should start working again.

So, supported_enctypes is not even in the krb5.conf file; I assume that
means it then reverts to defaults?

There were a number of other realms in there which I don't use. I just
removed them to see if that fixes things, but no luck.

The krb5.conf file currently looks like this (after removing comments):

-----
[libdefaults]
        default_realm = GREP.BE
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true
        fcc-mit-ticketflags = true

[realms]
        GREP.BE = {
                kdc = lounge.grep.be
                admin_server = lounge.grep.be
        }
[domain_realms]
        .grep.be = GREP.BE
        grep.be = GREP.BE
-----

adding "supported_enctypes = DEFAULT" in the libdefaults section also
doesn't fix it. I also remember now that I did in fact keep a VM aside
with krb5 1.17 (because I believed that would allow me to fix it at the
time, but I couldn't get it to work). It exhibits the same problem.

I did not write this file myself; I believe it was generated by a (very
old...) version of the Debian package, and then just copied from system
to system, although I obviously did adapt the kdc and admin_server
lines when upgrading.

It might be that I haven't properly migrated it from single-DES to more
modern enctypes; is this something I would be able to see if I looked at
a dump of the database? If so, how would I go about that, and can I
still fix this?

Thanks for your help,

-- 
     w at uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.