vSphere – Page 104

Monitoring vCenter SSO User Account Expiration

01.29.2013 by William Lam // 2 Comments

Did you know that user accounts created in the vCenter SSO Server automatically expire by default after 365 days? If you do not update your password prior to the expiration date, in about a years time you could potentially be locked out of your vCenter SSO Server which also applies to the admin@system-domain account.

You can change the default password expiration policy by logging into the vSphere Web Client with an SSO Administrator account. Under the configuration section of "Sign-On and Discovery", there is a Password Policies tab that allows you can modify password policies. By default, this is set to 365 days. I would also recommend that after you have installed and setup your vCenter SSO Server, you add at least one user or group from your directory service such as Active Directory and assign it to the SSO Administrator group. This will ensure that you can still log in to the SSO configuration in the event the local SSO user accounts are locked out.

Even though you can change the password expiration policy, there is still no automated notification or alerting built-in for user accounts that are going to expire. The best you can do is to create a calendar event to remind you update your passwords prior to the expiration date. I am sure that many of you are anxious to add another color event to your already busy schedule 🙂

While investigating alternative options a few weeks back, the only method that I have found to retrieve the status for each SSO user is to directly connect to the vCenter SSO Database. There are two specific tables of interest, one which provides the current password policy and the other providing the last password changed date for each SSO user:

ims_authn_password_policy
ims_principal_data

Disclaimer: This "may" not be officially supported by VMware.

Instead of having you manually dig around in the SSO Database, I have created a Perl script called getSSOUserExpiration.pl which can connect to either a MSSQL or vPostgress backend SSO database. The script which will automatically list out the current password policy as well as user accounts that will be expiring in N days, where N is input provided by the user. You also have the ability to configure the script to automatically email you the results which is nice for a daily or weekly report and can be setup using a cronjob or a scheduled task. There are several configuration variables that will need to be adjusted based on your environment and these are all located within the script itself. For more details on how to setup and use the script, please take a look at the Setup and Configuration section below.

Note: To reduce any negative impact to the vCenter SSO Database, you should add or ask your DBA's to create a limited read-only account and limit access to the following tables above. You may even be able to have your DBA's create a scheduled routine for the specific queries and have that emailed to you internally.

Here is a screenshot of connecting to a vPostgres backend Database:

Here is a screenshot of connecting to a MSSQL backend database:

Here is a screenshot of what the email report looks like:

Note: The email body should contain the specific vCenter SSO Database, but I am not sure why it is not showing up in Gmail, but it does work for other email clients.

Setup and Configuration

vPostgres

To connect to a vPostgres DB, you will need to install the following two perl packages: perl-DBI and perl-DBD-Pg. In this example, I am using the vMA appliance and the zypper package installer. For more details on how to add a SLES repo, please take a look at the following article. I also assume if you are connecting to a vPostgres DB, then you are using the VCSA (vCenter Server Appliance) and by default it does not accept remote connections. We will need to also make two configuration changes to the VCSA for our script to be able to connect to the database.

Step 1 - Run the following two commands to install both perl packages:

sudo zypper in perl-DBI
sudo zypper in perl-DBD-Pg

Step 2 - SSH into your VCSA and in the following configuration file /storage/db/vpostgres/pg_hba.conf you will need to add the network in which you will be connecting from:

host all all 172.30.0.0/24 trust

Step 3 - SSH into your VCSA and in the following configuration file /storage/db/vpostgres/postgresql.conf you will need to add the IP Address(s) that you want vPostgres to listen for remote connection. If you use "*", it will allow all addressees:

listen_addresses = '*'

Step 4 - For the changes to go into effect, you will need to restart the vPostgres DB by running the following command:

service vmware-vpostgres restart

Step 5 - Modify the getSSOUserExpiration.pl script and provide the credentials to your vCenter SSO DB. If you need help in identifying the vCenter SSO DB credentials, please refer to this article for the details.

MSSQL

To connect to an MSSQL DB, there are a few additional steps and packages that will be required. We will be using FreeTDS which provides libraries to connect to an MSSQL DB for UNIX/Linux platforms. There was a bit of trial and error in getting the MSSQL solution working and I would like to thank Reuben Stump for his assistance. The following article was used as a reference for the setup below.

Step 1 - Run the following two commands to install the required packages:

sudo zypper in perl-DBI
sudo zypper in gcc

Step 2 - Download and extract the contents of the FreeTDS package:

wget ftp://ftp.astron.com/pub/freetds/stable/freetds-stable.tgz
tar -zxvf freetds-stable.tgz
cd freetds-0.91

Step 3 - Compile and install FreeTDS under /usr/local/freetds:

export SYBASE=/usr/local/freetds/
./configure --prefix=/usr/local/freetds
make
sudo make install

Step 4 - Add your vCenter SSO Server details into the FreeTDS configuration file located in /usr/local/freetds/etc/freetds.conf

[sso]
host = 172.30.0.239
port = 1433
tds version = 7.0

In the example above, I named my database entry "sso" but you can use any name and this will be referenced when editing the script in step 5.

Step 5 - Modify the getSSOUserExpiration.pl script and provide the credentials to your vCenter SSO DB.

Blocking vSphere C# Client Logins

12.10.2012 by William Lam // 8 Comments

I recently picked up on this neat little tidbit from Mr. Not Supported aka Randy Keener, where you can block a user from logging into the vCenter Server using the vSphere C# Client. Other than playing a prank on your co-workers, you might be wondering is there a use case for this? Surprisingly, this is a request I have heard from a few customers in the past where they would like to block their users from using the vSphere C# Client in favor of leveraging only the vSphere APIs for routine tasks.

