Como atribuir permissões do ESXi ao usuário do Windows AD, para operar com o VMware vMA?

Question

Eu sigo as instruções em Guia oficial do vMA 5.1 (pdf) , e estou confuso com a seguinte operação (descrita em p18 ~ p19).

EuparticipeidomeuvMAnomeuvelab.chjdoWindowsAD,reinicializeovMAeoperedaseguinteforma:

Como você pode ver, não consigo executar esxcli system version get com a identidade de um usuário do Windows AD (chjadmin). Eu acho que isso é razoável, porque o host ESXi não atribuiu nenhuma permissão ou até mesmo não sabe a existência do chjadmin do usuário do AD.

Então, minha pergunta é, como configurar o host ESXi para permitir a execução do comando esxcli do chjadmin? O guia oficial do vMA parece não falar sobre isso.

    

Answer 1

O guia vMA assume que você já tomou as medidas para unir seu host ESXi ao seu Active Directory e recebeu permissões que permitiriam a execução desses comandos.

A documentação relevante pode ser encontrada aqui na documentação do ESXi e vCenter Server 5.5. Especificamente na seção Segurança do vSphere - Protegendo hosts do ESXi - Usando o Active Directory para gerenciar usuários do ESXi .

    

Answer 2

Graças à dica de documentação do Ryan. Eu acho a direção correta.

Primeiro, tenho que juntar minha máquina ESXi ao Windows AD, o que pode ser feito via viclient.

Segundo, de acordo com o documento do VMware vSphere, tenho que criar um grupo AD denominado ESX Admins (sem absurdo, você precisa usar esse nome de grupo) e tornar o chjadmin um membro dele.

Agora, posso executar esxcli com uma identidade de usuário AD:

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

Confirmo que o comando acima não depende do pré-requisito de vifp addserver 172.27.120.147 .... e é executado rapidamente (em dois segundos).

Até agora, tudo bem.

No entanto, existe outro problema. Os comandos vifp são executados tão lentamente.

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

Como eles custam tanto tempo?

O que é pior, antes de eu executar vifptarget -c para sair do contexto alvo padrão do ESXi , cada pressionamento de Enter na linha de comando custa 20+ segundos. O que aconteceu dentro?

EurapidamenteperceboquepodehaveralgoesquisitodentrodoPS1.Acontecesim.

O comando

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

é executado por mais de 20 segundos. Alguém pode ajudar a explicar isso?

BTW: Meu PS1 personalizado é (literalmente da linha de comando Bash):

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

[Update] vifp comandos execução lenta problema resolvido

Lendo a fonte de Bash de /opt/vmware/vma/bin/vifptarget e /opt/vmware/vma/bin/vitargetquery.sh , descobri que ambos executam um binário real fastVmaTargetCheck , como este /opt/vmware/vma/sbin/fastVmaTargetCheck 172.27.120.147 , onde a maior parte do tempo é consumido.

Como eu não tenho o código-fonte para fastVmaTargetCheck , tenho a idéia de pacotes cheirando a máquina vMA e, finalmente, revelar a causa. fastVmaTargetCheck 172.27.120.147 emite incondicionalmente uma pesquisa reversa de DNS para 172.27.120.147, com um tempo limite de aproximadamente 12 segundos, e meu servidor DNS da intranet não tinha uma zona de pesquisa inversa, então ela encaminhava a consulta para os servidores DNS da Internet que também expiravam. Os comandos vifp fazem muitas vezes essa consulta, então eu vi a execução lenta. A solução é adicionar a zona de pesquisa reversa 120.27.172.in-addr.arpa ao meu servidor DNS, para dar uma resposta instantânea ao VMA (não importa se é positivo ou negativo) e o atraso na execução desaparece.