Книга: Mastering VMware® Infrastructure3

User Access to VirtualCenter and ESX Server

User Access to VirtualCenter and ESX Server

With VirtualCenter's inherent Windows architecture, it can rely on and utilize the user and group infrastructure of Active Directory for logging into VirtualCenter. VirtualCenter has no functionality to manage Windows users or groups. The administrator can pull in any user or group that is locally on the Windows server that VirtualCenter is installed on or from the domain. Once the user has been identified and added, a role can be selected that best fits the requirements of that user. Once the user logs into VirtualCenter using the Virtual Infrastructure (VI) Client, the console only shows what the user is allowed to see and only provides specific functionality that corresponds with that user's role (see Figures 12.1 and 12.2).

Figure 12.1 An example of a user having logged into VirtualCenter and being shown an “Administrator” view of the inventory

Figure 12.2 An example of a user having logged into VirtualCenter and being shown a “VM Administrator” view on a specific resource pool

Perform the following steps to assign a user account and role to a VirtualCenter inventory object:

1. Log into VirtualCenter with the VI Client with the Administrator role (see Figure 12.3).

2. Right-click on the inventory object to which you wish to add a permission and select Add Permission, as shown in Figure 12.4.

3. In the Assign Permissions dialog box, click the Add button to open the Select Users dialog box (see Figure 12.5).

4. Make a selection from the Domains drop-down list, and select the user or group, as shown in Figure 12.6. Click Add, then OK.

Figure 12.3 Logging in with an account that can assign permissions

Figure 12.4 Select the inventory object for the new permission.

5. Select the appropriate role from the Assigned Role drop-down list, as shown in Figure 12.7. Choose a role that best fits the user's job function. If one of the predefined roles does not fit, create and use a custom role. Click OK when you're done.

6. The completed permission appears on the Permissions tab for that inventory object, as shown in Figure 12.8.

By default, ESX Server still relies on a local user and group accounts model. But with the advent of VirtualCenter's centralized management role, most activities are funnelled through VirtualCenter, using Windows accounts that have been assigned a role, which have then been assigned to an inventory object. This combination of Windows account, role, and inventory object creates a permission that allows (or disallows) the user to perform certain functions. Since the user doesn't log into the ESX Server directly, this minimizes the need for many local user accounts on the ESX Server and thus provides better security. Alas, there still is a need, however small or infrequent, for local accounts on an ESX Server used primarily for administration.

Figure 12.5 Beginning the process of adding a user

Figure 12.6 Choose a domain, user, or group, then click Add and OK.

Figure 12.7 Choosing a role for the new user

Figure 12.8 A new role has been created that best fits the user's job function.

When using VirtualCenter to access your virtual infrastructure, the administrator or user is usually only creating a task and not directly interfacing with the ESX Servers or the virtual machines. Say for instance, Shane, an administrator, wants to create a new virtual machine. He first needs a proper role, such as “VM Administrator” on an inventory object, to accomplish such a feat (see Figure 12.9). 

Figure 12.9 Having the proper role to accomplish your task is the starting point when using VirtualCenter.

As shown in Figure 12.9, Shane has been assigned the VM Administrator role on the ProductionVMs resource pool. This role gives him what he needs to create, modify, and monitor virtual machines for that pool. But, does Shane's user account have direct access to the ESX Servers when he's logged into VirtualCenter? No, and in fact, a proxy account is used to communicate Shane's tasks to the appropriate ESX Server. This account, vpxuser, is the only account that VirtualCenter stores and tracks in its back-end database as shown in Figure 12.10.

Figure 12.10 An ESX Server host managed by Virtual-Center has a vpxuser account created for communication between the host and VC.

Any time VirtualCenter polls an ESX Server or an administrator creates a task that needs to be communicated to an ESX Server, the account vpxuser is used.

If folders are used to organize these objects, or if the inventory view is changed to Virtual Machines and Templates, as shown in Figure 12.6, folders can be used to organize the virtual machines and templates, irrespective of the Host and Clusters inventory objects. Thus, you can assign roles to those folders that are related to virtual machine administration. It is best to use one view or the other when assigning virtual machine-centric roles to avoid conflicts in permissions. Since VirtualCenter presents the administrator with the Hosts and Clusters view by default, many administrators use this view for virtual machines. A good habit is to switch to Virtual Machines and Templates whenever you are assigning user roles to a virtual machine or a group of virtual machines in a folder. 

So, when is it appropriate to log into an ESX Server on the Service Console? Not very often for almost all everyday administrative tasks. There are times, however, when an administrator has to troubleshoot a problem or set up or monitor specific processes on the ESX Server that cannot be managed with VirtualCenter. A good example is setting up the NTP service so the ESX Server can synchronize its time with a trusted time source. Although the administrator can open the firewall with the VI Client connected to VirtualCenter for a given ESX Server, the actual service is enabled locally on the Service Console.

In most cases, the number and the frequency of use of local user accounts on an ESX Server have diminished considerably. Usually, two or three accounts are all that is needed for access to the Service Console. Why two or three? The best reason to have at least two accounts is in case one of the user accounts is unavailable for situations like user vacations, sickness, or accidents. Having fewer accounts also makes auditing much easier in those high-security environments that require auditing of administrative accounts. The following steps show one way to create local user accounts:

1. Log into the ESX Server Service Console with the root account.

2. Type useradd username at the command prompt.

3. Type passwd username to set an initial password.

4. Type the password twice as shown in Figure 12.11.

Figure 12.11 Creating a new user account and setting the initial password

5. Open a new ssh session and test the user account and password as shown in Figure 12.12.

Figure 12.12 Testing the new user account

You can also log into the ESX Server with the VI Client and create users using the Users and Groups tab. Be careful when creating passwords with this client, as many special characters are not passed through the interface properly. Once the accounts have been created, limit their access to specific tools and client services if needed, as you'll see in the next section.

Оглавление книги