mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-16 10:53:43 +00:00
Light updates to legacy firewall content
This commit is contained in:
Paolo Matarazzo
@ -1,14 +1,12 @@
|
||||
---
|
||||
title: Basic Firewall Policy Design
|
||||
description: Protect the devices in your organization from unwanted network traffic that gets through the perimeter defenses by using basic firewall policy design.
|
||||
ms.prod: windows-client
|
||||
ms.topic: conceptual
|
||||
ms.date: 12/31/2017
|
||||
ms.date: 11/07/2023
|
||||
---
|
||||
|
||||
# Basic Firewall Policy Design
|
||||
|
||||
|
||||
Many organizations have a network perimeter firewall that is designed to prevent the entry of malicious traffic in to the organization's network, but don't have a host-based firewall enabled on each device in the organization.
|
||||
|
||||
The Basic Firewall Policy Design helps you to protect the devices in your organization from unwanted network traffic that gets through the perimeter defenses, or that originates from inside your network. In this design, you deploy firewall rules to each device in your organization to allow traffic that is required by the programs that are used. Traffic that doesn't match the rules is dropped.
|
||||
@ -17,22 +15,16 @@ Traffic can be blocked or permitted based on the characteristics of each network
|
||||
|
||||
Many network administrators don't want to tackle the difficult task of determining all the appropriate rules for every program that is used by the organization, and then maintaining that list over time. In fact, most programs don't require specific firewall rules. The default behavior of Windows and most contemporary applications makes this task easy:
|
||||
|
||||
- On client devices, the default firewall behavior already supports typical client programs. Programs create any required rules for you as part of the installation process. You only have to create a rule if the client program must be able to receive unsolicited inbound network traffic from another device.
|
||||
|
||||
- When you install a server program that must accept unsolicited inbound network traffic, the installation program likely creates or enables the appropriate rules on the server for you.
|
||||
|
||||
For example, when you install a server role, the appropriate firewall rules are created and enabled automatically.
|
||||
|
||||
- For other standard network behavior, the predefined rules that are built into Windows 11, Windows 10, Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, Windows 8, and Windows 7 can easily be configured in a GPO and deployed to the devices in your organization.
|
||||
|
||||
For example, by using the predefined groups for Core Networking and File and Printer Sharing you can easily configure GPOs with rules for those frequently used networking protocols.
|
||||
- On client devices, the default firewall behavior already supports typical client programs. Programs create any required rules for you as part of the installation process. You only have to create a rule if the client program must be able to receive unsolicited inbound network traffic from another device
|
||||
- When you install a server program that must accept unsolicited inbound network traffic, the installation program likely creates or enables the appropriate rules on the server for you. For example, when you install a server role, the appropriate firewall rules are created and enabled automatically
|
||||
- For other standard network behavior, the predefined rules that are built into Windows can be configured in a GPO and deployed to the devices in your organization. For example, by using the predefined groups for Core Networking and File and Printer Sharing you can easily configure GPOs with rules for those frequently used networking protocols.
|
||||
|
||||
With a few exceptions, the firewall can be enabled on all configurations. Therefore, we recommend that you enable the firewall on every device in your organization. The term "device" includes servers in your perimeter network, on mobile and remote clients that connect to the network, and on all servers and clients in your internal network.
|
||||
|
||||
> [!CAUTION]
|
||||
> Stopping the service associated with Windows Defender Firewall with Advanced Security is not supported by Microsoft.
|
||||
|
||||
By default, in new installations, Windows Defender Firewall with Advanced Security is turned on in Windows Server 2012, Windows 8, and later.
|
||||
Windows Defender Firewall with Advanced Security is turned on by default.
|
||||
|
||||
If you turn off the Windows Defender Firewall service you lose other benefits provided by the service, such as the ability to use IPsec connection security rules, Windows Service Hardening, and network protection from forms of attacks that use network fingerprinting.
|
||||
|
||||
@ -49,15 +41,11 @@ The basic firewall design can be applied to devices that are part of an Active D
|
||||
|
||||
For more information about this design:
|
||||
|
||||
- This design coincides with the deployment goal to [Protect Devices from Unwanted Network Traffic](protect-devices-from-unwanted-network-traffic.md).
|
||||
|
||||
- To learn more about this design, see [Firewall Policy Design Example](firewall-policy-design-example.md).
|
||||
|
||||
- Before completing the design, gather the information described in [Designing a Windows Defender Firewall with Advanced Security Strategy](designing-a-windows-firewall-with-advanced-security-strategy.md).
|
||||
|
||||
- To help you make the decisions required in this design, see [Planning Settings for a Basic Firewall Policy](planning-settings-for-a-basic-firewall-policy.md).
|
||||
|
||||
- For a list of detailed tasks that you can use to deploy your basic firewall policy design, see [Checklist: Implementing a Basic Firewall Policy Design](checklist-implementing-a-basic-firewall-policy-design.md).
|
||||
- This design coincides with the deployment goal to [Protect Devices from Unwanted Network Traffic](protect-devices-from-unwanted-network-traffic.md)
|
||||
- To learn more about this design, see [Firewall Policy Design Example](firewall-policy-design-example.md)
|
||||
- Before completing the design, gather the information described in [Designing a Windows Defender Firewall with Advanced Security Strategy](designing-a-windows-firewall-with-advanced-security-strategy.md)
|
||||
- To help you make the decisions required in this design, see [Planning Settings for a Basic Firewall Policy](planning-settings-for-a-basic-firewall-policy.md)
|
||||
- For a list of detailed tasks that you can use to deploy your basic firewall policy design, see [Checklist: Implementing a Basic Firewall Policy Design](checklist-implementing-a-basic-firewall-policy-design.md)
|
||||
|
||||
> [!div class="nextstepaction"]
|
||||
> [Domain Isolation Policy Design](domain-isolation-policy-design.md)
|
||||
|
||||
@ -1,14 +1,12 @@
|
||||
---
|
||||
title: Create Windows Firewall rules in Intune
|
||||
description: Learn how to use Intune to create rules in Windows Defender Firewall with Advanced Security. Start by creating a profile in Device Configuration in Intune.
|
||||
ms.prod: windows-client
|
||||
ms.topic: conceptual
|
||||
ms.date: 12/31/2017
|
||||
ms.date: 11/07/2023
|
||||
---
|
||||
|
||||
# Create Windows Firewall rules in Intune
|
||||
|
||||
|
||||
>[!IMPORTANT]
|
||||
>This information relates to prereleased product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
|
||||
|
||||
@ -24,6 +22,7 @@ Select Windows Defender Firewall.
|
||||
The firewall rule configurations in Intune use the Windows CSP for Firewall. For more information, see [Firewall CSP](/windows/client-management/mdm/firewall-csp).
|
||||
|
||||
## Application
|
||||
|
||||
Control connections for an app or program.
|
||||
Apps and programs can be specified either file path, package family name, or Windows service short name.
|
||||
|
||||
@ -40,6 +39,7 @@ Default is All.
|
||||
[Learn more](/windows/client-management/mdm/firewall-csp#servicename)
|
||||
|
||||
## Protocol
|
||||
|
||||
Select the protocol for this port rule. Transport layer protocols—TCP and UDP—allow you to specify ports or port ranges. For custom protocols, enter a number between 0 and 255 representing the IP protocol.
|
||||
|
||||
Default is Any.
|
||||
@ -47,52 +47,60 @@ Default is Any.
|
||||
[Learn more](/windows/client-management/mdm/firewall-csp#protocol)
|
||||
|
||||
## Local ports
|
||||
|
||||
Comma separated list of ranges. For example, *100-120,200,300-320*. Default is All.
|
||||
|
||||
[Learn more](/windows/client-management/mdm/firewall-csp#localportranges)
|
||||
|
||||
## Remote ports
|
||||
|
||||
Comma separated list of ranges. For example, *100-120,200,300-320*. Default is All.
|
||||
|
||||
[Learn more](/windows/client-management/mdm/firewall-csp#remoteportranges)
|
||||
|
||||
## Local addresses
|
||||
|
||||
Comma-separated list of local addresses covered by the rule. Valid tokens include:
|
||||
- \* indicates any local address. If present, this token must be the only one included.
|
||||
- A subnet can be specified using either the subnet mask or network prefix notation. If a subnet mask or a network prefix isn't specified, the subnet mask default is 255.255.255.255.
|
||||
- A valid IPv6 address.
|
||||
- An IPv4 address range in the format of "start address-end address" with no spaces included.
|
||||
- An IPv6 address range in the format of "start address-end address" with no spaces included. Default is Any address.
|
||||
|
||||
- `*` indicates any local address. If present, this token must be the only one included
|
||||
- A subnet can be specified using either the subnet mask or network prefix notation. If a subnet mask or a network prefix isn't specified, the subnet mask default is 255.255.255.255
|
||||
- A valid IPv6 address
|
||||
- An IPv4 address range in the format of "start address-end address" with no spaces included
|
||||
- An IPv6 address range in the format of "start address-end address" with no spaces included. Default is Any address
|
||||
|
||||
[Learn more](/windows/client-management/mdm/firewall-csp#localaddressranges)
|
||||
|
||||
## Remote addresses
|
||||
|
||||
List of comma separated tokens specifying the remote addresses covered by the rule. Tokens are case insensitive. Valid tokens include:
|
||||
- \* indicates any remote address. If present, this token must be the only one included.
|
||||
|
||||
- `*` indicates any remote address. If present, this token must be the only one included
|
||||
- Defaultgateway
|
||||
- DHCP
|
||||
- DNS
|
||||
- WINS
|
||||
- Intranet (supported on Windows versions 1809+)
|
||||
- RmtIntranet (supported on Windows versions 1809+)
|
||||
- Internet (supported on Windows versions 1809+)
|
||||
- Ply2Renders (supported on Windows versions 1809+)
|
||||
- LocalSubnet indicates any local address on the local subnet.
|
||||
- A subnet can be specified using either the subnet mask or network prefix notation. If neither a subnet mask not a network prefix is specified, the subnet mask defaults to 255.255.255.255.
|
||||
- A valid IPv6 address.
|
||||
- An IPv4 address range in the format of "start address-end address" with no spaces included.
|
||||
- An IPv6 address range in the format of "start address-end address" with no spaces included.
|
||||
- Intranet
|
||||
- RmtIntranet
|
||||
- Internet
|
||||
- Ply2Renders
|
||||
- LocalSubnet indicates any local address on the local subnet
|
||||
- A subnet can be specified using either the subnet mask or network prefix notation. If neither a subnet mask not a network prefix is specified, the subnet mask defaults to 255.255.255.255
|
||||
- A valid IPv6 address
|
||||
- An IPv4 address range in the format of "start address-end address" with no spaces included
|
||||
- An IPv6 address range in the format of "start address-end address" with no spaces included
|
||||
|
||||
Default is Any address.
|
||||
Default is Any address
|
||||
|
||||
[Learn more](https://aka.ms/intunefirewallremotaddressrule)
|
||||
|
||||
## Edge traversal (UI coming soon)
|
||||
|
||||
Indicates whether edge traversal is enabled or disabled for this rule. The EdgeTraversal setting indicates that specific inbound traffic is allowed to tunnel through NATs and other edge devices using the Teredo tunneling technology. In order for this setting to work correctly, the application or service with the inbound firewall rule needs to support IPv6. The primary application of this setting allows listeners on the host to be globally addressable through a Teredo IPv6 address. New rules have the EdgeTraversal property disabled by default. This setting can only be configured via Intune Graph at this time.
|
||||
|
||||
[Learn more](/windows/client-management/mdm/firewall-csp#edgetraversal)
|
||||
|
||||
## Authorized users
|
||||
|
||||
Specifies the list of authorized local users for this rule. A list of authorized users can't be specified if the rule being authored is targeting a Windows service. Default is all users.
|
||||
|
||||
[Learn more](/windows/client-management/mdm/firewall-csp#localuserauthorizedlist)
|
||||
|
||||
@ -1,9 +1,8 @@
|
||||
---
|
||||
title: Filter origin audit log improvements
|
||||
description: Filter origin documentation audit log improvements
|
||||
ms.prod: windows-client
|
||||
ms.topic: troubleshooting
|
||||
ms.date: 12/31/2017
|
||||
ms.date: 11/07/2023
|
||||
---
|
||||
|
||||
# Filter origin audit log improvements
|
||||
@ -23,26 +22,18 @@ For customers to debug packet drop events correctly and efficiently, they would
|
||||
The blocking filters can be categorized under these filter origins:
|
||||
|
||||
1. Firewall rules
|
||||
|
||||
2. Firewall default block filters
|
||||
|
||||
a. AppContainer loopback
|
||||
|
||||
b. Boottime default
|
||||
|
||||
c. Quarantine default
|
||||
|
||||
d. Query user default
|
||||
|
||||
e. Stealth
|
||||
|
||||
f. Universal Windows Platform (UWP) default
|
||||
|
||||
g. Windows Service Hardening (WSH) default
|
||||
1. Firewall default block filters
|
||||
1. AppContainer loopback
|
||||
1. Boottime default
|
||||
1. Quarantine default
|
||||
1. Query user default
|
||||
1. Stealth
|
||||
1. Universal Windows Platform (UWP) default
|
||||
1. Windows Service Hardening (WSH) default
|
||||
|
||||
The next section describes the improvements made to audits 5157 and 5152, and how the above filter origins are used in these events. These improvements were added in the Windows Server 2022 and Windows 11 releases.
|
||||
|
||||
## Improved firewall audit
|
||||
## Improved firewall audit
|
||||
|
||||
The two new fields added to the audit 5157 and 5152 events are `Filter Origin` and `Interface Index`.
|
||||
|
||||
@ -54,10 +45,10 @@ The `Interface Index` field specifies the network interface in which the packet
|
||||
|
||||
To enable a specific audit event, run the corresponding command in an administrator command prompt:
|
||||
|
||||
|**Audit #**|**Enable command**|**Link**|
|
||||
|Audit #|Enable command|Link|
|
||||
|:-----|:-----|:-----|
|
||||
|**5157**|`Auditpol /set /category:"System" /SubCategory:"Filtering Platform Connection" /success:enable /failure:enable`|[5157(F): The Windows Filtering Platform has blocked a connection.](../../../threat-protection/auditing/event-5157.md)|
|
||||
|**5152**|`Auditpol /set /category:"System" /SubCategory:"Filtering Platform Packet Drop" /success:enable /failure:enable`|[5152(F): The Windows Filtering Platform blocked a packet.](../../../threat-protection/auditing/event-5152.md)|
|
||||
|5157|`Auditpol /set /category:"System" /SubCategory:"Filtering Platform Connection" /success:enable /failure:enable`|[5157(F): The Windows Filtering Platform has blocked a connection.](../../../threat-protection/auditing/event-5157.md)|
|
||||
|5152|`Auditpol /set /category:"System" /SubCategory:"Filtering Platform Packet Drop" /success:enable /failure:enable`|[5152(F): The Windows Filtering Platform blocked a packet.](../../../threat-protection/auditing/event-5152.md)|
|
||||
|
||||
## Example flow of debugging packet drops with filter origin
|
||||
|
||||
@ -85,7 +76,7 @@ After identifying the rule that caused the drop, the network admin can now modif
|
||||
|
||||
## Firewall default block filters
|
||||
|
||||
**AppContainer loopback**
|
||||
### AppContainer loopback
|
||||
|
||||
Network drop events from the AppContainer loopback block filter origin occur when localhost loopback isn't enabled properly for the Universal Windows Platform (UWP) app.
|
||||
|
||||
@ -93,19 +84,19 @@ To enable localhost loopback in a local debugging environment, see [Communicatin
|
||||
|
||||
To enable localhost loopback for a published app that requires loopback access to communicate with another UWP or packaged win32 app, see [uap4:LoopbackAccessRules](/uwp/schemas/appxpackage/uapmanifestschema/element-uap4-loopbackaccessrules).
|
||||
|
||||
**Boottime default**
|
||||
### Boottime default
|
||||
|
||||
Network drop events from the boottime default block filter origin occur when the computer is booting up and the firewall service isn't yet running. Services will need to create a boottime allow filter to allow the traffic. It should be noted that it's not possible to add boottime filters through firewall rules.
|
||||
|
||||
**Quarantine default**
|
||||
### Quarantine default
|
||||
|
||||
Network drops from the quarantine default block filter occur when the interface is temporarily quarantined by Firewall service. The firewall service quarantines an interface when it detects a change on the network, and based on several other factors, the firewall service may put the interface in quarantine as a safeguard. When an interface is in quarantine, the quarantine default block filter will block any new non-loopback inbound connections.
|
||||
|
||||
Run the following PowerShell command to generate more information about the interface:
|
||||
|
||||
```Powershell
|
||||
Get-NetIPInterface –InterfaceIndex <Interface Index>
|
||||
Get-NetIPInterface –InterfaceIndex 5
|
||||
Get-NetIPInterface -InterfaceIndex <Interface Index>
|
||||
Get-NetIPInterface -InterfaceIndex 5
|
||||
```
|
||||
|
||||
|
||||
@ -115,13 +106,12 @@ To learn more about the quarantine feature, see [Quarantine behavior](quarantine
|
||||
>[!NOTE]
|
||||
> Quarantine-related packet drops are often transient and signify nothing more than a network change on the interface.
|
||||
|
||||
**Query user default**
|
||||
### Query user default
|
||||
|
||||
Network packet drops from query user default block filters occur when there's no explicit rule created to allow an inbound connection for the packet. When an application binds to a socket but doesn't have a corresponding inbound rule to allow packets on that port, Windows generates a pop up for the user to allow or deny the app to receive packets on the available network categories. If the user clicks to deny the connection in this popup, subsequent inbound packets to the app will be dropped. To resolve the drops:
|
||||
|
||||
1. Create an inbound firewall rule to allow the packet for this application. This packet will allow the packet to bypass any query user default block filters.
|
||||
|
||||
2. Delete any block query user rules that may have been auto generated by the firewall service.
|
||||
1. Create an inbound firewall rule to allow the packet for this application. This packet will allow the packet to bypass any query user default block filters
|
||||
1. Delete any block query user rules that may have been auto generated by the firewall service
|
||||
|
||||
To generate a list of all the query user block rules, you can run the following PowerShell command:
|
||||
|
||||
@ -135,27 +125,28 @@ The query user pop-up feature is enabled by default.
|
||||
|
||||
To disable the query user pop-up, you can run the following command in administrative command prompt:
|
||||
|
||||
```Console
|
||||
```cmd
|
||||
Netsh set allprofiles inboundusernotification disable
|
||||
```
|
||||
|
||||
Or in PowerShell:
|
||||
|
||||
```Powershell
|
||||
Set-NetFirewallProfile -NotifyOnListen False
|
||||
```
|
||||
|
||||
**Stealth**
|
||||
### Stealth
|
||||
|
||||
Network drops from stealth filters are typically made to prevent port scanning.
|
||||
|
||||
To disable stealth-mode, see [Disable stealth mode in Windows](/troubleshoot/windows-server/networking/disable-stealth-mode).
|
||||
|
||||
**UWP default**
|
||||
### UWP default
|
||||
|
||||
Network drops from Universal Windows Platform (UWP) default inbound/outbound block filters are often caused by the UWP app not being configured correctly (that is, the UWP app is missing the correct capability tokens or loopback isn't enabled) or the private range is configured incorrectly.
|
||||
|
||||
For more information on how to debug drops caused by UWP default block filters, see [Troubleshooting UWP App Connectivity Issues](troubleshooting-uwp-firewall.md).
|
||||
|
||||
**WSH default**
|
||||
### WSH default
|
||||
|
||||
Network drops from Windows Service Hardening (WSH) default filters indicate that there wasn't an explicit Windows Service Hardening allow rule to allow network traffic for the protected service. The service owner will need to configure allow rules for the service if the block isn't expected.
|
||||
|
||||
@ -1,9 +1,8 @@
|
||||
---
|
||||
title: Troubleshooting Windows Firewall settings after a Windows upgrade
|
||||
description: Firewall settings lost on upgrade
|
||||
ms.prod: windows-client
|
||||
ms.topic: troubleshooting
|
||||
ms.date: 12/31/2017
|
||||
ms.date: 11/07/2023
|
||||
---
|
||||
|
||||
# Troubleshooting Windows Firewall settings after a Windows upgrade
|
||||
@ -14,9 +13,9 @@ Use this article to troubleshoot firewall settings that are turned off after upg
|
||||
|
||||
To help you organize your list, individual built-in firewall rules are categorized within a group. For example, the following rules form part of the Remote Desktop group.
|
||||
|
||||
- Remote Desktop – Shadow (TCP-In)
|
||||
- Remote Desktop – User Mode (TCP-In)
|
||||
- Remote Desktop – User-Mode (UDP-In)
|
||||
- Remote Desktop - Shadow (TCP-In)
|
||||
- Remote Desktop - User Mode (TCP-In)
|
||||
- Remote Desktop - User-Mode (UDP-In)
|
||||
|
||||
Other group examples include **core networking**, **file and print sharing**, and **network discovery**. Grouping allows administrators to manage sets of similar rules by filtering on categories in the firewall interface (wf.msc). Do this filtering by right-clicking on either **Inbound** or **Outbound Rules** and selecting **Filter by Group**. Optionally, you can use PowerShell using the `Get-NetFirewallRule` cmdlet with the `-Group` switch.
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,14 +1,11 @@
|
||||
---
|
||||
title: Zero Trust and Windows device health
|
||||
description: Describes the process of Windows device health attestation
|
||||
ms.reviewer:
|
||||
ms.topic: conceptual
|
||||
manager: aaroncz
|
||||
ms.author: paoloma
|
||||
author: paolomatarazzo
|
||||
ms.prod: windows-client
|
||||
ms.technology: itpro-security
|
||||
ms.date: 12/31/2017
|
||||
ms.date: 11/07/2023
|
||||
---
|
||||
|
||||
# Zero Trust and Windows device health
|
||||
@ -17,11 +14,9 @@ Organizations need a security model that more effectively adapts to the complexi
|
||||
|
||||
The [Zero Trust](https://www.microsoft.com/security/business/zero-trust) principles are:
|
||||
|
||||
- **Verify explicitly**. Always authenticate and authorize based on all available data points, including user identity, location, device health, service or workload, data classification, and monitor anomalies.
|
||||
|
||||
- **Use least-privileged access**. Limit user access with just-in-time and just-enough-access, risk-based adaptive policies, and data protection to help secure data and maintain productivity.
|
||||
|
||||
- **Assume breach**. Prevent attackers from obtaining access to minimize potential damage to data and systems. Protect privileged roles, verify end-to-end encryption, use analytics to get visibility, and drive threat detection to improve defenses.
|
||||
- **Verify explicitly**. Always authenticate and authorize based on all available data points, including user identity, location, device health, service or workload, data classification, and monitor anomalies
|
||||
- **Use least-privileged access**. Limit user access with just-in-time and just-enough-access, risk-based adaptive policies, and data protection to help secure data and maintain productivity
|
||||
- **Assume breach**. Prevent attackers from obtaining access to minimize potential damage to data and systems. Protect privileged roles, verify end-to-end encryption, use analytics to get visibility, and drive threat detection to improve defenses
|
||||
|
||||
The Zero Trust concept of **verify explicitly** applies to the risks introduced by both devices and users. Windows enables **device health attestation** and **conditional access** capabilities, which are used to grant access to corporate resources.
|
||||
|
||||
@ -45,25 +40,19 @@ Windows includes many security features to help protect users from malware and a
|
||||
|
||||
A summary of the steps involved in attestation and Zero Trust on the device side are as follows:
|
||||
|
||||
1. During each step of the boot process, such as a file load, update of special variables, and more, information such as file hashes and signature are measured in the TPM PCRs. The measurements are bound by a [Trusted Computing Group specification](https://trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/) (TCG) that dictates what events can be recorded and the format of each event.
|
||||
1. During each step of the boot process, such as a file load, update of special variables, and more, information such as file hashes and signature are measured in the TPM PCRs. The measurements are bound by a [Trusted Computing Group specification](https://trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/) (TCG) that dictates what events can be recorded and the format of each event
|
||||
1. Once Windows has booted, the attestor/verifier requests the TPM to fetch the measurements stored in its Platform Configuration Register (PCR) alongside a TCG log. The measurements in both these components together form the attestation evidence that is then sent to the attestation service
|
||||
1. The TPM is verified by using the keys/cryptographic material available on the chipset with an [Azure Certificate Service](/windows-server/identity/ad-ds/manage/component-updates/tpm-key-attestation)
|
||||
1. This information is then sent to the attestation service in the cloud to verify that the device is safe. Microsoft Endpoint Manger integrates with Microsoft Azure Attestation to review device health comprehensively and connect this information with Microsoft Entra Conditional Access. This integration is key for Zero Trust solutions that help bind trust to an untrusted device
|
||||
1. The attestation service does the following tasks:
|
||||
|
||||
2. Once Windows has booted, the attestor/verifier requests the TPM to fetch the measurements stored in its Platform Configuration Register (PCR) alongside a TCG log. The measurements in both these components together form the attestation evidence that is then sent to the attestation service.
|
||||
- Verify the integrity of the evidence. This verification is done by validating the PCRs that match the values recomputed by replaying the TCG log
|
||||
- Verify that the TPM has a valid Attestation Identity Key issued by the authenticated TPM
|
||||
- Verify that the security features are in the expected states
|
||||
|
||||
3. The TPM is verified by using the keys/cryptographic material available on the chipset with an [Azure Certificate Service](/windows-server/identity/ad-ds/manage/component-updates/tpm-key-attestation).
|
||||
|
||||
4. This information is then sent to the attestation service in the cloud to verify that the device is safe. Microsoft Endpoint Manger integrates with Microsoft Azure Attestation to review device health comprehensively and connect this information with Microsoft Entra Conditional Access. This integration is key for Zero Trust solutions that help bind trust to an untrusted device.
|
||||
|
||||
5. The attestation service does the following tasks:
|
||||
|
||||
- Verify the integrity of the evidence. This verification is done by validating the PCRs that match the values recomputed by replaying the TCG log.
|
||||
- Verify that the TPM has a valid Attestation Identity Key issued by the authenticated TPM.
|
||||
- Verify that the security features are in the expected states.
|
||||
|
||||
6. The attestation service returns an attestation report that contains information about the security features based on the policy configured in the attestation service.
|
||||
|
||||
7. The device then sends the report to the Microsoft Intune cloud to assess the trustworthiness of the platform according to the admin-configured device compliance rules.
|
||||
|
||||
8. Conditional access, along with device-compliance state then decides to allow or deny access.
|
||||
1. The attestation service returns an attestation report that contains information about the security features based on the policy configured in the attestation service
|
||||
1. The device then sends the report to the Microsoft Intune cloud to assess the trustworthiness of the platform according to the admin-configured device compliance rules
|
||||
1. Conditional access, along with device-compliance state then decides to allow or deny access
|
||||
|
||||
## Other Resources
|
||||
|
||||
|
||||
Reference in New Issue
Block a user