(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.
Make sure your configuration follows a simple setup described here: https://www.redhat.com/archives/freeipa-users/2013-June/msg00064.html
Ok, since I made that simple setup after verifying it works on RHEL 6.x and Fedora 18, I wish you had specified more details to help you.
Here is my working example with Fedora 19 (test sudo packages with RHEL 6.5 fixes forward ported):
[root@id ~]# nisdomainname
example.com
[root@id ~]# sudo -U admin -l
Matching Defaults entries for admin on this host:
requiretty, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR
LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME
LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
User admin may run the following commands on this host:
(root) /usr/bin/bash
[root@id ~]# LANG=en_US.utf8 ipa sudorule-show admins --all
dn: ipaUniqueID=83814998-68c1-11e3-a7ad-001a4a418612,cn=sudorules,cn=sudo,dc=example,dc=com
Rule name: admins
Enabled: TRUE
User Groups: admins
Hosts: id.example.com
Sudo Allow Commands: /usr/bin/bash
RunAs External User: root
ipauniqueid: 83814998-68c1-11e3-a7ad-001a4a418612
objectclass: ipaassociation, ipasudorule
[root@id ~]# su - admin
[admin@id ~]$ sudo /usr/bin/bash
[sudo] password for admin:
[root@id admin]# exit
[admin@id ~]$
Do you have nisdomainname defined?
Best Answer
Which SSH authentication method are you using? Are you typing in your password, or trying to use Kerberos ticket-based authentication (gssapi-with-mic or gssapi-keyex)?
The “decrypt integrity check failed” message could come from two sources. If you give it the wrong password (your password doesn’t match the keys for your principal in the KDC), you’d get that. You’d also get it if your password is fine, but the keytab on the server is out of date; this would happen with both ticket and password authentication (because with a password, the server obtains a ticket for its own host principal after doing kinit, to authenticate the KDC).
The keytab on the client is irrelevant; it’s not part of this scenario. The likely problem here is that the keytab on the server is out of sync with the KDC (the Kerberos authentication server, or "Key Distribution Center," which is part of FreeIPA). With Kerberos, all identities (or "principals") in the system have keys they share with the KDC. A user’s keys are generated from his password. The keys for a software service like sshd are randomly generated, and stored in a file called a keytab (for "key table") so the service can access them. This sounds like the keys for the SSH principal have been changed in the KDC, but the keytab hasn’t been updated to match. Your principal name is of the form user@REALM. The principal name for the SSH service is of the form host/hostname@REALM. Try:
... to extract the current keys for the SSH service principal into a new keytab. You can use
klist -ek <keytab>to view the contents of the old and new keytabs. If you have a key mismatch, it should show up as the keys for the same principal having different key version numbers (or “kvno”). You might see something like: