deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-12 13:27:23 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Merge branch 'main' into alexbuckgit/docutune-autopr-20231018-031426-4587577-ignore-build

Browse Source
This commit is contained in:
Stacyrch140 2023-10-18 14:04:36 -04:00 committed by GitHub
commit 8826d4bba1
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
33 changed files with 169 additions and 145 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
windows/application-management/private-app-repository-mdm-company-portal-windows-11.md
View File

@ -63,7 +63,7 @@ To install the Company Portal app, you have some options:
- [What is co-management?](/mem/configmgr/comanage/overview)
- [Use the Company Portal app on co-managed devices](/mem/configmgr/comanage/company-portal)
- **Use Windows Autopilot**: Windows Autopilot automatically provisions devices, registers them in your Azure AD organization (tenant), and gets them ready for production. If you're purchasing new devices, then we recommend using Windows Autopilot to preconfigure the devices, and get them ready for use.
- **Use Windows Autopilot**: Windows Autopilot automatically provisions devices, registers them in your Microsoft Entra organization (tenant), and gets them ready for production. If you're purchasing new devices, then we recommend using Windows Autopilot to preconfigure the devices, and get them ready for use.
- In the [Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431), you add the Company Portal app from the Microsoft Store. Once it's added, the app can be included in your Windows Autopilot deployment. When the device turns on and is getting ready, the Company Portal app is also installed, before users sign in.

34
windows/security/application-security/application-control/windows-defender-application-control/applocker/using-event-viewer-with-applocker.md
View File

@ -38,24 +38,24 @@ The following table contains information about the events that you can use to de
| Event ID | Level | Event message | Description |
| --- | --- | --- | --- |
| 8000 | Error| Application Identity Policy conversion failed. Status * <%1> *| Indicates that the policy wasn't applied correctly to the computer. The status message is provided for troubleshooting purposes.|
| 8000 | Error| AppID policy conversion failed. Status * <%1> *| Indicates that the policy wasn't applied correctly to the computer. The status message is provided for troubleshooting purposes.|
| 8001 | Information| The AppLocker policy was applied successfully to this computer.| Indicates that the AppLocker policy was successfully applied to the computer.|
| 8002 | Information| *<File name> * was allowed to run.| Specifies that the .exe or .dll file is allowed by an AppLocker rule.|
| 8003 | Warning| *<File name> * was allowed to run but would have been prevented from running if the AppLocker policy was enforced.| Applied only when the **Audit only** enforcement mode is enabled. Specifies that the .exe or .dll file would be blocked if the **Enforce rules** enforcement mode were enabled. |
| 8004 | Error| *<File name> * was not allowed to run.| Access to *<file name>* is restricted by the administrator. Applied only when the **Enforce rules** enforcement mode is set either directly or indirectly through Group Policy inheritance. The .exe or .dll file can't run.|
| 8003 | Warning| *<File name> * was allowed to run but would have been prevented from running if the AppLocker policy were enforced.| Applied only when the **Audit only** enforcement mode is enabled. Specifies that the .exe or .dll file would be blocked if the **Enforce rules** enforcement mode were enabled. |
| 8004 | Error| *<File name> * was prevented from running.| Access to *<file name>* is restricted by the administrator. Applied only when the **Enforce rules** enforcement mode is set either directly or indirectly through Group Policy inheritance. The .exe or .dll file can't run.|
| 8005| Information| *<File name> * was allowed to run.| Specifies that the script or .msi file is allowed by an AppLocker rule.|
| 8006 | Warning| *<File name> * was allowed to run but would have been prevented from running if the AppLocker policy was enforced.| Applied only when the **Audit only** enforcement mode is enabled. Specifies that the script or .msi file would be blocked if the **Enforce rules** enforcement mode were enabled. |
| 8007 | Error| *<File name> * was not allowed to run.| Access to *<file name>* is restricted by the administrator. Applied only when the **Enforce rules** enforcement mode is set either directly or indirectly through Group Policy inheritance. The script or .msi file can't run.|
| 8008| Error| AppLocker disabled on the SKU.| Added in Windows Server 2012 and Windows 8.|
| 8020| Information| Packaged app allowed.| Added in Windows Server 2012 and Windows 8.|
| 8021| Information| Packaged app audited.| Added in Windows Server 2012 and Windows 8.|
| 8022| Information| Packaged app disabled.| Added in Windows Server 2012 and Windows 8.|
| 8023 | Information| Packaged app installation allowed.| Added in Windows Server 2012 and Windows 8.|
| 8024 | Information| Packaged app installation audited.| Added in Windows Server 2012 and Windows 8.|
| 8025 | Warning| Packaged app installation disabled.| Added in Windows Server 2012 and Windows 8.|
| 8027 | Warning| No Packaged app rule configured.| Added in Windows Server 2012 and Windows 8.|
| 8028 | Warning | * was allowed to run but would have been prevented if the Config CI policy was enforced.| Added in Windows Server 2016 and Windows 10.|
| 8029 | Error | * was prevented from running due to Config CI policy.| Added in Windows Server 2016 and Windows 10.|
| 8006 | Warning| *<File name> * was allowed to run but would have been prevented from running if the AppLocker policy were enforced.| Applied only when the **Audit only** enforcement mode is enabled. Specifies that the script or .msi file would be blocked if the **Enforce rules** enforcement mode were enabled. |
| 8007 | Error| *<File name> * was prevented from running.| Access to *<file name>* is restricted by the administrator. Applied only when the **Enforce rules** enforcement mode is set either directly or indirectly through Group Policy inheritance. The script or .msi file can't run.|
| 8008| Warning| *<File name> *: AppLocker component not available on this SKU.| Added in Windows Server 2012 and Windows 8.|
| 8020| Information| *<File name> * was allowed to run.| Added in Windows Server 2012 and Windows 8.|
| 8021| Warning| *<File name> * was allowed to run but would have been prevented from running if the AppLocker policy were enforced.| Added in Windows Server 2012 and Windows 8.|
| 8022| Error| *<File name> * was prevented from running.| Added in Windows Server 2012 and Windows 8.|
| 8023 | Information| *<File name> * was allowed to be installed.| Added in Windows Server 2012 and Windows 8.|
| 8024 | Warning| *<File name> * was allowed to run but would have been prevented from running if the AppLocker policy were enforced.| Added in Windows Server 2012 and Windows 8.|
| 8025 | Error| *<File name> * was prevented from running.| Added in Windows Server 2012 and Windows 8.|
| 8027 | Error| No packaged apps can be executed while Exe rules are being enforced and no Packaged app rules have been configured.| Added in Windows Server 2012 and Windows 8.|
| 8028 | Warning | *<File name> * was allowed to run but would have been prevented if the Config CI policy were enforced.| Added in Windows Server 2016 and Windows 10.|
| 8029 | Error | *<File name> * was prevented from running due to Config CI policy.| Added in Windows Server 2016 and Windows 10.|
| 8030 | Information | ManagedInstaller check SUCCEEDED during Appid verification of * | Added in Windows Server 2016 and Windows 10.|
| 8031 | Information | SmartlockerFilter detected file * being written by process * | Added in Windows Server 2016 and Windows 10.|
| 8032 | Error | ManagedInstaller check FAILED during Appid verification of * | Added in Windows Server 2016 and Windows 10.|
@ -63,9 +63,9 @@ The following table contains information about the events that you can use to de
| 8034 | Information | ManagedInstaller Script check FAILED during Appid verification of * | Added in Windows Server 2016 and Windows 10.|
| 8035 | Error | ManagedInstaller Script check SUCCEEDED during Appid verification of * | Added in Windows Server 2016 and Windows 10.|
| 8036 | Error | * was prevented from running due to Config CI policy | Added in Windows Server 2016 and Windows 10.|
| 8037 | Information | * passed Config CI policy and was allowed to run | Added in Windows Server 2016 and Windows 10.|
| 8037 | Information | * passed Config CI policy and was allowed to run.| Added in Windows Server 2016 and Windows 10.|
| 8038 | Information | Publisher info: Subject: * Issuer: * Signature index * (* total) | Added in Windows Server 2016 and Windows 10.|
| 8039 | Warning | * passed Config CI policy and was allowed to run | Added in Windows Server 2016 and Windows 10.|
| 8039 | Warning | Package family name * version * was allowed to install or update but would have been prevented if the Config CI policy | Added in Windows Server 2016 and Windows 10.|
| 8040 | Error | Package family name * version * was prevented from installing or updating due to Config CI policy | Added in Windows Server 2016 and Windows 10.|

74
windows/security/identity-protection/hello-for-business/hello-planning-guide.md
View File

