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 user$@MERP.EDU /princ user.merp.edu@MERP.EDU /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?

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.