Hi,
I am trying to set up vMA and i am up to page 15 of the guide (http://www.vmware.com/support/developer/vima/vma41/doc/vma_41_guide.pdf).
Where it says to go to a windows PC and run this command
ktpass /out foo.keytab /princ foo@VMA-DC.ENG.VMWARE.COM /pass ca... /ptype KRB5_NT_PRINCIPAL -mapuser <vma-dc>\<foo>
replacing <vma-dc> with my domain and foo with the user with permission for the vCenter admin. My version, if i'm getting it correct, looks like this:
ktpass /out foo.keytab /princ foo@VMA-DC.ENG.VMWARE.COM /pass ca... /ptype KRB5_NT_PRINCIPAL -mapuser ampco.com.au\administrator
which returns
DsCrackNames returned 0x2 in the name entry for ampco.com.au\administrator.
and no file
any hints as to what i am doing wrong?
Thanks
Ian
Hi Ian,
This error code means that Ktpass was not able to find the user account. I found a few articles about this problem on the Net and proposed solutions were:
- use NetBIOS domain name, not its DNS name
- specify the username with double domain name, like : DOMAIN\DOMAIN.USERNAME
- specify the username with the "@" notation, like : USERNAME@DOMAINE
Hope it helps.
Regards
Franck
DsCrackNames returned 0x2 in the name entry for host_hostname
Application/Function: Attempt to use ktpass to map a service principal name to an Active Directory user name and generate a key table.
Potential Causes and Solution: Can indicate that the user account specified (host_hostname in this example) does not exist.
from MS
Thanks for the replies.
I modified the command to use my short domain name and ran it again. the command and results are below:
C:\temp>ktpass /out foo.keytab /princ foo@VMA-DC.ENG.VMWARE.COM /pass ca... /ptype KRB5_NT_PRINCIPAL -mapuser ampco0\administrator
Targeting domain controller: mail.ampco.com.au
Failed to set property "servicePrincipalName" to "foo" on Dn "CN=Administrator,CN=Users,DC=ampco,DC=com,DC=au": 0x13.
WARNING: Unable to set SPN mapping data.
If Administrator already has an SPN mapping installed for foo, this is no cause for concern.
Key created.
Output keytab to foo.keytab:
Keytab version: 0x502
keysize 51 foo@VMA-DC.ENG.VMWARE.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 2 etype 0x3
(DES-CBC-MD5) keylength 8 (0x0d8cbcc1b9ef269b)
Account Administrator has been set for DES-only encryption.
It made an output file but i don't know if it's correct due to the warnings above.
Also, am I supposed to change the foo@VMA-DC.ENG.VMWARE.COM to an address in my network? If yes, does the vMA server name have to be in the address?
i.e. should it be foo@vma.ampco.com.au or would foo@ampco.com.au be correct?
Thanks
Ian
From "vSphere Management Assistant Guide" on page 15:
"ktpass /out foo.keytab /princ foo@VMA-DC.ENG.VMWARE.COM /pass ca... /ptype KRB5_NT_PRINCIPAL -mapuser but not the first one. The Administrator account should already have an SPN. Try to use the certificate you created. If it doesn't work, try to use another account dedicated for that purpose.
Franck
Thanks,
I am trying to connect to the server with WinSCP as the guide says and when it asks for a username and password i give it vma-dc\foo as the username as listed in the guide and i have tried a blank password, the root password and every other password i can think of without luck.
The only user name and password i have managed to get in with was vi-admin and it's password but, then there is no /home/local/VMA-DC/foo folder and it will not let me make one.
Everything has worked up to joining and testing the domain. The very next step in the guide is the section on unatended authentication for AD on page 15 and then the guide is very vague.
If anyone can help with a string of commands that i can follow i would be grateful.
Thanks everyone
Ian
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.