WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
    • VMware Cloud Foundation 9.1
    • VMware Cloud Foundation 9.0
  • VKS
  • Homelab
    • Hardware Options
    • Hardware Reviews
    • Lab Deployment Scripts
    • Nested Virtualization
    • Homelab Podcasts
  • VMware Nostalgia
  • Apple

resxtop & vi-fastpass Downgraded Feature In vMA 4.1

07.19.2010 by William Lam // 4 Comments

For those that use VMware's vMA vi-fastpass authentication (vifpinit which is now vifptarget) which allows a user to perform an operation on an ESX(i) or vCenter host without having to provide credentials each time, may notice a change with the resxtop command. In vMA 4.0, if you initialized a fastpass target you could run resxtop against the host without having to provide additional credentials to the host.

In vMA 4.1, this functionality has actually been downgraded, that is right, a feature de-enhancement.

As you can see, even if you have initialized a fastpass target, you will need to specify both the username and password each time you call resxtop. resxtop only supports manual credentials and does not support other types of authentication mechanisms such as a configuration file, session file or passthrough auth. This can definitely slow things down if you are trying to troubleshoot multiple hosts and want to switch between them utilizing the fastpass authentication.

What is actually more interesting is this seems to be a feature that has been in the works over the 3 major releases of vMA, which was formally known as VIMA. Let's take a trip down memory lane regarding this feature in the vMA/VIMA release notes:

VIMA 1.0 - Oct 27, 2008 - Feature not supported and marked as a known issue.

vMA 4.0 - May 21, 2009 - Feature supported but may run into an issue with non-fastpass targets which has been resolved in this release.

vMA 4.1 - July 13, 2010 - Feature has been removed, requires both --username and --password each time.

 
Even though I consider this a bug, VMware did document this change as a "known issue" in the release notes. I am not sure if this feature will be resolved in a future release, but it just seems odd that we are taking one step backwards in terms of functionality.

Categories // Uncategorized Tags // resxtop, vma, vSphere 4.1

vMA 4.1 - Active Directory IntegrationTip

07.18.2010 by William Lam // 6 Comments

The latest release of vMA 4.1 now supports Active Directory integration which can be used to centralize all authentication within a Windows environment. To join a vMA host to your Active Directory domain, you just need to use one simple command called domainjoin-cli which is part of Likewise's "Open" product.

Here is an example of vMA host joining an AD domain:

By default, Likewise "Open" is configured to not assume the current Active Directory Domain as the default. This means if you are authenticating against vMA via SSH connection, you will need to specify both the username and the full domain. (e.g. ssh *protected email*@vMA-host)

Here is an example of logging into vMA using AD credentials:

This can be pretty tedious to type out everytime, especially if you have a very long domain name. However, this can be easily modified to assume the default domain.

You will need to edit /etc/likewise/lsassd.conf and uncomment "assume-default-domain = yes" and then save your changes:

sudo vi /etc/likewise/lsassd.conf

You will need to reload the configurations for the changes to take effect by running the following utility:

sudo /opt/likewise/bin/lw-refresh-configuration

Now, you can login by just specifying the username without having to provide the full AD domain name.

I actually wrote an article about a month ago on configuring Likewise "Open" AD intergration on vMA before the release of vSphere 4.1. The article goes through the process of setting up "Open" on vMA 4.0 and also documents the change of the default domain. For more Likewise commands and details, check out the article above.

Update1:
If you would like to add an AD group to sudoers file, you need to edit /etc/sudoers file. You need to make sure you escape the initial forward slash and any white spaces that maybe in the group name. In this example, we have a group called "VI Admins" that you would like all users to be able to login to vMA using their AD credentials and perform operations using sudo.

1. Edit /etc/sudoers using vi-admin account, make sure you use 'sudo':

[vi-admin@kate ~]$ sudo vi /etc/sudoers

2. Add the following towards the bottom of the file:

%PRIMP-IND\\VI\ Admins ALL=(ALL) ALL

Note: We're escaping both the initial forward slash and the space

3. Verify user can now sudo by querying sudo operatoins the user is allowed to execute:

[primp@kate ~]$ id
uid=1058014289(primp) gid=1058013696(domain^admins) groups=1058013696(domain^admins),1058014440(vi^admins)

[primp@kate ~]$ sudo -l
Password:
User primp may run the following commands on this host:
(ALL) ALL

Categories // Uncategorized Tags // vma, vSphere 4.1

How to configure Likewise "Open" AD intergration on vMA

07.01.2010 by William Lam // 10 Comments

I recently received a question about whether it was possible to configure Active Directory integration with vMA. Out of the box, this is not a feature that is available by default but can be set up. There are many articles online that provide instructions on configuring AD integration on UNIX/Linux host but they may not always be as straight forward to implement.

[Read more...]

Categories // Uncategorized Tags // active directory, likewise, vma

  • « Previous Page
  • 1
  • …
  • 3
  • 4
  • 5
  • 6
  • 7
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • VCF 9.1.1 - Connecting Pi Coding Agent to VCF Private AI Services (PAIS) 09/17/2026
  • Quick Tip - Automating vDefend Security Services Platform (SSP) 5.2.0 Installer OVA Deployment 09/16/2026
  • VCF 9.1.1 - Simplified vSphere Kubernetes Service (VKS) using VLAN-Backed VPCs without NSX Tunnel Endpoints (TEPs) 09/15/2026
  • VCF 9.1.1 - Using VCF Private AI Services (PAIS) Models with AI Assistant for VCF 09/11/2026
  • VCF 9.1.1 - Deploying Your Own AI Models with VCF Private AI Services (PAIS) 3.0 09/10/2026
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.

To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2026