Chris McCain - Mastering VMware® Infrastructure3

Of course, if your company mandates documentation, there might already be a solid audit trail. However, it is easy to see existing role usage from within the VI Client.</p> <p>To identify where a role has been assigned as a permission:</p> <p>1. Use the VI Client to connect to an ESX Server host.</p> <p>2. Click the Admin button from the toolbar.</p> <p>3. Click on the role whose usage you wish to identify.</p> <p>As shown in Figure 8.14, the details pane will identify where in the inventory the role has been used.</p> <img src=#i_290.png" > <p> <strong>Figure 8.14</strong>The VI Client makes it easy to identify where a role has been assigned as a permission.</p> <empty-line > <p>Over time, it is almost inevitable that management needs will change. At times, you may have to create new roles, edit an existing role, or even delete a role. If a role is not used, it should be removed simply to minimize the number of objects to be viewed and managed.</p> <p>To delete a role:</p> <p>1. Use the VI Client to connect to an ESX Server host.</p> <p>2. Click the Admin button from the toolbar.</p> <p>3. From the Roles tab, right-click the role to be deleted and select the Remove option, as shown in Figure 8.15.</p> <img src=#i_291.png" > <p> <strong>Figure 8.15</strong>Unused roles should be removed to minimize the objects viewed and managed on an ESX Server.</p> <empty-line > <p>When a role is in use and is selected for removal, the ESX Server will offer the opportunity to transfer the existing role members to a new role or simply to drop all members from the role, as shown in Figure 8.16. This eliminates the opportunity for accidentally deleting roles that are being used in the inventory.</p> <img src=#i_292.png" > <p> <strong>Figure 8.16</strong>When you attempt to delete a role that is in use, you'll see a prompt that asks if you want to drop or reassign the role members.</p> <empty-line > <p>Now that you understand how to work with Linux-based users, groups, roles, and permissions on an ESX Server host, be aware that you more than likely will not be doing much of this. Managing the Linux-based user accounts is administratively more cumbersome because of the lack of centralized management and authentication. This is, of course, because the bulk, if not all, of your access control strategies should revolve around Windows-based user accounts accessing the VirtualCenter environment. This offers the advantage of having a centralized user database with a single password management process.</p> <div class="title"> <p>Managing and Maintaining VirtualCenter Permissions</p> </div> <p>The security model for VirtualCenter is identical to that explained in the previous section for an ESX Server: take a user or group and assign them to a role for a specific inventory object. The difference in the VirtualCenter security model is the origin of the user or group objects. In the VirtualCenter environment, the users and groups are actually Windows users and groups, but exactly which users will depend on whether your VirtualCenter server is a part of a domain or not. If the VirtualCenter server belongs to a workgroup, then the users and groups are stored in the local Security Accounts Manager (SAM) on that server and are managed through the Local Users and Groups node of the Computer Management snap-in. If the VirtualCenter server belongs to an Active Directory domain, then the users and groups available for assignment to roles are pulled from the Active Directory database and are managed through the Active Directory Users and Groups snap-in. This is fairly typical for a Windows server-based application, and also helps us to continue to manage all of the users in our network in one place: Active Directory. If you don't have the ability to create users and/or groups in Active Directory, you will need to make arrangements with your Active Directory administration team to assist you in that area. Once the users and/or groups are created, they will be available for you to assign roles to them through VirtualCenter. We will assume that the VirtualCenter environment is based on a server that is a part of an Active Directory domain for the purposes of this discussion, although the procedures for assigning permissions remains essentially the same if you have a workgroup-based installation. The key is to remember where to create the users and groups you need to use.</p> <cite> <p> <strong>Real World Scenario</strong> </p> <div class="title">VirtualCenter in a Workgroup vs. VirtualCenter in a Domain</div> <p>You can install VirtualCenter on a Windows Server 2003 system that belongs to a workgroup or a domain. Although the security model and configuration steps are identical in both cases, there are significant concerns that arise in both cases.</p> <p>In most cases, you'll install VirtualCenter on a computer that belongs to a Windows Active Directory domain. Doing this means users and groups that are granted access will likely reside in the Active Directory database. It also means signing into a VirtualCenter will take place under the context of a domain account, which in turn means passwords for accessing VirtualCenter will be susceptible to the domain password policies in effect. Even though the account information is the same, VirtualCenter does not currently support any type of single sign-on method in which your existing credentials are passed to the application. You will still have to type your username and password for VirtualCenter access. From a management perspective, installing VirtualCenter on a domain member eliminates the need to manage multiple user accounts, but it does pose a security risk that must be addressed.</p> <p>The default permissions in a VirtualCenter installation provide the local Administrators group of the VirtualCenter server with membership in the Administrator role at the root of the inventory. As you learned in the previous section, this role has all privileges for virtual infrastructure management. The problem with this is that the Domain Admins group is, by default, a member of the local Administrators group, thereby granting all Domain Admins complete rights in the VirtualCenter infrastructure. In most cases, this will violate the principle of least privilege as all Domain Admins are not necessarily qualified or hired to be virtual infrastructure administrators. To mitigate the risk involved with the default configuration, create a new Active Directory organizational unit (OU) that includes the user accounts and groups for the virtual infrastructure administrators. Then, change the Active Directory permissions to prevent the Domain Admins from managing the new OU.</p> <p>As shown in this image, you can create and configure an Active Directory group to prevent Domain Admins from managing the group membership. This group can then replace the local Administrators group in the VirtualCenter root permissions list.</p> <p> <img src=#i_293.png" > </p> <p>Once you've created the new group and granted it rights in VirtualCenter, you can remove the local Administrators permissions entry from the root of the VirtualCenter inventory, which will remove the original security concern. The following image shows how replacing local Administrators with a custom group eliminates a Domain Admin's ability to manage the virtual infrastructure:</p> <p> <img src=#i_294.png" > </p> <p> Alternatively, you can install VirtualCenter on a Windows Server 2003 system that belongs to a workgroup. As part of a workgroup, the Domain Admins will not have a default membership in the local Administrators group.Читать дальше