@ -6,7 +6,7 @@ ms.topic: overview
---
# Planning a Windows Hello for Business Deployment
Congratulations! You are taking the first step forward in helping move your organizations away from password to a two-factor, convenience authentication for Windows — Windows Hello for Business. This planning guide helps you understand the different topologies, architectures, and components that encompass a Windows Hello for Business infrastructure.
Congratulations! You're taking the first step forward in helping move your organizations away from password to a two-factor, convenience authentication for Windows — Windows Hello for Business. This planning guide helps you understand the different topologies, architectures, and components that encompass a Windows Hello for Business infrastructure.
This guide explains the role of each component within Windows Hello for Business and how certain deployment decisions affect other aspects of the infrastructure. Armed with your planning worksheet, you'll use that information to select the correct deployment guide for your needs.
@ -15,7 +15,7 @@ This guide explains the role of each component within Windows Hello for Business
## Using this guide
There are many options from which you can choose when deploying Windows Hello for Business. Providing multiple options ensures nearly every organization can deploy Windows Hello for Business. Providing many options makes the deployment appear complex, however, most organization will realize they've already implemented most of the infrastructure on which the Windows Hello for Business deployment depends. It is important to understand that Windows Hello for Business is a distributed system and does take proper planning across multiple teams within an organization.
There are many options from which you can choose when deploying Windows Hello for Business. Providing multiple options ensures nearly every organization can deploy Windows Hello for Business. Providing many options makes the deployment appear complex, however, most organization will realize they've already implemented most of the infrastructure on which the Windows Hello for Business deployment depends. It's important to understand that Windows Hello for Business is a distributed system and does take proper planning across multiple teams within an organization.
This guide removes the appearance of complexity by helping you make decisions on each aspect of your Windows Hello for Business deployment and the options you'll need to consider. Using this guide also identifies the information needed to help you make decisions about the deployment that best suits your environment. Download the [Windows Hello for Business planning worksheet](https://go.microsoft.com/fwlink/?linkid=852514) from the Microsoft Download Center to help track your progress and make your planning easier.
@ -52,9 +52,9 @@ The cloud only deployment model is for organizations who only have cloud identit
The hybrid deployment model is for organizations that:
- Are federated with Azure Active Directory
- Have identities synchronized to Azure Active Directory using Azure Active Directory Connect
- Use applications hosted in Azure Active Directory, and want a single sign-in user experience for both on-premises and Azure Active Directory resources
- Are federated with Microsoft Entra ID
- Have identities synchronized to Microsoft Entra ID using Microsoft Entra Connect
- Use applications hosted in Microsoft Entra ID, and want a single sign-in user experience for both on-premises and Microsoft Entra resources
> [!Important]
> Hybrid deployments support non-destructive PIN reset that works with both the certificate trust and key trust models.
@ -64,7 +64,7 @@ The hybrid deployment model is for organizations that:
> - Reset above lock screen (_I forgot my PIN_ link) - Windows 10, version 1903
##### On-premises
The on-premises deployment model is for organizations that do not have cloud identities or use applications hosted in Azure Active Directory.
The on-premises deployment model is for organizations that do not have cloud identities or use applications hosted in Microsoft Entra ID.
> [!Important]
> On-premises deployments support destructive PIN reset that works with both the certificate trust and the key trust models.
@ -81,9 +81,9 @@ It's fundamentally important to understand which deployment model to use for a s
A deployment's trust type defines how each Windows Hello for Business client authenticates to the on-premises Active Directory. There are two trust types: key trust and certificate trust.
> [!NOTE]
> Windows Hello for Business introduced a new trust model called cloud Kerberos trust, in early 2022. This model enables deployment of Windows Hello for Business using the infrastructure introduced for supporting [security key sign-in on Hybrid Azure AD-joined devices and on-premises resource access on Azure AD Joined devices](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). For more information, see [Hybrid Cloud Kerberos Trust Deployment](hello-hybrid-cloud-kerberos-trust.md).
> Windows Hello for Business introduced a new trust model called cloud Kerberos trust, in early 2022. This model enables deployment of Windows Hello for Business using the infrastructure introduced for supporting [security key sign-in on Microsoft Entra hybrid joined devices and on-premises resource access on Microsoft Entra joined devices](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). For more information, see [Hybrid Cloud Kerberos Trust Deployment](hello-hybrid-cloud-kerberos-trust.md).
The key trust type does not require issuing authentication certificates to end users. Users authenticate using a hardware-bound key created during the built-in provisioning experience. This requires an adequate distribution of Windows Server 2016 or later domain controllers relative to your existing authentication and the number of users included in your Windows Hello for Business deployment. Read the [Planning an adequate number of Windows Server 2016 or later Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more.
The key trust type doesn't require issuing authentication certificates to end users. Users authenticate using a hardware-bound key created during the built-in provisioning experience. This requires an adequate distribution of Windows Server 2016 or later domain controllers relative to your existing authentication and the number of users included in your Windows Hello for Business deployment. Read the [Planning an adequate number of Windows Server 2016 or later Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more.
The certificate trust type issues authentication certificates to end users. Users authenticate using a certificate requested using a hardware-bound key created during the built-in provisioning experience. Unlike key trust, certificate trust does not require Windows Server 2016 domain controllers (but still requires [Windows Server 2016 or later Active Directory schema](/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust#directories)). Users can use their certificate to authenticate to any Windows Server 2008 R2, or later, domain controller.
@ -92,33 +92,33 @@ The certificate trust type issues authentication certificates to end users. Use
#### Device registration
All devices included in the Windows Hello for Business deployment must go through device registration. Device registration enables devices to authenticate to identity providers. For cloud only and hybrid deployment, the identity provider is Azure Active Directory. For on-premises deployments, the identity provider is the on-premises server running the Windows Server 2016 Active Directory Federation Services (AD FS) role.
All devices included in the Windows Hello for Business deployment must go through device registration. Device registration enables devices to authenticate to identity providers. For cloud only and hybrid deployment, the identity provider is Microsoft Entra ID. For on-premises deployments, the identity provider is the on-premises server running the Windows Server 2016 Active Directory Federation Services (AD FS) role.
#### Key registration
The built-in Windows Hello for Business provisioning experience creates a hardware bound asymmetric key pair as their user's credentials. The private key is protected by the device's security modules; however, the credential is a user key (not a device key). The provisioning experience registers the user's public key with the identity provider. For cloud only and hybrid deployments, the identity provider is Azure Active Directory. For on-premises deployments, the identity provider is the on-premises server running Windows Server 2016 Active Directory Federation Services (AD FS) role.
The built-in Windows Hello for Business provisioning experience creates a hardware bound asymmetric key pair as their user's credentials. The private key is protected by the device's security modules; however, the credential is a user key (not a device key). The provisioning experience registers the user's public key with the identity provider. For cloud only and hybrid deployments, the identity provider is Microsoft Entra ID. For on-premises deployments, the identity provider is the on-premises server running Windows Server 2016 Active Directory Federation Services (AD FS) role.
#### Multifactor authentication
> [!IMPORTANT]
> As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who require multi-factor authentication for their users should use cloud-based Azure AD Multi-Factor Authentication. Existing customers who have activated MFA Server prior to July 1, 2019 will be able to download the latest version, future updates and generate activation credentials as usual. See [Getting started with the Azure AD Multi-Factor Authentication Server](/azure/active-directory/authentication/howto-mfaserver-deploy) for more details.
> As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who require multifactor authentication for their users should use cloud-based Microsoft Entra multifactor authentication. Existing customers who have activated MFA Server prior to July 1, 2019 will be able to download the latest version, future updates and generate activation credentials as usual. See [Getting started with the Azure Multi-Factor Authentication Server](/azure/active-directory/authentication/howto-mfaserver-deploy) for more details.
The goal of Windows Hello for Business is to move organizations away from passwords by providing them a strong credential that provides easy two-factor authentication. The built-in provisioning experience accepts the user's weak credentials (username and password) as the first factor authentication; however, the user must provide a second factor of authentication before Windows provisions a strong credential.
The goal of Windows Hello for Business is to move organizations away from passwords by providing them a with strong credential that provides easy two-factor authentication. The built-in provisioning experience accepts the user's weak credentials (username and password) as the first factor authentication; however, the user must provide a second factor of authentication before Windows provisions a strong credential.
Cloud only and hybrid deployments provide many choices for multi-factor authentication. On-premises deployments must use a multi-factor authentication that provides an AD FS multi-factor adapter to be used in conjunction with the on-premises Windows Server 2016 AD FS server role. Organizations can use the on-premises Azure AD Multi-Factor Authentication server, or choose from several third parties (Read [Microsoft and third-party additional authentication methods](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs#microsoft-and-third-party-additional-authentication-methods) for more information).
Cloud only and hybrid deployments provide many choices for multifactor authentication. On-premises deployments must use a multifactor authentication that provides an AD FS multifactor adapter to be used in conjunction with the on-premises Windows Server 2016 AD FS server role. Organizations can use the on-premises Azure Multi-Factor Authentication Server, or choose from several third parties (Read [Microsoft and third-party additional authentication methods](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs#microsoft-and-third-party-additional-authentication-methods) for more information).
> [!NOTE]
> Azure AD Multi-Factor Authentication is available through:
> Microsoft Entra multifactor authentication is available through:
> * Microsoft Enterprise Agreement
> * Open Volume License Program
> * Cloud Solution Providers program
> * Bundled with
> * Azure Active Directory Premium
> * Microsoft Entra ID P1 or P2
> * Enterprise Mobility Suite
> * Enterprise Cloud Suite
#### Directory synchronization
Hybrid and on-premises deployments use directory synchronization, however, each for a different purpose. Hybrid deployments use Azure Active Directory Connect to synchronize Active Directory identities or credentials between itself and Azure Active Directory. This helps enable single sign-on to Azure Active Directory and its federated components. On-premises deployments use directory synchronization to import users from Active Directory to the Azure MFA Server, which sends data to the Azure MFA cloud service to perform the verification.
Hybrid and on-premises deployments use directory synchronization, however, each for a different purpose. Hybrid deployments use Microsoft Entra Connect to synchronize Active Directory identities or credentials between itself and Microsoft Entra ID. This helps enable single sign-on to Microsoft Entra ID and its federated components. On-premises deployments use directory synchronization to import users from Active Directory to the Azure MFA Server, which sends data to the Azure MFA cloud service to perform the verification.
### Management
@ -136,7 +136,7 @@ Modern management is an emerging device management paradigm that leverages the c
Windows Hello for Business is an exclusive Windows 10 and Windows 11 feature. As part of the Windows as a Service strategy, Microsoft has improved the deployment, management, and user experience with each new release of Windows and introduced support for new scenarios.
Most deployment scenarios require a minimum of Windows 10, version 1511, also known as the November Update. The client requirement may change based on different components in your existing infrastructure, or other infrastructure choices made later in planning your deployment. Those components and choices may require a minimum client running Windows 10, version 1703, also known as the Creators Update.
Most deployment scenarios require a minimum of Windows 10, version 1511, also known as the November Update. The client requirement might change based on different components in your existing infrastructure, or other infrastructure choices made later in planning your deployment. Those components and choices might require a minimum client running Windows 10, version 1703, also known as the Creators Update.
### Active Directory
@ -145,11 +145,11 @@ Hybrid and on-premises deployments include Active Directory as part of their inf
### Public Key Infrastructure
The Windows Hello for Business deployment depends on an enterprise public key infrastructure as a trust anchor for authentication. Domain controllers for hybrid and on-premises deployments need a certificate in order for Windows devices to trust the domain controller as legitimate. Deployments using the certificate trust type need an enterprise public key infrastructure and a certificate registration authority to issue authentication certificates to users. Hybrid deployments may need to issue VPN certificates to users to enable connectivity on-premises resources.
The Windows Hello for Business deployment depends on an enterprise public key infrastructure as a trust anchor for authentication. Domain controllers for hybrid and on-premises deployments need a certificate in order for Windows devices to trust the domain controller as legitimate. Deployments using the certificate trust type need an enterprise public key infrastructure and a certificate registration authority to issue authentication certificates to users. Hybrid deployments might need to issue VPN certificates to users to enable connectivity on-premises resources.
### Cloud
Some deployment combinations require an Azure account, and some require Azure Active Directory for user identities. These cloud requirements may only need an Azure account while other features need an Azure Active Directory Premium subscription. The planning process identifies and differentiates the components that are needed from those that are optional.
Some deployment combinations require an Azure account, and some require Microsoft Entra ID for user identities. These cloud requirements may only need an Azure account while other features need a Microsoft Entra ID P1 or P2 subscription. The planning process identifies and differentiates the components that are needed from those that are optional.
## Planning a Deployment
@ -173,13 +173,13 @@ If your organization does not have cloud resources, write **On-Premises** in box
### Trust type
Hybrid Azure AD-joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates. Hybrid Azure AD-joined devices and Azure AD-joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates.
Microsoft Entra hybrid joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates. Microsoft Entra hybrid joined devices and Microsoft Entra joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates.
Choose a trust type that is best suited for your organizations. Remember, the trust type determines two things. Whether you issue authentication certificates to your users and if your deployment needs Windows Server 2016 domain controllers.
One trust model is not more secure than the other. The major difference is based on the organization comfort with deploying Windows Server 2016 domain controllers and not enrolling users with end entity certificates (key-trust) against using existing domain controllers and needing to enroll certificates for all their users (certificate trust).
Because the certificate trust types issues certificates, there is more configuration and infrastructure needed to accommodate user certificate enrollment, which could also be a factor to consider in your decision. Additional infrastructure needed for certificate-trust deployments includes a certificate registration authority. In a federated environment, you need to activate the Device Writeback option in Azure AD Connect.
Because the certificate trust types issues certificates, there is more configuration and infrastructure needed to accommodate user certificate enrollment, which could also be a factor to consider in your decision. Additional infrastructure needed for certificate-trust deployments includes a certificate registration authority. In a federated environment, you need to activate the Device Writeback option in Microsoft Entra Connect.
If your organization wants to use the key trust type, write **key trust** in box **1b** on your planning worksheet. Write **Windows Server 2016** in box **4d**. Write **N/A** in box **5b**.
@ -203,17 +203,17 @@ If box **1a** on your planning worksheet reads **on-premises**, write **AD FS**
### Directory Synchronization
Windows Hello for Business is strong user authentication, which usually means there is an identity (a user or username) and a credential (typically a key pair). Some operations require writing or reading user data to or from the directory. For example, reading the user's phone number to perform multi-factor authentication during provisioning or writing the user's public key.
Windows Hello for Business is strong user authentication, which usually means there is an identity (a user or username) and a credential (typically a key pair). Some operations require writing or reading user data to or from the directory. For example, reading the user's phone number to perform multifactor authentication during provisioning or writing the user's public key.
If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **1e**. User information is written directly to Azure Active Directory and there is not another directory with which the information must be synchronized.
If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **1e**. User information is written directly to Microsoft Entra ID and there is not another directory with which the information must be synchronized.
If box **1a** on your planning worksheet reads **hybrid**, then write **Azure AD Connect** in box **1e** on your planning worksheet.
If box **1a** on your planning worksheet reads **hybrid**, then write **Microsoft Entra Connect** in box **1e** on your planning worksheet.
If box **1a** on your planning worksheet reads **on-premises**, then write **Azure MFA Server**. This deployment exclusively uses Active Directory for user information with the exception of the multi-factor authentication. The on-premises Azure MFA server synchronizes a subset of the user information, such as phone number, to provide multi-factor authentication while the user's credentials remain on the on-premises network.
If box **1a** on your planning worksheet reads **on-premises**, then write **Azure MFA Server**. This deployment exclusively uses Active Directory for user information with the exception of the multifactor authentication. The on-premises Azure MFA server synchronizes a subset of the user information, such as phone number, to provide multifactor authentication while the user's credentials remain on the on-premises network.
### Multifactor Authentication
### Multifactor authentication
The goal of Windows Hello for Business is to move user authentication away from passwords to a strong, key-based user authentication. Passwords are weak credentials and cannot be trusted by themselves as an attacker with a stolen password could be attempting to enroll in Windows Hello for Business. To keep the transition from a weak to a strong credential secure, Windows Hello for Business relies on multi-factor authentication during provisioning to have some assurances that the user identity provisioning a Windows Hello for Business credential is the proper identity.
The goal of Windows Hello for Business is to move user authentication away from passwords to a strong, key-based user authentication. Passwords are weak credentials and cannot be trusted by themselves as an attacker with a stolen password could be attempting to enroll in Windows Hello for Business. To keep the transition from a weak to a strong credential secure, Windows Hello for Business relies on multifactor authentication during provisioning to have some assurances that the user identity provisioning a Windows Hello for Business credential is the proper identity.
If box **1a** on your planning worksheet reads **cloud only**, then your only option is to use the Azure MFA cloud service. Write **Azure MFA** in box **1f** on your planning worksheet.
@ -225,7 +225,7 @@ If box **1a** on your planning worksheet reads **hybrid**, then you have a few o
You can directly use the Azure MFA cloud service for the second factor of authentication. Users contacting the service must authenticate to Azure prior to using the service.
If your Azure AD Connect is configured to synchronize identities (usernames only), then your users are redirected to your local on-premises federation server for authentication and then redirected back to the Azure MFA cloud service. Otherwise, your Azure AD Connect is configured to synchronize credentials (username and passwords), which enables your users to authenticate to Azure Active Directory and use the Azure MFA cloud service. If you choose to use the Azure MFA cloud service directly, write **Azure MFA** in box **1f** on your planning worksheet.
If your Microsoft Entra Connect is configured to synchronize identities (usernames only), then your users are redirected to your local on-premises federation server for authentication and then redirected back to the Azure MFA cloud service. Otherwise, your Microsoft Entra Connect is configured to synchronize credentials (username and passwords), which enables your users to authenticate to Microsoft Entra ID and use the Azure MFA cloud service. If you choose to use the Azure MFA cloud service directly, write **Azure MFA** in box **1f** on your planning worksheet.
You can configure your on-premises Windows Server 2016 AD FS role to use the Azure MFA service adapter. In this configuration, users are redirected to the on premises AD FS server (synchronizing identities only). The AD FS server uses the MFA adapter to communicate to the Azure MFA service to perform the second factor of authentication. If you choose to use AD FS with the Azure MFA cloud service adapter, write **AD FS with Azure MFA cloud adapter** in box **1f** on your planning worksheet.
@ -241,10 +241,10 @@ If you choose to use AD FS with the Azure MFA server adapter, write **AD FS with
Windows Hello for Business provides organizations with many policy settings and granular control on how these settings may be applied to both computers and users. The type of policy management you can use depends on your selected deployment and trust models.
If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **2a** on your planning worksheet. You have the option to manage non-domain joined devices. If you choose to manage Azure Active Directory-joined devices, write **modern management** in box **2b** on your planning worksheet. Otherwise, write** N/A** in box **2b**.
If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **2a** on your planning worksheet. You have the option to manage non-domain joined devices. If you choose to manage Microsoft Entra joined devices, write **modern management** in box **2b** on your planning worksheet. Otherwise, write** N/A** in box **2b**.
> [!NOTE]
> Azure Active Directory-joined devices without modern management automatically enroll in Windows Hello for Business using the default policy settings. Use modern management to adjust policy settings to match the business needs of your organization.
> Microsoft Entra joined devices without modern management automatically enroll in Windows Hello for Business using the default policy settings. Use modern management to adjust policy settings to match the business needs of your organization.
If box **1a** on your planning worksheet reads **on-prem**, write **GP** in box **2a** on your planning worksheet. Write **N/A** in box **2b** on your worksheet.
@ -260,7 +260,7 @@ Windows Hello for Business is a feature exclusive to Windows 10 and Windows 11.
If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **3a** on your planning worksheet. Optionally, you may write **1511 or later** in box **3b** on your planning worksheet if you plan to manage non-domain joined devices.
> [!NOTE]
> Azure Active Directory-joined devices without modern management automatically enroll in Windows Hello for Business using the default policy settings. Use modern management to adjust policy settings to match the business needs of your organization.
> Microsoft Entra joined devices without modern management automatically enroll in Windows Hello for Business using the default policy settings. Use modern management to adjust policy settings to match the business needs of your organization.
Write **1511 or later** in box **3a** on your planning worksheet if any of the following are true.
* Box **2a** on your planning worksheet read **modern management**.
@ -288,7 +288,7 @@ If box **1a** on your planning worksheet reads **cloud only**, ignore the public
If box **1b** on your planning worksheet reads **key trust**, write **N/A** in box **5b** on your planning worksheet. Key trust doesn't require any change in public key infrastructure, skip this part and go to **Cloud** section.
The registration authority only relates to certificate trust deployments and the management used for domain and non-domain joined devices. Hybrid Azure AD-joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates. Hybrid Azure AD-joined devices and Azure AD-joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates.
The registration authority only relates to certificate trust deployments and the management used for domain and non-domain joined devices. Microsoft Entra hybrid joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates. Microsoft Entra hybrid joined devices and Microsoft Entra joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates.
If box **2a** reads **GP** and box **2b** reads **modern management**, write **AD FS RA and NDES** in box **5b** on your planning worksheet. In box **5c**, write the following certificate templates names and issuances:
@ -323,18 +323,18 @@ If box **1a** on your planning worksheet reads **cloud only** or **hybrid**, wri
If box **1a** on your planning worksheet reads **on-premises**, and box **1f** reads **AD FS with third party**, write **No** in box **6a** on your planning worksheet. Otherwise, write **Yes** in box **6a** as you need an Azure account for per-consumption MFA billing. Write **No** in box **6b** on your planning worksheet—on-premises deployments do not use the cloud directory.
Windows Hello for Business does not require an Azure AD premium subscription. However, some dependencies, such as [MDM automatic enrollment](/mem/intune/enrollment/quickstart-setup-auto-enrollment) and [Conditional Access](/azure/active-directory/conditional-access/overview) do.
Windows Hello for Business does not require a Microsoft Entra ID P1 or P2 subscription. However, some dependencies, such as [MDM automatic enrollment](/mem/intune/enrollment/quickstart-setup-auto-enrollment) and [Conditional Access](/azure/active-directory/conditional-access/overview) do.
If box **1a** on your planning worksheet reads **on-premises**, write **No** in box **6c** on your planning worksheet.
If box **1a** on your planning worksheet reads **hybrid** and box **1b** reads **key trust**, write **No** in box **6c** on your planning worksheet. You can deploy Windows Hello for Business using the Azure Active Directory free tier. All Azure Active Directory free accounts can use Azure AD Multi-Factor Authentication through the use of security defaults. Some Azure AD Multi-Factor Authentication features require a license. For more details, see [Features and licenses for Azure AD Multi-Factor Authentication](/azure/active-directory/authentication/concept-mfa-licensing).
If box **1a** on your planning worksheet reads **hybrid** and box **1b** reads **key trust**, write **No** in box **6c** on your planning worksheet. You can deploy Windows Hello for Business using the Microsoft Entra ID Free tier. All Microsoft Entra ID Free accounts can use Microsoft Entra multifactor authentication through the use of security defaults. Some Microsoft Entra multifactor authentication features require a license. For more details, see [Features and licenses for Microsoft Entra multifactor authentication](/azure/active-directory/authentication/concept-mfa-licensing).
If box **5b** on your planning worksheet reads **AD FS RA**, write **Yes** in box **6c** on your planning worksheet. Enrolling a certificate using the AD FS registration authority requires devices to authenticate to the AD FS server, which requires device write-back, an Azure AD Premium feature.
If box **5b** on your planning worksheet reads **AD FS RA**, write **Yes** in box **6c** on your planning worksheet. Enrolling a certificate using the AD FS registration authority requires devices to authenticate to the AD FS server, which requires device write-back, a Microsoft Entra ID P1 or P2 feature.
Modern managed devices do not require an Azure AD premium subscription. By forgoing the subscription, your users must manually enroll devices in the modern management software, such as Intune or a supported third-party MDM.
Modern managed devices do not require a Microsoft Entra ID P1 or P2 subscription. By forgoing the subscription, your users must manually enroll devices in the modern management software, such as Intune or a supported third-party MDM.
If boxes **2a** or **2b** read **modern management** and you want devices to automatically enroll in your modern management software, write **Yes** in box **6c** on your planning worksheet. Otherwise, write **No** in box **6c**.
## Congratulations, You're Done
Your Windows Hello for Business planning worksheet should be complete. This guide provided understanding of the components used in the Windows Hello for Business infrastructure and rationalization of why they are used. The worksheet gives you an overview of the requirements needed to continue the next phase of the deployment. With this worksheet, you'll be able to identify key elements of your Windows Hello for Business deployment.
Your Windows Hello for Business planning worksheet should be complete. This guide provided understanding of the components used in the Windows Hello for Business infrastructure and rationalization of why they're used. The worksheet gives you an overview of the requirements needed to continue the next phase of the deployment. With this worksheet, you'll be able to identify key elements of your Windows Hello for Business deployment.

3
windows/security/identity-protection/hello-for-business/hello-prepare-people-to-use.md
View File

@ -10,7 +10,7 @@ When you set a policy to require Windows Hello for Business in the workplace, yo
After enrollment in Hello, users should use their gesture (such as a PIN or fingerprint) for access to corporate resources. Their gesture is only valid on the enrolled device.
Although the organization may require users to change their Active Directory or Azure Active Directory (AD) account password at regular intervals, changes to their passwords have no effect on Hello.
Although the organization may require users to change their Active Directory or Microsoft Entra account password at regular intervals, changes to their passwords have no effect on Hello.
People who are currently using virtual or physical smart cards for authentication can use their virtual smart card to verify their identity when they set up Hello.
@ -52,4 +52,3 @@ If your policy allows it, people can use biometrics (fingerprint, iris, and faci
- [Windows Hello errors during PIN creation](hello-errors-during-pin-creation.md)
- [Event ID 300 - Windows Hello successfully created](/windows/security/identity-protection/hello-for-business/hello-faq)
- [Windows Hello biometrics in the enterprise](hello-biometrics-in-enterprise.md)

2
windows/security/identity-protection/hello-for-business/includes/hello-deployment-cloud.md
View File

@ -3,4 +3,4 @@ ms.date: 12/08/2022
ms.topic: include
---
[cloud :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#cloud-deployment "For organizations using Azure AD-only identities. Device management is usually done via Intune/MDM")
[cloud :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#cloud-deployment "For organizations using Microsoft Entra-only identities. Device management is usually done via Intune/MDM")

2
windows/security/identity-protection/hello-for-business/includes/hello-deployment-hybrid.md
View File

@ -3,4 +3,4 @@ ms.date: 12/08/2022
ms.topic: include
---
[hybrid :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#hybrid-deployment "For organizations using Active Directory identities synchronized to Azure AD. Device management is usually done via Group Policy or Intune/MDM")
[hybrid :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#hybrid-deployment "For organizations using Active Directory identities synchronized to Microsoft Entra ID. Device management is usually done via Group Policy or Intune/MDM")

2
windows/security/identity-protection/hello-for-business/includes/hello-deployment-onpremises.md
View File

@ -3,4 +3,4 @@ ms.date: 12/08/2022
ms.topic: include
---
[on-premises :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#on-premises-deployment "For organizations using Active Directory identities, not synchronized to Azure AD. Device management is usually done via Group Policy")
[on-premises :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#on-premises-deployment "For organizations using Active Directory identities, not synchronized to Microsoft Entra ID. Device management is usually done via Group Policy")

2
windows/security/identity-protection/hello-for-business/includes/hello-join-aad.md
View File

@ -3,4 +3,4 @@ ms.date: 12/08/2022
ms.topic: include
---
[Azure AD join :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#azure-active-directory-join "Devices that are Azure AD joined do not have any dependencies on Active Directory. Only local users accounts and Azure AD users can sign in to these devices")
[Microsoft Entra join :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#azure-active-directory-join "Devices that are Microsoft Entra joined do not have any dependencies on Active Directory. Only local users accounts and Microsoft Entra users can sign in to these devices")

2
windows/security/identity-protection/hello-for-business/includes/hello-join-hybrid.md
View File

@ -3,4 +3,4 @@ ms.date: 12/08/2022
ms.topic: include
---
[hybrid Azure AD join :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#hybrid-azure-ad-join "Devices that are hybrid Azure AD joined don't have any dependencies on Azure AD. Only local users accounts and Active Directory users can sign in to these devices. Active Directory users that are synchronized to Azure AD will have single-sign on to both Active Directory and Azure AD-protected resources")
[Microsoft Entra hybrid join :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#hybrid-azure-ad-join "Devices that are Microsoft Entra hybrid joined don't have any dependencies on Microsoft Entra ID. Only local users accounts and Active Directory users can sign in to these devices. Active Directory users that are synchronized to Microsoft Entra ID will have single-sign on to both Active Directory and Microsoft Entra protected resources")

8
windows/security/identity-protection/hello-for-business/index.md
View File

@ -25,7 +25,7 @@ Windows Hello lets users authenticate to:
- A Microsoft account.
- An Active Directory account.
- A Microsoft Azure Active Directory (Azure AD) account.
- A Microsoft Entra account.
- Identity Provider Services or Relying Party Services that support [Fast ID Online (FIDO) v2.0](https://fidoalliance.org/) authentication.
After an initial two-step verification of the user during enrollment, Windows Hello is set up on the user's device and Windows asks the user to set a gesture, which can be a biometric, such as a fingerprint, or a PIN. The user provides the gesture to verify their identity. Windows then uses Windows Hello to authenticate users.
@ -71,7 +71,7 @@ Windows Hello helps protect user identities and user credentials. Because the us
- Windows Hello credentials are based on certificate or asymmetrical key pair. Windows Hello credentials can be bound to the device, and the token that is obtained using the credential is also bound to the device.
- An identity provider validates the user identity and maps the Windows Hello public key to a user account during the registration step. Example providers are Active Directory, Azure AD, or a Microsoft account.
- An identity provider validates the user identity and maps the Windows Hello public key to a user account during the registration step. Example providers are Active Directory, Microsoft Entra ID, or a Microsoft account.
- Keys can be generated in hardware (TPM 1.2 or 2.0 for enterprises, and TPM 2.0 for consumers) or software, based on the policy. To guarantee that keys are generated in hardware, you must set policy.
@ -81,7 +81,7 @@ Windows Hello helps protect user identities and user credentials. Because the us
- PIN entry and biometric gesture both trigger Windows 10 and later to use the private key to cryptographically sign data that is sent to the identity provider. The identity provider verifies the user's identity and authenticates the user.
- Personal (Microsoft account) and corporate (Active Directory or Azure AD) accounts use a single container for keys. All keys are separated by identity providers' domains to help ensure user privacy.
- Personal (Microsoft account) and corporate (Active Directory or Microsoft Entra ID) accounts use a single container for keys. All keys are separated by identity providers' domains to help ensure user privacy.
- Certificate private keys can be protected by the Windows Hello container and the Windows Hello gesture.
@ -89,7 +89,7 @@ For details, see [How Windows Hello for Business works](hello-how-it-works.md).
## Comparing key-based and certificate-based authentication
Windows Hello for Business can use either keys (hardware or software) or certificates in hardware or software. Enterprises that have a public key infrastructure (PKI) for issuing and managing end user certificates can continue to use PKI in combination with Windows Hello for Business. Enterprises that don't use PKI or want to reduce the effort associated with managing user certificates can rely on key-based credentials for Windows Hello. This functionality still uses certificates on the domain controllers as a root of trust. Starting with Windows 10 version 21H2, there's a feature called cloud Kerberos trust for hybrid deployments, which uses Azure AD as the root of trust. cloud Kerberos trust uses key-based credentials for Windows Hello but doesn't require certificates on the domain controller.
Windows Hello for Business can use either keys (hardware or software) or certificates in hardware or software. Enterprises that have a public key infrastructure (PKI) for issuing and managing end user certificates can continue to use PKI in combination with Windows Hello for Business. Enterprises that don't use PKI or want to reduce the effort associated with managing user certificates can rely on key-based credentials for Windows Hello. This functionality still uses certificates on the domain controllers as a root of trust. Starting with Windows 10 version 21H2, there's a feature called cloud Kerberos trust for hybrid deployments, which uses Microsoft Entra ID as the root of trust. cloud Kerberos trust uses key-based credentials for Windows Hello but doesn't require certificates on the domain controller.
Windows Hello for Business with a key, including cloud Kerberos trust, doesn't support supplied credentials for RDP. RDP doesn't support authentication with a key or a self signed certificate. RDP with Windows Hello for Business is supported with certificate based deployments as a supplied credential. Windows Hello for Business with a key credential can be used with [Remote Credential Guard](../remote-credential-guard.md).

8
windows/security/identity-protection/hello-for-business/passwordless-strategy.md
View File

@ -17,7 +17,7 @@ Over the past few years, Microsoft has continued their commitment to enabling a
### 1. Develop a password replacement offering
Before you move away from passwords, you need something to replace them. With Windows 10 and Windows 11, Microsoft introduced Windows Hello for Business, a strong, hardware protected two-factor credential that enables single sign-on to Azure Active Directory and Active Directory.
Before you move away from passwords, you need something to replace them. With Windows 10 and Windows 11, Microsoft introduced Windows Hello for Business, a strong, hardware protected two-factor credential that enables single sign-on to Microsoft Entra ID and Active Directory.
Deploying Windows Hello for Business is the first step towards a password-less environment. Windows Hello for Business coexists nicely with existing password-based security. Users are likely to use Windows Hello for Business because of its convenience, especially when combined with biometrics. However, some workflows and applications may still need passwords. This early stage is about implementing an alternative and getting users used to it.
@ -147,7 +147,7 @@ After successfully moving a work persona to password freedom, you can prioritize
### Password-less replacement offering (step 1)
The first step to password freedom is providing an alternative to passwords. Windows 10 and Windows 11 provide an affordable and easy in-box alternative to passwords, Windows Hello for Business, a strong, two-factor authentication to Azure Active Directory and Active Directory.
The first step to password freedom is providing an alternative to passwords. Windows 10 and Windows 11 provide an affordable and easy in-box alternative to passwords, Windows Hello for Business, a strong, two-factor authentication to Microsoft Entra ID and Active Directory.
#### Identify test users that represent the targeted work persona
@ -160,7 +160,7 @@ Next, you'll want to plan your Windows Hello for Business deployment. Your test
With the Windows Hello for Business infrastructure in place, you can limit Windows Hello for Business enrollments to the targeted work personas. The great news is that you'll only need to deploy the infrastructure once. When other targeted work personas need to start using Windows Hello for Business, add them to a group. You'll use the first work persona to validate your Windows Hello for Business deployment.
> [!NOTE]
> There are many different ways to connect a device to Azure. Deployments may vary based on how the device is joined to Azure Active Directory. Review your planning guide and deployment guide to ensure additional infrastructure is not needed for an additional Azure joined devices.
> There are many different ways to connect a device to Azure. Deployments may vary based on how the device is joined to Microsoft Entra ID. Review your planning guide and deployment guide to ensure additional infrastructure is not needed for an additional Azure joined devices.
#### Validate that passwords and Windows Hello for Business work
@ -206,7 +206,7 @@ Start mitigating password usages based on the workflows of your targeted persona
Mitigating password usage with applications is one of the more challenging obstacles in the password-less journey. If your organization develops the application, then you are in better shape the common-off-the-shelf software (COTS).
The ideal mitigation for applications that prompt the user for a password is to enable those applications to use an existing authenticated identity, such as Azure Active Directory or Active Directory. Work with the applications vendors to have them add support for Azure identities. For on-premises applications, have the application use Windows integrated authentication. The goal for your users should be a seamless single sign-on experience where each user authenticates once when they sign-in to Windows. Use this same strategy for applications that store their own identities in their own databases.
The ideal mitigation for applications that prompt the user for a password is to enable those applications to use an existing authenticated identity, such as Microsoft Entra ID or Active Directory. Work with the applications vendors to have them add support for Azure identities. For on-premises applications, have the application use Windows integrated authentication. The goal for your users should be a seamless single sign-on experience where each user authenticates once when they sign-in to Windows. Use this same strategy for applications that store their own identities in their own databases.
Each scenario on your list should now have a problem statement, an investigation as to why the password was used, and a mitigation plan on how to make the password usage go away. Armed with this data, one-by-one, close the gaps on user-visible passwords. Change policies and procedures as needed, make infrastructure changes where possible. Convert in-house applications to use federated identities or Windows integrated authentication. Work with third-party software vendors to update their software to support federated identities or Windows integrated authentication.

6
windows/security/identity-protection/hello-for-business/toc.yml
View File

@ -41,7 +41,7 @@ items:
- name: Configure and provision Windows Hello for Business
href: hello-hybrid-key-trust-provision.md
displayName: key trust
- name: Configure SSO for Azure AD joined devices
- name: Configure SSO for Microsoft Entra joined devices
href: hello-hybrid-aadj-sso.md
displayName: key trust
- name: Certificate trust deployment
@ -58,10 +58,10 @@ items:
- name: Configure and provision Windows Hello for Business
href: hello-hybrid-cert-whfb-provision.md
displayName: certificate trust
- name: Configure SSO for Azure AD joined devices
- name: Configure SSO for Microsoft Entra joined devices
href: hello-hybrid-aadj-sso.md
displayName: certificate trust
- name: Deploy certificates to Azure AD joined devices
- name: Deploy certificates to Microsoft Entra joined devices
href: hello-hybrid-aadj-sso-cert.md
displayName: certificate trust
- name: On-premises deployments

4
windows/security/identity-protection/passwordless-experience/index.md
View File

@ -24,7 +24,7 @@ With Windows passwordless experience, users who sign in with Windows Hello or a
>[!NOTE]
>Users can reset their password using <kbd>CTRL</kbd>+<kbd>ALT</kbd>+<kbd>DEL</kbd> > **Manage your account**
Windows passwordless experience doesn't affect the initial sign-in experience and local accounts. It only applies to subsequent sign-ins for Microsoft Entra ID accounts. It also doesn't prevent a user from signing in with a password when using the *Other user* option in the lock screen.\
Windows passwordless experience doesn't affect the initial sign-in experience and local accounts. It only applies to subsequent sign-ins for Microsoft Entra accounts. It also doesn't prevent a user from signing in with a password when using the *Other user* option in the lock screen.\
The password credential provider is hidden only for the last signed in user who signed in Windows Hello or a FIDO2 security key. Windows passwordless experience isn't about preventing users from using passwords, rather to guide and educate them to not use passwords.
This article explains how to enable Windows passwordless experience and describes the user experiences.
@ -122,7 +122,7 @@ Here's a list of recommendations to consider before enabling Windows passwordles
- If Windows Hello for Business is enabled, configure the [PIN reset](../hello-for-business/hello-feature-pin-reset.md) feature to allow users to reset their PIN from the lock screen. The PIN reset experience is improved starting in Windows 11, version 22H2 with [KB5030310][KB-1]
- Don't configure the security policy *Interactive logon: Don't display last signed-in*, as it prevents Windows passwordless experience from working
- Don't disable the password credential provider using the *Exclude credential providers* policy. The key differences between the two policies are:
- The Exclude credential providers policy disables passwords for *all accounts*, including local accounts. Windows passwordless experience only applies to Microsoft Entra ID accounts that sign in with Windows Hello or a FIDO2 security key. It also excludes *Other User* from the policy, so users have a backup sign in option
- The Exclude credential providers policy disables passwords for *all accounts*, including local accounts. Windows passwordless experience only applies to Microsoft Entra accounts that sign in with Windows Hello or a FIDO2 security key. It also excludes *Other User* from the policy, so users have a backup sign in option
- Exclude credential providers policy prevents the use of passwords for RDP and *Run as* authentication scenarios
- To facilitate helpdesk support operations, consider enabling the local administrator account or create a separate one, randomizing its password using the [Windows Local Administrator Password Solution (LAPS)][SERV-1]

4
windows/security/identity-protection/remote-credential-guard.md
View File

@ -211,8 +211,8 @@ For more information about LAPS, see [What is Windows LAPS][LEARN-1].
Here are some additional considerations for Remote Credential Guard:
- Remote Credential Guard doesn't support compound authentication. For example, if you're trying to access a file server from a remote host that requires a device claim, access will be denied
- Remote Credential Guard can be used only when connecting to a device that is joined to an Active Directory domain. It can't be used when connecting to remote devices joined to Azure Active Directory (Azure AD)
- Remote Credential Guard can be used from an Azure AD joined client to connect to an Active Directory joined remote host, as long as the client can authenticate using Kerberos
- Remote Credential Guard can be used only when connecting to a device that is joined to an Active Directory domain. It can't be used when connecting to remote devices joined to Microsoft Entra ID
- Remote Credential Guard can be used from a Microsoft Entra joined client to connect to an Active Directory joined remote host, as long as the client can authenticate using Kerberos
- Remote Credential Guard only works with the RDP protocol
- No credentials are sent to the target device, but the target device still acquires Kerberos Service Tickets on its own
- The server and client must authenticate using Kerberos

4
windows/security/identity-protection/web-sign-in/index.md
View File

@ -128,7 +128,7 @@ For more information, see [Use a Temporary Access Pass][AAD-3].
:::row:::
:::column span="3":::
If the Microsoft Entra ID tenant is federated with a third-party SAML-P identity provider (IdP), federated users can sign using the Web sign-in credential provider.
If the Microsoft Entra tenant is federated with a third-party SAML-P identity provider (IdP), federated users can sign using the Web sign-in credential provider.
:::column-end:::
:::column span="1":::
:::image type="content" source="images/web-sign-in-federated-auth.png" border="false" lightbox="images/web-sign-in-federated-auth.gif" alt-text="Animation of the sign in experience with a federated user.":::
@ -138,7 +138,7 @@ For more information, see [Use a Temporary Access Pass][AAD-3].
> [!TIP]
> To improve the user experience for federated identities:
>
> - Configure the *preferred Azure AD tenant name* feature, which allows users to select the domain name during the sign-in process. The users are then automatically redirected to the identity provider sign-in page.
> - Configure the *preferred Microsoft Entra tenant name* feature, which allows users to select the domain name during the sign-in process. The users are then automatically redirected to the identity provider sign-in page.
> - Enable Windows Hello for Business. Once the user signs in, the user can enroll in Windows Hello for Business and then use it to sign in to the device
For more information about preferred tenant name, see [Authentication CSP - PreferredAadTenantDomainName][WIN-1].

2
windows/security/includes/sections/cloud-services.md
View File

@ -9,7 +9,7 @@ ms.topic: include
| Feature name | Description |
|:---|:---|
| **[Active Directory domain join, Microsoft Entra join, and Microsoft Entra Hybrid join with single sign-on (SSO)](/azure/active-directory/devices/concept-directory-join)** | Microsoft Entra ID is a comprehensive cloud-based identity management solution that helps enable secure access to applications, networks, and other resources and guard against threats. |
| **[Active Directory domain join, Microsoft Entra join, and Microsoft Entra hybrid join with single sign-on (SSO)](/azure/active-directory/devices/concept-directory-join)** | Microsoft Entra ID is a comprehensive cloud-based identity management solution that helps enable secure access to applications, networks, and other resources and guard against threats. |
| **[Security baselines](/windows/security/operating-system-security/device-management/windows-security-configuration-framework/windows-security-baselines)** | Windows 11 supports modern device management so that IT pros can manage company security policies and business applications without compromising user privacy on corporate or employee-owned devices. With MDM solutions, IT can manage Windows 11 using industry-standard protocols. To simplify setup for users, management features are built directly into Windows, eliminating the need for a separate MDM client. <br><br>Windows 11 can be configured with Microsoft's MDM security baseline backed by ADMX policies, which functions like the Microsoft GP-based security baseline. The security baseline enables IT administrators to easily address security concerns and compliance needs for modern cloud-managed devices. |
| **[Remote wipe](/windows/client-management/mdm/remotewipe-csp)** | When a device is lost or stolen, IT administrators may want to remotely wipe data stored on the device. A helpdesk agent may also want to reset devices to fix issues encountered by remote workers. <br><br>With the Remote Wipe configuration service provider (CSP), an MDM solution can remotely initiate any of the following operations on a Windows device: reset the device and remove user accounts and data, reset the device and clean the drive, reset the device but persist user accounts and data. |
| **[Modern device management through (MDM)](/windows/client-management/mdm-overview)** | Windows 11 supports modern device management through mobile device management (MDM) protocols.<br><br>IT pros can manage company security policies and business applications without compromising user privacy on corporate or employee-owned devices. With MDM solutions, IT can manage Windows 11 using industry-standard protocols.<br><br>To simplify setup for users, management features are built directly into Windows, eliminating the need for a separate MDM client. |

2
windows/security/includes/sections/identity.md
View File

@ -23,7 +23,7 @@ ms.topic: include
|:---|:---|
| **[Web sign-in](/windows/security/identity-protection/web-sign-in)** | Web sign-in is a credential provider initially introduced in Windows 10 with support for Temporary Access Pass (TAP) only. With the release of Windows 11, the supported scenarios and capabilities of Web sign-in have been expanded. For example, users can sign-in to Windows using the Microsoft Authenticator app or with a federated identity. |
| **[Federated sign-in](/education/windows/federated-sign-in)** | Windows 11 Education editions support federated sign-in with third-party identity providers. Federated sign-in enables secure sign in through methods like QR codes or pictures. |
| **[Windows LAPS](/windows-server/identity/laps/laps-overview)** | Windows Local Administrator Password Solution (Windows LAPS) is a Windows feature that automatically manages and backs up the password of a local administrator account on your Microsoft Entra ID-joined or Windows Server Active Directory-joined devices. You also can use Windows LAPS to automatically manage and back up the Directory Services Restore Mode (DSRM) account password on your Windows Server Active Directory domain controllers. An authorized administrator can retrieve the DSRM password and use it. |
| **[Windows LAPS](/windows-server/identity/laps/laps-overview)** | Windows Local Administrator Password Solution (Windows LAPS) is a Windows feature that automatically manages and backs up the password of a local administrator account on your Microsoft Entra joined or Windows Server Active Directory-joined devices. You also can use Windows LAPS to automatically manage and back up the Directory Services Restore Mode (DSRM) account password on your Windows Server Active Directory domain controllers. An authorized administrator can retrieve the DSRM password and use it. |
| **[Account Lockout Policy](/windows/security/threat-protection/security-policy-settings/account-lockout-policy)** | Account Lockout Policy settings control the response threshold for failed logon attempts and the actions to be taken after the threshold is reached. |
| **[Enhanced phishing protection with SmartScreen](/windows/security/operating-system-security/virus-and-threat-protection/microsoft-defender-smartscreen/enhanced-phishing-protection)** | Users who are still using passwords can benefit from powerful credential protection. Microsoft Defender SmartScreen includes enhanced phishing protection to automatically detect when a user enters their Microsoft password into any app or website. Windows then identifies if the app or site is securely authenticating to Microsoft and warns if the credentials are at risk. Since users are alerted at the moment of potential credential theft, they can take preemptive action before their password is used against them or their organization. |
| **[Access Control (ACL/SACL)](/windows/security/identity-protection/access-control/access-control)** | Access control in Windows ensures that shared resources are available to users and groups other than the resource's owner and are protected from unauthorized use. IT administrators can manage users', groups', and computers' access to objects and assets on a network or computer. After a user is authenticated, the Windows operating system implements the second phase of protecting resources by using built-in authorization and access control technologies to determine if an authenticated user has the correct permissions.<br><br>Access Control Lists (ACL) describe the permissions for a specific object and can also contain System Access Control Lists (SACL). SACLs provide a way to audit specific system level events, such as when a user attempt to access file system objects. These events are essential for tracking activity for objects that are sensitive or valuable and require extra monitoring. Being able to audit when a resource attempts to read or write part of the operating system is critical to understanding a potential attack. |

10
windows/security/information-protection/windows-information-protection/create-and-verify-an-efs-dra-certificate.md
View File

@ -122,18 +122,18 @@ It's possible that you might revoke data from an unenrolled device only to later
## Auto-recovery of encryption keys
Starting with Windows 10, version 1709, WIP includes a data recovery feature that lets your employees auto-recover access to work files if the encryption key is lost and the files are no longer accessible. This typically happens if an employee reimages the operating system partition, removing the WIP key info, or if a device is reported as lost and you mistakenly target the wrong device for unenrollment.
To help make sure employees can always access files, WIP creates an auto-recovery key that's backed up to their Azure Active Directory (Azure AD) identity.
To help make sure employees can always access files, WIP creates an auto-recovery key that's backed up to their Microsoft Entra identity.
The employee experience is based on signing in with an Azure AD work account. The employee can either:
The employee experience is based on signing in with a Microsoft Entra ID work account. The employee can either:
- Add a work account through the **Windows Settings > Accounts > Access work or school > Connect** menu.
-OR-
- Open **Windows Settings > Accounts > Access work or school > Connect** and choose the **Join this device to Azure Active Directory** link, under **Alternate actions**.
- Open **Windows Settings > Accounts > Access work or school > Connect** and choose the **Join this device to Microsoft Entra ID** link, under **Alternate actions**.
>[!Note]
>To perform an Azure AD Domain Join from the Settings page, the employee must have administrator privileges to the device.
>To perform a Microsoft Entra Domain Join from the Settings page, the employee must have administrator privileges to the device.
After signing in, the necessary WIP key info is automatically downloaded and employees are able to access the files again.
@ -147,7 +147,7 @@ After signing in, the necessary WIP key info is automatically downloaded and emp
The **Access work or school settings** page appears.
3. Sign-in to Azure AD as the employee and verify that the files now open
3. Sign-in to Microsoft Entra ID as the employee and verify that the files now open
## Related topics

2
windows/security/information-protection/windows-information-protection/create-vpn-and-wip-policy-using-intune-azure.md
View File

@ -52,7 +52,7 @@ After you've created your VPN policy, you'll need to deploy it to the same group
1. On the **App policy** blade, select your newly created policy, select **User groups** from the menu that appears, and then select **Add user group**.
A list of user groups, made up of all of the security groups in your Azure Active Directory, appear in the **Add user group** blade.
A list of user groups, made up of all of the security groups in your Microsoft Entra ID, appear in the **Add user group** blade.
2. Choose the group you want your policy to apply to, and then select **Select** to deploy the policy.

12
windows/security/information-protection/windows-information-protection/create-wip-policy-using-intune-azure.md
View File

@ -27,23 +27,23 @@ You can create an app protection policy in Intune either with device enrollment
- MAM has more **Access** settings for Windows Hello for Business.
- MAM can [selectively wipe company data](/intune/apps-selective-wipe) from a user's personal device.
- MAM requires an [Azure Active Directory (Azure AD) Premium license](/azure/active-directory/fundamentals/active-directory-whatis#what-are-the-azure-ad-licenses).
- An Azure AD Premium license is also required for WIP auto-recovery, where a device can re-enroll and regain access to protected data. WIP auto-recovery depends on Azure AD registration to back up the encryption keys, which requires device auto-enrollment with MDM.
- MAM requires an [Microsoft Entra ID P1 or P2 license](/azure/active-directory/fundamentals/active-directory-whatis#what-are-the-azure-ad-licenses).
- A Microsoft Entra ID P1 or P2 license is also required for WIP auto-recovery, where a device can re-enroll and regain access to protected data. WIP auto-recovery depends on Microsoft Entra registration to back up the encryption keys, which requires device auto-enrollment with MDM.
- MAM supports only one user per device.
- MAM can only manage [enlightened apps](enlightened-microsoft-apps-and-wip.md).
- Only MDM can use [BitLocker CSP](/windows/client-management/mdm/bitlocker-csp) policies.
- If the same user and device are targeted for both MDM and MAM, the MDM policy will be applied to devices joined to Azure AD. For personal devices that are workplace-joined (that is, added by using **Settings** > **Email & accounts** > **Add a work or school account**), the MAM-only policy will be preferred but it's possible to upgrade the device management to MDM in **Settings**. Windows Home edition only supports WIP for MAM-only; upgrading to MDM policy on Home edition will revoke WIP-protected data access.
- If the same user and device are targeted for both MDM and MAM, the MDM policy will be applied to devices joined to Microsoft Entra ID. For personal devices that are workplace-joined (that is, added by using **Settings** > **Email & accounts** > **Add a work or school account**), the MAM-only policy will be preferred but it's possible to upgrade the device management to MDM in **Settings**. Windows Home edition only supports WIP for MAM-only; upgrading to MDM policy on Home edition will revoke WIP-protected data access.
## Prerequisites
Before you can create a WIP policy using Intune, you need to configure an MDM or MAM provider in Azure Active Directory (Azure AD). MAM requires an [Azure Active Directory (Azure AD) Premium license](/azure/active-directory/fundamentals/active-directory-whatis#what-are-the-azure-ad-licenses). An Azure AD Premium license is also required for WIP auto-recovery, where a device can re-enroll and regain access to protected data. WIP auto-recovery relies on Azure AD registration to back up the encryption keys, which requires device auto-enrollment with MDM.
Before you can create a WIP policy using Intune, you need to configure an MDM or MAM provider in Microsoft Entra ID. MAM requires an [Microsoft Entra ID P1 or P2 license](/azure/active-directory/fundamentals/active-directory-whatis#what-are-the-azure-ad-licenses). A Microsoft Entra ID P1 or P2 license is also required for WIP auto-recovery, where a device can re-enroll and regain access to protected data. WIP auto-recovery relies on Microsoft Entra registration to back up the encryption keys, which requires device auto-enrollment with MDM.
## Configure the MDM or MAM provider
1. Sign in to the Azure portal.
2. Select **Azure Active Directory** > **Mobility (MDM and MAM)** > **Microsoft Intune**.
2. Select **Microsoft Entra ID** > **Mobility (MDM and MAM)** > **Microsoft Intune**.
3. Select **Restore Default URLs** or enter the settings for MDM or MAM user scope and select **Save**:
@ -431,7 +431,7 @@ For example:
URL <,proxy>|URL <,proxy>|/*AppCompat*/
```
When you use this string, we recommend that you also turn on [Azure Active Directory Conditional Access](/azure/active-directory/active-directory-conditional-access), using the **Domain joined or marked as compliant** option, which blocks apps from accessing any enterprise cloud resources that are protected by conditional access.
When you use this string, we recommend that you also turn on [Microsoft Entra Conditional Access](/azure/active-directory/active-directory-conditional-access), using the **Domain joined or marked as compliant** option, which blocks apps from accessing any enterprise cloud resources that are protected by conditional access.
Value format with proxy:

4
windows/security/introduction.md
View File

@ -25,7 +25,7 @@ A Zero Trust security model gives the right people the right access at the right
1. When verified, give people and devices access to only necessary resources for the necessary amount of time
1. Use continuous analytics to drive threat detection and improve defenses
For Windows 11, the Zero Trust principle of *verify explicitly* applies to risks introduced by both devices and people. Windows 11 provides *chip-to-cloud security*, enabling IT administrators to implement strong authorization and authentication processes with features like [Windows Hello for Business](identity-protection/hello-for-business/index.md). IT administrators also gain attestation and measurements for determining if a device meets requirements and can be trusted. Windows 11 works out-of-the-box with Microsoft Intune and Azure Active Directory, which enables timely and seamless access decisions. Furthermore, IT administrators can easily customize Windows to meet specific user and policy requirements for access, privacy, compliance, and more.
For Windows 11, the Zero Trust principle of *verify explicitly* applies to risks introduced by both devices and people. Windows 11 provides *chip-to-cloud security*, enabling IT administrators to implement strong authorization and authentication processes with features like [Windows Hello for Business](identity-protection/hello-for-business/index.md). IT administrators also gain attestation and measurements for determining if a device meets requirements and can be trusted. Windows 11 works out-of-the-box with Microsoft Intune and Microsoft Entra ID, which enables timely and seamless access decisions. Furthermore, IT administrators can easily customize Windows to meet specific user and policy requirements for access, privacy, compliance, and more.
### Security, by default
@ -49,7 +49,7 @@ Passwords have been an important part of digital security for a long time, and t
### Connecting to cloud services
Microsoft offers comprehensive cloud services for identity, storage, and access management in addition to the tools needed to attest that Windows devices connecting to your network are trustworthy. You can also enforce compliance and conditional access with a modern device management (MDM) service such as Microsoft Intune, which works with Azure Active Directory and Microsoft Azure Attestation to control access to applications and data through the cloud.
Microsoft offers comprehensive cloud services for identity, storage, and access management in addition to the tools needed to attest that Windows devices connecting to your network are trustworthy. You can also enforce compliance and conditional access with a modern device management (MDM) service such as Microsoft Intune, which works with Microsoft Entra ID and Microsoft Azure Attestation to control access to applications and data through the cloud.
## Next steps

4
windows/security/operating-system-security/data-protection/bitlocker/bitlocker-basic-deployment.md
View File

@ -59,7 +59,7 @@ For the operating system volume the **BitLocker Drive Encryption Wizard** presen
The recovery key can be stored using the following methods:
- **Save to your Azure AD account** (if applicable)
- **Save to your Microsoft Entra account** (if applicable)
- **Save to a USB flash drive**
- **Save to a file** - the file needs to be saved to a location that isn't on the computer itself such as a network folder or OneDrive
- **Print the recovery key**
@ -126,7 +126,7 @@ Encrypting data volumes using the BitLocker control panel works in a similar fas
3. The **BitLocker Drive Encryption Wizard** presents options for storage of the recovery key. These options are the same as for operating system volumes:
- **Save to your Azure AD account** (if applicable)
- **Save to your Microsoft Entra account** (if applicable)
- **Save to a USB flash drive**
- **Save to a file** - the file needs to be saved to a location that isn't on the computer itself such as a network folder or OneDrive
- **Print the recovery key**

10
windows/security/operating-system-security/data-protection/bitlocker/bitlocker-deployment-comparison.md
View File

@ -16,7 +16,7 @@ This article depicts the BitLocker deployment comparison chart.
| *Minimum client operating system version* | Windows 11 and Windows 10 | Windows 11, Windows 10, and Windows 8.1 | Windows 7, Windows 8, Windows 8.1, Windows 10, Windows 10 IoT, and Windows 11 |
| *Supported Windows SKUs* | Enterprise, Pro, Education | Enterprise, Pro, Education | Enterprise |
| *Minimum Windows version* | 1909 | None | None |
| *Supported domain-joined status* | Microsoft Azure Active Directory (Azure AD) joined, hybrid Azure AD joined | Active Directory-joined, hybrid Azure AD joined | Active Directory-joined |
| *Supported domain-joined status* | Microsoft Entra joined, Microsoft Entra hybrid joined | Active Directory-joined, Microsoft Entra hybrid joined | Active Directory-joined |
| *Permissions required to manage policies* | Endpoint security manager or custom | Full administrator or custom | Domain Admin or Delegated GPO access |
| *Cloud or on premises* | Cloud | On premises | On premises |
| Server components required? | | ✅ | ✅ |
@ -31,16 +31,16 @@ This article depicts the BitLocker deployment comparison chart.
| *Select cipher strength and algorithms for fixed drives* | ✅ | ✅ | ✅ |
| *Select cipher strength and algorithms for removable drives* | ✅ | ✅ | ✅ |
| *Select cipher strength and algorithms for operating environment drives* | ✅ | ✅ | ✅ |
| *Standard recovery password storage location* | Azure AD or Active Directory | Configuration Manager site database | MBAM database |
| *Store recovery password for operating system and fixed drives to Azure AD or Active Directory* | Yes (Active Directory and Azure AD) | Yes (Active Directory only) | Yes (Active Directory only) |
| *Standard recovery password storage location* | Microsoft Entra ID or Active Directory | Configuration Manager site database | MBAM database |
| *Store recovery password for operating system and fixed drives to Microsoft Entra ID or Active Directory* | Yes (Active Directory and Microsoft Entra ID) | Yes (Active Directory only) | Yes (Active Directory only) |
| *Customize preboot message and recovery link* | ✅ | ✅ | ✅ |
| *Allow/deny key file creation* | ✅ | ✅ | ✅ |
| *Deny Write permission to unprotected drives* | ✅ | ✅ | ✅ |
| *Can be administered outside company network* | ✅ | ✅ | |
| *Support for organization unique IDs* | | ✅ | ✅ |
| *Self-service recovery* | Yes (through Azure AD or Company Portal app) | ✅ | ✅ |
| *Self-service recovery* | Yes (through Microsoft Entra ID or Company Portal app) | ✅ | ✅ |
| *Recovery password rotation for fixed and operating environment drives* | Yes (Windows 10, version 1909 and later) | ✅ | ✅ |
| *Wait to complete encryption until recovery information is backed up to Azure AD* | ✅ | | |
| *Wait to complete encryption until recovery information is backed up to Microsoft Entra ID* | ✅ | | |
| *Wait to complete encryption until recovery information is backed up to Active Directory* | | ✅ | ✅ |
| *Allow or deny Data Recovery Agent* | ✅ | ✅ | ✅ |
| *Unlock a volume using certificate with custom object identifier* | | ✅ | ✅ |

4
windows/security/operating-system-security/data-protection/bitlocker/bitlocker-device-encryption-overview-windows-10.md
View File

@ -67,7 +67,7 @@ Unlike a standard BitLocker implementation, BitLocker Device Encryption is enabl
With this configuration, the recovery password is created automatically when the computer joins the domain, and then the recovery key is backed up to AD DS, the TPM protector is created, and the clear key is removed.
- Similar to signing in with a domain account, the clear key is removed when the user signs in to an Azure AD account on the device. As described in the bullet point above, the recovery password is created automatically when the user authenticates to Azure AD. Then, the recovery key is backed up to Azure AD, the TPM protector is created, and the clear key is removed.
- Similar to signing in with a domain account, the clear key is removed when the user signs in to a Microsoft Entra account on the device. As described in the bullet point above, the recovery password is created automatically when the user authenticates to Microsoft Entra ID. Then, the recovery key is backed up to Microsoft Entra ID, the TPM protector is created, and the clear key is removed.
Microsoft recommends automatically enabling BitLocker Device Encryption on any systems that support it. However, the automatic BitLocker Device Encryption process can be prevented by changing the following registry setting:
@ -160,4 +160,4 @@ Part of the Microsoft Desktop Optimization Pack, Microsoft BitLocker Administrat
Going forward, the functionality of MBAM will be incorporated into Configuration Manager. For more information, see [Plan for BitLocker management](/mem/configmgr/protect/plan-design/bitlocker-management).
Enterprises not using Configuration Manager can use the built-in features of Azure AD and Microsoft Intune for administration and monitoring. For more information, see [Monitor device encryption with Intune](/mem/intune/protect/encryption-monitor).
Enterprises not using Configuration Manager can use the built-in features of Microsoft Entra ID and Microsoft Intune for administration and monitoring. For more information, see [Monitor device encryption with Intune](/mem/intune/protect/encryption-monitor).

16
windows/security/operating-system-security/data-protection/bitlocker/bitlocker-management-for-enterprises.md
View File

@ -17,22 +17,24 @@ Though much Windows [BitLocker documentation](index.md) has been published, cust
Companies that image their own computers using Configuration Manager can use an existing task sequence to [pre-provision BitLocker](/configmgr/osd/understand/task-sequence-steps#BKMK_PreProvisionBitLocker) encryption while in Windows Preinstallation Environment (WinPE) and can then [enable protection](/configmgr/osd/understand/task-sequence-steps#BKMK_EnableBitLocker). These steps during an operating system deployment can help ensure that computers are encrypted from the start, even before users receive them. As part of the imaging process, a company could also decide to use Configuration Manager to pre-set any desired [BitLocker Group Policy](bitlocker-group-policy-settings.md).
Enterprises can use [Microsoft BitLocker Administration and Monitoring (MBAM)](/microsoft-desktop-optimization-pack/mbam-v25/) to manage client computers with BitLocker that are domain-joined on-premises until [mainstream support ends in July 2019](/lifecycle/products/?alpha=Microsoft%20BitLocker%20Administration%20and%20Monitoring%202.5%20Service%20Pack%201%2F) or they can receive extended support until April 2026. Thus, over the next few years, a good strategy for enterprises will be to plan and move to cloud-based management for BitLocker. Refer to the [PowerShell examples](#powershell-examples) to see how to store recovery keys in Azure Active Directory (Azure AD).
Enterprises can use [Microsoft BitLocker Administration and Monitoring (MBAM)](/microsoft-desktop-optimization-pack/mbam-v25/) to manage client computers with BitLocker that are domain-joined on-premises until [mainstream support ends in July 2019](/lifecycle/products/?alpha=Microsoft%20BitLocker%20Administration%20and%20Monitoring%202.5%20Service%20Pack%201%2F) or they can receive extended support until April 2026. Thus, over the next few years, a good strategy for enterprises will be to plan and move to cloud-based management for BitLocker. Refer to the [PowerShell examples](#powershell-examples) to see how to store recovery keys in Microsoft Entra ID.
> [!IMPORTANT]
> Microsoft BitLocker Administration and Monitoring (MBAM) capabilities are offered through Configuration Manager BitLocker Management. See [Plan for BitLocker management](/mem/configmgr/protect/plan-design/bitlocker-management) in the Configuration Manager documentation for additional information.
## Managing devices joined to Azure Active Directory
<a name='managing-devices-joined-to-azure-active-directory'></a>
Devices joined to Azure AD are managed using Mobile Device Management (MDM) policy from an MDM solution such as Microsoft Intune. Prior to Windows 10, version 1809, only local administrators can enable BitLocker via Intune policy. Starting with Windows 10, version 1809, Intune can enable BitLocker for standard users. [BitLocker Device Encryption](bitlocker-device-encryption-overview-windows-10.md#bitlocker-device-encryption) status can be queried from managed machines via the [Policy Configuration Settings Provider (CSP)](/windows/client-management/mdm/policy-configuration-service-provider/), which reports on whether BitLocker Device Encryption is enabled on the device. Compliance with BitLocker Device Encryption policy can be a requirement for [Conditional Access](https://www.microsoft.com/cloud-platform/conditional-access/) to services like Exchange Online and SharePoint Online.
## Managing devices joined to Microsoft Entra ID
Devices joined to Microsoft Entra ID are managed using Mobile Device Management (MDM) policy from an MDM solution such as Microsoft Intune. Prior to Windows 10, version 1809, only local administrators can enable BitLocker via Intune policy. Starting with Windows 10, version 1809, Intune can enable BitLocker for standard users. [BitLocker Device Encryption](bitlocker-device-encryption-overview-windows-10.md#bitlocker-device-encryption) status can be queried from managed machines via the [Policy Configuration Settings Provider (CSP)](/windows/client-management/mdm/policy-configuration-service-provider/), which reports on whether BitLocker Device Encryption is enabled on the device. Compliance with BitLocker Device Encryption policy can be a requirement for [Conditional Access](https://www.microsoft.com/cloud-platform/conditional-access/) to services like Exchange Online and SharePoint Online.
Starting with Windows 10 version 1703, the enablement of BitLocker can be triggered over MDM either by the [Policy CSP](/windows/client-management/mdm/policy-configuration-service-provider/) or the [BitLocker CSP](/windows/client-management/mdm/bitlocker-csp/). The BitLocker CSP adds policy options that go beyond ensuring that encryption has occurred, and is available on computers that run Windows 11, Windows 10, and on Windows phones.
For hardware that is compliant with Modern Standby and HSTI, when using either of these features, [BitLocker Device Encryption](bitlocker-device-encryption-overview-windows-10.md#bitlocker-device-encryption) is automatically turned on whenever the user joins a device to Azure AD. Azure AD provides a portal where recovery keys are also backed up, so users can retrieve their own recovery key for self-service, if necessary. For older devices that aren't yet encrypted, beginning with Windows 10 version 1703, admins can use the [BitLocker CSP](/windows/client-management/mdm/bitlocker-csp/) to trigger encryption and store the recovery key in Azure AD. This process and feature is applicable to Azure Hybrid AD as well.
For hardware that is compliant with Modern Standby and HSTI, when using either of these features, [BitLocker Device Encryption](bitlocker-device-encryption-overview-windows-10.md#bitlocker-device-encryption) is automatically turned on whenever the user joins a device to Microsoft Entra ID. Microsoft Entra ID provides a portal where recovery keys are also backed up, so users can retrieve their own recovery key for self-service, if necessary. For older devices that aren't yet encrypted, beginning with Windows 10 version 1703, admins can use the [BitLocker CSP](/windows/client-management/mdm/bitlocker-csp/) to trigger encryption and store the recovery key in Microsoft Entra ID. This process and feature is applicable to Azure Hybrid AD as well.
## Managing workplace-joined PCs and phones
For Windows PCs and Windows Phones that are enrolled using **Connect to work or school account**, BitLocker Device Encryption is managed over MDM, the same as devices joined to Azure AD.
For Windows PCs and Windows Phones that are enrolled using **Connect to work or school account**, BitLocker Device Encryption is managed over MDM, the same as devices joined to Microsoft Entra ID.
## Managing servers
@ -47,9 +49,9 @@ If a server is being installed manually, such as a stand-alone server, then choo
## PowerShell examples
For Azure AD-joined computers, including virtual machines, the recovery password should be stored in Azure AD.
For Microsoft Entra joined computers, including virtual machines, the recovery password should be stored in Microsoft Entra ID.
**Example**: *Use PowerShell to add a recovery password and back it up to Azure AD before enabling BitLocker*
**Example**: *Use PowerShell to add a recovery password and back it up to Microsoft Entra ID before enabling BitLocker*
```powershell
Add-BitLockerKeyProtector -MountPoint "C:" -RecoveryPasswordProtector

18
windows/security/operating-system-security/data-protection/bitlocker/bitlocker-recovery-guide-plan.md
View File

@ -344,7 +344,7 @@ BitLocker metadata has been enhanced starting in Windows 10, version 1903, to in
![Customized BitLocker recovery screen.](images/bl-password-hint2.png)
> [!IMPORTANT]
> It is not recommend to print recovery keys or saving them to a file. Instead, use Active Directory backup or a cloud-based backup. Cloud-based backup includes Azure Active Directory (Azure AD) and Microsoft account.
> It is not recommend to print recovery keys or saving them to a file. Instead, use Active Directory backup or a cloud-based backup. Cloud-based backup includes Microsoft Entra ID and Microsoft account.
There are rules governing which hint is shown during the recovery (in the order of processing):
@ -356,7 +356,7 @@ There are rules governing which hint is shown during the recovery (in the order
4. Prioritize keys with successful backup over keys that have never been backed up.
5. Prioritize backup hints in the following order for remote backup locations: **Microsoft Account > Azure AD > Active Directory**.
5. Prioritize backup hints in the following order for remote backup locations: **Microsoft Account > Microsoft Entra ID > Active Directory**.
6. If a key has been printed and saved to file, display a combined hint, "Look for a printout or a text file with the key," instead of two separate hints.
@ -371,7 +371,7 @@ There are rules governing which hint is shown during the recovery (in the order
| Custom URL | Yes |
|----------------------|------------|
| Saved to Microsoft Account | Yes |
| Saved to Azure AD | No |
| Saved to Microsoft Entra ID | No |
| Saved to Active Directory | No |
| Printed | No |
| Saved to file | No |
@ -385,7 +385,7 @@ There are rules governing which hint is shown during the recovery (in the order
| Custom URL | Yes |
|----------------------|------------|
| Saved to Microsoft Account | No |
| Saved to Azure AD | No |
| Saved to Microsoft Entra ID | No |
| Saved to Active Directory | Yes |
| Printed | No |
| Saved to file | No |
@ -399,7 +399,7 @@ There are rules governing which hint is shown during the recovery (in the order
| Custom URL | No |
|----------------------|------------|
| Saved to Microsoft Account | Yes |
| Saved to Azure AD | Yes |
| Saved to Microsoft Entra ID | Yes |
| Saved to Active Directory | No |
| Printed | Yes |
| Saved to file | Yes |
@ -413,7 +413,7 @@ There are rules governing which hint is shown during the recovery (in the order
| Custom URL | No |
|----------------------|-----------------|
| Saved to Microsoft Account | No |
| Saved to Azure AD | No |
| Saved to Microsoft Entra ID | No |
| Saved to Active Directory | No |
| Printed | No |
| Saved to file | Yes |
@ -426,7 +426,7 @@ There are rules governing which hint is shown during the recovery (in the order
| Custom URL | No |
|----------------------|-----------------|
| Saved to Microsoft Account | No |
| Saved to Azure AD | No |
| Saved to Microsoft Entra ID | No |
| Saved to Active Directory | No |
| Printed | No |
| Saved to file | No |
@ -442,7 +442,7 @@ There are rules governing which hint is shown during the recovery (in the order
| Custom URL | No |
|----------------------|-----------------|
| Saved to Microsoft Account | Yes |
| Saved to Azure AD | Yes |
| Saved to Microsoft Entra ID | Yes |
| Saved to Active Directory | No |
| Printed | No |
| Saved to file | No |
@ -452,7 +452,7 @@ There are rules governing which hint is shown during the recovery (in the order
| Custom URL | No |
|----------------------|-----------------|
| Saved to Microsoft Account | No |
| Saved to Azure AD | Yes |
| Saved to Microsoft Entra ID | Yes |
| Saved to Active Directory | No |
| Printed | No |
| Saved to file | No |

2
windows/security/operating-system-security/data-protection/bitlocker/faq.yml
View File

@ -473,4 +473,4 @@ sections:
- question: |
Can I use BitLocker with virtual machines (VMs)?
answer: |
Yes. Password protectors and virtual TPMs can be used with BitLocker to protect virtual machines. VMs can be domain joined, Azure AD-joined, or workplace-joined (via **Settings** > **Accounts** > **Access work or school** > **Connect**) to receive policy. Encryption can be enabled either while creating the VM or by using other existing management tools such as the BitLocker CSP, or even by using a startup script or sign-in script delivered by Group Policy. Windows Server 2016 also supports [Shielded VMs and guarded fabric](/windows-server/virtualization/guarded-fabric-shielded-vm/guarded-fabric-and-shielded-vms-top-node) to protect VMs from malicious administrators.
Yes. Password protectors and virtual TPMs can be used with BitLocker to protect virtual machines. VMs can be domain joined, Microsoft Entra joined, or workplace-joined (via **Settings** > **Accounts** > **Access work or school** > **Connect**) to receive policy. Encryption can be enabled either while creating the VM or by using other existing management tools such as the BitLocker CSP, or even by using a startup script or sign-in script delivered by Group Policy. Windows Server 2016 also supports [Shielded VMs and guarded fabric](/windows-server/virtualization/guarded-fabric-shielded-vm/guarded-fabric-and-shielded-vms-top-node) to protect VMs from malicious administrators.

2
windows/security/operating-system-security/data-protection/personal-data-encryption/configure.md
View File

@ -32,7 +32,7 @@ The following table lists the recommended settings to improve PDE's security.
|Kernel-mode crash dumps and live dumps|Kernel-mode crash dumps and live dumps can potentially cause the keys used by PDE to protect content to be exposed. For greatest security, disable kernel-mode crash dumps and live dumps.|
|Windows Error Reporting (WER)/user-mode crash dumps|Disabling Windows Error Reporting prevents user-mode crash dumps. User-mode crash dumps can potentially cause the keys used by PDE to protect content to be exposed. For greatest security, disable user-mode crash dumps.|
|Hibernation|Hibernation files can potentially cause the keys used by Personal Data Encryption (PDE) to protect content to be exposed. For greatest security, disable hibernation.|
|Allow users to select when a password is required when resuming from connected standby |When this policy isn't configured on Azure AD joined devices, users on a Connected Standby device can change the amount of time after the device´s screen turns off before a password is required to wake the device. During the time when the screen turns off but a password isn't required, the keys used by PDE to protect content could potentially be exposed. It's recommended to explicitly disable this policy on Azure AD joined devices.|
|Allow users to select when a password is required when resuming from connected standby |When this policy isn't configured on Microsoft Entra joined devices, users on a Connected Standby device can change the amount of time after the device´s screen turns off before a password is required to wake the device. During the time when the screen turns off but a password isn't required, the keys used by PDE to protect content could potentially be exposed. It's recommended to explicitly disable this policy on Microsoft Entra joined devices.|
## Configure PDE with Microsoft Intune

2
windows/security/operating-system-security/data-protection/personal-data-encryption/index.md
View File

@ -25,7 +25,7 @@ Unlike BitLocker that releases data encryption keys at boot, PDE doesn't release
To use PDE, the following prerequisites must be met:
- Windows 11, version 22H2 and later
- The devices must be [Azure AD joined][AAD-1]. Domain-joined and hybrid Azure AD joined devices aren't supported
- The devices must be [Microsoft Entra joined][AAD-1]. Domain-joined and Microsoft Entra hybrid joined devices aren't supported
- Users must sign in using [Windows Hello for Business](../../../identity-protection/hello-for-business/index.md)
> [!IMPORTANT]

4
windows/security/operating-system-security/network-security/vpn/how-to-use-single-sign-on-sso-over-vpn-and-wi-fi-connections.md
View File

@ -74,8 +74,8 @@ If the credentials are certificate-based, then the elements in the following tab
|------------------|---------------|
| SubjectName | The user's distinguished name (DN) where the domain components of the distinguished name reflect the internal DNS namespace when the SubjectAlternativeName does not have the fully qualified UPN required to find the domain controller. </br>This requirement is relevant in multi-forest environments as it ensures a domain controller can be located. |
| SubjectAlternativeName | The user's fully qualified UPN where a domain name component of the user's UPN matches the organizations internal domain's DNS namespace. </br>This requirement is relevant in multi-forest environments as it ensures a domain controller can be located when the SubjectName does not have the DN required to find the domain controller. |
| Key Storage Provider (KSP) | If the device is joined to Azure AD, a discrete SSO certificate is used. |
| EnhancedKeyUsage | One or more of the following EKUs is required: </br><ul><li>Client Authentication (for the VPN)</li><li>EAP Filtering OID (for Windows Hello for Business)</li><li>SmartCardLogon (for Azure AD-joined devices)</li></ul>If the domain controllers require smart card EKU either:<ul><li>SmartCardLogon</li><li>id-pkinit-KPClientAuth (1.3.6.1.5.2.3.4) </li></ul>Otherwise:</br><ul><li>TLS/SSL Client Authentication (1.3.6.1.5.5.7.3.2)</li></ul> |
| Key Storage Provider (KSP) | If the device is joined to Microsoft Entra ID, a discrete SSO certificate is used. |
| EnhancedKeyUsage | One or more of the following EKUs is required: </br><ul><li>Client Authentication (for the VPN)</li><li>EAP Filtering OID (for Windows Hello for Business)</li><li>SmartCardLogon (for Microsoft Entra joined devices)</li></ul>If the domain controllers require smart card EKU either:<ul><li>SmartCardLogon</li><li>id-pkinit-KPClientAuth (1.3.6.1.5.2.3.4) </li></ul>Otherwise:</br><ul><li>TLS/SSL Client Authentication (1.3.6.1.5.5.7.3.2)</li></ul> |
## NDES server configuration

36
windows/security/operating-system-security/network-security/vpn/vpn-conditional-access.md
View File

@ -1,25 +1,25 @@
---
title: VPN and conditional access
description: Learn how to integrate the VPN client with the Conditional Access platform, and how to create access rules for Azure Active Directory (Azure AD) connected apps.
description: Learn how to integrate the VPN client with the Conditional Access platform, and how to create access rules for Microsoft Entra connected apps.
ms.date: 08/03/2023
ms.topic: conceptual
---
# VPN and conditional access
The VPN client is now able to integrate with the cloud-based Conditional Access Platform to provide a device compliance option for remote clients. Conditional Access is a policy-based evaluation engine that lets you create access rules for any Azure Active Directory (Azure AD) connected application.
The VPN client is now able to integrate with the cloud-based Conditional Access Platform to provide a device compliance option for remote clients. Conditional Access is a policy-based evaluation engine that lets you create access rules for any Microsoft Entra connected application.
>[!NOTE]
>Conditional Access is an Azure AD Premium feature.
>Conditional Access is a Microsoft Entra ID P1 or P2 feature.
Conditional Access Platform components used for Device Compliance include the following cloud-based services:
- [Conditional Access Framework](/archive/blogs/tip_of_the_day/tip-of-the-day-the-conditional-access-framework-and-device-compliance-for-vpn)
- [Azure AD Connect Health](/azure/active-directory/connect-health/active-directory-aadconnect-health)
- [Microsoft Entra Connect Health](/azure/active-directory/connect-health/active-directory-aadconnect-health)
- [Windows Health Attestation Service](../../system-security/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices.md) (optional)
- Azure AD Certificate Authority - It's a requirement that the client certificate used for the cloud-based device compliance solution be issued by an Azure Active Directory-based Certificate Authority (CA). An Azure AD CA is essentially a mini-CA cloud tenant in Azure. The Azure AD CA can't be configured as part of an on-premises Enterprise CA.
- Microsoft Entra Certificate Authority - It's a requirement that the client certificate used for the cloud-based device compliance solution be issued by a Microsoft Entra ID-based Certificate Authority (CA). A Microsoft Entra CA is essentially a mini-CA cloud tenant in Azure. The Microsoft Entra CA can't be configured as part of an on-premises Enterprise CA.
See also [Always On VPN deployment for Windows Server and Windows 10](/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/always-on-vpn-deploy).
- Azure AD-issued short-lived certificates - When a VPN connection attempt is made, the Azure AD Token Broker on the local device communicates with Azure Active Directory, which then checks for health based on compliance rules. If compliant, Azure AD sends back a short-lived certificate that is used to authenticate the VPN. Note that certificate authentication methods such as EAP-TLS can be used. When the client reconnects and determines that the certificate has expired, the client will again check with Azure AD for health validation before a new certificate is issued.
- Microsoft Entra ID-issued short-lived certificates - When a VPN connection attempt is made, the Microsoft Entra Token Broker on the local device communicates with Microsoft Entra ID, which then checks for health based on compliance rules. If compliant, Microsoft Entra ID sends back a short-lived certificate that is used to authenticate the VPN. Note that certificate authentication methods such as EAP-TLS can be used. When the client reconnects and determines that the certificate has expired, the client will again check with Microsoft Entra ID for health validation before a new certificate is issued.
- [Microsoft Intune device compliance policies](/mem/intune/protect/device-compliance-get-started): Cloud-based device compliance uses Microsoft Intune Compliance Policies, which are capable of querying the device state and define compliance rules for the following, among other things.
- Antivirus status
- Auto-update status and update compliance
@ -35,12 +35,12 @@ The following client-side components are also required:
## VPN device compliance
At this time, the Azure AD certificates issued to users don't contain a CRL Distribution Point (CDP) and aren't suitable for Key Distribution Centers (KDCs) to issue Kerberos tokens. For users to gain access to on-premises resources such as files on a network share, client authentication certificates must be deployed to the Windows profiles of the users, and their VPNv2 profiles must contain the &lt;SSO&gt; section.
At this time, the Microsoft Entra certificates issued to users don't contain a CRL Distribution Point (CDP) and aren't suitable for Key Distribution Centers (KDCs) to issue Kerberos tokens. For users to gain access to on-premises resources such as files on a network share, client authentication certificates must be deployed to the Windows profiles of the users, and their VPNv2 profiles must contain the &lt;SSO&gt; section.
Server-side infrastructure requirements to support VPN device compliance include:
- The VPN server should be configured for certificate authentication.
- The VPN server should trust the tenant-specific Azure AD CA.
- The VPN server should trust the tenant-specific Microsoft Entra CA.
- For client access using Kerberos/NTLM, a domain-trusted certificate is deployed to the client device and is configured to be used for single sign-on (SSO).
After the server side is set up, VPN admins can add the policy settings for conditional access to the VPN profile using the VPNv2 DeviceCompliance node.
@ -48,7 +48,7 @@ After the server side is set up, VPN admins can add the policy settings for cond
Two client-side configuration service providers are leveraged for VPN device compliance.
- VPNv2 CSP DeviceCompliance settings:
- **Enabled**: enables the Device Compliance flow from the client. If marked as **true**, the VPN client attempts to communicate with Azure AD to get a certificate to use for authentication. The VPN should be set up to use certificate authentication and the VPN server must trust the server returned by Azure AD.
- **Enabled**: enables the Device Compliance flow from the client. If marked as **true**, the VPN client attempts to communicate with Microsoft Entra ID to get a certificate to use for authentication. The VPN should be set up to use certificate authentication and the VPN server must trust the server returned by Microsoft Entra ID.
- **Sso**: entries under SSO should be used to direct the VPN client to use a certificate other than the VPN authentication certificate when accessing resources that require Kerberos authentication.
- **Sso/Enabled**: if this field is set to **true**, the VPN client looks for a separate certificate for Kerberos authentication.
- **Sso/IssuerHash**: hashes for the VPN client to look for the correct certificate for Kerberos authentication.
@ -71,20 +71,22 @@ The VPN client side connection flow works as follows:
When a VPNv2 Profile is configured with \<DeviceCompliance> \<Enabled>true<\/Enabled> the VPN client uses this connection flow:
1. The VPN client calls into Windows 10's or Windows 11's Azure AD Token Broker, identifying itself as a VPN client.
1. The Azure AD Token Broker authenticates to Azure AD and provides it with information about the device trying to connect. The Azure AD Server checks if the device is in compliance with the policies.
1. If compliant, Azure AD requests a short-lived certificate.
1. Azure AD pushes down a short-lived certificate to the Certificate Store via the Token Broker. The Token Broker then returns control back over to the VPN client for further connection processing.
1. The VPN client uses the Azure AD-issued certificate to authenticate with the VPN server.
1. The VPN client calls into Windows 10's or Windows 11's Microsoft Entra Token Broker, identifying itself as a VPN client.
1. The Microsoft Entra Token Broker authenticates to Microsoft Entra ID and provides it with information about the device trying to connect. The Microsoft Entra Server checks if the device is in compliance with the policies.
1. If compliant, Microsoft Entra ID requests a short-lived certificate.
1. Microsoft Entra ID pushes down a short-lived certificate to the Certificate Store via the Token Broker. The Token Broker then returns control back over to the VPN client for further connection processing.
1. The VPN client uses the Microsoft Entra ID-issued certificate to authenticate with the VPN server.
## Configure conditional access
See [VPN profile options](vpn-profile-options.md) and [VPNv2 CSP](/windows/client-management/mdm/vpnv2-csp) for XML configuration.
## Learn more about Conditional Access and Azure AD Health
<a name='learn-more-about-conditional-access-and-azure-ad-health'></a>
- [Azure Active Directory conditional access](/azure/active-directory/conditional-access/overview)
- [Getting started with Azure Active Directory Conditional Access](/azure/active-directory/authentication/tutorial-enable-azure-mfa)
## Learn more about Conditional Access and Microsoft Entra Health
- [Microsoft Entra Conditional Access](/azure/active-directory/conditional-access/overview)
- [Getting started with Microsoft Entra Conditional Access](/azure/active-directory/authentication/tutorial-enable-azure-mfa)
- [Control the health of Windows devices](../../system-security/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices.md)
- [Tip of the Day: The Conditional Access Framework and Device Compliance for VPN (Part 1)](/archive/blogs/tip_of_the_day/tip-of-the-day-the-conditional-access-framework-and-device-compliance-for-vpn)
- [Tip of the Day: The Conditional Access Framework and Device Compliance for VPN (Part 2)](/archive/blogs/tip_of_the_day/tip-of-the-day-the-conditional-access-framework-and-device-compliance-for-vpn-part-2)

2
windows/security/operating-system-security/network-security/vpn/vpn-guide.md
View File

@ -23,7 +23,7 @@ To create a Windows VPN device configuration profile see: [Windows device settin
| [VPN connection types](vpn-connection-type.md) | Select a VPN client and tunneling protocol |
| [VPN routing decisions](vpn-routing.md) | Choose between split tunnel and force tunnel configuration |
| [VPN authentication options](vpn-authentication.md) | Select a method for Extensible Authentication Protocol (EAP) authentication. |
| [VPN and conditional access](vpn-conditional-access.md) | Use Azure Active Directory policy evaluation to set access policies for VPN connections. |
| [VPN and conditional access](vpn-conditional-access.md) | Use Microsoft Entra policy evaluation to set access policies for VPN connections. |
| [VPN name resolution](vpn-name-resolution.md) | Decide how name resolution should work |
| [VPN auto-triggered profile options](vpn-auto-trigger-profile.md) | Set a VPN profile to connect automatically by app or by name, to be "always on", and to not trigger VPN on trusted networks |
| [VPN security features](vpn-security-features.md) | Configure traffic filtering, connect a VPN profile to Windows Information Protection (WIP), and more |

25
windows/security/operating-system-security/network-security/windows-firewall/best-practices-configuring.md
View File

@ -105,7 +105,7 @@ To determine why some applications are blocked from communicating in the network
Creation of application rules at runtime can also be prohibited by administrators using the Settings app or Group Policy.
![Windows Firewall prompt.](images/fw04-userquery.png)
:::image type="content" alt-text="Windows Firewall prompt." source="images/fw04-userquery.png":::
*Figure 4: Dialog box to allow access*
@ -185,7 +185,7 @@ incoming connections, including those in the list of allowed apps** setting foun
*Figure 6: Windows settings App/Windows Security/Firewall Protection/Network Type*
![Firewall cpl.](images/fw07-legacy.png)
:::image type="content" alt-text="Firewall cpl." source="images/fw07-legacy.png":::
*Figure 7: Legacy firewall.cpl*
@ -208,3 +208,24 @@ For tasks related to creating outbound rules, see [Checklist: Creating Outbound
## Document your changes
When creating an inbound or outbound rule, you should specify details about the app itself, the port range used, and important notes like creation date. Rules must be well-documented for ease of review both by you and other admins. We highly encourage taking the time to make the work of reviewing your firewall rules at a later date easier. And *never* create unnecessary holes in your firewall.
## Configure Windows Firewall rules with WDAC tagging policies
Windows Firewall now supports the use of Windows Defender Application Control (WDAC) Application ID (AppID) tags in firewall rules. With this capability, Windows Firewall rules can now be scoped to an application or a group of applications by referencing process tags, without using absolute path or sacrificing security. There are two steps for this configuration:
### Step 1: Deploy WDAC AppId Tagging Policies
A Windows Defender Application Control (WDAC) policy needs to be deployed which specifies individual applications or groups of applications to apply a PolicyAppId tag to the process token(s). Then, the admin can define firewall rules which are scoped to all processes tagged with the matching PolicyAppId.  
Follow the detailed [WDAC Application ID (AppId) Tagging Guide](/windows/security/threat-protection/windows-defender-application-control/appidtagging/windows-defender-application-control-appid-tagging-guide) to create, deploy, and test an AppID (Application ID) policy to tag applications. 
### Step 2: Configure Firewall Rules using PolicyAppId Tags
- **Deploy firewall rules with Intune:** When creating firewall rules with Intune Microsoft Defender Firewall Rules, provide the AppId tag in the Policy App ID setting. The properties come directly from the [Firewall configuration service provider ](/windows/client-management/mdm/firewall-csp)(CSP) and apply to the Windows platform.
You can do this through the Intune admin center under Endpoint security > Firewall. Policy templates can be found via Create policy > Windows 10, Windows 11, and Windows Server > Microsoft Defender Firewall or Microsoft Defender Firewall Rules.
OR
- **Create local firewall rules with PowerShell**: You can use PowerShell to configure by adding a Firewall rule using [New-NetFirewallRule](/powershell/module/netsecurity/new-netfirewallrule) and specify the `–PolicyAppId` tag. You can specify one tag at a time while creating firewall rules. Multiple User Ids are supported.