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:
Select * from vpx_access
Will return results similar to this:
| ID | PRINCIPAL | ROLE_ID | ENTITY_ID | FLAH |
| 1 | Administrators | -1 | 1 | 3 |
| 2 | ACME\VCENTER_Admins | -1 | 1 | 3 |
| 21 | ACME\TJones | 120 | 1422 | 1 |
| 45 | ACME\VCENTER_Users | 140 | 21 | 3 |
Let's go over what these fields and the data within them means.
- ID is a unique identifier for the table that every entry is assigned.
- Principal is the name of the local or domain user/group. Domain users and groups are preceded by a \ (i.e. ACME\TJones).
- Role_ID is the ID that corresponds to a role that is defined in the VPC_ROLE table which contains IDs and roles. -1 corresponds to the Administrator role that cannot be deleted from VCENTER and subsequently is not in the database. Some of the sample roles that come with VCENTER have IDs like 2 for DataCenterAdministrator and 5 for VirtualMachine user.
- Entity_ID is the ID that corresponds to an object that is defined in the VPX_ENTITY table which contains IDs and entities. All objects in VCENTER have a unique entity ID including virtual machines, hosts, clusters, resource pools and datacenters. The ID 1 is used for the very top-level entity which is Hosts and Clusters.
- Flag is used to define the principal as either a user or a group. A flag of 3 is used to signify that the principal is a group and a flag of 1 is used to signify that the prinicipal is a user.
So now that we know what these mean we can decipher the data returned from the vpx_access table as the following:
- The local Windows group administrators is a member of the adminstrator role at the hosts and clusters level.
- The vCenter_Admins group in the ACME Windows domain is a member of the Administrator role at the hosts and cluster level.
- The TJones user in the ACME Windows domain is a member of a role called vCenter Network (120 = vCenterNetwork in the vpx_entity table) for a specific virtual machine called Win2000-5 (1422 = Win2000-5 in the vpx_entity table)
- The vCenter_Users group in the ACME Windows domain is a member of a role called vCenterOps (140 = vCenterOps in the vpx_entity table) for the Denver1 data center (21 = Denver1 in the vpx_entity table)
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, FLAG) 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.
