How to assign ESXi permissions to Windows AD user, to operate with VMware vMA?

Question

I follow the instruction in Official vMA Guide 5.1(pdf), and I'm baffled by the following operation(described in p18~p19).

I have joined my vMA to my Windows AD velab.chj , reboot vMA, then operate as follows:

As you can see, I cannot execute esxcli system version get with the identity of a Windows AD user(chjadmin). I think that's reasonable, because the ESXi host has not assign any permission to, or even does not know the existence of, the AD user chjadmin.

So, my question is, how to configure ESXi host to allow chjadmin's execution of the esxcli command? The official vMA guide does not seem to talk about this.

Answer 1

The vMA guide assumes you have already taken steps to join your ESXi host to your Active Directory and granted permissions that would allow the running of those commands.

The relevant documentation can be found here in the ESXi and vCenter Server 5.5 Documentation. Specifically in the section vSphere Security - Securing ESXi Hosts - Using Active Directory to Manage ESXi Users.

Answer 2

Thanks to Ryan's documentation hint. I find the correct direction.

First, I have to join my ESXi machine to Windows AD, which can be done via viclient.

Second, according to VMware vSphere's doc, I have to create an AD group named ESX Admins (no nonsense, you have to use this group name) and make chjadmin a member of it.

Now, I can execute esxcli with an AD user identity:

esxcli --server=172.27.120.147 -u chjadmin -p 123456 system version get

I confirm that the above command does not rely on the prerequisite of vifp addserver 172.27.120.147 .... and it executes quickly (in two seconds).

So far, so good.

HOWEVER, another problem exists. The vifp commands executes so slowly.

vifp addserver 172.27.120.147 --authpolicy adauth --username 'velab.chj\chjadmin' # costs 10 seconds
vifptarget -s 172.27.120.147  # cost 30+ seconds

How come they cost so long?

What's worse, before I execute vifptarget -c to quit the default ESXi target context , each press of Enter on the command line costs 20+ seconds. What happened inside?

I quickly realize there may be something cranky inside PS1. It turns out yes.

The command

LD_PRELOAD=`__get_ld_preload_without_vmalibs` /opt/vmware/vma/bin/vitargetquery.sh

executes for so long, 20+ seconds. Can someone help explain this?

BTW: My customized PS1 is(verbatim from Bash command line):

PS1="\n[\[\033[32m\]$(tty) \d \t\[\033[31m\] jobs:\j\[\033[0m\] "'ERR:$?$(if [ $? != 0 ];then echo -e \a; fi)] \n'"[\u @\h \[\033[33m\w\033[0m\]]\n\[\033[1;37;44m\]#\[\033[0m\] "

[Update] vifp commands execution slow problem solved

Reading the Bash source of /opt/vmware/vma/bin/vifptarget and /opt/vmware/vma/bin/vitargetquery.sh, I found that they both execute a real binary fastVmaTargetCheck like this /opt/vmware/vma/sbin/fastVmaTargetCheck 172.27.120.147 where most of the time is consumed.

Since I don't have the source code for fastVmaTargetCheck, I come up with the idea of packet sniffing the vMA machine, and finally reveal the cause. fastVmaTargetCheck 172.27.120.147 unconditionally issues a reverse DNS lookup for 172.27.120.147, with a roughly 12 second timeout, and my intranet DNS server did not have a reverse lookup zone so it forwarded the query to Internet DNS servers which also timeed out. The vifp commands do many times of such query so I saw the slow execution. The solution is, adding reverse lookup zone 120.27.172.in-addr.arpa to my DNS server so to give vMA an instant answer(no matter positive or negative) and the execution lag disappears.