Old post but stumbled on it while getting AD (and ktpass / kinit) to work with vMA 5.1.
One thing to point out after an afternoon reading on vMA and AD authentication.
1. If you use Server 2003 (why??) then make sure you have SP1 or ktpass doesn't work. Period.
2. I'm using W2K8R2 SP1 and - guess what? - ktpass failed for me also. But only if I used "-pass *" (prompt for password). In that case - the password is hashed *wrong*.
That second point led me to lots of "preauthentication errors" when running kinit on the vMA appliance. And it was all so avoidable - the VMware vMA instructions really should indicate example command lines and should definitely indicate that ktpass should have the "-pass [password]".
Also some points on capitalization would have been appreciated.
So for others, here is my ktpass call on Windows Server 2008 R2. Note that the domain is CAPITALIZED to match the "realm" entry in /etc/krb5.conf on the vMA appliance. Also notice that I capitalized the NetBIOS (short) mapping name (although that is not necessary):
<cut>
C:\Windows\System32>ktpass /out vmaproxy.keytab /princ vmaproxy@ARMYCLOUD.CLOUD.ARMY.MIL /ptype KRB5_NT_PRINCIPAL -mapuser ARMYCLOUD\vmaproxy -mapOp set -pass [real_honest_to_goodness_password]
Targeting domain controller: CLOUDAD001CD.armycloud.cloud.army.mil
Using legacy password setting method
Failed to set property 'servicePrincipalName' to 'vmaproxy' on Dn 'CN=vmaproxy,OU=VMware,OU=InternalAccounts,D
C=armycloud,DC=cloud,DC=army,DC=mil': 0x13.
WARNING: Unable to set SPN mapping data.
If vmaproxy already has an SPN mapping installed for vmaproxy, this is no cause for concern.
Key created.
Output keytab to vmaproxy.keytab:
Keytab version: 0x502
keysize 67 vmaproxy@ARMYCLOUD.CLOUD.ARMY.MIL ptype 1 (KRB5_NT_PRINCIPAL) vno 7 etype 0x17 (RC4-HMAC) keylength
16 ([hidden_you_will_see_hashcode])
</cut>
Do not worry about the SPN warnings...for this effort they are not important (SPN is for *services* like HTTP).
So I take the keytab file to vMA and run "klist" so I can verify the keytab contents:
<cut>
vmaxxxx002vt:~> klist -e -k -t -K ./vmaproxy.keytab
Keytab name: FILE:./vmaproxy.keytab
KVNO Timestamp Principal
---- ----------------- --------------------------------------------------------
7 01/01/70 00:00:00 vmaproxy@ARMYCLOUD.CLOUD.ARMY.MIL (ArcFour with HMAC/md5) ([hidden_you_will_see_hashcode])
</cut>
This tells me that user-principal name is my vMA proxy account and the realm is properly upper-cased.
Finally on the vMA appliance I can test the instructions from page 15 that have the hourly cron job to renew the Kerberos ticket for the AD user:
<cut>
vmaxxxx002vt:~> kinit -k -t ./vmaproxy.keytab vmaproxy
vmaxxxx002vt:~>
</cut>
Yup, that is success. When I used the "-pass *" option on ktpass (to force password prompt), I instead got "preauthentication failure" because the ktpass is not salting the entered password correctly. (As mentioned, this was a known problem for ktpass in general on W2K3 prior to SP1 and I suspect a variant of the same encryption problem exists in W2K8R2).
Cheers and good luck...vMA is now working nicely with AD authentication *and* the kinit to get new "ticket granting tickets" so that long-running automations will work as expected.