Creating a keytab to use with kinit in Windows

Question

I am writing a pGina plugin to get AFS Tokens and a Kerberos TGT from our KDC at login, while writing I noticed a 'feature' of kinit being that it wont let you provide any input unless its from the keyboard, there went my idea of just redirecting the standard input...

Someone suggested using a keytab file for the principal, which seemed super easy, until I realized I'd only used kutil on linux and am having difficulties with the Windows version of that which is ktpass.exe. I have tried repeatedly with a large number of combinations of arguments to create a keytab but have had absolutely no success so far, the current command I am issuing is:

ktpass /out key.tab /mapuser [email protected] /princ [email protected] /crypto RC4-HMAC-NT /ptype KRB5_NT_PRINCIPAL /pass mahpasswordlol /target MERP.EDU

Unfortunately all this outputs is

Using legacy password setting method

FAIL: ldap_bind_s failed: 0x31

Which according to my research is a authentication/crypto problem, I have tried it with the other DES settings but this also doesn't seem to work... anyone have any experience/ideas on how this might work?

Rale

DES is disabled by default in Windows 2008 R2 Active Directory and above. This may have been the issue on that particular front back then when you tried it. – Balladist

Answer 1

ktpass.exe is indeed awful; I don't use it. Instead, just use ktutil on Unix to create a matching keytab independently using the password, e.g.:

$ ktutil
ktutil:  addent -password -p foo@BAR -k 1 -e aes128-cts-hmac-sha1-96
Password for foo@BAR:
ktutil:  l
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    1                                  foo@BAR
ktutil:  wkt /tmp/zz
$ klist -ek /tmp/zz
Keytab name: WRFILE:/tmp/zz
KVNO Principal
---- --------------------------------------------------------------------------
   1 foo@BAR (aes128-cts-hmac-sha1-96)

The LDAP bind error indicates that ktpass can't authenticate you to the domain controller; are you logged into a domain account when this happens? It has to be a domain account, rather than a local one (and it must be authorized to make the necessary changes to AD, though lacking just that would give a permission error rather than bind).

FWIW, we take a different approach to this: we use cross-realm trust between our Unix and AD realms. The AD TGT the user gets upon logging in is then sufficient to acquire credentials for services in the Unix realm as well; e.g., I can use PuTTY to SSH into a Unix host, Firefox/Chrome/IE to authenticate to Unix web services (Apache/mod_auth_kerb), etc.

Ell

When you use cross trust, do you overlap UNIX and WINDOWS DNS names or have you setup a subdomain to enclose your UNIX hosts? – Scraper

Ours overlap; that is to say, there is no simple rule that can distinguish the names of hosts in the two realms. However, I recommend using non-overlapping domains for each if that’s feasible, e.g. *.WIN.FOO.COM and *.UNIX.FOO.COM; our mixed setup is the result of legacy infrastructure that we can’t change now. The mixed setup requires a fair amount of complexity in the form of referrals and/or static domain/realm configuration on both sides, in order to ensure that all ticket requests get to the right place. I used distinct domains in a brand-new deployment recently, to avoid all that. – Ell