Since the vSphere C# Client also uses the vSphere API itself, a user with proper credentials to the vSphere environment can easily download the client from an alternative source and still login. Of course, there are ways of preventing this such as restricting application installation on end users desktop but there is some amount of management overhead of identifying those existing and new users, especially if access is delegated out to other teams.

There is a very simple solution if you choose to block ALL users from using the vSphere C# Client which requires a tiny modification on the vCenter Server itself and it takes effect immediately with no service restarts.

Disclaimer: This is probably not officially supported by VMware, use at your own risk.

Windows: C:\ProgramData\VMware\VMware VirtualCenter\docRoot\client
VCSA: /etc/vmware-vpx/docRoot/client

There is parameter called exactVersion which will be set to current supported version of the vSphere C# Client which should also match the version of your vCenter Server. You just need to change this to some other value that you know will not exist in your environment such as 9.0.0. Once you have made this change, now when a user tries to connect and there is a miss-match in the version, the vCenter Server will provide you with a download to the vSphere C# Client located on the server as it normally would if you did not have the latest client.

What the user will find out shortly, is that this will continue in an infinite loop even after installing the proper vSphere C# Client. The reason for this is that the number in version.txt will never match the vSphere C# Client and vCenter Server will just continue serving the installer in an infinite loop. I also looked into this trick for a standalone ESXi host and you can do the same by editing a file called clients.xml which is located in /usr/lib/vmware/hostd/docroot/client and users will not be able to login to the ESXi host using the vSphere C# Client.

Now, even though this prevents users from logging into the vSphere C# Client, users will still be able to connect using the vSphere API which includes the use of vCLI/ESXCLI, PowerCLI, vCO, SDKs, etc. and the use of the vSphere Web Client for either vSphere 5.0 or 5.1 will continue to work. Ideally, it would be nice to be able to control this access on a per user/group basis and perhaps even specify how a user can connect whether that is through the use of the APIs or UI only. Is this even useful to have at all? Would love to hear your comments.

For now, if you want users to get familiar with the new vSphere Web Client 5.1 ... this is one way of "encouraging" them 😉

Configuring Additional VCSA 5.1 as vSphere Web Client Servers

09.24.2012 by William Lam // 6 Comments

In my previous article, I showed you how to configure additional vSphere Web Client 5.1 Servers for a Windows environment. For those interested in using the VCSA (vCenter Server Appliance) instead to configure additional vSphere Web Client Servers, here is the process.

Disclaimer: This is for educational purposes only, this is not officially supported by VMware. Please test this in a development environment before using it on actual systems.

Before getting started, it is very important to ensure you have proper DNS resolution (forward / reverse working) on all your VCSA's.

Step 1 - You will need to know the IP Address or hostname of your vCenter SSO Server (If you are using the VCSA, then it is the same address as your vCenter Server). Next, deploy a brand new VCSA and go ahead and configure the IP Address, hostname, etc. in preparation for the next step.

Step 2 - Create a script called configureVCSAvSphereWebClientStandalone.sh (this script reside on the new VCSA itself or on a remote host) which contains the following

#!/bin/bash
# William Lam
# www.virtuallyghetto.com

# User Configurations

VCENTER_SSO_IPADDRESS=172.30.0.181

## DO NOT EDIT BEYOND HERE ##

echo "Adding Lookup Service URL to /etc/vmware/ls_url.txt & /etc/vmware-sso/ls_url.txt"
echo "https://${VCENTER_SSO_IPADDRESS}:7444/lookupservice/sdk" > /etc/vmware/ls_url.txt;echo "https://${VCENTER_SSO_IPADDRESS}:7444/lookupservice/sdk" > /etc/vmware-sso/ls_url.txt;

echo "Retrieving ${VCENTER_SSO_IPADDRESS} SSL Certificate"
echo "" | openssl s_client -connect ${VCENTER_SSO_IPADDRESS}:7444 2> /dev/null 1> /tmp/cert

echo "Storing ${VCENTER_SSO_IPADDRESS} SSL Certificate in /etc/ssl/certs/VMware-Lookup-Service-Root-CA.pem"
openssl x509 -in /tmp/cert > /etc/ssl/certs/VMware-Lookup-Service-Root-CA.pem

echo "Registering vSphere Web Client with ${VCENTER_SSO_IPADDRESS}"
/usr/lib/vmware-vsphere-client/vsphere-client-sso-hook install --ls-server https://${VCENTER_SSO_IPADDRESS}:7444/lookupservice/sdk --user root --password vmware

You will need to change the VCENTER_SSO_IPADDRESS variable to the address of your vCenter SSO Server.

Step 3 - Set the script to executable by running the following command:

chmod +x configureVCSAvSphereWebClientStandalone.sh

Step 4 - You can either execute the script locally on the VCSA or my preferred method is just to execute it remotely by running the following command:

ssh [email protected] < configureVCSAvSphereWebClientStandalone.sh

Note: Make sure to replace the IP Address with address of your VCSA

As part of the configuration, the vSphere Web Client service will automatically start up at the very end. Once the service has successfully started, you will be able to connect to the vSphere Web Client URL by going to https://[webclient-hostname-ip]:9443/vsphere-client and you now should be able to see all the vCenter Servers that have registered with the same vCenter SSO server.

Here is another view using the new VIN 1.2 (vSphere Infrastructure Navigator) to show that I have two vSphere Web Client servers (webclient1 and webclient2) registered to my primary vCenter SSO Server (vcenter51-1) as well as two additional vCenter Server (vcenter51-2 and vcenter51-3) that are also registered with the same SSO Server.

As you can see, if you need to add additional vSphere Web Client Servers, the VCSA can easily be configured to enable only this feature to help you scale out and provide additional capacity as well as redundancy. Stay tuned for some more details on configuring a Load Balancer to load balance multiple vSphere Web Client Servers.

Additional Resources: