Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

kadmind error - krb5_recvauth: start_seq_get is not supported in the HDBGET keytab type #133

Closed
kartiksubbarao opened this issue Jul 6, 2015 · 7 comments
Milestone

Comments

@kartiksubbarao
Copy link

I'm trying to migrate a heimdal KDC with an OpenLDAP backend from a Debian 5.x server (heimdal 1.2.dfsg.1-2.1) to a Ubuntu 14.04 server (heimdal 1.6~git20131207+dfsg-1ubuntu1.1), and am running into problems with kadmind on the 14.04 system.

Some kerberos functionality works fine -- I can run kinit, get a ticket and use GSSAPI authentication with sshd successfully. I can even use kadmin with the -l option successfully. However, when I leave out the -l option and try to talk to kadmind, I get errors. For example, if I export the kadmin/admin keytab to the file /tmp/kadmin.keytab and run:

kadmin -p kadmin/admin -K /tmp/kadmin.keytab get kadmin/admin

I get the error:

kadmind[38823]: krb5_recvauth: start_seq_get is not supported in the HDBGET keytab type

This exact same command, with the exact same kadmin.keytab file, works just fine on the debian 5.x system.

The situation in which I get the above error is where I've either copied the /var/lib/heimdal-kdc/heimdal.db file from the Debian 5.x server to the Ubuntu 14.04 server, or the heimdal.db file is nonexistent. If I use the default heimdal.db file that gets created along with the heimdal package installation, I see a different error from kadmind:

kadmind[38853]: krb5_recvauth: Decrypt integrity check failed for checksum type hmac-sha1-96-aes256, key type aes256-cts-hmac-sha1-96

I don't understand why the contents of heimdal.db matters, since I'm using an OpenLDAP backend. It seems odd that a static db file is somehow being consulted when the principals are in the LDAP directory. I have verified that I have copied the LDAP directory intact from the Debian 5.x system to the Ubuntu 14.04 system, and there is no master key being used (there is no mkey_file directive, and even if I copy over the default m-key file that was auto-generated originally on the Debian 5.x it doesn't make any difference). Not sure what else I could do to ensure that the configurations are as similar as possible.

I also tried backporting the more recent heimdal 1.6rc2 package to 14.04 but got the same errors. I tried tracing through kadmind's behavior with gdb but nothing jumped out as being an obvious issue.

Does anyone know what might be going on here? Here are /etc/krb5.conf and /etc/heimdal-kdc/kdc.conf files to illustrate the config:

# /etc/krb5.conf
[libdefaults]
default_realm = EXAMPLE.COM
forwardable = true
proxiable = true
renewable = true
scan_interfaces = true

[realms]
EXAMPLE.COM = {
  admin_server = localhost
  kdc = localhost
}

[domain_realm]
example.com = EXAMPLE.COM
.example.com = EXAMPLE.COM

[logging]
default = SYSLOG:INFO

# /etc/heimdal-kdc/kdc.conf
[logging]
kdc = FILE:/var/log/heimdal-kdc.log
kdc = SYSLOG:INFO

[kdc]
database = {
  dbname = ldap:dc=example,dc=com
  hdb-ldap-create-base = ou=Kerberos,dc=example,dc=com
  acl_file = /etc/heimdal-kdc/kadmind.acl
}
@kartiksubbarao
Copy link
Author

closed by accident

@kartiksubbarao kartiksubbarao reopened this Jul 6, 2015
@kartiksubbarao
Copy link
Author

I found the problem, which seems to have echoes of #41. I'm not too familiar with the kerberos code, so what follows may be an imprecise/inaccurate explanation, but hopefully it's close enough to help someone who can look at this better. In version 1.6, kadmind by default looks for the kadmin/admin princpal key in "HDBGET:" (which I think ends up mapping to /var/lib/heimdal-kdc/heimdal.db on my system). It doesn't seem to have a way to recognize that kadmin/admin is actually in LDAP, and look for it there. As a workaround, I've done the following:

  1. Added the kadmin/admin principal to /etc/krb5.keytab
  2. Appended "--keytab=/etc/krb5.keytab" to the kadmind arguments in /etc/inetd.conf

This tells kadmind to explicitly find the kadmin/admin principal in /etc/krb5.keytab, and my kadmin commands work fine now.

Some ideas:

  • Would it be possible to have kadmind check to see if the keystore is stored in LDAP, and look for the kadmin/admin principal there? It would be helpful not to have to re-copy the kadmin/admin principal into /etc/krb5.keytab if a new key needs to be generated for whatever reason.
  • A clearer error message or even just a short addition to the man page would be extremely valuable in these situations. For example, if the kadmind man page mentioned that it looks for the kadmin/admin principal that it uses to authenticate to kdc in "HDBGET:" and explained what that means, that would definitely help.

@nicowilliams
Copy link
Contributor

nicowilliams commented Apr 15, 2016

kadmind[38823]: krb5_recvauth: start_seq_get is not supported in the HDBGET keytab type

This means that kadmind was not able to find a key for the kadmin service principal and kvno whose key is used to encrypt the kadmin client's service Ticket. This can only happen if kadmind is using a different HDB than the kdc that issued the Ticket.

Normally, when a service cannot find a suitable key in the keytab, the library will try decrypting the Ticket with every key in the keytab that has the same enctype. This is not desirable when a keytab has many, many entries in it. The keytab system support using an HDB as a keytab, which is very convenient for running KDC-side services, but the HDB is very likely to be very large, so trying every key in the HDB (of the same enctype as the Ticket encryption key) would be costly and would create a DoS. This is why the HDB-as-keytab does not support iterating its content via the keytab API.

EDIT: It would also be a security problem!

@kartiksubbarao
Copy link
Author

Thanks for the response Nico. It's been a while since I've looked at this problem, so my knowledge of this stuff has somewhat lapsed -- apologies if what I'm about to ask is missing something obvious. I can't quite make out whether your response addresses the specific points that I raised in my previous comment:

  • Would it be possible to have kadmind check to see if the keystore is stored in LDAP, and look for the kadmin/admin principal there? It would be helpful not to have to re-copy the kadmin/admin principal into /etc/krb5.keytab if a new key needs to be generated for whatever reason
  • A clearer error message or even just a short addition to the man page would be extremely valuable in these situations. For example, if the kadmind man page mentioned that it looks for the kadmin/admin principal that it uses to authenticate to kdc in "HDBGET:" and explained what that means, that would definitely help.

If you could address these points more directly that'd be great. Again, sorry if I'm missing something here and not connecting the dots. Kerberos tends to tax my mind :-)

