Select any two versions of this STIG to compare the individual requirements
Select any old version/release of this STIG to view the previous requirements
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. View the value of the "Restrict reuse" setting. If the "Restrict reuse" policy is not set to "5" or more, this is a finding.
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. Click "Edit". Enter "5" into the "Restrict reuse" setting and click "OK".
Note: For vCenter Server Windows, this is not applicable. On the vCenter Server, execute the following command: # grep "^refresh\.rate" /etc/vmware/vsphere-client/webclient.properties Expected result: refresh.rate = -1 If the output does not match the expected result, this is a finding.
Navigate to and open /etc/vmware/vsphere-ui/webclient.properties. Remove any existing "refresh.rate" line and add the following: refresh.rate = -1 After editing the file, the vSphere Client service must be restarted. # service-control --restart vsphere-client
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. View the value of the "Maximum lifetime" setting. If the "Maximum lifetime" policy is not set to "60", this is a finding.
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. Click "Edit". Enter "60" into the "Maximum lifetime" setting and click "OK".
Note: For vCenter Server Windows, this is not applicable. On the vCenter Server, execute the following command: # grep "^session\.timeout" /etc/vmware/vsphere-client/webclient.properties Expected result: session.timeout = 10 If the output does not match the expected result, this is a finding.
Navigate to and open /etc/vmware/vsphere-client/webclient.properties. Remove any existing "session.timeout" line and add the following: session.timeout = 10
From the vSphere Client, go to Administration >> Access Control >> Roles. View each role and verify the users and/or groups assigned to it. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VIPermission | Sort Role | Select Role,Principal,Entity,Propagate,IsGroup | FT -Auto Application service account and user required privileges should be documented. If any user or service account has more privileges than required, this is a finding.
To update a user's or group's permissions to an existing role with reduced permissions: From the vSphere Client, go to Administration >> Access Control >> Global Permissions. Select the user or group, click "Edit", change the assigned role, and click "OK". If permissions are assigned on a specific object, the role must be updated where it is assigned (for example, at the cluster level). To create a new role with reduced permissions: From the vSphere Client, go to Administration >> Access Control >> Roles. Click the green plus sign, enter a name for the role, and select only the specific permissions required. Users can then be assigned to the newly created role.
If distributed switches are not used, this is not applicable. From the vSphere Client, go to Networking >> select a distributed switch >> Configure >> Settings >> Properties. View the "Properties" pane and verify Network I/O Control is enabled. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VDSwitch | select Name,@{N="NIOC Enabled";E={$_.ExtensionData.config.NetworkResourceManagementEnabled}} If Network I/O Control is disabled, this is a finding.
From the vSphere Client, go to Networking >> select a distributed switch >> Configure >> Settings >> Properties. In the "Properties" pane, click "Edit" and change Network I/O Control to enabled. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: (Get-VDSwitch "VDSwitch Name" | Get-View).EnableNetworkResourceManagement($true)
From the vSphere Client, go to Hosts and Clusters >> select a vCenter Server >> Configure >> More >> Alarm Definitions. Verify there is an alarm created to alert if an ESXi host can no longer reach its syslog server. The alarm definition will have a rule for the "Remote logging host has become unreachable" event. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-AlarmDefinition | Where {$_.ExtensionData.Info.Expression.Expression.EventTypeId -eq "esx.problem.vmsyslogd.remote.failure"} | Select Name,Enabled,@{N="EventTypeId";E={$_.ExtensionData.Info.Expression.Expression.EventTypeId}} If an alarm is not created and enabled to alert when syslog failures occur, this is a finding.
From the vSphere Client, go to Hosts and Clusters >> select a vCenter Server >> Configure >> More >> Alarm Definitions. Click "Add". Provide an alarm name and description. Select "Hosts" from the "Target type" dropdown menu. Click "Next". Paste "esx.problem.vmsyslogd.remote.failure" in the line after IF and press "Enter". Select "Show as Warning" for severity. Click "Next". Configure any other options as desired, enable alarm, and finish. Note: This alarm will only trigger if syslog is configured for TCP or SSL connections and not UDP.
From the vSphere Web Client, go to Administration >> Single Sign-On >> Configuration. Click the "Identity Sources" tab. If there is no identity source of type "Active Directory", this is a finding.
From the vSphere Web Client go to Administration >> Single Sign-On >> Configuration. Click the "Add identity source". Select either "Active Directory over LDAP" or "Active Directory" and configure appropriately. Note: Windows Integrated Authentication requires that the vCenter server be joined to AD before configuration via Administration >> Single Sign-On >> Configuration >> Active Directory Domain.
Verify the built-in SSO administrator account is only used for emergencies and situations where it is the only option due to permissions. If the built-in SSO administrator account is used for daily operations or there is no policy restricting its use, this is a finding.
Develop a policy to limit the use of the built-in SSO administrator account.
If distributed switches are not used, this is not applicable. From the vSphere Client, go to Networking >> select a distributed switch >> Configure >> Settings >> Health Check. View the health check pane and verify that the "VLAN and MTU" and "Teaming and failover" checks are disabled. or From a PowerCLI command prompt while connected to the vCenter server, run the following commands: $vds = Get-VDSwitch $vds.ExtensionData.Config.HealthCheckConfig If the health check feature is enabled on distributed switches and is not on temporarily for troubleshooting purposes, this is a finding.
From the vSphere Client, go to Networking >> select a distributed switch >> Configure >> Settings >> Health Check. Click "Edit" and disable the "VLAN and MTU" and "Teaming and failover" checks. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-View -ViewType DistributedVirtualSwitch | ?{($_.config.HealthCheckConfig | ?{$_.enable -notmatch "False"})}| %{$_.UpdateDVSHealthCheckConfig(@((New-Object Vmware.Vim.VMwareDVSVlanMtuHealthCheckConfig -property @{enable=0}),(New-Object Vmware.Vim.VMwareDVSTeamingHealthCheckConfig -property @{enable=0})))}
If distributed switches are not used, this is not applicable. From the vSphere Client, go to Networking >> select a distributed switch >> select a port group >> Configure >> Settings >> Policies. Verify "Forged Transmits" is set to reject. or From a PowerCLI command prompt while connected to the vCenter server, run the following commands: Get-VDSwitch | Get-VDSecurityPolicy Get-VDPortgroup | ?{$_.IsUplink -eq $false} | Get-VDSecurityPolicy If the "Forged Transmits" policy is set to accept for a non-uplink port, this is a finding.
From the vSphere Client, go to Networking >> select a distributed switch >> select a port group >> Configure >> Settings >> Policies >> Edit >> Security. Set "Forged Transmits" to reject. Click "OK". or From a PowerCLI command prompt while connected to the vCenter server, run the following commands: Get-VDSwitch | Get-VDSecurityPolicy | Set-VDSecurityPolicy -ForgedTransmits $false Get-VDPortgroup | ?{$_.IsUplink -eq $false} | Get-VDSecurityPolicy | Set-VDSecurityPolicy -ForgedTransmits $false
If distributed switches are not used, this is not applicable. From the vSphere Client, go to Networking >> select a distributed switch >> select a port group >> Configure >> Settings >> Policies. Verify "MAC Address Changes" is set to reject. or From a PowerCLI command prompt while connected to the vCenter server, run the following commands: Get-VDSwitch | Get-VDSecurityPolicy Get-VDPortgroup | ?{$_.IsUplink -eq $false} | Get-VDSecurityPolicy If the "MAC Address Changes" policy is set to accept, this is a finding.
From the vSphere Client, go to Networking >> select a distributed switch >> select a port group >> Configure >> Settings >> Policies >> Edit >> Security. Set "MAC Address Changes" to reject. Click "OK". or From a PowerCLI command prompt while connected to the vCenter server, run the following commands: Get-VDSwitch | Get-VDSecurityPolicy | Set-VDSecurityPolicy -MacChanges $false Get-VDPortgroup | ?{$_.IsUplink -eq $false} | Get-VDSecurityPolicy | Set-VDSecurityPolicy -MacChanges $false
If distributed switches are not used, this is not applicable. From the vSphere Client, go to Networking >> select a distributed switch >> select a port group >> Configure >> Settings >> Policies. Verify "Promiscuous Mode" is set to reject. or From a PowerCLI command prompt while connected to the vCenter server, run the following commands: Get-VDSwitch | Get-VDSecurityPolicy Get-VDPortgroup | ?{$_.IsUplink -eq $false} | Get-VDSecurityPolicy If the "Promiscuous Mode" policy is set to accept, this is a finding.
From the vSphere Client, go to Networking >> select a distributed switch >> select a port group >> Configure >> Settings >> Policies >> Edit >> Security. Set "Promiscuous Mode" to reject. Click "OK". or From a PowerCLI command prompt while connected to the vCenter server, run the following commands: Get-VDSwitch | Get-VDSecurityPolicy | Set-VDSecurityPolicy -AllowPromiscuous $false Get-VDPortgroup | ?{$_.IsUplink -eq $false} | Get-VDSecurityPolicy | Set-VDSecurityPolicy -AllowPromiscuous $false
If distributed switches are not used, this is not applicable. To view NetFlow Collector IPs configured on distributed switches: From the vSphere Client, go to Networking >> select a distributed switch >> Configure >> Settings >> NetFlow. View the NetFlow pane and verify that any collector IP addresses are valid and in use for troubleshooting. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VDSwitch | select Name,@{N="NetFlowCollectorIPs";E={$_.ExtensionData.config.IpfixConfig.CollectorIpAddress}} To view if NetFlow is enabled on any distributed port groups: From the vSphere Client, go to Networking >> select a distributed port group >> Manage >> Settings >> Policies. Go to Monitoring and view the NetFlow status. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VDPortgroup | select Name,VirtualSwitch,@{N="NetFlowEnabled";E={$_.Extensiondata.Config.defaultPortConfig.ipfixEnabled.Value}} If NetFlow is configured and the collector IP is not known and documented, this is a finding.
To remove collector IPs: From the vSphere Client, go to Networking >> select a distributed switch >> Configure >> Settings >> NetFlow. Click "Edit" and remove any unknown collector IPs. or From a PowerCLI command prompt while connected to the vCenter server, run the following commands: $dvs = Get-VDSwitch dvswitch | Get-View ForEach($vs in $dvs){ $spec = New-Object VMware.Vim.VMwareDVSConfigSpec $spec.configversion = $vs.Config.ConfigVersion $spec.IpfixConfig = New-Object VMware.Vim.VMwareIpfixConfig $spec.IpfixConfig.CollectorIpAddress = "" $spec.IpfixConfig.CollectorPort = "0" $spec.IpfixConfig.ActiveFlowTimeout = "60" $spec.IpfixConfig.IdleFlowTimeout = "15" $spec.IpfixConfig.SamplingRate = "0" $spec.IpfixConfig.InternalFlowsOnly = $False $vs.ReconfigureDvs_Task($spec) } Note: This will reset the NetFlow collector configuration back to the defaults. To disable NetFlow on a distributed port group: From the vSphere Client, go to Networking >> select a distributed port group >> Manage >> Settings >> Policies. Go to "Monitoring" and change "NetFlow" to disabled. or From a PowerCLI command prompt while connected to the vCenter server, run the following commands: $pgs = Get-VDPortgroup | Get-View ForEach($pg in $pgs){ $spec = New-Object VMware.Vim.DVPortgroupConfigSpec $spec.configversion = $pg.Config.ConfigVersion $spec.defaultPortConfig = New-Object VMware.Vim.VMwareDVSPortSetting $spec.defaultPortConfig.ipfixEnabled = New-Object VMware.Vim.BoolPolicy $spec.defaultPortConfig.ipfixEnabled.inherited = $false $spec.defaultPortConfig.ipfixEnabled.value = $false $pg.ReconfigureDVPortgroup_Task($spec) }
If distributed switches are not used, this is not applicable. From the vSphere Client, go to Networking >> select a distributed switch >> select a distributed port group >> Configure >> Settings >> Policies. Review the port group VLAN tags and verify they are not set to the native VLAN ID of the attached physical switch. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VDPortgroup | select Name, VlanConfiguration If any port group is configured with the native VLAN of the ESXi host's attached physical switch, this is a finding.
From the vSphere Client, go to Networking >> select a distributed switch >> select a distributed port group >> Configure >> Settings >> Policies. Click "Edit". Under the VLAN section, change the VLAN ID to a non-native VLAN and click "OK". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VDPortgroup "portgroup name" | Set-VDVlanConfiguration -VlanId "New VLAN#"
If distributed switches are not used, this is not applicable. From the vSphere Client, go to Networking >> select a distributed switch >> select a distributed port group >> Configure >> Settings >> Policies. Review the port group "VLAN Type" and "VLAN trunk range", if present. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VDPortgroup | Where {$_.ExtensionData.Config.Uplink -ne "True"} | select Name,VlanConfiguration If any port group is configured with "VLAN Trunk" and is not documented as a needed exception (such as NSX appliances), this is a finding. If any port group is authorized to be configured with "VLAN trunking" but is not configured with the most limited range necessary, this is a finding.
From the vSphere Client, go to Networking >> select a distributed switch >> select a distributed port group >> Configure >> Settings >> Policies. Click "Edit". Click the "VLAN" tab. If "VLAN trunking" is not authorized, remove it by setting "VLAN type" to "VLAN" and configure an appropriate VLAN ID. Click "OK". If "VLAN trunking" is authorized but the range is too broad, modify the range in the "VLAN trunk range" field to the minimum necessary and authorized range. An example range would be "1,3-5,8". Click "OK". or From a PowerCLI command prompt while connected to the vCenter server, run the following command to configure trunking: Get-VDPortgroup "Portgroup Name" | Set-VDVlanConfiguration -VlanTrunkRange "<VLAN Range(s) comma separated>" or Run this command to configure a single VLAN ID: Get-VDPortgroup "Portgroup Name" | Set-VDVlanConfiguration -VlanId "<New VLAN#>"
If distributed switches are not used, this is not applicable. From the vSphere Client, go to Networking >> select a distributed switch >> select a distributed port group >> Configure >> Settings >> Policies. Review the port group VLAN tags and verify they are not set to a reserved VLAN ID. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VDPortgroup | select Name, VlanConfiguration If any port group is configured with a reserved VLAN ID, this is a finding.
From the vSphere Client, go to Networking >> select a distributed switch >> select a distributed port group >> Configure >> Settings >> Policies. Click "Edit". Under the VLAN section, change the VLAN ID to an unreserved VLAN ID and click "OK". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VDPortgroup "portgroup name" | Set-VDVlanConfiguration -VlanId "New VLAN#"
From the vSphere Client, go to Hosts and Clusters >> select a vCenter Server >> Configure >> Settings >> Advanced Settings. Verify that "VirtualCenter.VimPasswordExpirationInDays" is set to "30". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-AdvancedSetting -Entity <vcenter server name> -Name VirtualCenter.VimPasswordExpirationInDays and verify it is set to 30. If the "VirtualCenter.VimPasswordExpirationInDays" is set to a value other than "30" or does not exist, this is a finding.
From the vSphere Client, go to Hosts and Clusters >> select a vCenter Server >> Configure >> Settings >> Advanced Settings. Click "Edit Settings" and configure the "VirtualCenter.VimPasswordExpirationInDays" value to "30". If the value does not exist, create it by entering the values in the "Key" and "Value" fields and clicking "Add". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: If the setting already exists: Get-AdvancedSetting -Entity <vcenter server name> -Name VirtualCenter.VimPasswordExpirationInDays | Set-AdvancedSetting -Value 30 If the setting does not exist: New-AdvancedSetting -Entity <vcenter server name> -Name VirtualCenter.VimPasswordExpirationInDays -Value 30
From the vSphere Client, go to Hosts and Clusters >> select a vCenter Server >> Configure >> Settings >> Advanced Settings. Verify that "config.vpxd.hostPasswordLength" is set to "32". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-AdvancedSetting -Entity <vcenter server name> -Name config.vpxd.hostPasswordLength Verify it is set to "32". If the "config.vpxd.hostPasswordLength" is set to a value other than "32", this is a finding. If the setting does not exist, this is not a finding.
From the vSphere Client, go to Hosts and Clusters >> select a vCenter Server >> Configure >> Settings >> Advanced Settings. Click "Edit Settings" and configure the "config.vpxd.hostPasswordLength" value to "32". or From a PowerCLI command prompt while connected to the vCenter server run the following command if the setting already exists: Get-AdvancedSetting -Entity <vcenter server name> -Name config.vpxd.hostPasswordLength | Set-AdvancedSetting -Value 32
Check the operational status of the MOB by performing one of the following or both: Browse to the MOB page on the vCenter server: https://<vcenter fqdn or IP>/mob If a "503 Service Unavailable" error is returned, the MOB is disabled. If a prompt for authentication appears, it is enabled. or Run the following command from the vCenter appliance: grep -i "enableDebugBrowse" /etc/vmware-vpx/vpxd.cfg If the MOB is enabled, ask the SA if it is being used for object maintenance and if so, this is not a finding. If the "enableDebugBrowse" element is enabled (set to true) or absent, and object maintenance is not being performed, this is a finding.
If the datastore browser is enabled and required for object maintenance, no fix is immediately required. Disable the managed object browser by editing the /etc/vmware-vpx/vpxd.cfg file. Edit the file and locate the <vpxd> ... </vpxd> element. Add or update the following element in the vpxd section: <enableDebugBrowse>false</enableDebugBrowse> Note: It is not present by default and is case sensitive. Restart the vCenter Service to ensure the configuration file change(s) are in effect by running the following command on the vCenter appliance: service-control --restart vmware-vpxd
Note: For vCenter Server Appliance, this is not applicable. After the Windows server hosting the vCenter Server has been rebooted, a vCenter Server user or member of the user group granted the Administrator role must log in and verify the role permissions remain intact. If the user and/or user group granted vCenter Administrator role permissions cannot be verified as intact, this is a finding.
As the SSO Administrator, log in to the vCenter Server and restore a legitimate Administrator account per site-specific user/group/role requirements.
Note: For vCenter Server Windows, this is not applicable. On the vCenter Server, execute the following command: # grep "^show\.allusers\.tasks" /etc/vmware/vsphere-client/webclient.properties Expected result: show.allusers.tasks = true If the output does not match the expected result, this is a finding.
Navigate to and open /etc/vmware/vsphere-client/webclient.properties. Remove any existing "show.allusers.tasks" line and add the following: show.allusers.tasks = true
Check the following conditions: 1. The Update Manager must be configured to use the Update Manager Download Server. 2. The use of physical media to transfer update files to the Update Manager server (air gap model example: separate Update Manager Download Server, which may source vendor patches externally via the internet versus an internal, organization-defined source) must be enforced with site policies. From the vSphere Client, click Update Manager >> Settings >> Administrative Settings >> Patch Setup and click the "Change Download Source" button. Verify that the "Download patches from a UMDS shared repository" radio button is selected and that a valid UMDS repository is supplied. If "Direct connection to Internet" is configured, this is a finding. If all of the above conditions are not met, this is a finding.
Configure the Update Manager Server to use a separate Update Manager Download Server; the use of physical media to transfer updated files to the Update Manager server (air gap model) must be enforced and documented with organization policies. Configure the Update Manager Download Server and enable the Download Service. Patches must not be directly accessible to the Update Manager Server application from the internet. To configure a web server or local disk repository as a download source (i.e., "Direct connection to Internet" must not be selected as the source), from the vSphere Client/vCenter Server system, click "Update Manager" under "Solutions and Applications". On the "Configuration" tab, under "Settings", click "Download Settings". In the "Download Sources" pane, select "Use a shared repository". Enter the <site-specific> path or the URL to the shared repository. Click "Validate URL" to validate the path. Click "Apply".
Note: For vCenter Server Appliance, this is not applicable. Verify that only the following permissions are allowed on the vCenter database for the following roles and users. vCenter database administrator role used only for initial setup and periodic maintenance of the database: Schema permissions: ALTER, REFERENCES, and INSERT. Permissions CREATE TABLE, CREATE VIEW, and CREATE PROCEDURE vCenter database user role: Schema permissions: SELECT, INSERT, DELETE, UPDATE, and EXECUTE EXECUTE permissions on sp_add_job, sp_delete_job, sp_add_jobstep, sp_update_job, sp_add_jobserver, sp_add_jobschedule, and sp_add_category stored procedures. SELECT permission on syscategories, sysjobsteps, sysjobs_view, and sysjobs tables. vCenter database user: VIEW SERVER STATE and VIEW ANY DEFINITIONS. Equivalent permissions must be set for non-MSSQL databases. If the above database permissions are not set correctly, this is a finding. If the database user role is not assigned to the database account after installation, this is a finding. If the embedded Postgres database is used, this finding is not applicable. For more information, refer to the following website: https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vcenter.install.doc/GUID-66638880-75B5-446E-BD8C-0230FECF60E0.html
Configure correct permissions and roles for SQL: Grant these privileges to a vCenter database administrator role used only for initial setup and periodic maintenance of the database: Schema permissions ALTER, REFERENCES, and INSERT. Permissions CREATE TABLE, VIEW, and CREATE PROCEDURES Grant these privileges to a vCenter database user role: SELECT, INSERT, DELETE, UPDATE, and EXECUTE EXECUTE permissions on sp_add_job, sp_delete_job, sp_add_jobstep, sp_update_job, sp_add_jobserver, sp_add_jobschedule, and sp_add_category stored procedures. SELECT permission on syscategories, sysjobsteps, sysjobs_view, and sysjobs tables. Grant the permissions VIEW SERVER STATE and VIEW ANY DEFINITIONS to the vCenter database user. For more information, refer to the following website: https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vcenter.install.doc/GUID-66638880-75B5-446E-BD8C-0230FECF60E0.html
Verify that each external application that connects to vCenter has a unique service account dedicated to that application. For example, there should be separate accounts for Log Insight, Operations Manager, or anything else that requires an account to access vCenter. If any application shares a service account that is used to connect to vCenter, this is a finding.
For applications sharing service accounts, create a new service account to assign to the application so that no application shares a service account with another. When standing up a new application that requires access to vCenter, always create a new service account prior to installation and grant only the permissions needed for that application.
Verify the vSphere Client used by administrators includes only authorized extensions from trusted sources. From the vSphere Client, go to Administration >> Solutions >> Client Plug-Ins. View the Installed/Available Plug-ins list and verify they are all identified as authorized VMware, third-party (partner), and/or site-specific approved plug-ins. If any Installed/Available plug-ins in the viewable list cannot be verified as an allowed vSphere Client plug-ins from trusted sources, this is a finding.
From the vSphere Client, go to Administration >> Solutions >> Client Plug-Ins. Click the radio button next to the unknown plug-in and click disable. Proceed to uninstall the plug-in. To remove plug-ins: If vCenter Server is in linked mode, perform this procedure on the vCenter Server that is used to install the plug-in initially and then restart the vCenter Server services on the linked vCenter Server. In a web browser, navigate to http://vCenter_Server_name_or_IP/mob. vCenter_Server_name_or_IP/mob is the name of the vCenter Server or its IP address. Click "Content". Click "ExtensionManager". Select and copy the name of the plug-in to be removed from the list of values under "Properties". Click "UnregisterExtension". A new window appears. Paste the name of the plug-in and click "Invoke Method". This removes the plug-in. Close the window. Refresh the "Managed Object Type:ManagedObjectReference:ExtensionManager" window to verify that the plug-in is removed successfully. Note: If the plug-in still appears, restart the vSphere Client. Note: Enable the Managed Object Browser (MOB) temporarily if it was previously disabled.
From the vSphere Client, go to Hosts and Clusters >> select a vCenter Server >> Configure >> Settings >> Advanced Settings. Verify that "config.log.level" value is set to "info". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-AdvancedSetting -Entity <vcenter server name> -Name config.log.level Verify it is set to "info". If the "config.log.level" value is not set to "info" or does not exist, this is a finding.
From the vSphere Client, go to Hosts and Clusters >> select a vCenter Server >> Configure >> Settings >> Advanced Settings. Click "Edit Settings" and configure the "config.log.level" setting to "info". or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-AdvancedSetting -Entity <vcenter server name> -Name config.log.level | Set-AdvancedSetting -Value info
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. View the values of the password format requirements. The following password requirement should be set at a minimum: Minimum Length: 15 If this password policy is not configured as stated, this is a finding.
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. Click "Edit". Set the Minimum Length to "15" and click "OK".
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. View the values of the password format requirements. The following password requirement should be set at a minimum: Upper-case Characters: At least 1 If this password complexity policy is not configured as stated, this is a finding.
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. Click "Edit". Set "Upper-case Characters" to at least "1" and click "OK".
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. View the values of the password format requirements. The following password requirement should be set at a minimum: Lower-case Characters: At least 1 If this password complexity policy is not configured as stated, this is a finding.
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. Click "Edit". Set "Lower-case Characters" to at least "1" and click "OK".
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. View the values of the password format requirements. The following password requirement should be set at a minimum: Numeric Characters: At least 1 If this password complexity policy is not configured as stated, this is a finding.
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. Click "Edit". Set "Numeric Characters" to at least "1" and click "OK".
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. View the values of the password format requirements. The following password requirements should be set at a minimum: Special Characters: At least 1 If this password complexity policy is not configured as stated, this is a finding.
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. Click "Edit". Set "Special Characters" to at least "1" and click "OK".
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Lockout Policy. View the values for the lockout policies. The following lockout policy should be set at follows: Maximum number of failed login attempts: 3 If this account lockout policy is not configured as stated, this is a finding.
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Lockout Policy. Click "Edit". Set the "Maximum number of failed login attempts" to "3" and click "OK".
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Lockout Policy. View the values for the lockout policies. The following lockout policy should be set at follows: Time interval between failures: 900 seconds If this lockout policy is not configured as stated, this is a finding.
From the vSphere Client go to Administration >> Single Sign-On >> Configuration >> Policies >> Lockout Policy. Click "Edit". Set the "Time interval between failures" to "900" and click "OK".
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Lockout Policy. View the values for the lockout policies. The following lockout policy should be set at follows: Unlock time: 0 If this account lockout policy is not configured as stated, this is a finding.
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Policies >> Lockout Policy. Click "Edit". Set the "Unlock time" to "0" and click "OK".
From the vSphere Client, go to Administration >> Access Control >> Roles. View each role and verify the users and/or groups assigned to it. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VIPermission | Sort Role | Select Role,Principal,Entity,Propagate,IsGroup | FT -Auto Application service account and user required privileges should be documented. If any user or service account has more privileges than required, this is a finding.
To create a new role with specific permissions: From the vSphere Client, go to Administration >> Access Control >> Roles. Click the plus sign, enter a name for the role, and select only the specific permissions required. Users can then be assigned to the newly created role.
If IP-based storage is not used, this is not applicable. IP-based storage (iSCSI, NFS, vSAN) VMkernel port groups must be in a dedicated VLAN that can be on a standard or distributed virtual switch that is logically separated from other traffic types. The check for this will be unique per environment. To check a standard switch, from the vSphere Client select the ESXi host and go to Configure >> Networking >> Virtual switches. Select a standard switch. For each storage port group (iSCSI, NFS, vSAN), select the port group and click the "Details" button. Note the VLAN ID associated with each port group and verify that it is dedicated to that purpose and is logically separated from other traffic types. To check a distributed switch, from the vSphere Client go to Networking >> select and expand a distributed switch. For each storage port group (iSCSI, NFS, vSAN), select the port group and navigate to the "Summary" tab. Note the VLAN ID associated with each port group and verify that it is dedicated to that purpose and is logically separated from other traffic types. If any IP-based storage networks are not isolated from other traffic types, this is a finding.
Configuration of an IP-based VMkernel will be unique to each environment but, for example, to modify the IP address and VLAN information to the correct network on a standard switch for an iSCSI VMkernel, do the following: From the vSphere Client, select the ESXi host and go to Configure >> Networking >> VMkernel adapters. Select the Storage VMkernel (for any IP-based storage) and click the "Edit" button. On the Port properties tab, uncheck everything (unless vSAN). On the IP Settings tab, enter the appropriate IP address and subnet information and click "OK". To configure a standard switch, from the vSphere Client, select the ESXi host and go to Configure >> Networking >> Virtual switches. Select a standard switch. For each storage port group (iSCSI, NFS, vSAN), select the port group and click the "Edit" button. On the properties page, enter the appropriate VLAN ID and click "OK". To configure a distributed switch, from the vSphere Client, go to Networking. Select and expand a distributed switch. For each storage port group (iSCSI, NFS, vSAN), select the port group and navigate to Configure >> Settings >> Properties. Click the "Edit" button. On the VLAN page, enter the appropriate VLAN type and ID and click "OK".
If no clusters are enabled for vSAN, this is not applicable. From the vSphere Client, go to Hosts and Clusters >> select the vCenter Server >> Configure >> vSAN >> Internet Connectivity. If the HCL internet download is not required, verify that "Status" is disabled. If the "Status" is enabled, this is a finding. If the HCL internet download is required, verify that "Status" is enabled and a proxy host is configured. If "Status" is enabled and a proxy is not configured, this is a finding.
From the vSphere Client, go to Hosts and Clusters >> vCenter Server >> Configure >> vSAN >> Internet Connectivity >> Edit. If the HCL internet download is not required, ensure that "Status" is disabled. If the HCL internet download is required, ensure that "Status" is enabled and a proxy host is appropriately configured.
If no clusters are enabled for vSAN, this is not applicable. From the vSphere Client, go to Hosts and Clusters >> select a vSAN Enabled Cluster >> Datastores. Review the datastores. Identify any datastores with "vSAN" as the datastore type. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: If($(Get-Cluster | where {$_.VsanEnabled} | Measure).Count -gt 0){ Write-Host "vSAN Enabled Cluster found" Get-Cluster | where {$_.VsanEnabled} | Get-Datastore | where {$_.type -match "vsan"} } else{ Write-Host "vSAN is not enabled, this finding is not applicable" } If vSAN is enabled and the datastore is named "vsanDatastore", this is a finding.
From the vSphere Client, go to Hosts and Clusters >> select a vSAN Enabled Cluster >> Datastores. Right-click on the datastore named "vsanDatastore" and select "Rename". Rename the datastore based on site-specific naming standards. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: If($(Get-Cluster | where {$_.VsanEnabled} | Measure).Count -gt 0){ Write-Host "vSAN Enabled Cluster found" $Clusters = Get-Cluster | where {$_.VsanEnabled} Foreach ($clus in $clusters){ $clus | Get-Datastore | where {$_.type -match "vsan"} | Set-Datastore -Name $(($clus.name) + "_vSAN_Datastore") } } else{ Write-Host "vSAN is not enabled, this finding is not applicable" }
Note: For vCenter Server Windows, this is not applicable. On the vCenter Server, execute the following command: # $(find /usr/lib -name reconfigureVc) scan If the output indicates versions of TLS other than 1.2 are enabled, this is a finding.
On the vCenter Server, execute the following commands: # $(find /usr/lib -name reconfigureVc) backup # $(find /usr/lib -name reconfigureVc) update -p TLS1.2 vCenter services will be restarted as part of the reconfiguration, the OS will not be restarted. You can add the --no-restart flag to restart services at a later time. Changes will not take effect until all services are restarted or the machine is rebooted.
From the vSphere Client, go to Administration >> Certificates >> Certificate Management >> Machine SSL Certificate. Click "View Details". Examine the "Issuer Information" block. If the issuer specified is not a DoD-approved certificate authority (or other AO approved CA), this is a finding.
Obtain a DoD-issued certificate and private key for each vCenter in the system, following these requirements: Key size: 2048 bits or more (PEM encoded) CRT format (Base-64) x509 version 3 SubjectAltName must contain DNS Name=<machine_FQDN> Contains the following Key Usages: Digital Signature, Non Repudiation, Key Encipherment Ensure that the certificate includes all intermediates and root certificates. If it does not, export the entire certificate issuing chain up to the root in Base-64 format and concatenate the individual certificates onto the issued certificate. From the vSphere Client, go to Administration >> Certificates >> Certificate Management >> Machine SSL Certificate. Click Actions >> Replace. Supply the CA-issued certificate with the exported roots file and the private key. Click "Replace".
See supplemental document. Ensure that CAC authentication is required to log in to the vSphere Client. If CAC authentication is not required, this is a finding.
Configure CAC Authentication per supplemental document.
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Smart Card Authentication. Under Smart card authentication settings >> Certificate revocation, verify that "Revocation check" does not show as disabled. If "Revocation check" shows as disabled, this is a finding.
From the vSphere Client, go to Administration >> Single Sign-On > Configuration >> Smart Card Authentication. Under Smart card authentication settings >> Certificate revocation, click the "Edit" button. By default, the PSC will use the CRL from the certificate to check revocation check status. OCSP with CRL fallback is recommended, but this setting is site specific and should be configured appropriately.
Note: For vCenter Server Windows, this is not applicable. From the vSphere Client go to Administration >> Single Sign-On >> Configuration >> Smart Card Authentication. If "Smart card authentication" is not enabled and "Password and windows session authentication" is not disabled, this is a finding.
From the vSphere Client go to Administration >> Single Sign-On >> Configuration >> Smart Card Authentication. Next to "Authentication methods", click "Edit". Click the "Enable smart card authentication" radio button and click "Save". To re-enable password authentication for troubleshooting purposes, run the following command on the vCenter server: /opt/vmware/bin/sso-config.sh -set_authn_policy -pwdAuthn true -winAuthn false -certAuthn false -securIDAuthn false -t vsphere.local
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Login Message. If selection boxes next to "Show login message" are disabled or if "Details of login message" is not configured to the standard DoD User Agreement, this is a finding. Note: Supplementary Information: DoD Logon Banner "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Login Message. Click "Edit". Click the "Show login message" slider to enable. Configure the "Login message" to "DoD User Agreement". Click the "Consent checkbox" slider to enable. Set the "Details of login message" to the standard DoD User Agreement text. Click "Save".
From the vSphere Client, go to Administration >> Access Control >> Roles. or From a PowerCLI command prompt while connected to the vCenter server, run the following command: Get-VIPermission | Where {$_.Role -eq "Admin"} | Select Role,Principal,Entity,Propagate,IsGroup | FT -Auto If there are any users other than Solution Users with the "Administrator" role that are not explicitly designated for cryptographic operations, this is a finding.
From the vSphere Client, go to Administration >> Access Control >> Roles. Move any accounts not explicitly designated for cryptographic operations, other than Solution Users, to other roles such as "No Cryptography Administrator".
From the vSphere Client, go to Administration >> Access Control >> Roles. Highlight each role and click the "Privileges" button in the right pane. Verify that only the Administrator and any site-specific cryptographic group(s) have the following permissions: Cryptographic Operations privileges Global.Diagnostics Host.Inventory.Add host to cluster Host.Inventory.Add standalone host Host.Local operations.Manage user groups or From a PowerCLI command prompt while connected to the vCenter server, run the following command: $roles = Get-VIRole ForEach($role in $roles){ $privileges = $role.PrivilegeList If($privileges -match "Crypto*" -or $privileges -match "Global.Diagnostics" -or $privileges -match "Host.Inventory.Add*" -or $privileges -match "Host.Local operations.Manage user groups"){ Write-Host "$role has Cryptographic privileges" } } If any role other than Administrator and any site-specific group(s) have any of these permissions, this is a finding.
From the vSphere Client, go to Administration >> Access Control >> Roles. Highlight each role and click the pencil button if it is enabled. Remove the following permissions from any group other than Administrator and any site-specific cryptographic group(s): Cryptographic Operations privileges Global.Diagnostics Host.Inventory.Add host to cluster Host.Inventory.Add standalone host Host.Local operations.Manage user groups
If no clusters are enabled for vSAN or if vSAN is enabled but iSCSI is not enabled, this is not applicable. From the vSphere Client, go to Hosts and Clusters >> select a vSAN Enabled Cluster >> Configure >> vSAN >> iSCSI Target Service. For each iSCSI target, review the value in the "Authentication" column. If the Authentication method is not set to "CHAP_Mutual" for any iSCSI target, this is a finding.
From the vSphere Client, go to Hosts and Clusters >> select a vSAN Enabled Cluster >> Configure >> vSAN >> iSCSI Target Service. For each iSCSI target, select the item and click "Edit". Change the "Authentication" field to "Mutual CHAP" and configure the incoming and outgoing users and secrets appropriately.
Interview the SA to determine that a procedure has been implemented to perform a mustow rekey of all vSAN encrypted datastores at regular, site-defined intervals. VMware recommends a 60-day rekey task, but this interval must be defined by the SA and the ISSO. If vSAN encryption is not in use, this is not a finding.
If vSAN encryption is in use, ensure that a regular rekey procedure is in place.
From the vSphere Client, go to Administration >> Deployment >> Customer Experience Improvement Program. If Customer Experience Improvement "Program Status" is "Joined", this is a finding.
From the vSphere Client, go to Administration >> Deployment >> Customer Experience Improvement Program. Click the "Leave" button.
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration. Click the "Identity Sources" tab. For each identity source of type "Active Directory", if the "Server URL" does not indicate "ldaps://", this is a finding.
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration. Click the "Identity Sources" tab. For each identity source of type "Active Directory" where LDAPS is not configured, highlight the item and click "Edit". Ensure the primary and secondary server URLs, if specified, are configured for "ldaps://". At the bottom, click the "Browse" button, select the AD LDAP cert previously exported to the local computer, click "Open", and "Save" to complete modifications. Note: With LDAPS, the server must be a specific domain controller and its specific certificate or the domain alias with a certificate that is valid for that URL.
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration. Click the "Identity Sources" tab. For each identity source with of type "Active Directory", highlight the item and click "Edit". If the account that is configured to bind to the LDAPS server is not one with minimal privileges, this is a finding.
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration. Click the "Identity Sources" tab. For each identity source that has been configured with a highly privileged AD account, highlight the item and click "Edit". Change the username and password to one with read-only rights to the base DN and complete the dialog.
Note: For vCenter Server Appliance, this is not applicable. On the vCenter Server locate the "webclient.properties" file in C:\ProgramData\VMware\vCenterServer\cfg\vsphere-client Find the "refresh.rate =" line in the "webclient.properties" file. If the refresh rate is not set to "-1" in the "webclient.properties" file, this is a finding.
Change the refresh rate value by editing the "webclient.properties" file. On the vCenter Server locate the "webclient.properties" file in C:\ProgramData\VMware\vCenterServer\cfg\vsphere-client Edit the file to include the line "refresh.rate = -1" where "-1" indicates sessions are not automatically refreshed. Uncomment the line if necessary. After editing the file the vSphere Client service must be restarted.
Note: For vCenter Server Appliance, this is not applicable. By default, vSphere Client sessions terminate after "120" minutes of idle time, requiring the user to log in again to resume using the client. You can view the timeout value by viewing the "webclient.properties" file. On the vCenter Server locate the "webclient.properties" file in C:\ProgramData\VMware\vCenterServer\cfg\vsphere-client Find the "session.timeout =" line in the "webclient.properties" file. If the session timeout is not set to "10" in the "webclient.properties" file, this is a finding.
Change the timeout value by editing the "webclient.properties" file. On the vCenter Server locate the "webclient.properties" file in C:\ProgramData\VMware\vCenterServer\cfg\vsphere-client Edit the file to include the line "session.timeout = 10" where "10" is the timeout value in minutes. Uncomment the line if necessary. After editing the file the vSphere Client service must be restarted.
Note: For vCenter Server Appliance, this is not applicable. The following services should be set to run as a service account: VMware Content Library Service VMware Inventory Service VMware Performance Charts VMware VirtualCenter Server vCenter should be installed using the service account as that will configure the services appropriately. If vCenter is not installed with a service account, this is a finding. If the services identified in this control are not running as a service account, this is a finding.
For each of the following services open the services console on the vCenter server and right-click, select "Properties" on the service. Go to the "Log On" tab and configure the service to run as a service account and restart the service. VMware Content Library Service VMware Inventory Service VMware Performance Charts VMware VirtualCenter Server
Note: For vCenter Server Appliance, this is not applicable. Login to the vCenter server and verify the only local administrators group contains users and/or groups that contain vCenter Administrators. If the local administrators group contains users and/or groups that are not vCenter Administrators such as "Domain Admins", this is a finding.
Remove all unnecessary users and/or groups from the local administrators group of the vCenter server.
Note: For vCenter Server Appliance, this is not applicable. If at any time a vCenter Server installation fails, only the log files of format "hs_err_pid...." should be identified on the Windows host and deleted securely before putting the host into production. Determine if a site policy exists for handling failed installation cleanup of the Windows host prior to deployment. Using the Windows host search function, determine the existence of any log files of format "hs_err_pid". If a file name of the format "hs_err_pid" is found, this is a finding. If a site policy does not exist and/or is not followed, this is a finding.
Develop a site policy for handling failed installation cleanup of the Windows host prior to deployment. Using the Windows host search function, determine the existence of any log files of format "hs_err_pid" and remove them.
Note: For vCenter Server Appliance, this is not applicable. Verify the "webclient.properties" file contains the line "show.allusers.tasks = true". On the vCenter Server locate the "webclient.properties" file in C:\ProgramData\VMware\vCenterServer\cfg\vsphere-client If "show.allusers.tasks" is not set to "true", this is a finding.
Edit the "webclient.properties" file to set the "show.allusers.tasks" value to "true". On the vCenter Server locate the "webclient.properties" file in C:\ProgramData\VMware\vCenterServer\cfg\vsphere-client After editing the file the vSphere Client service will need to be restarted.
Note: For vCenter Server Appliance, this is not applicable. If enhanced linked mode is used then local windows authentication is not available to vCenter, this is not applicable. Under the computer management console for windows view the local administrators group and verify only vCenter administrators have access to the vCenter server. Other groups and users that are not vCenter administrators should be removed from the local administrators group such as Domain Admins. If there are any groups or users present in the local administrators group of the vCenter server, this is a finding.
Under the computer management console for windows view the local administrators group and remove any users or groups that do not fit the criteria defined in the check content.
Note: For vCenter Server Appliance, this is not applicable. Download the VMware TLS Reconfigurator utility from my.vmware.com. Follow installation instructions for your vCenter platform according to VMware KB 2147469. 1. Open a command prompt and cd to C:\Program Files\VMware\CIS\vSphereTlsReconfigurator\VcTlsReconfigurator 2. Enter command "reconfigureVc scan" and press "Enter" If the output indicates versions of TLS other than 1.2 are enabled, this is a finding.
Download the VMware TLS Reconfigurator utility from my.vmware.com. Follow installation instructions for your vCenter platform according to VMware KB 2147469. Run the following commands. 1. Open a command prompt and cd to C:\Program Files\VMware\CIS\vSphereTlsReconfigurator\VcTlsReconfigurator 2. Enter command "reconfigureVc backup" and press "Enter" 3. Enter command "reconfigureVc update -p TLS1.2" and press "Enter" vCenter services will be restarted as part of the reconfiguration, the OS will not be restarted. You can add the --no-restart flag to restart services at a later time. Changes will not take effect until all services are restarted or the machine is rebooted.
Note: For vCenter Server Appliance, this is not applicable. From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Smart Card Authentication. If "Smart card authentication" is not enabled and "Password and windows session authentication" is not disabled, this is a finding.
From the vSphere Client, go to Administration >> Single Sign-On >> Configuration >> Smart Card Authentication. Next to "Authentication methods", click "Edit". Click the "Enable smart card authentication" radio button and click "Save". To reenable password authentication for troubleshooting purposes, run the following command on the vCenter server: C:\Program Files\VMware\VCenter server\VMware Identity Services\sso-config.bat -set_authn_policy -pwdAuthn true -winAuthn false -certAuthn false -securIDAuthn false -t vsphere.local
vCenter 6.7 is no longer supported by the vendor. If the system is running vCenter 6.7, this is a finding.
Upgrade to a supported version.