vMA 4.1 error Failed to add users.

[Silverchenau]

hi, guys:

I have just installed a new vCenter 4.1 with 1 esxi 4.0u2 and 1 esxi 4.1.

I have downloaded vMA 4.1 and try to use AD auth to connect vCenter.

I have joined the vMA into domain and restarted vMA.

However, when I tried to add vCenter with --authpolicy adauth, it asked me to type in username for vCenter server.

I typed mydomain
myaccount

It gave me Error: Failed to add users

Can you tell me why?

Thanks alot

- Silver

My Vmware blog: http://geeksilverblog.com

[hmartin]

I believe you missed Silverchenau's point. I believe s/he's saying that when using adauth and setting the target to be a vCenter instance, anytime you run a command that uses --vihost (as you show in your blog), that unless the ESX host is joined to the domain, you will get prompted for username and password. I seem to be experiencing this as well.

Per the VM docs and your blog, the only systems required to be joined to the AD domain are the vCenter server and the vMA. If Silverchenau is right, then all hosts under vCenter also have to be joined to the domain if you want to use the --vihost param.

Silverchenau, did I get that right? Have you done any further testing?

[damiankarlson]

Heh. After taking some time off on this, I decided to look at it again today -- and I am still at a loss. I've got vCenter, VMA and an ESXi 4.1 host on the domain, and I still get prompted for username and password when executing an esxcfg command on the vihost that's on the domain. What am I doing wrong?

Details:

• vCenter, VMA and ESX4.1 host on the AD domain

• Verified forward and reverse DNS lookups for vCenter, VMA, and ESXi host

• Logged into VMA as vi-admin and set "sudo vifp addserver vCenter.domain.com --authpolicy adauth"; entered domain\adminusername when prompted

• Logged into VMA as domain\adminusername and set "vifptarget -s vCenter.domain.com", which completed successfully

• Executed "esxcfg-nics -l --vihost esxihost.domain.com and got prompted for username and password

I've rebooted VMA after joining it to AD, verified the computer account existed in AD, and received the expected results from "sudo domainjoin-cli query".

I've gotten the expected results from "sudo /opt/likewise/bin/lw-find-user-by-name adminusername -- level 2"

[lamw]

I'm curious, can you try to make the following change per this blog article - http://www.virtuallyghetto.com/2010/07/vma-41-active-directory-intergration.html

Wondering if the domain is assumed, if it would make a difference? To tell you truth, I've not had these issues but my configuration is slightly modified from the original Likewise configuration as I prefer not to type out the full domain each time I login to a host.

=========================================================================

William Lam

VMware vExpert 2009,2010

VMware scripts and resources at:

Twitter: @lamw

Getting Started with the vMA (tips/tricks)

Getting Started with the vSphere SDK for Perl

VMware Code Central - Scripts/Sample code for Developers and Administrators

VMware Developer Community

If you find this information useful, please award points for "correct" or "helpful".

[damiankarlson]

Logging in as domainadmin, domain\domainadmin, and domainadmin@domain.com make no difference. I still get prompted to enter credentials in order to perform a command on vihost.

Perhaps its time I open a service request.

[hmartin]

Nice tip - thanks. I tested this change, but it did not affect the behavior. I still get prompted for a username and password.

[lamw]

I think an SR with VMware will get us to the root caused. Looking forward to see what the resolution and behavior is

=========================================================================

William Lam

VMware vExpert 2009,2010

VMware scripts and resources at:

Twitter: @lamw

Getting Started with the vMA (tips/tricks)

Getting Started with the vSphere SDK for Perl

VMware Code Central - Scripts/Sample code for Developers and Administrators

VMware Developer Community

If you find this information useful, please award points for "correct" or "helpful".

[damiankarlson]

I opened one, and referenced this forum post. I didn't have the time to wait on hold, so I'll let you guys know what transpired after I talk to them.

[hmartin]

Great - look forward to hearing the results. Thanks.

[Silverchenau]

hi, Guys:

Thank you for spending time on this question. First of all, Silver is he, not she.

I have opened SR last week but clearly, vmware requires their lab to reproduce the issue. The case is still open and I haven't heard anything for a while.

I think I will give them a little bit push today if I have time.

