Objective 1 – Configure and Administer vSphere Security

This section covers Objective 1 of the VCP6-DCV delta exam, detailed here

Objective 1.1: Configure and Administer Role-based Access Control

    • Compare and contrast propagated and explicit permission assignments
      • When assigning permissions on an object, deselecting “propagate to children” will set permissions on that object only. Selecting “propagate to children” will apply the permissions to all lower level objects.
      • By default permissions propagate.
      • Review hierarchical inheritance of permissions, vsphere security guide page 116
      • Multiple Permissions permissions applied on a child object always override permissions that are applied on a parent object.
      • If a permission is defined for a group that the user is a part of and the user has permissions defined, the users permissions take precedence over all group permissions.
      • If permissions are defined on an object where the user is member of multiple groups, and user does not explicitly have permissions defined, the resultant set is a union of the multiple group permissions.
      • User role overrides group role
      • Explicit Child permissions override parent permissions
      • Allow takes precedence over deny.
      • Basically the smallest, closest permissions win.
    • Add/Modify/Remove permissions for users and groups on vCenter Server inventory objects
      • To modify permissions on an object, you must have Permissions.Modify privilege
      • At the appropriate level, Manage->permissions. Add. Select the user or group from the appropriate identity source. Select the appropriate role. Select whether to propagate to children
    • Determine how permissions are applied and inherited in vCenter Server
      • Permissions in vCenter are a combination of:
        • Privilege: can perform a specific task/activity
        • Roles: group of privileges
        • Permissions: a combination of user or group and privileges associated with an object
    • Configure VMware Directory Service
    • Apply a role to a User/Group and to an object or group of objects
      • Initially only administrator@vsphere.local can logon. To add additional user you apply roles to groups/users (need an identity source first, of course)
      • At the appropriate level, Manage->permissions. Add. Select the user or group from the appropriate identity source. Select the appropriate role. Select whether to propagate to children.
    • Determine the appropriate set of privileges for common tasks in vCenter Server
      • ***Security guide page 127***. Best practices & privileges required for common tasks
      • Datastore.allocate space privilege is required on the target datastore for any space consuming operation
      • Resource.Assign Virtual Machine to Resource Pool privilege. Each host/cluster has it’s own default resource  pool. Must have the above privilege to deploy a machine into host/cluster

 

  • Security guide chapter 10 – Defined Privileges

 

  • Compare and contrast default system/sample roles
    • System roles. Can’t be modified or removed
      • Administrator
        • Can do everything on the object where permissions are granted
      • Read-only
        • View state and details of the object
      • No access
        • Cannot view or change an object in anyway. New users are assigned this role by default (except administrator@vsphere.local, root and vpxuser)
    • Sample roles. CAN be modified/removed, but shouldn’t. Clone the role and then modify the new role
      • Resource Pool administrator
        • Alarm: Create/modify/remove alarm
        • Datastore: Browse datastore
        • Folder: (*) create/delete/move/rename
        • Global: cancel task; log event; set custom attribute
        • Permissions: Modify permission
        • Resource: All except apply recommendation; assign vapp to resource pool
        • Scheduled task: (*) create/modify/remove/run tasks
        • Virtual machine: review, many settings
      • Virtual machine user.
        • Cancel tasks, schedule tasks and basic interactions with VM
      • Content library administrator
        • Everything with content library except “import storage”
      • Tagging admin
        • Inventory Service->vsphere tagging, nearly all management tasks
      • Vmware consolidated backup user
        • VM, create/remove snapshot management, allow disk read & vm download
      • Datastore consumer
        • datastore->allocate space (that’s it? What’s the point)
      • Network administrator
        • network->assign network (that’s it? What’s the point)
          • Used for creating machines and assigning a network
      • Virtual machine power user
        • VM snapshots, basic VM interactions, basic configurations
    • Custom roles
      • You can create custom esxi host roles, but you shouldn’t. Use vcenter to manage hosts.
  • Determine the correct permissions needed to integrate vCenter Server with other VMware products
    • You can use global permissions to grant permissions across objects. Global permissions are replicated across vsphere.local domain
    • You must have Permissions.modify privileges on the root object for all inventory hierarchies. vCenter->administration->manage->access control-> global permissions. Add/modify/remove permissions process is the same as any other object.

Objective 1.2: Secure ESXi, vCenter Server, and vSphere Virtual Machines

