Hi,

A while ago, I migrated my personal server (containing a small Kerberos
realm) from my old (dedicated) server to a new one. When I decomissioned
the server, however, I forgot to check that kadmin was still working. It
turned out afterwards that it didn't.

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@lounge ~ # kadmin.local
Authenticating as principal root/admin@GREP.BE with password.
kadmin.local: Required parameters in kdc.conf missing while initializing kadmin.local interface

...and I'm not sure how to fix this.

What did I do wrong? How can I debug this? How can I figure out which parameters are missing?

Thanks for any insight,

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

To: kerberos@mit.edu

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@lounge ~ # kadmin.local
Authenticating as principal root/admin@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 ).

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: kerberos@mit.edu

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@lounge ~ # kadmin.local
Authenticating as principal root/admin@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@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: ghudson@mit.edu (Greg Hudson)
Copy: kerberos@mit.edu

Wouter Verhelst <w@uter.be> writes:

On Tue, Sep 20, 2022 at 11:43:40AM -0400, Greg Hudson wrote:

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?

That's your krb5.conf, but the error message is about your kdc.conf (/etc/krb5kdc/kdc.conf). It has its own separate supported_enctypes
setting.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: kerberos@mit.edu

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...

"Back in the day" I kept a build of MIT Kerberos with full debugging
symbols around, so I could use a debugger to trace down the source
of weird errors like this (things are much better now, but you still
run into these issues occasionally).

fcc-mit-ticketflags = true

This seems like a Heimdal-specific configuration entry, FWIW.

Russ already explained that this is probably a problem with your kdc.conf
file, so I'd start there.

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?

Look at the manpage for kdb5_util, specifically the "tabdump" subcommand.
You can easily get a list of encryption types for all principals. The only tricky principals to change the key of are the master key (see the procedure
in the MIT documentation) and the kadmin password history key (well, that is straightforward, but you invalidate all password histories).

--Ken

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: ghudson@mit.edu (Greg Hudson)
Copy: kerberos@mit.edu

On Tue, Sep 20, 2022 at 12:56:51PM -0700, Russ Allbery wrote:

Wouter Verhelst <w@uter.be> writes:

On Tue, Sep 20, 2022 at 11:43:40AM -0400, Greg Hudson wrote:

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?

That's your krb5.conf, but the error message is about your kdc.conf (/etc/krb5kdc/kdc.conf). It has its own separate supported_enctypes
setting.

My kdc.conf currently looks like this:

-----
[kdcdefaults]
kdc_ports = 750,88

[realms]
GREP.BE = {
database_name = /var/lib/krb5kdc/principal
admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
acl_file = /etc/krb5kdc/kadm5.acl
key_stash_file = /etc/krb5kdc/stash
kdc_ports = 750,88
max_life = 10h 0m 0s
max_renewable_life = 7d 0h 0m 0s
master_key_type = des3-hmac-sha1
default_principal_flags = +preauth
default_principal_expiration = 0
}
-----

Adding a line "supported_enctypes = DEFAULT" in either the "kdcdefaults"
or "GREP.BE" section did not fix the issue.

It might be the "master_key_type" thing? But the issue exists in 1.17, too.

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: kerberos@mit.edu

On 9/21/22 03:45, Wouter Verhelst wrote:

default_principal_expiration = 0

This value is failing to parse as a timestamp. Removing this line
appears to clear up the config parsing error, and the default should
have the same effect.

I see that the documentation for default_principal_expiration says "The
default value is 0, which means no expiration date." I see how someone
would get that from the code when writing the documentation, but clearly
the documented default should be something that parses. (I think you'd
have to write out the beginning of the POSIX time epoch--in local
time--in something like yyyymmddhhmmss format to get this default.) The
whole concept of default_principal_expiration as an absolute time seems
suspect to me; I have trouble imagining a productive realm configuration
where every new principal by default expires on some particular fixed date.

I don't see any meaningful differences between the current code in this
area and the code going back fifteen years or so. So I'm not sure how
this broke during a migration.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: kerberos@mit.edu

On Wed, Sep 21, 2022 at 10:29:57AM -0400, Greg Hudson wrote:

On 9/21/22 03:45, Wouter Verhelst wrote:

default_principal_expiration = 0

This value is failing to parse as a timestamp. Removing this line
appears to clear up the config parsing error, and the default should
have the same effect.

Yes, that seems to fix the issue -- at least kadmin.local works again.

\o/

Thanks!

I see that the documentation for default_principal_expiration says "The default value is 0, which means no expiration date." I see how someone
would get that from the code when writing the documentation, but clearly
the documented default should be something that parses. (I think you'd
have to write out the beginning of the POSIX time epoch--in local
time--in something like yyyymmddhhmmss format to get this default.) The whole concept of default_principal_expiration as an absolute time seems suspect to me; I have trouble imagining a productive realm configuration where every new principal by default expires on some particular fixed date.

I don't see any meaningful differences between the current code in this
area and the code going back fifteen years or so. So I'm not sure how
this broke during a migration.

The migration was quite a while ago; it is possible (given this error,
perhaps a better way to put it is "likely") that I fiddled with the configuration files while migrating to the new server (while wanting to
"clean things up" or some such) and forgot about it in the time since.

Sincerest apologies for the confusion there, but a heartfelt thanks for
helping me fix it! I never would've found that by myself...

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)