To hmartin:

Yes, you are right about what I believe. Thanks

Please call me Silver, guys.

- Silver

My Vmware blog: http://geeksilverblog.com

[Silverchenau]

New Updates about this issue.

I just got call from Vmware Support and they admited this is a bug in the vMA 4.1.

They will try to fix this issue in the next release. I would like to thank William and damiankarlson for all the help and time on this case.

You guys rock!!

I will update this issue from my blog from now if you want to chase it more.

- Silver

My Vmware blog: http://geeksilverblog.com

[damiankarlson]

Silver -- Would you mind sharing your SR#, please? The tech I'm working with would like to view the SR.

[Silverchenau]

np.

Support Request ID: 1549765244

- Silver

My Vmware blog: http://geeksilverblog.com

[lamw]

Silver,

I actually had a few questions regarding the issue you're facing. I know that you mentioned VMware support said this maybe a bug, though in my test environment, I've not been able to reproduce the issue.

I ran the following test and was wondering if you had done something similar:

vCenter 4.1 - Is joined to our AD domain

ESX 4.1 - Not joined to AD

vMA 4.1 - Joined to AD using "Administrator" local account

I added vCenter into vMA's vifastpass using authpolicy "adauth" and using Administrator account and FQDN of vCenter server. I then login to vMA using a valid AD account that has the proper permission on vCenter and initialize the target by running "vifptarget -s " and was able to get the commands to work without having to provide any credentials. It was using the credentials of the user account I login to vMA which is my expectation.

I can confirm that running "vmware-cmd" definitely took longer as it sat there for about 10sec before it provided any output. It's interesting to note that you don't necessary need to have the actual ESX(i) host added to vCenter to get this working. It just depends on what you're connecting against, and since you can auth against vCenter, it should provide you access to the necessary host.

I also found that if I did not specify the FQDN of the --vihost entry, that I would get prompted for username and password. In my vCenter, I have the host added using the shortname, so it's not using vCenter to do the lookup, or it maybe but you need to specify FQDN.

I'm wondering if you've tried the following and if you've gotten similar results or still getting prompted for username/password.

=========================================================================

William Lam

VMware vExpert 2009,2010

VMware scripts and resources at:

Twitter: @lamw

Getting Started with the vMA (tips/tricks)

Getting Started with the vSphere SDK for Perl

VMware Code Central - Scripts/Sample code for Developers and Administrators

VMware Developer Community

If you find this information useful, please award points for "correct" or "helpful".

[Silverchenau]

hi, William:

Thank you for still taking interest in my case again. For your answer:

vCenter 4.1 - Is joined to our AD domain

ESX 4.1 - joined to AD

vMA 4.1 - Joined to AD using domain admin account.

All servers name are FQDN no exception

Login vMA 4.1 with domain/account and vMA vi-admin(there are no difference on result).

run vifp listservers -l

There are 1 vCenter and 1 ESXi, all use adauth

vifptarget -s vCenter_FQDN

vmware-cmd -l --vihost ESXi_FQDn

require username password: domain admin

result prints.

vmware-cmd -l

require username password: domain admin

result prints.

Does this help you?

- Silver

My Vmware blog: http://geeksilverblog.com

[lamw]

Interesting, yea no matter how hard I try, I'm unable to reproduce the issue. I'm able to get the correct behavior everytime when I connect to vCenter and the ESX host does not necessary have to be under AD, as the passthrough is happening at the vCenter level.

I'm assuming the account you're using has full access to your vCenter system, but have you tried the local administrator account and seeing if you get the same results? I guess at this point, we may just need wait on your case to see what the issue is. I'll be very surprised if this turns out to be a major bug as I would expect this feature to be tested thoroughly.

=========================================================================

William Lam

VMware vExpert 2009,2010

VMware scripts and resources at:

Twitter: @lamw

Getting Started with the vMA (tips/tricks)

Getting Started with the vSphere SDK for Perl

VMware Code Central - Scripts/Sample code for Developers and Administrators

VMware Developer Community

If you find this information useful, please award points for "correct" or "helpful".

[Silverchenau]

Not working either. Just try to use vCenter local administrator to connect, still crying at second time.