pay particular attention to the hardening guide and the VMCA hardening guide

If you suspect that any certs have been compromised, replace & remove all certs including the VMCA root. Use the vSphere Certificate Manager to automate certificate replacement across solutions.

Use vSphere Certificate Manager to:create CSR’s, replace certificates, revert to last performed certs, make VMCA an intermediate CA, regenerate VMCA cert

https://psc_server_name/psc to browse certificate stores

  • Harden virtual machine access
    • review vsphere security-> securing virtual machines
    • Control VM data access
      • disable HGFS (host guest file system) file transfers
        • Vm options->advanced-> edit. isolation.tools.hgfsServerSet.disable = TRUE
      • disable copy/paste between guest & remote
        • Isolation.tools.copy.disable = true
        • isolation.tools.paste.disable = true
      • prevent user/process from connecting/disconnecting devices
        • Isolation.device.connectable.disable = true
        • isolation.device.edit.disable = true
      • copy/paste should be disabled
      • Restrict users from running commands within VM.
        • Admin users may not actually need access to the VM. Create custom role to allow admin functions, but disable, remote console, remote options within OS, etc
          • “Deselect All Privileges.Virtual machine.Guest Operations to remove the Guest Operations set of privileges”
        • disable unnecessary functions inside VM
      • Configure virtual machine security policies
        • When you use independent nonpersistent disks, successful attackers can remove any evidence that the machine was compromised by shutting down or rebooting the system
    • Harden a virtual machine against Denial-of-Service attacks
        • A Denial of Service can occur when you do not control the size of a virtual machine’s VMX file and the amount of information exceeds the datastore’s capacity
        • Non-administrative users in the guest operating system are able to shrink virtual disks. Shrinking a virtual disk reclaims the disk’s unused space. However, if you shrink a virtual disk repeatedly, the disk can become unavailable and cause a denial of service. To prevent this, disable the ability to shrink virtual disks.
          • Vm options->advanced->edit
            • isolation.tools.diskWiper.disable TRUE
            • isolation.tools.diskShrink.disable TRUE
        • When one virtual machine consumes so much of the host resources that other virtual machines on the host cannot perform their intended functions, a Denial of Service (DoS) might occur. To prevent a virtual machine from causing a DoS, use host resource management features such as setting Shares and using resource pools.
        • Using a distributed switch you can use traffic filtering and marking to protect against unwanted traffic.
      • Control VM-VM communications
        • Segment networks
        • Use vlan’s and separate physical adapters
        • Set security policy on port groups and ports
          • On a standard switch you can configure VLAN networking mode at switch or port group level, and on a distributed switch at distributed port group or port level
          • Set mac address changes to reject (default is accept)
            • (inbound traffic)
          • Set forged transmits to reject to reject (default is accept)
            • Compares source mac to effective match. If there is no match, esxi host drops the packet
            • Outbound traffic
          • Set promiscuous mode to reject (default is reject)
            • Allows user or VM to view traffic destined for other systems
      • Control VM device connections
        • Disconnect unused physical devices, such as CD/DVD drives, floppy drives, and USB adaptors.
      • Configure network security policies
        • Ensure that port groups are not configured to VLAN values reserved by upstream physical switches.
    • Harden ESXi Hosts
      • Enable/Configure/Disable services in the ESXi firewall
        • by default firewall ports on ESXi are opened only when you start a corresponding service
        • By default the firewall for each service allows access to all IP’s. Restrict traffic by deselecting “allow all IP’s” and specify IP’s or ranges
        • select hosts -> manage -> security profile
        • Firewall, standard source/dest/protocol/port acl mode
        • Customize hosts with the security profile. Best use case is for single hosts or very small environments. Otherwise use server profiles, SDK, script
          • host->manage->settings->security profile
        • Installing additional VIB’s may add additional services/firewall ports
        • NFS client firewall behaves differently
          • NFS v3 auto configs the rule set when you add a NFS v3 mount
          • NFS v4.1 sets allowedAll to TRUE on first mount. No change on unmount.
      • Change default account access
        • Create roles with different access privileges and group hosts into folders according to the tasks you want to perform
        • Typically managed via vCenter. Can manage local permissions, but usually only if standalone host.
        • Users predefined
          • root.
            • Do not remove.
            • Set highly complex password.
            • Only root can add a host to vCenter
          • vpxuser
            • vCenter server uses vpxuser for managing hosts
            • DO NOT change vpxuser in any way.
          • dcui user
            • Runs on hosts and has administrator rights.
        • Roles predefined
          • Read Only
          • Administrator
          • No access (default for users)
        • For managed hosts, “Best practice is to create at least one named user account, assign it full administrative privileges on the host, and use this account instead of the root account. Set a highly complex password for the root account and limit the use of the root account. (Do not remove the root account.)” page 164, security guide
      • Add an ESXi Host to a directory service
        • esxi -> manage ->authentication services-> join domain
          • Synchronize time using NTP
          • Ensure DNS can resolve AD host names
        • the DOMAIN group ESXi Admins is assigned full administrative access to the host (if it exists)
        • If a host is provisioned with auto deploy, you can’t use AD, because credentials can’t be stored. Must use VMware vsphere authentication proxy
        • Using authentication proxy
          • Install
          • Export the auth proxy cert
          • Install the auth proxy cert in ESXi
          • Join to authentication services, selecting the option for “using proxy server” -> provide IP of auth proxy
        • You can use a smart card & pin to auth to the DCUI instead of U/P
          • host->manage->settings->authentication services->smart card authentication. Edit. Add trusted CA certs. Select the option to enable smart card authentication.
      • Enable Lockdown Mode
        • How to enable lockdown mode
          • When adding a host to vCenter
          • Via web client
            • manage->settings->security profile->lockdown mode
          • Via DCUI (normal lockdown mode only)
            • F2->configure lockdown mode
        • How to disable lockdown mode
          • Via web client (privileged users only)
          • Via DCUI (normal lockdown mode only)
            • Local permissions for users/groups are discarded when using this method
        • no users other than vpxuser (vcenter user)have authentication permissions. Forces users to use vCenter to manage the environment. ensures consistency
        • DCUI.Access -> specifies users who can access DCUI
          • manage->advanced system settings->DCUI.access
          • Enter comma separated user names
        • strict lockdown mode
          • DCUI service is stopped.
          • if the connection to vCenter is lost and web client is no longer available, the ESXi host becomes unavailable.
            • in this situation, host can only be accessed if ESXi shell & SSH are enabled and exception list users are defined.
          • Exception users have ability to access ESXi host directly via remote connection
          • For this to be truly effective security measure, you also need to disable ESXi shell and SSH.
        • Normal Lockdown mode
          • DCUI is not stopped.
          • Privileged accounts can still use direct console access
          • Exception users can still access the host via ESXi shell or SSH (assuming that they are enabled). Requires administrator privileges.
          • Only the following can access the DCUI
            • Users in the Exception User list who have administrative privileges on the host
            • Users defined in the DCUI.access advanced option for the host.
              • DCUI.access is meant for emergency access. Break glass.
              • Users in this list DO NOT require administrative privileges on the host
        • Exception users do not lose their privileges when the host enters lockdown mode
          • Use to allow direct access for service accounts that still need direct access to the host.
          • DON”T use this to add administrators -> defeats the purpose of lockdown mode.
          • Exception users can still access the host via ESXi shell or SSH (assuming that they are enabled). Requires administrator privileges.
          • To add users to the exception user list
            • manage->settings->security profile->lockdown mode-> edit->specify exception users
            • Local users only, if not joined to a domain. If joined to a domain, domain users only.
      • Control access to hosts (DCUI/Shell/SSH/MOB)
        • Disable the MOB. Can be used to change configuratons of host/vcenter
          • Under advanced system settings, Config.HostAgent.plugins.solo.enableMob set to false (disabled by default)
        • SSH supports account lockouts. DCUI & ESXi shell do not support account lockout.
        • Disable use of authorized keys for SSH
          • Ensure this file is empty: /etc/ssh/keys-root/authorized_keys
        • When shell is enabled, alt-f1 to access via physical console
      • GENERAL ESXi security stuff
        • Host profiles allow you to setup standard configurations, reducing human error
          • Setup a reference host to specs, create host profile from it.
          • Attach profile to host or cluster
        • Don’t manage hosts directly. Don’t use root unless necessary, use scripts or clients.
        • Customize hosts with the security profile. Best use case is for single hosts or very small environments.
          • host->manage->settings->security profile
        • Default protections in esxi
          • shell/ssh disabled
          • Weak ciphers are disabled
          • Tomcat has been modified to only run those functions required for vsphere administration and/or by web client
        • Change VIB acceptance level to keep unsigned VIBs off hosts
          • Edit via esxcli
        • Create a timeout for the ESXi shell
          • manage->settings->advanced system settings.  UserVars.ESXiShellTimeOut. Restart SSH & ESXi
    • Harden vCenter Server
      • Create/Manage vCenter Server Security Certificates
        • review vSphere security -> vSphere security certificates (chapter 3)
        • VMware Certificate Authority (VMCA) provisions each host w/ a signed cert that has VMCA as root CA.
        • Certs can be replaced by a third party CA
        • check password expiration (vmware best practice). default vcenter sso password policy is 90 days. SSO password policies are set: vsphere web client->administration->sso->configuration->policies
        • Use NTP. VMCA requires accurate time stamps
          • vmware best practice is to use NTP
        • solution user certs are used for authentication to vCenter SSO.
        • VECS = VMware Endpoint Certificate Store
          • All certs for vCenter and related services are stored here
          • local (client-side) repository for certs, private keys, etc.
          • ESXi certs are stored locally on each host and not in VECS
          • runs on each embedded, PSC or management nodes.
          • holds keystores that contain certs and keys
          • VECS includes one store for each solution user. Subject of each cert must be unique.
            • Know information contained in table 3-3, page 60
          • Change default account access
            • administrator@vsphere.local does not expire and is not subject to lockout policy from SSO
            • other vsphere.local users are controlled by the account policies. Users from other identify sources (ex.\ domain) are controlled by the identity source itself.
            • If local windows administrator has admin rights to vCenter, ensure that others have these rights and then remove the rights from the local windows admin account.  (no longer an issue by default with vsphere 6)
            • Using local OS users is not a recommended identity source
            • Restrict access to vCenter database. Database user only requires certain privileges, some of which are required only for login. Remove unnecessary privileges
            • By default, vCenter Server changes the vpxuser password automatically every 30 days. You can change that value from the vSphere Web Client.
              • manage->settings->advanced settings, VirtualCenter.VimPasswordExpirationInDays
    • Restrict administrative privileges
      • least privilege
      • Use a windows service account for vCenter services, rather than the local system account
    • General vCenter security
      • vSphere Web Client extensions run at the same privilege level as the user who is logged in. Ensure validity of plugins

