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,22 +22,14 @@ 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.
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -1,9 +1,8 @@
|
||||
---
|
||||
title: Troubleshooting UWP App Connectivity Issues in Windows Firewall
|
||||
description: Troubleshooting UWP App Connectivity Issues in Windows Firewall
|
||||
ms.prod: windows-client
|
||||
ms.topic: troubleshooting
|
||||
ms.date: 12/31/2017
|
||||
ms.date: 11/07/2023
|
||||
---
|
||||
|
||||
# Troubleshooting UWP App Connectivity Issues
|
||||
@ -17,22 +16,18 @@ This document guides you through steps to debug Universal Windows Platform (UWP
|
||||
|
||||
UWP app network connectivity issues are typically caused by:
|
||||
|
||||
1. The UWP applications not being permitted to receive loopback traffic. This permission must be configured. By default, UWP applications aren't allowed to receive loopback traffic.
|
||||
2. The UWP app is missing the proper capability tokens.
|
||||
3. The private range is configured incorrectly. For example, the private range is set incorrectly through GP/MDM policies, etc.
|
||||
1. The UWP applications not being permitted to receive loopback traffic. This permission must be configured. By default, UWP applications aren't allowed to receive loopback traffic
|
||||
1. The UWP app is missing the proper capability tokens
|
||||
1. The private range is configured incorrectly. For example, the private range is set incorrectly through GP/MDM policies, etc.
|
||||
|
||||
To understand these causes more thoroughly, there are several concepts to review.
|
||||
|
||||
The traffic of network packets (what's permitted and what’s not) on Windows is determined by the Windows Filtering Platform (WFP). When a UWP app
|
||||
or the private range is configured incorrectly, it affects how the UWP app’s network traffic will be processed by WFP.
|
||||
The traffic of network packets (what's permitted and what's not) on Windows is determined by the Windows Filtering Platform (WFP). When a UWP app
|
||||
or the private range is configured incorrectly, it affects how the UWP app's network traffic will be processed by WFP.
|
||||
|
||||
When a packet is processed by WFP, the characteristics of that packet must explicitly match all the conditions of a filter to either be permitted or dropped to its target address. Connectivity issues typically happen when the packet doesn't match any of the filter conditions, leading the packet to be dropped by a default block filter. The presence of the default block filters ensures network isolation for UWP applications. Specifically, it guarantees a network drop for a packet that doesn't have the correct capabilities for the resource it's trying to reach. Such a packet drop ensures the application’s granular access to each resource type and preventing the application from escaping its environment.
|
||||
When a packet is processed by WFP, the characteristics of that packet must explicitly match all the conditions of a filter to either be permitted or dropped to its target address. Connectivity issues typically happen when the packet doesn't match any of the filter conditions, leading the packet to be dropped by a default block filter. The presence of the default block filters ensures network isolation for UWP applications. Specifically, it guarantees a network drop for a packet that doesn't have the correct capabilities for the resource it's trying to reach. Such a packet drop ensures the application's granular access to each resource type and preventing the application from escaping its environment.
|
||||
|
||||
For more information on the filter arbitration algorithm and network isolation,
|
||||
see [Filter
|
||||
Arbitration](/windows/win32/fwp/filter-arbitration)
|
||||
and
|
||||
[Isolation](/windows/win32/secauthz/appcontainer-isolation).
|
||||
For more information on the filter arbitration algorithm and network isolation, see [Filter Arbitration](/windows/win32/fwp/filter-arbitration) and [Isolation](/windows/win32/secauthz/appcontainer-isolation).
|
||||
|
||||
The following sections cover debugging case examples for loopback and non-loopback UWP app network connectivity issues.
|
||||
|
||||
@ -46,15 +41,17 @@ If you need to establish a TCP/IP connection between two processes on the same h
|
||||
|
||||
To enable loopback for client outbound connections, run the following command at a command prompt:
|
||||
|
||||
```console
|
||||
```cmd
|
||||
CheckNetIsolation.exe LoopbackExempt -a -n=<AppContainer or Package Family>
|
||||
```
|
||||
|
||||
To enable loopback for server inbound connections, run the following command at a
|
||||
command prompt:
|
||||
```console
|
||||
|
||||
```cmd
|
||||
CheckNetIsolation.exe LoopbackExempt -is -n=<AppContainer or Package Family>
|
||||
```
|
||||
|
||||
You can ensure loopback is enabled by checking the appx manifests of both the sender and receiver.
|
||||
|
||||
For more information about loopback scenarios, see [Communicating with
|
||||
@ -78,7 +75,7 @@ Netsh wfp capture start keywords=19
|
||||
Netsh wfp capture stop
|
||||
```
|
||||
|
||||
These commands generate a wfpdiag.cab. Inside the .cab exists a wfpdiag.xml, which contains any allow or drop netEvents and filters that existed during that repro. Without “keywords=19”, the trace will only collect drop netEvents.
|
||||
These commands generate a wfpdiag.cab. Inside the .cab exists a wfpdiag.xml, which contains any allow or drop netEvents and filters that existed during that repro. Without "keywords=19", the trace will only collect drop netEvents.
|
||||
|
||||
Inside the wfpdiag.xml, search for netEvents that have
|
||||
FWPM_NET_EVENT_TYPE_CLASSIFY_DROP as the netEvent type. To find the relevant drop events, search for the drop events with matching destination IP address,
|
||||
@ -108,7 +105,8 @@ In this scenario, the app could successfully send a packet to the Internet targe
|
||||
The following code shows the allow netEvent of the app connecting to the target IP. The netEvent contains information about the packet including its local address,
|
||||
remote address, capabilities, etc.
|
||||
|
||||
**Classify Allow netEvent, Wfpdiag-Case-1.xml**
|
||||
### Classify Allow netEvent, `Wfpdiag-Case-1.xml`
|
||||
|
||||
```xml
|
||||
<netEvent>
|
||||
<header>
|
||||
@ -181,7 +179,8 @@ The following is the filter that permitted the packet to be sent to the target
|
||||
address according to the **terminatingFiltersInfo** in the **netEvent**. This packet was
|
||||
allowed by Filter #125918, from the InternetClient Default Rule.
|
||||
|
||||
**InternetClient Default Rule Filter #125918, Wfpdiag-Case-1.xml**
|
||||
### InternetClient Default Rule Filter #125918, `Wfpdiag-Case-1.xml`
|
||||
|
||||
```xml
|
||||
<item>
|
||||
<filterKey>{3389708e-f7ae-4ebc-a61a-f659065ab24e}</filterKey>
|
||||
@ -265,7 +264,8 @@ allowed by Filter #125918, from the InternetClient Default Rule.
|
||||
</item>
|
||||
```
|
||||
|
||||
**Capabilities Condition in Filter \#125918, Wfpdiag-Case-1.xml**
|
||||
### Capabilities Condition in Filter #125918, `Wfpdiag-Case-1.xml`
|
||||
|
||||
```xml
|
||||
<item>
|
||||
<fieldKey>FWPM_CONDITION_ALE_USER_ID</fieldKey>
|
||||
@ -276,26 +276,23 @@ allowed by Filter #125918, from the InternetClient Default Rule.
|
||||
</conditionValue>
|
||||
</item>
|
||||
```
|
||||
|
||||
This condition enables checking capabilities in this filter.
|
||||
|
||||
The important part of this condition is **S-1-15-3-1**, which is the capability SID
|
||||
for **INTERNET_CLIENT** privileges.
|
||||
The important part of this condition is **S-1-15-3-1**, which is the capability SID for **INTERNET_CLIENT** privileges.
|
||||
|
||||
From the **netEvent** capabilities section, capabilities from netEvent, Wfpdiag-Case-1.xml.
|
||||
|
||||
From the **netEvent** capabilities section,
|
||||
capabilities from netEvent, Wfpdiag-Case-1.xml.
|
||||
```xml
|
||||
<capabilities numItems="3">
|
||||
<item>FWP_CAPABILITIES_FLAG_INTERNET_CLIENT</item> <item>FWP_CAPABILITIES_FLAG_INTERNET_CLIENT_SERVER</item>
|
||||
<item>FWP_CAPABILITIES_FLAG_INTERNET_CLIENT</item>
|
||||
<item>FWP_CAPABILITIES_FLAG_INTERNET_CLIENT_SERVER</item>
|
||||
<item>FWP_CAPABILITIES_FLAG_PRIVATE_NETWORK</item>
|
||||
</capabilities>
|
||||
```
|
||||
These capabilities show the packet came from an app with an Internet client token (**FWP_CAPABILITIES_FLAG_INTERNET_CLIENT**) which matches the capability SID in the
|
||||
filter. All the other conditions are also met for the filter, so the packet is
|
||||
allowed.
|
||||
|
||||
Something to note is that the only capability token required for the packet to
|
||||
reach bing.com was the Internet client token, even though this example showed
|
||||
the packet having all capabilities.
|
||||
These capabilities show the packet came from an app with an Internet client token (**FWP_CAPABILITIES_FLAG_INTERNET_CLIENT**) which matches the capability SID in the filter. All the other conditions are also met for the filter, so the packet is
|
||||
allowed. Something to note is that the only capability token required for the packet to reach bing.com was the Internet client token, even though this example showed the packet having all capabilities.
|
||||
|
||||
## Case 2: UWP APP can't reach Internet target address and has no capabilities
|
||||
|
||||
@ -304,7 +301,8 @@ In this example, the UWP app is unable to connect to bing.com
|
||||
|
||||
The following example is that of a drop netEvent that was captured in the trace.
|
||||
|
||||
**Classify Drop netEvent, Wfpdiag-Case-2.xml**
|
||||
### Classify Drop netEvent, `Wfpdiag-Case-2.xml`
|
||||
|
||||
```xml
|
||||
<netEvent>
|
||||
<header>
|
||||
@ -373,12 +371,11 @@ The following example is that of a drop netEvent that was captured in the trace.
|
||||
</internalFields>
|
||||
</netEvent>
|
||||
```
|
||||
The first thing that you should check in the **netEvent** is the capabilities
|
||||
field. In this example, the capabilities field is empty, indicating that the
|
||||
UWP app wasn't configured with any capability tokens to allow it to connect to
|
||||
a network.
|
||||
|
||||
**Internal Fields from netEvent, Wfpdiag-Case-2.xml**
|
||||
The first thing that you should check in the **netEvent** is the capabilities field. In this example, the capabilities field is empty, indicating that the UWP app wasn't configured with any capability tokens to allow it to connect to a network.
|
||||
|
||||
### Internal Fields from netEvent, `Wfpdiag-Case-2.xml`
|
||||
|
||||
```xml
|
||||
<internalFields>
|
||||
<internalFlags/>
|
||||
@ -400,9 +397,11 @@ a network.
|
||||
</terminatingFiltersInfo>
|
||||
</internalFields>
|
||||
```
|
||||
|
||||
The **netEvent** also shows information about the filter that explicitly dropped this packet, like the **FilterId**, listed under classify drop.
|
||||
|
||||
**Classify Drop from netEvent, Wfpdiag-Case-2.xml**
|
||||
### Classify Drop from netEvent, `Wfpdiag-Case-2.xml`
|
||||
|
||||
```xml
|
||||
<classifyDrop>
|
||||
<filterId>68893</filterId>
|
||||
@ -417,10 +416,11 @@ The **netEvent** also shows information about the filter that explicitly dropped
|
||||
<vSwitchDestinationPort>0</vSwitchDestinationPort>
|
||||
</classifyDrop>
|
||||
```
|
||||
|
||||
If you search for the filter #68893 in Wfpdiag-Case2.xml, you'll see that
|
||||
the packet was dropped by a Block Outbound Default Rule filter.
|
||||
|
||||
**Block Outbound Default Rule Filter #68893, Wfpdiag-Case-2.xml**
|
||||
### Block Outbound Default Rule Filter #68893, `Wfpdiag-Case-2.xml`
|
||||
|
||||
```xml
|
||||
<item>
|
||||
@ -464,24 +464,18 @@ the packet was dropped by a Block Outbound Default Rule filter.
|
||||
</item>
|
||||
```
|
||||
|
||||
A packet will reach a default block filter if the packet was unable to match any of the conditions of other filters, and not allowed by the other filters in
|
||||
the same sublayer.
|
||||
A packet will reach a default block filter if the packet was unable to match any of the conditions of other filters, and not allowed by the other filters in the same sublayer.
|
||||
|
||||
If the packet had the correct capability token,
|
||||
**FWP_CAPABILITIES_FLAG_INTERNET_CLIENT**, it would have matched a condition for a
|
||||
non-default block filter, and would have been permitted to reach bing.com.
|
||||
Without the correct capability tokens, the packet will be explicitly dropped by
|
||||
a default block outbound filter.
|
||||
If the packet had the correct capability token, **FWP_CAPABILITIES_FLAG_INTERNET_CLIENT**, it would have matched a condition for a non-default block filter, and would have been permitted to reach bing.com. Without the correct capability tokens, the packet will be explicitly dropped by a default block outbound filter.
|
||||
|
||||
## Case 3: UWP app can't reach Internet target address without Internet Client capability
|
||||
|
||||
In this example, the app is unable to connect to bing.com [2620:1ec:c11::200].
|
||||
|
||||
The app in this scenario only has private network capabilities (Client and
|
||||
Server). The app is trying to connect to an Internet resource (bing.com), but
|
||||
only has a private network token. Therefore, the packet will be dropped.
|
||||
The app in this scenario only has private network capabilities (Client and Server). The app is trying to connect to an Internet resource (bing.com), but only has a private network token. Therefore, the packet will be dropped.
|
||||
|
||||
### Classify Drop netEvent, `Wfpdiag-Case-3.xml`
|
||||
|
||||
**Classify Drop netEvent, Wfpdiag-Case-3.xml**
|
||||
```xml
|
||||
<netEvent>
|
||||
<header>
|
||||
@ -555,10 +549,10 @@ only has a private network token. Therefore, the packet will be dropped.
|
||||
|
||||
## Case 4: UWP app can't reach Intranet target address without Private Network capability
|
||||
|
||||
In this example, the UWP app is unable to reach the Intranet target address,
|
||||
10.50.50.50, because it doesn't have a Private Network capability.
|
||||
In this example, the UWP app is unable to reach the Intranet target address, 10.50.50.50, because it doesn't have a Private Network capability.
|
||||
|
||||
### Classify Drop netEvent, `Wfpdiag-Case-4.xml`
|
||||
|
||||
**Classify Drop netEvent, Wfpdiag-Case-4.xml**
|
||||
```xml
|
||||
<netEvent>
|
||||
<header>
|
||||
@ -630,12 +624,13 @@ In this example, the UWP app is unable to reach the Intranet target address,
|
||||
</internalFields>
|
||||
</netEvent>
|
||||
```
|
||||
## Case 5: UWP app can't reach “Intranet” target address with Private Network capability
|
||||
|
||||
In this example, the UWP app is unable to reach the Intranet target address,
|
||||
10.1.1.1, even though it has a Private Network capability token.
|
||||
## Case 5: UWP app can't reach "Intranet" target address with Private Network capability
|
||||
|
||||
In this example, the UWP app is unable to reach the Intranet target address, 10.1.1.1, even though it has a Private Network capability token.
|
||||
|
||||
### Classify Drop netEvent, `Wfpdiag-Case-5.xml`
|
||||
|
||||
**Classify Drop netEvent, Wfpdiag-Case-5.xml**
|
||||
```xml
|
||||
<netEvent>
|
||||
<header>
|
||||
@ -706,9 +701,10 @@ In this example, the UWP app is unable to reach the Intranet target address,
|
||||
</internalFields>
|
||||
</netEvent>
|
||||
```
|
||||
|
||||
The following shows the filter that blocked the event:
|
||||
|
||||
**Block Outbound Default Rule Filter \#121180, Wfpdiag-Case-5.xml**
|
||||
### Block Outbound Default Rule Filter #121180, `Wfpdiag-Case-5.xml`
|
||||
|
||||
```xml
|
||||
<item>
|
||||
@ -751,14 +747,13 @@ The following shows the filter that blocked the event:
|
||||
</effectiveWeight>
|
||||
</item>
|
||||
```
|
||||
If the target was in the private range, then it should have been allowed by a
|
||||
PrivateNetwork Outbound Default Rule filter.
|
||||
|
||||
The following PrivateNetwork Outbound Default Rule filters have conditions for matching Intranet IP addresses. Since the expected Intranet target address,
|
||||
10.1.1.1, isn't included in these filters it becomes clear that the address isn't in the private range. Check the policies that configure the private range
|
||||
on the device (MDM, Group Policy, etc.) and make sure it includes the private target address you wanted to reach.
|
||||
If the target was in the private range, then it should have been allowed by a PrivateNetwork Outbound Default Rule filter.
|
||||
|
||||
The following PrivateNetwork Outbound Default Rule filters have conditions for matching Intranet IP addresses. Since the expected Intranet target address, 10.1.1.1, isn't included in these filters it becomes clear that the address isn't in the private range. Check the policies that configure the private range on the device (MDM, Group Policy, etc.) and make sure it includes the private target address you wanted to reach.
|
||||
|
||||
### PrivateNetwork Outbound Default Rule Filters, `Wfpdiag-Case-5.xml`
|
||||
|
||||
**PrivateNetwork Outbound Default Rule Filters, Wfpdiag-Case-5.xml**
|
||||
```xml
|
||||
<item>
|
||||
<filterKey>{fd65507b-e356-4e2f-966f-0c9f9c1c6e78}</filterKey>
|
||||
@ -992,17 +987,12 @@ on the device (MDM, Group Policy, etc.) and make sure it includes the private ta
|
||||
</effectiveWeight>
|
||||
</item>
|
||||
```
|
||||
|
||||
## Debugging Past Drops
|
||||
|
||||
If you're debugging a network drop from the past or from a remote machine, you
|
||||
may have traces already collected from Feedback Hub, such as nettrace.etl and
|
||||
wfpstate.xml. Once nettrace.etl is converted, nettrace.txt will have the
|
||||
netEvents of the reproduced event, and wfpstate.xml will contain the filters
|
||||
that were present on the machine at the time.
|
||||
If you're debugging a network drop from the past or from a remote machine, you may have traces already collected from Feedback Hub, such as nettrace.etl and wfpstate.xml. Once nettrace.etl is converted, nettrace.txt will have the netEvents of the reproduced event, and wfpstate.xml will contain the filters that were present on the machine at the time.
|
||||
|
||||
If you don't have a live repro or traces already collected, you can still
|
||||
collect traces after the UWP network connectivity issue has happened by running
|
||||
these commands in an admin command prompt
|
||||
If you don't have a live repro or traces already collected, you can still collect traces after the UWP network connectivity issue has happened by running these commands in an admin command prompt:
|
||||
|
||||
```xml
|
||||
<Run UWP app>
|
||||
@ -1010,34 +1000,22 @@ these commands in an admin command prompt
|
||||
Netsh wfp show state
|
||||
```
|
||||
|
||||
**Netsh wfp show netevents** creates netevents.xml, which contains the past
|
||||
net events. **Netsh wfp show state** creates wfpstate.xml, which contains
|
||||
the current filters present on the machine.
|
||||
`Netsh wfp show netevents` creates `netevents.xml`, which contains the past net events. `Netsh wfp show state` creates wfpstate.xml, which contains the current filters present on the machine.
|
||||
|
||||
Unfortunately, collecting traces after the UWP network connectivity issue isn't always reliable.
|
||||
|
||||
NetEvents on the device are stored in a buffer. Once that buffer has reached
|
||||
maximum capacity, the buffer will overwrite older net events. Due to the buffer
|
||||
overwrite, it's possible that the collected netevents.xml won't contain the
|
||||
net event associated with the UWP network connectivity issue. It could have been ov
|
||||
overwritten. Additionally, filters on the device can get deleted and re-added
|
||||
with different filterIds due to miscellaneous events on the device. Because of
|
||||
these implications, a **filterId** from **netsh wfp show netevents** may not necessarily match any
|
||||
filter in **netsh wfp show state** because that **filterId** may be outdated.
|
||||
NetEvents on the device are stored in a buffer. Once that buffer has reached maximum capacity, the buffer will overwrite older net events. Due to the buffer overwrite, it's possible that the collected netevents.xml won't contain the net event associated with the UWP network connectivity issue. It could have been overwritten. Additionally, filters on the device can get deleted and re-added with different filterIds due to miscellaneous events on the device. Because of these implications, a **filterId** from **netsh wfp show netevents** may not necessarily match any filter in **netsh wfp show state** because that **filterId** may be outdated.
|
||||
|
||||
If you can reproduce the UWP network connectivity issue consistently, we
|
||||
recommend using the commands from Debugging Live Drops instead.
|
||||
If you can reproduce the UWP network connectivity issue consistently, we recommend using the commands from Debugging Live Drops instead.
|
||||
|
||||
Additionally, you can still follow the examples from Debugging Live Drops
|
||||
section using the trace commands in this section, even if you don't have a live
|
||||
repro. The **netEvents** and filters are stored in one file in Debugging Live Drops
|
||||
Additionally, you can still follow the examples from Debugging Live Drops section using the trace commands in this section, even if you don't have a live repro. The **netEvents** and filters are stored in one file in Debugging Live Drops
|
||||
as opposed to two separate files in the following Debugging Past Drops examples.
|
||||
|
||||
## Case 7: Debugging Past Drop - UWP app can't reach Internet target address and has no capabilities
|
||||
|
||||
In this example, the UWP app is unable to connect to bing.com.
|
||||
|
||||
Classify Drop Net Event, NetEvents-Case-7.xml
|
||||
### Classify Drop Net Event, `NetEvents-Case-7.xml`
|
||||
|
||||
```xml
|
||||
<item>
|
||||
@ -1108,15 +1086,12 @@ Classify Drop Net Event, NetEvents-Case-7.xml
|
||||
</item>
|
||||
```
|
||||
|
||||
The Internal fields list no active capabilities, and the packet is dropped at
|
||||
filter 206064.
|
||||
The Internal fields list no active capabilities, and the packet is dropped at nfilter 206064.
|
||||
|
||||
This filter is a default block rule filter, meaning the packet passed through every
|
||||
filter that could have allowed it, but because conditions didn’t match for any of
|
||||
those filters, the packet fell to the filter that blocks any packet that the
|
||||
Security Descriptor doesn’t match.
|
||||
This filter is a default block rule filter, meaning the packet passed through every filter that could have allowed it, but because conditions didn't match for any of those filters, the packet fell to the filter that blocks any packet that the
|
||||
Security Descriptor doesn't match.
|
||||
|
||||
**Block Outbound Default Rule Filter \#206064, FilterState-Case-7.xml**
|
||||
### Block Outbound Default Rule Filter #206064, `FilterState-Case-7.xml`
|
||||
|
||||
```xml
|
||||
<item>
|
||||
@ -1159,11 +1134,12 @@ Security Descriptor doesn’t match.
|
||||
</effectiveWeight>
|
||||
</item>
|
||||
```
|
||||
|
||||
## Case 8: Debugging Past Drop - UWP app connects to Internet target address with all capabilities
|
||||
|
||||
In this example, the UWP app successfully connects to bing.com [204.79.197.200].
|
||||
|
||||
**Classify Allow Net Event, NetEvents-Case-8.xml**
|
||||
### Classify Allow Net Event, `NetEvents-Case-8.xml`
|
||||
|
||||
```xml
|
||||
<item>
|
||||
@ -1232,11 +1208,13 @@ In this example, the UWP app successfully connects to bing.com [204.79.197.200].
|
||||
</internalFields>
|
||||
</item>
|
||||
```
|
||||
|
||||
All capabilities are enabled and the resulting filter determining the flow of the packet is 208757.
|
||||
|
||||
The filter stated above with action permit:
|
||||
|
||||
**InternetClient Default Rule Filter \#208757, FilterState-Case-8.xml**
|
||||
### InternetClient Default Rule Filter #208757, `FilterState-Case-8.xml`
|
||||
|
||||
```xml
|
||||
<item>
|
||||
<filterKey>{e0f6f24e-1f0a-4f1a-bdd8-b9277c144fb5}</filterKey>
|
||||
@ -1319,5 +1297,3 @@ The filter stated above with action permit:
|
||||
</effectiveWeight>
|
||||
</item>
|
||||
```
|
||||
The capabilities field in a netEvent was added to the traces in the Windows 10
|
||||
May 2019 Update.
|
||||
|
||||
@ -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