But that's not the point cause adauth should use ad account to authenticate rather than local admin.

Anyway, I guess we just leave it to developers.....

- Silver

My Vmware blog: http://geeksilverblog.com

[lamw]

But that's not the point cause adauth should use ad account to authenticate rather than local admin.

I know, but I'm trying to see if this is with a specific user you're using to add the system to AD domain that is causing the problem. I've tried both using a domain admin account and local admin account to add vMA to AD. Both work for me when using a valid AD account to login to vMA and adauth works as expected.

I will be pretty floored if this is a bug, I'm wondering if its a specific corner case or environment specific. I've also pinged the vMA PM to see if he can shed more light on the issue.

Look forward to hearing the final resolution

=========================================================================

William Lam

VMware vExpert 2009,2010

VMware scripts and resources at:

Twitter: @lamw

Getting Started with the vMA (tips/tricks)

Getting Started with the vSphere SDK for Perl

VMware Code Central - Scripts/Sample code for Developers and Administrators

VMware Developer Community

If you find this information useful, please award points for "correct" or "helpful".

[Dave_Mishchenko]

I can confirm that it works as William describes. I had some flakiness earlier today and was prompted, but after a reboot of everything it's working as prescribed. Just to clarify a few things

- the ESXi does not have to be an AD member if you're going through vCenter. Once you authenticate with vCenter then it uses vpxuser to get that info from ESXi.

- if you're logging in with vi-admin then you have to enable kerberos ticketing. It's mentioned on William's site, but I didn't see that mentioned above.

[vmproteau]

Maybe there has been an update to this by now but, I haven't found one. I understand that VMware has stated this is a bug but, I wanted to go ahead an share my experience because I have recently had success and failure using adauth on the same VMA server suggesting an intermittent flakiness.

I recently rebuilt 20 ESX hosts to ESX 4.1 (320137). I had already added my VMA server to my Domain. This is the order of steps with regards to Hosts and VMA:

1. Added Host to AD Domain via VIC
   
2. Logged directly into the Host via VIC to verify access with 'Domain\username' credentials
   
3. Added Host to VMA
   
   • Login to VMA with 'Domain\username'
     
   • sudo vifp addserver 'hostname FQDN' --authpolicy adauth
     
   • promted for username (entered 'Domain\username')
     
4. I set the target to the newly added Host with vifptarget -s 'hostname FQDN'
   
5. Tested command esxcfg-vswitch -l
   

The 20 Hosts were rebuilt over a week and all 20 worked as designed. Once setting the target, I could run commands at will never prompted for credentials. Cut to 60 days later. We have some lease replacements. My decommision process was:

1. Isolate Host
   
2. Remove from VMA sudo vifp removeserver 'hostname FQDN'
   
3. Remove from AD Domain via VIC
   
4. Manually remove Host Server object from AD
   
5. Remove from vCenter and Powerdown
   

Racked and rebuilt replacement Host in the same spot reusing name, IPs, cables, etc. and followed the exact same build as 60 days ago. This time after adding the Host to VMA and testing esxcfg-vswitch -l, I was prompted for a username and password. A check verified the other Hosts continued to work without a credentials prompt.

I went through the various steps of rebooting everything involved, removing from the Domain, adding the Host to VMA with both vi-admin and with my Domain credentials but, each time the result was the same. Removed and readded the Host several times with no change.The day after I decided to try again. This time I decided to do it a bit differently and use the username switch:

1. Logged into VMA with vi-admin
   
2. vifp addserver dmspesxa15.dmsp.pvt --authpolicy adauth --username 'Domain\\username'
   
   • NOTE: extra slash is escape character not a typo
     
3. Tested esxcfg-vswitch -l and now I am not prompted for username and password.
   

I can't verify whether this was just a timing thing, the different command syntax, or something random but, I have 2 other lease replacements to do. I will see if I can duplicate these results and post my findings.

[vmproteau]

Update: Unfortunately no problems with the remaining 2 lease replacements. They both functioned exactly as the original 20 builds. Once added to VMA and setting the Host as target no usename/password prompts. I can't offer an explanation foir that one problem Host but, in my environment that is the only one I've ever had an issue with. At this point, I'd assume it was something I did differently.