Protecting and securing VMware vCenter Server (formerly known as VirtualCenter) is important, as it has full access to all of the host virtual machines that it manages. You may have taken some steps to protect vCenter from unauthorized users, but there are two areas that many system administrators might have overlooked. VCenter has two important integration components: its database, which stores its configuration data, and Active Directory, which authenticates users. If these two components are not properly secured, someone can use them to gain access to your environment.
Protecting the vCenter Server database
The vCenter database is where configuration and other data is stored. This includes roles, permissions, events, tasks, performance data, data center/cluster/resource pool information and much more.
If you connect to the SQL Server database with an SQL utility and look at the vCenter database, you will see many tables that are used by vCenter. Many of them start with VPX. The VPX_ACCESS table is where the access information for vCenter is stored. It has the following columns (fields): ID, PRINCIPAL, ROLE_ID, ENTITY_ID and FLAG. If we type in a simple SQL query we can see what is contained in that table. For example, the following query:
Will return results similar to this:
[TABLE]
Let's go over what these fields and the data within them means.
So now that we know what these mean we can decipher the data returned from the vpx_access table as the following:
If someone had access to the database and had either a local Windows account or domain account they could grant themselves Administrator access at the top Hosts & Clusters level by typing the following SQL commands:
insert into vpx_access (ID, PRINCIPAL, ROLE_ID, ENTITY_ID, F
To continue reading for free, register below or login
To read more you must become a member of SearchVMware.com
LAG) values ('100', 'ACME\JSMITH', '-1', '1', '1');
commit;
This grants a domain user account (1) called JSmith (ACME\JSMITH) the administrator role (-1) at the top hosts and clusters level (1); the 100 ID was entered as it was not currently in use in the table. When the SQL table is updated in this manner vCenter does not immediately recognize the updated information, stopping and starting the vCenter service will force it to be picked up and at that point the user will be able to log into vCenter server.
Moral of the story: Protect your vCenter SQL database by using a strong password and restricting access to the database. Also make sure that you are using strong passwords for any other accounts that may have access to the tables (like the 'sa' account in MS-SQL). Additionally, run your vCenter database on a dedicated SQL server if possible instead of using a shared SQL server with other users. Finally, keep your SQL server patched to ensure that all known vulnerabilities cannot be used to gain access to it.
Active Directory and vCenter permissions
Next let's cover Active Directory. By default, vCenter will validate all the users and groups that are used in permissions on vCenter objects once a day. What this means is that it will look at all the users and groups and make sure that they still exist in AD. If they do not then the permissions are automatically deleted. If an AD account is deleted and a new account with the same name is created before the permissions are removed by vCenter it can be used to access vCenter with the same permissions. So if an AD account called MJONES is deleted in the morning that had Administrator access to vCenter and someone creates a new account called MJONES a few hours later, it will have the same Administrator access to vCenter because it was recreated before vCenter performed its daily validation.
This is possible because vCenter does not use the system identifiers (SIDS), or long strings of letters and numbers, used by Windows to uniquely identify users. If an account is deleted in AD and recreated with the same name it will have a different SID in Windows and not have access to any of the Windows permissions it previously had. To vCenter, however, it will look like the same account and have the same permissions because vCenter only uses the domain and username of the user, not the SID.
The setting that controls this behavior in vCenter can be accessed by selecting Administration from the top menu, and then the vCenter Management Server Configuration option. Select Active Directory from the left pane. In the right pane you will see a setting called Enable Validation, and below that a validation period that can be specified in minutes. This feature can be disabled entirely, and the interval can be changed from the default of 1440 minutes (one day). If you are concerned about security in your environment, you should change the validation period to a lower value (i.e. 120 minutes). It is not recommended to disable this feature as it protects vCenter by automatically removing permissions that are no longer valid.
As you can see, there are additional areas that you should be concerned about with vCenter. Make sure you are aware of them and secure them properly. Protecting the database is critical, and ensuring that invalid permissions are promptly removed is the key to preventing unauthorized access to the vCenter server.
ABOUT THE AUTHOR: Eric Siebert is a 25-year IT veteran with experience in programming, networking, telecom and systems administration. He is a guru-status moderator on the VMware community VMTN forums and maintains VMware-land.com, a VI3 information site.
