User Account Troubleshooting - VMware Third Party Applications

Information

Title: 

User Account Troubleshooting - VMware Third Party Applications

Author(s): 

Xtravirt (Paul Buckle, Jason Miles)

Target Audience: 

Technical - Intermediate

First Published: 

22 January 2009

Products: 

VMware ESX 3.x, Vizioncore vRanger, vReplicator

UID: 

XD10002

A hot tip on how to troubleshoot specific authentication errors for 3rd party VMware ESX applications and a case study on Vizioncore vRanger and vReplicator products.

To root or not to root, that is the question

Overview

Some 3rd party applications such as Vizioncore vRanger Pro and vReplicator require root-level access to the ESX Service Console (SC) to perform their job function, whether backup, migration, replication etc. Best practice is to set up a dedicated account with shell access to perform these management functions. The application then logs on as this regular user (not directly as root) and switches user (su) to root to issue administrative commands.

In the case of the vRanger Pro and vReplicator, an in-built feature of the installation/configuration routine is to create this dedicated account. However, this part of the installation routine can fail if the default security context of a host’s SC has been hardened. See Figure 1-1, “unable to connect to host” and Figure 1-2, “Host not added, user root could not be authenticated”.

Figure 1-1

This issue is not limited to Vizioncore products, other 3rd party products can be similarly affected, such that any product which requires root-level access permissions to the SC in order to achieve their management function must conform to the security context of the host, ie: by design, access to the su commands can be restricted by design to a specific ESX user group (typically wheel).

Figure 1-2

2.0 Solution

If access has been restricted, vRanger Pro and vReplicator may successfully create their management account on the host but will fail to validate its elevated privilege levels as shown in the screenshots above.

In this case, the solution is to determine if the designated account has the appropriate permissions on the host. To check or edit the group memberships and confirm if su to root has been restricted, follow these steps:

1. Open a SSH session to the ESX host
2. Then check to see if su to root privileges have been restricted to the wheel group by viewing the file /etc/pam.d/su with command:
3. cat /etc/pam.d/su
4. Now check the following line:
5. # Uncomment the following line to require a user to be in the “wheel” group
6. auth required /lib/security/pam_wheel.so use_uid
7. By default, the line will be commented, with no restrictions for which accounts are able to su to root. If the line is uncommented however, su to root privileges have been restricted to the wheel group only, typically due to post deployment security hardening.
8. In this scenario, if the line is uncommented then the Vizioncore management account must be added to the wheel group. To add the account to the wheel group, issue command:
9. usermod -G wheel
10. Log off SSH session

3.0 Conclusion

Without correct root-level access, the above authentication errors can appear, demonstrating a failed connection attempt.

When electing to create a non-root account, keep in mind this account must be also added to a group with su privileges. Users in the wheel group (a root-level access group) can issue su commands, so can be the solution in these circumstances.

References

References: 

1. Nil

Links: 

1. Nil