Linux – Kerberos service login only possible for 30 minutes after running ktpass.exe

active-directorykerberoslinux

I'm trying to Kerberize an Apache-server, and allow the created server principal to sign on to the Active Directory. I've followed one of the numerous tutorials available online, and it seems to work fine. I'm on the Linux side of the project, and Corporate IT is on the Windows side.

IT has provided me with a service account and a service principal for it. In this example, I'll refer to it as HTTP/mysite.mycorp.com@MYCORP.COM. They have provided me with a keytab file for said principal, which involves running a tool called ktpass.exe on the AD server.

I've verified that the KVNOs of the AD/KDC and the keytab file match. All is well.

There is a proper DNS A-record for the hostname, and a proper PTR record for the IP. Both servers are in time sync.

I'm able to request a ticket from the AD/KDC for the above mentioned service principal with the issued keytab file, like this:

kinit -k -t http.keytab HTTP/mysite.mycorp.com@MYCORP.COM

This works. I obtain a ticket, and I'm able to use this ticket for things like querying the AD/LDAP directory. The keytab also works great for running a Single Signon Apache site, which is partly the goal of this exercise.

Half an hour passes.

Attempts to log on with the above kinit command now fails with this message:

Client not found in Kerberos database

I'm unable to authenticate as the service principal, much as if the principal was deleted on the AD server.

Now it gets weird, at least for me:

By request, the AD administrator runs the ktpass.exe tool again, building a fresh keytab file for my service. The KVNO (Key Version Number) is incremented on the server, causing our Apache test server to stop validating Kerberos single signon. This is expected with my present configuration. What surprised all of us, was that now the kinit command worked again. We bought ourselves another half hour, and then it stopped working again.

Our IT department is at a loss here, and they're speculating that this is a problem with the AD server itself. I'm thinking it's configuration, but according to them, there are no half hour limits anywhere in their setup.

I've followed http://www.grolmsnet.de/kerbtut/ (see section 7) but the method seems to be the same in all the documentation I've found. I haven't found any reference to time limits on service principals.

EDIT: This seems to be a replication issue. Although no errors are reported in the replication process, the SPN value of the service account is changed (reverted?) from "HTTP/mysite.mycorp.com@MYCORP.COM" to "name-of-service-account@mycorp.com" after 30 minutes.

Best Answer

Thanks for all your input, guys. We got Microsoft on board, and they helped us debug the authentication process on the AD side. Everything worked as it was supposed to, but failed after thirty minutes.

While we were doing a remote debugging session, on of the participants noticed that the UPN/SPN of the service account was suddenly resat from HTTP/mysite.mycorp.com@MYCORP.COM to service-account@mycorp.com. After a LOT of digging around, including debugging AD replication, we found the culprit:

Someone had made a script that ran periodically (or probably by event, since it was exactly thirty minutes after running ktpass.exe), which updated the UPN/PSN to "ensure cloud connectivity". I do not have any supplemental information on the reasons for doing this.

The script was changed to allow existing UPN/SPN values ending in @mycorp.com, effectively solving the problem.

Tips for debugging issues like this:

Ensure all the participants in the authentication supports the same encryption types. Avoid DES - it's outdated and insecure.
Make sure to enable AES-128 and AES-256 encryption on the service account
Be aware that enabling DES on the service account means "use ONLY DES for this account", even if you enabled any of the AES encryptions. Do a search for UF_USE_DES_KEY_ONLY for details on this.
Make sure the UPN/SPN value is currect and matches the value in the issued keytab file (i.e. through an LDAP lookup)
Make sure the KVNO (Key Version Number) in the keytab file matches the on on the server
Inspect traffic between server and client (i.e. with tcpdump and/or WireShark)
Enable debugging of authentication on the AD side - inspect logs
Enable debugging of replication on the AD side - inspect logs

Again, thank you for your input.

Related Solutions

Help using setspn and ktpass

(this question is a bit old, but my analysis might help others)

You seem to be missing some understanding and therefore not executing the commands correctly. I'm assuming that your KDC is actually an Active Directory KDC. This is not entirely clear from your description.

Firstly, in active directory kerberos (contrary to standard MIT/Heimdal kerberos) a Service Principal Name (SPN - a service running a machine) needs to be connected to a User Principal Name (UPN, a user siting behind a machine). Hence the mapping.

setspn will add the service principal name to a user by adding the ldap attribute to the cn of the user

ktpass will output your key tab and rewrite the UserPrincipalName to username/fully.qualified.domainname@REALM .

By doing a kinit -k -t key.tab principal a lookup will happen in both the key.tab file and active directory UPN on the principal. If it cannot find the principal in the key tab it will give an error like "Key table entry not found while getting initial credentials". If it cannot be found in the directory it will give "Client not found in Kerberos database while getting initial credentials".

Now to your issue at hand. It seems that you are missing the /princ parameter to ktpass. This is required to actually get the principal in the key tab file and get the mapping right. I wonder what a klist -k keytab gives.

so your lines should be something like (including putting the REALM at the right location:

setspn HTTP/ubuntu-ad.wad.eng.hytrust.com aulfeldt

ktpass /princ HTTP/ubuntu-ad.wad.eng.hytrust.com@WAD.ENG.HYTRUST.COM /out tomcat.keytab /mapuser aulfeldt /crypto ALL /pass * /ptype KRB5_NT_PRINCIPAL

Extra: if you are using SAMBA 4 with the samba-tool to do this you will need to manually change userPrincipalName to (in this case): HTTP/ubuntu-ad.wad.eng.hytrust.com@WAD.ENG.HYTRUST.COM this is because the key tab generation of samba does not update the UPN and hence you will get an error when doing a lookup.

On a side note: an active directory machine name is COMPUTER$ (mark the $). Your's seems off.

Redhat – RHEL 5.8 Kerberos Active Directory Windows 2003 Server SP2

When using kinit with a keytab it in necessary to provide the principle you wish to authenticate as. This is probably because keytabs can contain more than one principle.

[root@dhcp2 ~]# kinit -k
kinit(v5): Cannot resolve network address for KDC in realm  while getting initial credentials
[root@dhcp2 ~]# kinit -k  host/dhcp2.domain.tld
[root@dhcp2 ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: host/dhcp2.domain.tld@DOMAIN.TLD

Valid starting     Expires            Service principal
07/29/12 19:27:49  07/30/12 07:27:49  krbtgt/DOMAIN.TLD@DOMAIN.TLD
        renew until 07/30/12 19:27:49


Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached

Best Answer

Related Solutions

Help using setspn and ktpass

Redhat – RHEL 5.8 Kerberos Active Directory Windows 2003 Server SP2

Related Topic