Objective 1.3: Enable SSO and Active Directory Integration

SSO management is done from the vSphere web client

to configure SSO you must have sso global administrator privileges (this differs from administrator role on vCenter or ESXi)

vsphere security guide -> vsphere authentication w/ vCenter SSO

know web & CLI commands.

  • Describe SSO architecture and components
    • view/take action on services: vsphere web client->administration->system configuration->services
    • manage password/lockout/token policies: vsphere web client->administration->SSO->configuration->policies
    • embedded deployment or management node or PSC has its own SSL cert. all services running on that node use this machine SSL cert to expose SSL endpoints
    • PSC is: lookup service, SSO, CA, license, directory service
      • embedded is really suitable only for small deployments and/or where only one vmware solution will be used.
      • understand enhanced linked mode. one web client, multiple vcenter servers, managing inventory between all of those environments -> allows for new features like cross vcenter migrations
      • Primarily:
        • Sts
        • License
        • VMCA
        • Syslog
        • Vmdir
        • Lookup service
    • sso is an authentication broker and security token exchange infrastructure
    • SSO allows components to use a SAML token instead of requiring users to auth separately w/ each component
    • STS (security token service) issues/validates/renews the SAML tokens
      • replace the STS certificate -> vsphere web client w/ SSO admin privleges -> administration->SSO->configuration->certificates->sts signing->add sts signing certificate icon->browse to the key store JKS file.  Restart the vsphere web client service
      • you can share information from STS with other SAML providers in your environment
        • vsphere web client ->administration->SSO->configuration->saml service providers. Follow the directions for both export/import.
    • administration server allows users w/ admin privileges to configure SSO, users/groups from the web client
    • vmdir (VMware Directory service) multi-tenant, multi-mastered directory service that makes ldap directory available on port 389. updates to vmdir propagate to other instances in additional PSC’s. Stores SSO info & certificate info.
    • Identity Management service (IDM): handles identity sources and STS auth requests.
    • VMCA (vmware certificate authority) & VECS
      • You view certificates associated with the VMCA instance that is included with your embedded deployment or with the Platform Services Controller. Certificate information is replicated across instances of VMware Directory Service (vmdir).
      • To view certificates associated with VMCA. Vcenter with CAAadmin privileges. Administration->deployment->system configuration-> nodes->select node->manage->CA
    • from page 20 of the vsphere security guidesso-handshake
  • Differentiate available authentication methods with VMware vCenter
    • users authenticate with U/P & solution users authenticate w/ a cert
    • ad integration & local users (local server users) (do not use in an external deployment methodology) & vmdir (vsphere.local) -> multiple authentication sources
  • Perform a multi-site SSO installation
  • Configure/Manage Active Directory Authentication
    • add AD identity source
      • after adding you still have to add users to roles. All users have the “no access” role by default after adding an identity source
      • when adding the AD identity source you can use the local machine account as the SPN.
    • add ESXi servers to AD
      • manage server -> authentication services -> join domain
  • Configure/Manage Platform Services Controller (PSC)
    • VMCA, enterprises CA, 3rd party CA certs are supported. self-signed certs created using OpenSSL where no root CA exists are NOT supported.
  • Configure/Manage VMware Certificate Authority (VMCA)
    • VMCA automates certificate management for you if you do not replace VMware certificates
    • replacing the VMCA root cert with a CA signed cert makes the VMCA cert an intermediate.
      • if you cannot have intermediate certs, you must manually replace all certs
    • vSphere Certificate manager (command line utility) replaces the “certificate replacement tool”
    • You view certificates associated with the VMCA instance that is included with your embedded deployment or with the Platform Services Controller. Certificate information is replicated across instances of VMware Directory Service (vmdir).
    • To view certificates associated with VMCA. Vcenter with CAAadmin privileges. Administration->deployment->system configuration-> nodes->select node->manage->CA
    • When a host is added to vCenter, it is provisioned with a cert signed by VMCA.
      • For auto-deploy hosts, the signed cert is stored by the auto deploy server in its local cert store.  If VMCA is not available on first auto-deploy boot, it reboots until VMCA is available and can provide a cert.
    • When a host is added to vCenter, vCenter sends a CSR for the host to the VMCA
      • Change the default CSR values/behavior for hosts via vCenter advanced settings. Filter on certmgmt
      • Manage host certs. Host->manage->settings->System->certificate
        • Refresh CA certs. Gets all certs in the TRUSTED_ROOTS store from VECS and pushed them to the host
      • Renew. Gets a new host cert from VMCA
    • To use custom certs with ESXi
      • From page 143 of the vsphere security guide:
        • If your company policy requires that you use a different root CA than VMCA, you can switch the certificate mode in your environment after careful planning. The recommended workflow is as follows.
        • 1 Obtain the certificates that you want to use.
        • 2 Remove all hosts from vCenter Server.
        • 3 Add the custom CA’s root certificate to VECS.
        • 4 Deploy the custom CA certificates to each host and restart services on that host.
        • 5 Switch to Custom CA mode. See “Change the Certificate Mode,” on page 144.
        • 6 Add the hosts to the vCenter Server system.
      • To switch back to using VMCA as CA. remove all hosts from vcenter, remove 3rd part CA;s root cet from VECS, switch cert mode, add hosts back to vcenter
    • manage certs with:
      • vSphere Certificate Manager Utility
      • Certificate management CLI’s
        • dir-cli, certool & vecs-cli
      • vSphere web client certificate management
        • view access to look at certs and expiration info
        • ESXi cert management is performed via web client
        • Logon to web client as a member of the CAAdmins group.
  • Enable/Disable Single Sign-On (SSO) Users
    • vsphere web client -> administration->SSO->users and groups. right-click user -> disable. will show in the column “disabled”
    • If you delete the administrator user in the vsphere.local domain you can no longer logon to vcenter single sign-on. You must reinstall vCenter and its components.
    • by default passwords expire every 90 days, but administrator@vsphere.local does not expire
    • SSO groups
      • administrator: can manage SSO
        • users added to this group have global permissions to SSO & all of inventory that are managed by that SSO domain
      • CAAdmins: can manage VMCA
      • LicenseService.Administrators: can manage licenses
      • SolutionUsers: do not add members to this group explictly