@vdukhovni vdukhovni added this to the Heimdal 7 milestone Nov 8, 2016
@nicowilliams
Copy link
Contributor

OK, looping back to this one...

First, this message:

kadmind[38823]: krb5_recvauth: start_seq_get is not supported in the HDBGET keytab type

can't really be removed. What it means to the user is that something is wrong with their HDB.

Second, looking back through your comments, you want to use the LDAP HDB backend, but you accidentally copied a local file-based HDB into place. And you mention using a non-standard krb5.conf (/etc/heimdal-kdc/kdc.conf). So I suspect user error: kadmind must have been using the system krb5.conf?

@nicowilliams
Copy link
Contributor

(Incidentally, the HDB keytab type does support iteration... but you really shouldn't use it.)

The HDBGET keytab type is the default for the various services, like kadmind, but you can specify the name of an HDB:

kadmind --keytab HDBGET:ldap:dc=example,dc=com

NOTE! That's the name from the dbname parameter in your krb5.conf that you posted, but it's not a good HDB dbname, and the dc=example,dc=com is not interpreted. Also, : is used as a separator, so it's not a good idea to use : in your HDBs' dbnames.

The format of HDB and HDBGET keytab names is as follows:

HDB[GET][:[HDBFORMAT:database-specific-data[:mkey=mkey-file]]]

Yes, you can even specify the path to a master key file.

The default is HDBGET for the default/first HDB listed in krb5.conf.

@kartiksubbarao
Copy link
Author

kartiksubbarao commented Nov 10, 2016

Thanks for the additional comments Nico. I think I'm getting closer to understanding, but I feel like I'm missing one or two key pieces. It would be very helpful to me if you could answer this question:

Starting from a default configuration of heimdal-kerberos on Ubuntu, how does one tell kadmind to look in ou=kerberos,dc=example,dc=com on the LDAP server named ldap.example.com to find the kadmin/admin principal?

If you could spell out for me exactly what to put in krb5.conf and/or kdc.conf to achieve the above goal, I think it would help me understand much more clearly and better appreciate the rest of your explanation. I apologize for the rudimentary nature of this question -- I did try to scour through the documentation when first working on this problem, but couldn't find a clear answer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants