mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-05-13 13:57:22 +00:00
Merge branch 'master' of https://cpubwin.visualstudio.com/_git/it-client into HApubpreview3
This commit is contained in:
commit
1b16fb2022
@ -114,7 +114,7 @@ User rights grant specific privileges and sign-in rights to users and groups in
|
||||
|
||||
User rights are different from permissions because user rights apply to user accounts, and permissions are associated with objects. Although user rights can apply to individual user accounts, user rights are best administered on a group account basis. There is no support in the access control user interface to grant user rights. However, user rights assignment can be administered through **Local Security Settings**.
|
||||
|
||||
For more information about user rights, see [User Rights Assignment](/windows/device-security/security-policy-settings/access-user-rights-assignment).
|
||||
For more information about user rights, see [User Rights Assignment](/windows/device-security/security-policy-settings/user-rights-assignment).
|
||||
|
||||
## Object auditing
|
||||
|
||||
|
@ -15,14 +15,18 @@ author: brianlic-msft
|
||||
- Windows 10
|
||||
- Windows Server 2016
|
||||
|
||||
Credential Guard has certain application requirements. Credential Guard blocks specific authentication capabilities. Therefore applications that require such capabilities will not function when Credential Guard is enabled. For further information, see [Application requirements](https://docs.microsoft.com/en-us/windows/access-protection/credential-guard/credential-guard-requirements#application-requirements).
|
||||
Credential Guard has certain application requirements. Credential Guard blocks specific authentication capabilities. Therefore applications that require such capabilities will not function when Credential Guard is enabled. For further information, see [Application requirements](https://docs.microsoft.com/windows/access-protection/credential-guard/credential-guard-requirements#application-requirements).
|
||||
|
||||
The following known issue has been fixed by servicing releases made available in the Cumulative Security Updates for April 2017:
|
||||
The following known issues have been fixed by servicing releases made available in the Cumulative Security Updates for April 2017:
|
||||
|
||||
- [KB4015217 Credential Guard generates double bad password count on Active Directory domain-joined Windows 10 machines](https://support.microsoft.com/en-us/help/4015217/windows-10-update-kb4015217)
|
||||
- [KB4015217 Credential Guard generates double bad password count on Active Directory domain-joined Windows 10 machines](https://support.microsoft.com/help/4015217/windows-10-update-kb4015217)
|
||||
|
||||
This issue can potentially lead to unexpected account lockouts. See also Microsoft® Knowledge Base articles [KB4015219](https://support.microsoft.com/help/4015219/windows-10-update-kb4015219) and [KB4015221](https://support.microsoft.com/help/4015221/windows-10-update-kb4015221)
|
||||
|
||||
- [KB4033236 Two incorrect logon attempts sent to Active Directory after Credential Guard installed on Windows 10](https://support.microsoft.com/help/4033236/two-incorrect-logon-attempts-sent-to-active-directory-after-credential?preview)
|
||||
|
||||
See also Microsoft Knowledge Base article [KB4015217](https://internal.support.services.microsoft.com/help/4015217/windows-10-update-kb4015217)
|
||||
|
||||
This issue can potentially lead to unexpected account lockouts. See also Microsoft® Knowledge Base articles [KB4015219](https://support.microsoft.com/en-us/help/4015219/windows-10-update-kb4015219) and
|
||||
[KB4015221](https://support.microsoft.com/en-us/help/4015221/windows-10-update-kb4015221)
|
||||
|
||||
The following issue affects Cisco AnyConnect Secure Mobility Client:
|
||||
|
||||
@ -43,7 +47,7 @@ The following issue affects Citrix applications:
|
||||
|
||||
<sup>[1]</sup> Products that connect to Virtualization Based Security (VBS) protected processes can cause Credential Guard-enabled Windows 10 or Windows Server 2016 machines to exhibit high CPU usage. For technical and troubleshooting information, see the following Microsoft Knowledge Base article:
|
||||
|
||||
- [KB4032786 High CPU usage in the LSAISO process on Windows 10 or Windows Server 2016](https://support.microsoft.com/en-us/help/4032786)
|
||||
- [KB4032786 High CPU usage in the LSAISO process on Windows 10 or Windows Server 2016](https://support.microsoft.com/help/4032786)
|
||||
|
||||
For further technical information on LSAISO.exe, see the MSDN article: [Isolated User Mode (IUM) Processes](https://msdn.microsoft.com/library/windows/desktop/mt809132(v=vs.85).aspx)
|
||||
|
||||
|
@ -22,10 +22,9 @@ in the Deep Dive into Credential Guard video series.
|
||||
For Credential Guard to provide protections, the computers you are protecting must meet certain baseline hardware, firmware, and software requirements which we will refer to as [Hardware and software requirements](#hardware-and-software-requirements). Additionally, Credential Guard blocks specific authentication capabilities, so applications that require such capabilities will break. We will refer to this as [Application requirements](#application-requirements). Beyond that, computers can meet additional hardware and firmware qualifications, and receive additional protections. Those computers will be more hardened against certain threats. For detailed information on baseline protections, plus protections for improved security that are associated with hardware and firmware options available in 2015, 2016, and 2017, refer to the tables in [Security Considerations](#security-considerations).
|
||||
|
||||
|
||||
|
||||
## Hardware and software requirements
|
||||
|
||||
To provide basic protection against OS level attempts to read Credential Manager domain credentials, NTLM and Kerberos derived credentials, Credential Guard uses:
|
||||
To provide basic protections against OS level attempts to read Credential Manager domain credentials, NTLM and Kerberos derived credentials, Credential Guard uses:
|
||||
- Support for Virtualization-based security (required)
|
||||
- Secure boot (required)
|
||||
- TPM 2.0 either discrete or firmware (preferred - provides binding to hardware)
|
||||
@ -75,25 +74,26 @@ The following tables describe baseline protections, plus protections for improve
|
||||
|
||||
### Baseline protections
|
||||
|
||||
|Baseline Protections | Description |
|
||||
|---------------------------------------------|----------------------------------------------------|
|
||||
|Baseline Protections | Description | Security benefits
|
||||
|---|---|---|
|
||||
| Hardware: **64-bit CPU** | A 64-bit computer is required for the Windows hypervisor to provide VBS. |
|
||||
| Hardware: **CPU virtualization extensions**,<br>plus **extended page tables** | **Requirements**: These hardware features are required for VBS:<br>One of the following virtualization extensions:<br>• VT-x (Intel) or<br>• AMD-V<br>And:<br>• Extended page tables, also called Second Level Address Translation (SLAT).<br><br>**Security benefits**: VBS provides isolation of secure kernel from normal operating system. Vulnerabilities and Day 0s in normal operating system cannot be exploited because of this isolation. |
|
||||
| Hardware: **Trusted Platform Module (TPM)** | **Requirement**: TPM 1.2 or TPM 2.0, either discrete or firmware.<br>[TPM recommendations](https://technet.microsoft.com/itpro/windows/keep-secure/tpm-recommendations)<br><br>**Security benefits**: A TPM provides protection for VBS encryption keys that are stored in the firmware. This helps protect against attacks involving a physically present user with BIOS access. |
|
||||
| Firmware: **UEFI firmware version 2.3.1.c or higher with UEFI Secure Boot** | **Requirements**: See the following Windows Hardware Compatibility Program requirement: [System.Fundamentals.Firmware.UEFISecureBoot](http://msdn.microsoft.com/library/windows/hardware/dn932805.aspx#system-fundamentals-firmware-uefisecureboot)<br><br>**Security benefits**: UEFI Secure Boot helps ensure that the device boots only authorized code. This can prevent boot kits and root kits from installing and persisting across reboots. |
|
||||
| Firmware: **Secure firmware update process** | **Requirements**: UEFI firmware must support secure firmware update found under the following Windows Hardware Compatibility Program requirement: [System.Fundamentals.Firmware.UEFISecureBoot](http://msdn.microsoft.com/library/windows/hardware/dn932805.aspx#system-fundamentals-firmware-uefisecureboot).<br><br>**Security benefits**: UEFI firmware just like software can have security vulnerabilities that, when found, need to be patched through firmware updates. Patching helps prevent root kits from getting installed. |
|
||||
| Software: Qualified **Windows operating system** | **Requirement**: Windows 10 Enterprise, Windows 10 Education, Windows Server 2016, or Windows 10 IoT Enterprise<br><blockquote><p><strong>Important:</strong><br> Windows Server 2016 running as a domain controller does not support Credential Guard. Only Device Guard is supported in this configuration.</p></blockquote><br>**Security benefits**: Support for VBS and for management features that simplify configuration of Credential Guard. |
|
||||
| Hardware: **CPU virtualization extensions**,<br>plus **extended page tables** | **Requirements**: These hardware features are required for VBS:<br>One of the following virtualization extensions:<br>• VT-x (Intel) or<br>• AMD-V<br>And:<br>• Extended page tables, also called Second Level Address Translation (SLAT). | VBS provides isolation of secure kernel from normal operating system. Vulnerabilities and Day 0s in normal operating system cannot be exploited because of this isolation. |
|
||||
| Hardware: **Trusted Platform Module (TPM)** | **Requirement**: TPM 1.2 or TPM 2.0, either discrete or firmware.<br>[TPM recommendations](https://technet.microsoft.com/itpro/windows/keep-secure/tpm-recommendations) | A TPM provides protection for VBS encryption keys that are stored in the firmware. This helps protect against attacks involving a physically present user with BIOS access. |
|
||||
| Firmware: **UEFI firmware version 2.3.1.c or higher with UEFI Secure Boot** | **Requirements**: See the following Windows Hardware Compatibility Program requirement: [System.Fundamentals.Firmware.UEFISecureBoot](http://msdn.microsoft.com/library/windows/hardware/dn932805.aspx#system-fundamentals-firmware-uefisecureboot)| UEFI Secure Boot helps ensure that the device boots only authorized code. This can prevent boot kits and root kits from installing and persisting across reboots. |
|
||||
| Firmware: **Secure firmware update process** | **Requirements**: UEFI firmware must support secure firmware update found under the following Windows Hardware Compatibility Program requirement: [System.Fundamentals.Firmware.UEFISecureBoot](http://msdn.microsoft.com/library/windows/hardware/dn932805.aspx#system-fundamentals-firmware-uefisecureboot).| UEFI firmware just like software can have security vulnerabilities that, when found, need to be patched through firmware updates. Patching helps prevent root kits from getting installed. |
|
||||
| Software: Qualified **Windows operating system** | **Requirement**: Windows 10 Enterprise, Windows 10 Education, Windows Server 2016, or Windows 10 IoT Enterprise<br><blockquote><p><strong>Important:</strong><br> Windows Server 2016 running as a domain controller does not support Credential Guard. Only Device Guard is supported in this configuration.</p></blockquote> |Support for VBS and for management features that simplify configuration of Credential Guard. |
|
||||
|
||||
> [!IMPORTANT]
|
||||
> The following tables list additional qualifications for improved security. We strongly recommend meeting the additional qualifications to significantly strengthen the level of security that Credential Guard can provide.
|
||||
|
||||
|
||||
### 2015 Additional security qualifications starting with Windows 10, version 1507, and Windows Server 2016 Technical Preview 4
|
||||
|
||||
| Protections for Improved Security | Description |
|
||||
|---------------------------------------------|----------------------------------------------------|
|
||||
| Hardware: **IOMMU** (input/output memory management unit) | **Requirement**: VT-D or AMD Vi IOMMU<br><br>**Security benefits**: An IOMMU can enhance system resiliency against memory attacks. For more information, see [ACPI description tables](https://msdn.microsoft.com/windows/hardware/drivers/bringup/acpi-system-description-tables). |
|
||||
| Firmware: **Securing Boot Configuration and Management** | **Requirements**:<br>• BIOS password or stronger authentication must be supported.<br>• In the BIOS configuration, BIOS authentication must be set.<br>• There must be support for protected BIOS option to configure list of permitted boot devices (for example, “Boot only from internal hard drive”) and boot device order, overriding BOOTORDER modification made by operating system.<br>• In the BIOS configuration, BIOS options related to security and boot options (list of permitted boot devices, boot order) must be secured to prevent other operating systems from starting and to prevent changes to the BIOS settings.<br><br>**Security benefits**:<br>• BIOS password or stronger authentication helps ensure that only authenticated Platform BIOS administrators can change BIOS settings. This helps protect against a physically present user with BIOS access.<br>• Boot order when locked provides protection against the computer being booted into WinRE or another operating system on bootable media. |
|
||||
| Firmware: **Secure MOR, revision 2 implementation** | **Requirement**: Secure MOR, revision 2 implementation<br><br>**Security benefits**: A secure MOR bit prevents advanced memory attacks. For more information, see [Secure MOR implementation](https://msdn.microsoft.com/windows/hardware/drivers/bringup/device-guard-requirements). |
|
||||
| Hardware: **IOMMU** (input/output memory management unit) | **Requirement**: VT-D or AMD Vi IOMMU **Security benefits**: An IOMMU can enhance system resiliency against memory attacks. For more information, see [ACPI description tables](https://msdn.microsoft.com/windows/hardware/drivers/bringup/acpi-system-description-tables). |
|
||||
| Firmware: **Securing Boot Configuration and Management** | **Requirements**:<br>• BIOS password or stronger authentication must be supported.<br>• In the BIOS configuration, BIOS authentication must be set.<br>• There must be support for protected BIOS option to configure list of permitted boot devices (for example, “Boot only from internal hard drive”) and boot device order, overriding BOOTORDER modification made by operating system.<br>• In the BIOS configuration, BIOS options related to security and boot options (list of permitted boot devices, boot order) must be secured to prevent other operating systems from starting and to prevent changes to the BIOS settings. | **Security benefits**:<br>• BIOS password or stronger authentication helps ensure that only authenticated Platform BIOS administrators can change BIOS settings. This helps protect against a physically present user with BIOS access.<br>• Boot order when locked provides protection against the computer being booted into WinRE or another operating system on bootable media. |
|
||||
| Firmware: **Secure MOR, revision 2 implementation** | **Requirement**: Secure MOR, revision 2 implementation | **Security benefits**: A secure MOR bit prevents advanced memory attacks. For more information, see [Secure MOR implementation](https://msdn.microsoft.com/windows/hardware/drivers/bringup/device-guard-requirements). |
|
||||
|
||||
<br>
|
||||
|
||||
@ -102,11 +102,11 @@ The following tables describe baseline protections, plus protections for improve
|
||||
> [!IMPORTANT]
|
||||
> The following tables list additional qualifications for improved security. Systems that meet these additional qualifications can provide more protections.
|
||||
|
||||
| Protections for Improved Security | Description |
|
||||
|---------------------------------------------|----------------------------------------------------|
|
||||
| Firmware: **Hardware Rooted Trust Platform Secure Boot** | **Requirements**:<br>Boot Integrity (Platform Secure Boot) must be supported. See the Windows Hardware Compatibility Program requirements under [System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby](https://msdn.microsoft.com/library/windows/hardware/dn932807(v=vs.85).aspx#system_fundamentals_firmware_cs_uefisecureboot_connectedstandby)<br>• The Hardware Security Test Interface (HSTI) must be implemented. See [Hardware Security Testability Specification](https://msdn.microsoft.com/en-us/library/windows/hardware/mt712332(v=vs.85).aspx).<br><br>**Security benefits**:<br>• Boot Integrity (Platform Secure Boot) from Power-On provides protections against physically present attackers, and defense-in-depth against malware.<br>• HSTI provides additional security assurance for correctly secured silicon and platform. |
|
||||
| Firmware: **Firmware Update through Windows Update** | **Requirements**: Firmware must support field updates through Windows Update and UEFI encapsulation update.<br><br>**Security benefits**: Helps ensure that firmware updates are fast, secure, and reliable. |
|
||||
| Firmware: **Securing Boot Configuration and Management** | **Requirements**:<br>• Required BIOS capabilities: Ability of OEM to add ISV, OEM, or Enterprise Certificate in Secure Boot DB at manufacturing time.<br>• Required configurations: Microsoft UEFI CA must be removed from Secure Boot DB. Support for 3rd-party UEFI modules is permitted but should leverage ISV-provided certificates or OEM certificate for the specific UEFI software.<br><br>**Security benefits**:<br>• Enterprises can choose to allow proprietary EFI drivers/applications to run.<br>• Removing Microsoft UEFI CA from Secure Boot DB provides full control to enterprises over software that runs before the operating system boots. |
|
||||
| Protections for Improved Security | Description |Security Benefits |
|
||||
|---|---|---|
|
||||
| Firmware: **Hardware Rooted Trust Platform Secure Boot** | **Requirements**:<br>Boot Integrity (Platform Secure Boot) must be supported. See the Windows Hardware Compatibility Program requirements under [System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby](https://msdn.microsoft.com/library/windows/hardware/dn932807(v=vs.85).aspx#system_fundamentals_firmware_cs_uefisecureboot_connectedstandby)<br>• The Hardware Security Test Interface (HSTI) must be implemented. See [Hardware Security Testability Specification](https://msdn.microsoft.com/en-us/library/windows/hardware/mt712332(v=vs.85).aspx). | Boot Integrity (Platform Secure Boot) from Power-On provides protections against physically present attackers, and defense-in-depth against malware.<br>• HSTI provides additional security assurance for correctly secured silicon and platform. |
|
||||
| Firmware: **Firmware Update through Windows Update** | **Requirements**: Firmware must support field updates through Windows Update and UEFI encapsulation update. | Helps ensure that firmware updates are fast, secure, and reliable. |
|
||||
| Firmware: **Securing Boot Configuration and Management** | **Requirements**:<br>• Required BIOS capabilities: Ability of OEM to add ISV, OEM, or Enterprise Certificate in Secure Boot DB at manufacturing time.<br>• Required configurations: Microsoft UEFI CA must be removed from Secure Boot DB. Support for 3rd-party UEFI modules is permitted but should leverage ISV-provided certificates or OEM certificate for the specific UEFI software. | • Enterprises can choose to allow proprietary EFI drivers/applications to run.<br>• Removing Microsoft UEFI CA from Secure Boot DB provides full control to enterprises over software that runs before the operating system boots. |
|
||||
|
||||
<br>
|
||||
|
||||
@ -114,7 +114,7 @@ The following tables describe baseline protections, plus protections for improve
|
||||
|
||||
The following table lists qualifications for Windows 10, version 1703, which are in addition to all preceding qualifications.
|
||||
|
||||
| Protection for Improved Security | Description |
|
||||
|---------------------------------------------|----------------------------------------------------|
|
||||
| Firmware: **VBS enablement of NX protection for UEFI runtime services** | **Requirements**:<br>• VBS will enable No-Execute (NX) protection on UEFI runtime service code and data memory regions. UEFI runtime service code must support read-only page protections, and UEFI runtime service data must not be executable.<br>• UEFI runtime service must meet these requirements: <br> - Implement UEFI 2.6 EFI_MEMORY_ATTRIBUTES_TABLE. All UEFI runtime service memory (code and data) must be described by this table. <br> - PE sections need to be page-aligned in memory (not required for in non-volatile storage).<br> - The Memory Attributes Table needs to correctly mark code and data as RO/NX for configuration by the OS:<br> - All entries must include attributes EFI_MEMORY_RO, EFI_MEMORY_XP, or both <br> - No entries may be left with neither of the above attributes, indicating memory that is both executable and writable. Memory must be either readable and executable or writeable and non-executable. <br><blockquote><p><strong>Notes:</strong><br>• This only applies to UEFI runtime service memory, and not UEFI boot service memory. <br>• This protection is applied by VBS on OS page tables.</p></blockquote><br> Please also note the following: <br>• Do not use sections that are both writeable and executable<br>• Do not attempt to directly modify executable system memory<br>• Do not use dynamic code<br><br>**Security benefits**:<br>• Vulnerabilities in UEFI runtime, if any, will be blocked from compromising VBS (such as in functions like UpdateCapsule and SetVariable)<br>• Reduces the attack surface to VBS from system firmware. |
|
||||
| Firmware: **Firmware support for SMM protection** | **Requirements**: The [Windows SMM Security Mitigations Table (WSMT) specification](http://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-BAA2-1A54E0E490B6/WSMT.docx) contains details of an Advanced Configuration and Power Interface (ACPI) table that was created for use with Windows operating systems that support Windows virtualization-based security (VBS) features.<br><br>**Security benefits**:<br>• Protects against potential vulnerabilities in UEFI runtime services, if any, will be blocked from compromising VBS (such as in functions like UpdateCapsule and SetVariable)<br>• Reduces the attack surface to VBS from system firmware.<br>• Blocks additional security attacks against SMM. |
|
||||
| Protections for Improved Security | Description | Security Benefits
|
||||
|---|---|---|
|
||||
| Firmware: **VBS enablement of NX protection for UEFI runtime services** | **Requirements**:<br>• VBS will enable No-Execute (NX) protection on UEFI runtime service code and data memory regions. UEFI runtime service code must support read-only page protections, and UEFI runtime service data must not be executable.<br>• UEFI runtime service must meet these requirements: <br> - Implement UEFI 2.6 EFI_MEMORY_ATTRIBUTES_TABLE. All UEFI runtime service memory (code and data) must be described by this table. <br> - PE sections need to be page-aligned in memory (not required for in non-volatile storage).<br> - The Memory Attributes Table needs to correctly mark code and data as RO/NX for configuration by the OS:<br> - All entries must include attributes EFI_MEMORY_RO, EFI_MEMORY_XP, or both <br> - No entries may be left with neither of the above attributes, indicating memory that is both executable and writable. Memory must be either readable and executable or writeable and non-executable. <br><blockquote><p><strong>Notes:</strong><br>• This only applies to UEFI runtime service memory, and not UEFI boot service memory. <br>• This protection is applied by VBS on OS page tables.</p></blockquote><br> Please also note the following: <br>• Do not use sections that are both writeable and executable<br>• Do not attempt to directly modify executable system memory<br>• Do not use dynamic code | • Vulnerabilities in UEFI runtime, if any, will be blocked from compromising VBS (such as in functions like UpdateCapsule and SetVariable)<br>• Reduces the attack surface to VBS from system firmware. |
|
||||
| Firmware: **Firmware support for SMM protection** | **Requirements**: The [Windows SMM Security Mitigations Table (WSMT) specification](http://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-BAA2-1A54E0E490B6/WSMT.docx) contains details of an Advanced Configuration and Power Interface (ACPI) table that was created for use with Windows operating systems that support Windows virtualization-based security (VBS) features. | • Protects against potential vulnerabilities in UEFI runtime services, if any, will be blocked from compromising VBS (such as in functions like UpdateCapsule and SetVariable)<br>• Reduces the attack surface to VBS from system firmware.<br>• Blocks additional security attacks against SMM. |
|
||||
|
Loading…
x
Reference in New Issue
Block a user