diff --git a/.openpublishing.redirection.json b/.openpublishing.redirection.json index c8b24a5865..7972e54a7e 100644 --- a/.openpublishing.redirection.json +++ b/.openpublishing.redirection.json @@ -742,12 +742,12 @@ }, { "source_path": "windows/security/threat-protection/security-policy-settings/microsoft-network-client-digitally-sign-communications-if-server-agrees.md", - "redirect_url": "/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-client-digitally-sign-communications-if-server-agrees", + "redirect_url": "/windows/security/threat-protection/security-policy-settings/microsoft-network-client-digitally-sign-communications-always", "redirect_document_id": false }, { "source_path": "windows/security/threat-protection/security-policy-settings/microsoft-network-server-digitally-sign-communications-if-client-agress.md", - "redirect_url": "/windows/security/threat-protectionsecurity-policy-settings/smbv1-microsoft-network-server-digitally-sign-communications-if-client-agrees", + "redirect_url": "/windows/security/threat-protection/security-policy-settings/microsoft-network-server-digitally-sign-communications-always", "redirect_document_id": false }, { @@ -3447,7 +3447,7 @@ }, { "source_path": "windows/device-security/security-policy-settings/microsoft-network-client-digitally-sign-communications-if-server-agrees.md", - "redirect_url": "/windows/security/threat-protection/security-policy-settings/microsoft-network-client-digitally-sign-communications-if-server-agrees", + "redirect_url": "/windows/security/threat-protection/security-policy-settings/microsoft-network-client-digitally-sign-communications-always", "redirect_document_id": false }, { @@ -3472,7 +3472,7 @@ }, { "source_path": "windows/device-security/security-policy-settings/microsoft-network-server-digitally-sign-communications-if-client-agrees.md", - "redirect_url": "/windows/security/threat-protection/security-policy-settings/microsoft-network-server-digitally-sign-communications-if-client-agrees", + "redirect_url": "/windows/security/threat-protection/security-policy-settings/microsoft-network-server-digitally-sign-communications-always", "redirect_document_id": false }, { @@ -12392,12 +12392,12 @@ }, { "source_path": "windows/keep-secure/microsoft-network-client-digitally-sign-communications-always.md", - "redirect_url": "/windows/device-security/security-policy-settings/microsoft-network-client-digitally-sign-communications-always", + "redirect_url": "/windows/security/threat-protection/security-policy-settings/microsoft-network-client-digitally-sign-communications-always", "redirect_document_id": false }, { "source_path": "windows/keep-secure/microsoft-network-client-digitally-sign-communications-if-server-agrees.md", - "redirect_url": "/windows/device-security/security-policy-settings/microsoft-network-client-digitally-sign-communications-if-server-agrees", + "redirect_url": "/windows/security/threat-protection/security-policy-settings/microsoft-network-client-digitally-sign-communications-always", "redirect_document_id": false }, { @@ -12417,12 +12417,12 @@ }, { "source_path": "windows/keep-secure/microsoft-network-server-digitally-sign-communications-always.md", - "redirect_url": "/windows/device-security/security-policy-settings/microsoft-network-server-digitally-sign-communications-always", + "redirect_url": "/windows/security/threat-protection/security-policy-settings/microsoft-network-server-digitally-sign-communications-always", "redirect_document_id": false }, { "source_path": "windows/keep-secure/microsoft-network-server-digitally-sign-communications-if-client-agrees.md", - "redirect_url": "/windows/device-security/security-policy-settings/microsoft-network-server-digitally-sign-communications-if-client-agrees", + "redirect_url": "/windows/security/threat-protection/security-policy-settings/microsoft-network-server-digitally-sign-communications-always", "redirect_document_id": false }, { @@ -20295,6 +20295,101 @@ "redirect_url": "/azure/active-directory/authentication/howto-authentication-passwordless-security-key", "redirect_document_id": false }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-prereqs.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust", + "redirect_document_id": true + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-dirsync.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-ad.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-pki.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-dir-sync.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-policy.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-devreg.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-provision.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-key-new-install.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso", + "redirect_document_id": true + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-prereqs.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust", + "redirect_document_id": true + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-cert-new-install.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-devreg.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-ad.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-dir-sync.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-pki.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-validate-pki", + "redirect_document_id": true + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-policy.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-provision", + "redirect_document_id": true + }, { "source_path": "windows/configuration/provisioning-packages/provision-pcs-with-apps-and-certificates.md", "redirect_url": "/windows/configuration/provisioning-packages/provision-pcs-with-apps", @@ -20314,6 +20409,26 @@ "source_path": "windows/configuration/manage-wifi-sense-in-enterprise.md", "redirect_url": "/windows/resources", "redirect_document_id": false + }, + { + "source_path": "windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-client-digitally-sign-communications-always.md", + "redirect_url": "/windows/security/threat-protection/security-policy-settings/microsoft-network-client-digitally-sign-communications-always", + "redirect_document_id": false + }, + { + "source_path": "windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-client-digitally-sign-communications-if-server-agrees.md", + "redirect_url": "/windows/security/threat-protection/security-policy-settings/microsoft-network-client-digitally-sign-communications-always", + "redirect_document_id": false + }, + { + "source_path": "windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-server-digitally-sign-communications-always.md", + "redirect_url": "/windows/security/threat-protection/security-policy-settings/microsoft-network-server-digitally-sign-communications-always", + "redirect_document_id": false + }, + { + "source_path": "windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-server-digitally-sign-communications-if-client-agrees.md", + "redirect_url": "/windows/security/threat-protection/security-policy-settings/microsoft-network-server-digitally-sign-communications-always", + "redirect_document_id": false } ] } \ No newline at end of file diff --git a/education/includes/education-content-updates.md b/education/includes/education-content-updates.md new file mode 100644 index 0000000000..f3861da706 --- /dev/null +++ b/education/includes/education-content-updates.md @@ -0,0 +1,26 @@ + + + + +## Week of January 09, 2023 + + +| Published On |Topic title | Change | +|------|------------|--------| +| 1/12/2023 | [Configure federation between Google Workspace and Azure AD](/education/windows/configure-aad-google-trust) | added | + + +## Week of December 19, 2022 + + +| Published On |Topic title | Change | +|------|------------|--------| +| 12/22/2022 | [Windows 11 SE Overview](/education/windows/windows-11-se-overview) | modified | + + +## Week of December 12, 2022 + + +| Published On |Topic title | Change | +|------|------------|--------| +| 12/13/2022 | [Configure Stickers for Windows 11 SE](/education/windows/edu-stickers) | modified | diff --git a/windows/client-management/mdm-enrollment-of-windows-devices.md b/windows/client-management/mdm-enrollment-of-windows-devices.md index eba080fea2..f5d5c1dc39 100644 --- a/windows/client-management/mdm-enrollment-of-windows-devices.md +++ b/windows/client-management/mdm-enrollment-of-windows-devices.md @@ -285,13 +285,13 @@ The deep link used for connecting your device to work will always use the follow > [!NOTE] > AWA and Azure Active Directory-joined values for mode are only supported on Windows 10, version 1709 and later. - ### Connect to MDM using a deep link > [!NOTE] -> Deep links only work with Internet Explorer or Microsoft Edge browsers. When connecting to MDM using a deep link, the URI you should use is: -> **ms-device-enrollment:?mode=mdm** -> **ms-device-enrollment:?mode=mdm&username=someone@example.com&servername=<`https://example.server.com`>** +> Deep links only work with Internet Explorer or Microsoft Edge browsers. Examples of URI's that may be used to connect to MDM using a deep link: +> +> - **ms-device-enrollment:?mode=mdm** +> - **ms-device-enrollment:?mode=mdm&username=`someone@example.com`&servername=`https://example.server.com`** To connect your devices to MDM using deep links: @@ -303,6 +303,9 @@ To connect your devices to MDM using deep links: ![using enrollment deeplink in email.](images/deeplinkenrollment1.png) + > [!NOTE] + > Ensure that your email filters do not block deep links. + - IT admins can also add this link to an internal web page that users refer to enrollment instructions. 2. After you select the link or run it, Windows 10 launches the enrollment app in a special mode that only allows MDM enrollments (similar to the Enroll into device management option in Windows 10, version 1511). diff --git a/windows/client-management/mdm/policy-csp-admx-smartcard.md b/windows/client-management/mdm/policy-csp-admx-smartcard.md index 859415fe2f..c7e75ea97b 100644 --- a/windows/client-management/mdm/policy-csp-admx-smartcard.md +++ b/windows/client-management/mdm/policy-csp-admx-smartcard.md @@ -108,7 +108,7 @@ manager: aaroncz This policy setting lets you allow certificates without an Extended Key Usage (EKU) set to be used for signing in. -In versions of Windows, prior to Windows Vista, smart card certificates that are used for a sign-in require an enhanced key usage (EKU) extension with a smart card logon object identifier. This policy setting can be used to modify that restriction. +In versions of Windows, prior to Windows Vista, smart card certificates that are used for a sign-in require an extended key usage (EKU) extension with a smart card logon object identifier. This policy setting can be used to modify that restriction. If you enable this policy setting, certificates with the following attributes can also be used to sign in on with a smart card: diff --git a/windows/client-management/mdm/windowsdefenderapplicationguard-csp.md b/windows/client-management/mdm/windowsdefenderapplicationguard-csp.md index 32799b0ffd..8e0ff9f02d 100644 --- a/windows/client-management/mdm/windowsdefenderapplicationguard-csp.md +++ b/windows/client-management/mdm/windowsdefenderapplicationguard-csp.md @@ -334,7 +334,7 @@ Value type is integer. Supported operation is Get. -- Bit 0 - Set to 1 when Application Guard is enabled into enterprise manage mode. +- Bit 0 - Set to 1 when Application Guard is enabled into Windows Isolated environment mode. - Bit 1 - Set to 1 when the client machine is Hyper-V capable. - Bit 2 - Reserved for Microsoft. - Bit 3 - Set to 1 when Application Guard is installed on the client machine. diff --git a/windows/configuration/find-the-application-user-model-id-of-an-installed-app.md b/windows/configuration/find-the-application-user-model-id-of-an-installed-app.md index 2eda1c13b6..6ff2246977 100644 --- a/windows/configuration/find-the-application-user-model-id-of-an-installed-app.md +++ b/windows/configuration/find-the-application-user-model-id-of-an-installed-app.md @@ -111,3 +111,41 @@ listAumids("CustomerAccount") # Get a list of AUMIDs for all accounts on the device: listAumids("allusers") ``` + +## Example + +The following code sample creates a function in Windows PowerShell that returns the AUMID of any application currently listed in the Start menu. + +```powershell +function Get-AppAUMID { +param ( +[string]$AppName +) +$Apps = (New-Object -ComObject Shell.Application).NameSpace('shell:::{4234d49b-0245-4df3-b780-3893943456e1}').Items() +if ($AppName){ + $Result = $Apps | Where-Object { $_.name -like "*$AppName*" } | Select-Object name,@{n="AUMID";e={$_.path}} + if ($Result){ + Return $Result + } + else {"Unable to locate {0}" -f $AppName} +} +else { + $Result = $Apps | Select-Object name,@{n="AUMID";e={$_.path}} + Return $Result +} +} +``` + +The following Windows PowerShell commands demonstrate how you can call the Get-AppAUMID function after you've created it. + +```powershell +# Get the AUMID for OneDrive +Get-AppAUMID -AppName OneDrive + +# Get the AUMID for Microsoft Word +Get-AppAUMID -AppName Word + +# List all apps and their AUMID in the Start menu +Get-AppAUMID +``` + diff --git a/windows/deployment/breadcrumb/toc.yml b/windows/deployment/breadcrumb/toc.yml index 3cb4555445..bbaa26132d 100644 --- a/windows/deployment/breadcrumb/toc.yml +++ b/windows/deployment/breadcrumb/toc.yml @@ -21,4 +21,17 @@ items: items: - name: Deployment tocHref: /windows/whats-new - topicHref: /windows/deployment/ \ No newline at end of file + topicHref: /windows/deployment/ + +- name: Learn + tocHref: / + topicHref: / + items: + - name: Windows + tocHref: /mem/intune/ + topicHref: /windows/resources/ + items: + - name: Deployment + tocHref: /mem/intune/protect/ + topicHref: /windows/deployment/ + diff --git a/windows/deployment/update/PSFxWhitepaper.md b/windows/deployment/update/PSFxWhitepaper.md index 0e62430e64..a0f9346acc 100644 --- a/windows/deployment/update/PSFxWhitepaper.md +++ b/windows/deployment/update/PSFxWhitepaper.md @@ -2,13 +2,11 @@ title: Windows Updates using forward and reverse differentials description: A technique to produce compact software updates optimized for any origin and destination revision pair ms.prod: windows-client -author: aczechowski +author: mestew ms.localizationpriority: medium -ms.author: aaroncz -ms.reviewer: -manager: dougeby +ms.author: mstewart +manager: aaroncz ms.topic: article -ms.custom: seo-marvel-apr2020 ms.technology: itpro-updates ms.date: 12/31/2017 --- diff --git a/windows/deployment/update/WIP4Biz-intro.md b/windows/deployment/update/WIP4Biz-intro.md index 9671062faf..15954efa93 100644 --- a/windows/deployment/update/WIP4Biz-intro.md +++ b/windows/deployment/update/WIP4Biz-intro.md @@ -1,12 +1,10 @@ --- title: Introduction to the Windows Insider Program for Business description: In this article, you'll learn about the Windows Insider Program for Business and why IT Pros should join. -ms.custom: seo-marvel-apr2020 ms.prod: windows-client -author: aczechowski -ms.author: aaroncz -manager: dougeby -ms.reviewer: +author: mestew +ms.author: mstewart +manager: aaroncz ms.topic: article ms.technology: itpro-updates ms.date: 12/31/2017 diff --git a/windows/deployment/update/create-deployment-plan.md b/windows/deployment/update/create-deployment-plan.md index 9db3fb6b10..bc649af09d 100644 --- a/windows/deployment/update/create-deployment-plan.md +++ b/windows/deployment/update/create-deployment-plan.md @@ -2,10 +2,10 @@ title: Create a deployment plan description: Devise the number of deployment rings you need and how you want to populate them ms.prod: windows-client -author: aczechowski +author: mestew ms.localizationpriority: medium -ms.author: aaroncz -manager: dougeby +ms.author: mstewart +manager: aaroncz ms.topic: article ms.technology: itpro-updates ms.date: 12/31/2017 diff --git a/windows/deployment/update/deploy-updates-configmgr.md b/windows/deployment/update/deploy-updates-configmgr.md index e15dae5bcc..3a6115792f 100644 --- a/windows/deployment/update/deploy-updates-configmgr.md +++ b/windows/deployment/update/deploy-updates-configmgr.md @@ -5,8 +5,7 @@ ms.prod: windows-client author: mestew ms.localizationpriority: medium ms.author: mstewart -ms.reviewer: -manager: dougeby +manager: aaroncz ms.topic: article ms.technology: itpro-updates ms.date: 12/31/2017 diff --git a/windows/deployment/update/deploy-updates-intune.md b/windows/deployment/update/deploy-updates-intune.md index f81e158e4b..d30f45fc12 100644 --- a/windows/deployment/update/deploy-updates-intune.md +++ b/windows/deployment/update/deploy-updates-intune.md @@ -2,11 +2,10 @@ title: Deploy updates with Intune description: Deploy Windows client updates with Intune ms.prod: windows-client -author: aczechowski +author: mestew ms.localizationpriority: medium -ms.author: aaroncz -ms.reviewer: -manager: dougeby +ms.author: mstewart +manager: aaroncz ms.topic: article ms.technology: itpro-updates ms.collection: diff --git a/windows/deployment/update/deployment-service-overview.md b/windows/deployment/update/deployment-service-overview.md index b04b472ad9..3d655149d9 100644 --- a/windows/deployment/update/deployment-service-overview.md +++ b/windows/deployment/update/deployment-service-overview.md @@ -1,13 +1,11 @@ --- title: Windows Update for Business deployment service description: Overview of deployment service to control approval, scheduling, and safeguarding of Windows updates -ms.custom: seo-marvel-apr2020 ms.prod: windows-client -author: aczechowski +author: mestew ms.localizationpriority: medium -ms.author: aaroncz -ms.reviewer: -manager: dougeby +ms.author: mstewart +manager: aaroncz ms.topic: article ms.technology: itpro-updates ms.date: 12/31/2017 diff --git a/windows/deployment/update/deployment-service-troubleshoot.md b/windows/deployment/update/deployment-service-troubleshoot.md index 8d974c72fe..f584bbae71 100644 --- a/windows/deployment/update/deployment-service-troubleshoot.md +++ b/windows/deployment/update/deployment-service-troubleshoot.md @@ -1,13 +1,11 @@ --- title: Troubleshoot the Windows Update for Business deployment service description: Solutions to common problems with the service -ms.custom: seo-marvel-apr2020 ms.prod: windows-client -author: aczechowski +author: mestew ms.localizationpriority: medium -ms.author: aaroncz -ms.reviewer: -manager: dougeby +ms.author: mstewart +manager: aaroncz ms.topic: article ms.technology: itpro-updates ms.date: 12/31/2017 diff --git a/windows/deployment/update/eval-infra-tools.md b/windows/deployment/update/eval-infra-tools.md index 29557c5e99..14e8129982 100644 --- a/windows/deployment/update/eval-infra-tools.md +++ b/windows/deployment/update/eval-infra-tools.md @@ -2,9 +2,9 @@ title: Evaluate infrastructure and tools description: Steps to make sure your infrastructure is ready to deploy updates ms.prod: windows-client -author: aczechowski -ms.author: aaroncz -manager: dougeby +author: mestew +ms.author: mstewart +manager: aaroncz ms.localizationpriority: medium ms.topic: article ms.technology: itpro-updates diff --git a/windows/deployment/update/feature-update-user-install.md b/windows/deployment/update/feature-update-user-install.md index 019f4f5331..1385930bef 100644 --- a/windows/deployment/update/feature-update-user-install.md +++ b/windows/deployment/update/feature-update-user-install.md @@ -2,14 +2,12 @@ title: Best practices - deploy feature updates for user-initiated installations description: Learn recommendations and best practices for manually deploying a feature update for a user-initiated installation. ms.prod: windows-client -author: aczechowski +author: mestew ms.localizationpriority: medium -ms.author: aaroncz +ms.author: mstewart ms.date: 07/10/2018 -ms.reviewer: -manager: dougeby +manager: aaroncz ms.topic: article -ms.custom: seo-marvel-apr2020 ms.technology: itpro-updates --- diff --git a/windows/deployment/update/fod-and-lang-packs.md b/windows/deployment/update/fod-and-lang-packs.md index 3d51115d70..2978105443 100644 --- a/windows/deployment/update/fod-and-lang-packs.md +++ b/windows/deployment/update/fod-and-lang-packs.md @@ -2,14 +2,12 @@ title: Make FoD and language packs available for WSUS/Configuration Manager description: Learn how to make FoD and language packs available when you're using WSUS/Configuration Manager. ms.prod: windows-client -ms.author: aaroncz -author: aczechowski +ms.author: mstewart +author: mestew ms.localizationpriority: medium ms.date: 03/13/2019 -ms.reviewer: -manager: dougeby +manager: aaroncz ms.topic: article -ms.custom: seo-marvel-apr2020 ms.technology: itpro-updates --- # How to make Features on Demand and language packs available when you're using WSUS or Configuration Manager diff --git a/windows/deployment/update/get-started-updates-channels-tools.md b/windows/deployment/update/get-started-updates-channels-tools.md index 777e52fd68..0ed7fc519a 100644 --- a/windows/deployment/update/get-started-updates-channels-tools.md +++ b/windows/deployment/update/get-started-updates-channels-tools.md @@ -2,10 +2,10 @@ title: Windows client updates, channels, and tools description: Brief summary of the kinds of Windows updates, the channels they are served through, and the tools for managing them ms.prod: windows-client -author: aczechowski +author: mestew ms.localizationpriority: medium -ms.author: aaroncz -manager: dougeby +ms.author: mstewart +manager: aaroncz ms.topic: article ms.technology: itpro-updates ms.date: 12/31/2017 diff --git a/windows/deployment/update/how-windows-update-works.md b/windows/deployment/update/how-windows-update-works.md index 4a82f9dda6..907f34dd28 100644 --- a/windows/deployment/update/how-windows-update-works.md +++ b/windows/deployment/update/how-windows-update-works.md @@ -2,12 +2,11 @@ title: How Windows Update works description: In this article, learn about the process Windows Update uses to download and install updates on a Windows client devices. ms.prod: windows-client -author: aczechowski +author: mestew ms.localizationpriority: medium -ms.author: aaroncz -manager: dougeby +ms.author: mstewart +manager: aaroncz ms.topic: article -ms.custom: seo-marvel-apr2020 ms.technology: itpro-updates ms.date: 12/31/2017 --- diff --git a/windows/deployment/update/index.md b/windows/deployment/update/index.md index a9e7a9592a..98552e3194 100644 --- a/windows/deployment/update/index.md +++ b/windows/deployment/update/index.md @@ -2,10 +2,10 @@ title: Update Windows client in enterprise deployments description: Windows as a service provides an all-new way to think about building, deploying, and servicing Windows client. ms.prod: windows-client -author: aczechowski -manager: dougeby +author: mestew +manager: aaroncz ms.localizationpriority: high -ms.author: aaroncz +ms.author: mstewart ms.topic: article ms.technology: itpro-updates ms.date: 12/31/2017 diff --git a/windows/deployment/update/media-dynamic-update.md b/windows/deployment/update/media-dynamic-update.md index 83136ce4d4..af27a5c840 100644 --- a/windows/deployment/update/media-dynamic-update.md +++ b/windows/deployment/update/media-dynamic-update.md @@ -2,13 +2,14 @@ title: Update Windows installation media with Dynamic Update description: Learn how to deploy feature updates to your mission critical devices ms.prod: windows-client -author: SteveDiAcetis +author: mestew ms.localizationpriority: medium -ms.author: aaroncz -manager: dougeby +ms.author: mstewart +manager: aaroncz ms.topic: article ms.technology: itpro-updates ms.date: 12/31/2017 +ms.reviewer: stevedia --- # Update Windows installation media with Dynamic Update diff --git a/windows/deployment/update/olympia/olympia-enrollment-guidelines.md b/windows/deployment/update/olympia/olympia-enrollment-guidelines.md index d9091e373e..06c5076a73 100644 --- a/windows/deployment/update/olympia/olympia-enrollment-guidelines.md +++ b/windows/deployment/update/olympia/olympia-enrollment-guidelines.md @@ -5,7 +5,6 @@ ms.author: lizlong ms.topic: article ms.prod: windows-client author: lizgt2000 -ms.reviewer: manager: aaroncz ms.technology: itpro-updates ms.date: 12/31/2017 diff --git a/windows/deployment/update/optional-content.md b/windows/deployment/update/optional-content.md index b362518be7..ee5da0bb30 100644 --- a/windows/deployment/update/optional-content.md +++ b/windows/deployment/update/optional-content.md @@ -2,10 +2,10 @@ title: Migrating and acquiring optional Windows content description: Keep language resources and Features on Demand during operating system updates ms.prod: windows-client -author: aczechowski +author: mestew ms.localizationpriority: medium -ms.author: aaroncz -manager: dougeby +ms.author: mstewart +manager: aaroncz ms.topic: article ms.technology: itpro-updates ms.date: 12/31/2017 diff --git a/windows/deployment/update/plan-define-readiness.md b/windows/deployment/update/plan-define-readiness.md index e3399f0279..cf56100362 100644 --- a/windows/deployment/update/plan-define-readiness.md +++ b/windows/deployment/update/plan-define-readiness.md @@ -2,9 +2,9 @@ title: Define readiness criteria description: Identify important roles and figure out how to classify apps ms.prod: windows-client -author: aczechowski -ms.author: aaroncz -manager: dougeby +author: mestew +ms.author: mstewart +manager: aaroncz ms.localizationpriority: medium ms.topic: article ms.technology: itpro-updates diff --git a/windows/deployment/update/plan-define-strategy.md b/windows/deployment/update/plan-define-strategy.md index 32d063dab3..bc225337f8 100644 --- a/windows/deployment/update/plan-define-strategy.md +++ b/windows/deployment/update/plan-define-strategy.md @@ -2,10 +2,10 @@ title: Define update strategy description: Two examples of a calendar-based approach to consistent update installation ms.prod: windows-client -author: aczechowski +author: mestew ms.localizationpriority: medium -ms.author: aaroncz -manager: dougeby +ms.author: mstewart +manager: aaroncz ms.topic: article ms.technology: itpro-updates ms.date: 12/31/2017 diff --git a/windows/deployment/update/plan-determine-app-readiness.md b/windows/deployment/update/plan-determine-app-readiness.md index 8d7abb8429..4d7cf5c662 100644 --- a/windows/deployment/update/plan-determine-app-readiness.md +++ b/windows/deployment/update/plan-determine-app-readiness.md @@ -1,12 +1,12 @@ --- title: Determine application readiness -manager: dougeby +manager: aaroncz description: How to test your apps to know which need attention prior to deploying an update ms.prod: windows-client ms.localizationpriority: medium ms.topic: article -ms.author: aaroncz -author: aczechowski +ms.author: mstewart +author: mestew ms.technology: itpro-updates ms.date: 12/31/2017 --- diff --git a/windows/deployment/update/prepare-deploy-windows.md b/windows/deployment/update/prepare-deploy-windows.md index e88bc01c45..7d787fbeda 100644 --- a/windows/deployment/update/prepare-deploy-windows.md +++ b/windows/deployment/update/prepare-deploy-windows.md @@ -2,11 +2,10 @@ title: Prepare to deploy Windows description: Final steps to get ready to deploy Windows, including preparing infrastructure, environment, applications, devices, network, capability, and users ms.prod: windows-client -author: aczechowski +author: mestew ms.localizationpriority: medium -ms.author: aaroncz -ms.reviewer: -manager: dougeby +ms.author: mstewart +manager: aaroncz ms.topic: article ms.technology: itpro-updates ms.date: 12/31/2017 diff --git a/windows/deployment/update/quality-updates.md b/windows/deployment/update/quality-updates.md index 2f3003eef4..4597ce3369 100644 --- a/windows/deployment/update/quality-updates.md +++ b/windows/deployment/update/quality-updates.md @@ -2,11 +2,10 @@ title: Monthly quality updates (Windows 10/11) description: Learn about Windows monthly quality updates to stay productive and protected. ms.prod: windows-client -author: aczechowski +author: mestew ms.localizationpriority: medium -ms.author: aaroncz -ms.reviewer: -manager: dougeby +ms.author: mstewart +manager: aaroncz ms.topic: article ms.technology: itpro-updates ms.date: 12/31/2017 diff --git a/windows/deployment/update/safeguard-holds.md b/windows/deployment/update/safeguard-holds.md index 7287acbcc1..7d3d501e00 100644 --- a/windows/deployment/update/safeguard-holds.md +++ b/windows/deployment/update/safeguard-holds.md @@ -2,10 +2,10 @@ title: Safeguard holds description: What are safeguard holds, how can you tell if one is in effect, and what to do about it ms.prod: windows-client -author: aczechowski +author: mestew ms.localizationpriority: medium -ms.author: aaroncz -manager: dougeby +ms.author: mstewart +manager: aaroncz ms.topic: article ms.technology: itpro-updates ms.collection: diff --git a/windows/deployment/update/safeguard-opt-out.md b/windows/deployment/update/safeguard-opt-out.md index d5e7feb5f0..96b29c913a 100644 --- a/windows/deployment/update/safeguard-opt-out.md +++ b/windows/deployment/update/safeguard-opt-out.md @@ -2,10 +2,10 @@ title: Opt out of safeguard holds description: Steps to install an update even it if has a safeguard hold applied ms.prod: windows-client -author: aczechowski +author: mestew ms.localizationpriority: medium -ms.author: aaroncz -manager: dougeby +ms.author: mstewart +manager: aaroncz ms.topic: article ms.technology: itpro-updates ms.date: 12/31/2017 diff --git a/windows/deployment/update/servicing-stack-updates.md b/windows/deployment/update/servicing-stack-updates.md index f7d7f2d1b8..a74559df0f 100644 --- a/windows/deployment/update/servicing-stack-updates.md +++ b/windows/deployment/update/servicing-stack-updates.md @@ -2,14 +2,13 @@ title: Servicing stack updates description: In this article, learn how servicing stack updates improve the code that installs the other updates. ms.prod: windows-client -author: aczechowski +author: mestew ms.localizationpriority: high -ms.author: aaroncz -manager: dougeby +ms.author: mstewart +manager: aaroncz ms.collection: - highpri ms.topic: article -ms.custom: seo-marvel-apr2020 ms.technology: itpro-updates ms.date: 12/31/2017 --- diff --git a/windows/deployment/update/update-baseline.md b/windows/deployment/update/update-baseline.md index e860aa2cbb..9173c21e30 100644 --- a/windows/deployment/update/update-baseline.md +++ b/windows/deployment/update/update-baseline.md @@ -2,10 +2,10 @@ title: Update Baseline description: Use an update baseline to optimize user experience and meet monthly update goals ms.prod: windows-client -author: aczechowski +author: mestew ms.localizationpriority: medium -ms.author: aaroncz -manager: dougeby +ms.author: mstewart +manager: aaroncz ms.topic: article ms.technology: itpro-updates ms.date: 12/31/2017 diff --git a/windows/deployment/update/update-compliance-configuration-manual.md b/windows/deployment/update/update-compliance-configuration-manual.md index 56aabc0f35..2cd4b2f59a 100644 --- a/windows/deployment/update/update-compliance-configuration-manual.md +++ b/windows/deployment/update/update-compliance-configuration-manual.md @@ -1,7 +1,6 @@ --- title: Manually configuring devices for Update Compliance -ms.reviewer: -manager: aczechowski +manager: aaroncz description: Manually configuring devices for Update Compliance ms.prod: windows-client author: mestew diff --git a/windows/deployment/update/update-compliance-configuration-mem.md b/windows/deployment/update/update-compliance-configuration-mem.md index 2a40c16a2a..14c94f5341 100644 --- a/windows/deployment/update/update-compliance-configuration-mem.md +++ b/windows/deployment/update/update-compliance-configuration-mem.md @@ -1,7 +1,6 @@ --- title: Configuring Microsoft Intune devices for Update Compliance -ms.reviewer: -manager: aczechowski +manager: aaroncz description: Configuring devices that are enrolled in Intune for Update Compliance ms.prod: windows-client author: mestew diff --git a/windows/deployment/update/update-compliance-configuration-script.md b/windows/deployment/update/update-compliance-configuration-script.md index bcae3d1cce..2d8e1183db 100644 --- a/windows/deployment/update/update-compliance-configuration-script.md +++ b/windows/deployment/update/update-compliance-configuration-script.md @@ -1,7 +1,6 @@ --- title: Update Compliance Configuration Script -ms.reviewer: -manager: aczechowski +manager: aaroncz description: Downloading and using the Update Compliance Configuration Script ms.prod: windows-client author: mestew diff --git a/windows/deployment/update/update-compliance-delivery-optimization.md b/windows/deployment/update/update-compliance-delivery-optimization.md index d4189f5d1b..37aad4dc7a 100644 --- a/windows/deployment/update/update-compliance-delivery-optimization.md +++ b/windows/deployment/update/update-compliance-delivery-optimization.md @@ -1,14 +1,12 @@ --- title: Delivery Optimization in Update Compliance -ms.reviewer: -manager: aczechowski +manager: aaroncz description: Learn how the Update Compliance solution provides you with information about your Delivery Optimization configuration. ms.prod: windows-client author: mestew ms.author: mstewart ms.localizationpriority: medium ms.topic: article -ms.custom: seo-marvel-apr2020 ms.technology: itpro-updates ms.date: 12/31/2017 --- diff --git a/windows/deployment/update/update-compliance-feature-update-status.md b/windows/deployment/update/update-compliance-feature-update-status.md index 6144ffaf3a..51a728c4c8 100644 --- a/windows/deployment/update/update-compliance-feature-update-status.md +++ b/windows/deployment/update/update-compliance-feature-update-status.md @@ -1,13 +1,11 @@ --- title: Update Compliance - Feature Update Status report -ms.reviewer: -manager: aczechowski +manager: aaroncz description: Learn how the Feature Update Status report provides information about the status of feature updates across all devices. ms.prod: windows-client author: mestew ms.author: mstewart ms.topic: article -ms.custom: seo-marvel-apr2020 ms.technology: itpro-updates ms.date: 12/31/2017 --- diff --git a/windows/deployment/update/update-compliance-get-started.md b/windows/deployment/update/update-compliance-get-started.md index 1b4b422507..693f8b440d 100644 --- a/windows/deployment/update/update-compliance-get-started.md +++ b/windows/deployment/update/update-compliance-get-started.md @@ -1,6 +1,6 @@ --- title: Get started with Update Compliance -manager: aczechowski +manager: aaroncz description: Prerequisites, Azure onboarding, and configuring devices for Update Compliance ms.prod: windows-client author: mestew diff --git a/windows/deployment/update/update-compliance-monitor.md b/windows/deployment/update/update-compliance-monitor.md index 4e34f7828b..323cc9207e 100644 --- a/windows/deployment/update/update-compliance-monitor.md +++ b/windows/deployment/update/update-compliance-monitor.md @@ -1,14 +1,12 @@ --- title: Monitor Windows Updates and Microsoft Defender AV with Update Compliance -ms.reviewer: -manager: aczechowski +manager: aaroncz description: You can use Update Compliance in Azure portal to monitor the progress of updates and key anti-malware protection features on devices in your network. ms.prod: windows-client author: mestew ms.author: mstewart ms.localizationpriority: medium ms.topic: article -ms.custom: seo-marvel-apr2020 ms.technology: itpro-updates ms.date: 12/31/2017 --- diff --git a/windows/deployment/update/update-compliance-need-attention.md b/windows/deployment/update/update-compliance-need-attention.md index 7ac31b890b..2dcb66b2bf 100644 --- a/windows/deployment/update/update-compliance-need-attention.md +++ b/windows/deployment/update/update-compliance-need-attention.md @@ -1,6 +1,6 @@ --- title: Update Compliance - Need Attention! report -manager: aczechowski +manager: aaroncz description: Learn how the Need attention! section provides a breakdown of all Windows 10 device and update issues detected by Update Compliance. author: mestew ms.author: mstewart diff --git a/windows/deployment/update/update-compliance-privacy.md b/windows/deployment/update/update-compliance-privacy.md index 068ccd2f9a..72b284c0c6 100644 --- a/windows/deployment/update/update-compliance-privacy.md +++ b/windows/deployment/update/update-compliance-privacy.md @@ -1,7 +1,6 @@ --- title: Privacy in Update Compliance -ms.reviewer: -manager: aczechowski +manager: aaroncz description: an overview of the Feature Update Status report ms.prod: windows-client author: mestew diff --git a/windows/deployment/update/update-compliance-safeguard-holds.md b/windows/deployment/update/update-compliance-safeguard-holds.md index 9974fa5753..071e0da12f 100644 --- a/windows/deployment/update/update-compliance-safeguard-holds.md +++ b/windows/deployment/update/update-compliance-safeguard-holds.md @@ -1,13 +1,11 @@ --- title: Update Compliance - Safeguard Holds report -ms.reviewer: -manager: aczechowski +manager: aaroncz description: Learn how the Safeguard Holds report provides information about safeguard holds in your population. ms.prod: windows-client author: mestew ms.author: mstewart ms.topic: article -ms.custom: seo-marvel-apr2020 ms.technology: itpro-updates ms.date: 12/31/2017 --- diff --git a/windows/deployment/update/update-compliance-schema-waasdeploymentstatus.md b/windows/deployment/update/update-compliance-schema-waasdeploymentstatus.md index 62ba2be862..125d1a6de3 100644 --- a/windows/deployment/update/update-compliance-schema-waasdeploymentstatus.md +++ b/windows/deployment/update/update-compliance-schema-waasdeploymentstatus.md @@ -1,7 +1,6 @@ --- title: Update Compliance Schema - WaaSDeploymentStatus -ms.reviewer: -manager: aczechowski +manager: aaroncz description: WaaSDeploymentStatus schema ms.prod: windows-client author: mestew diff --git a/windows/deployment/update/update-compliance-schema-waasinsiderstatus.md b/windows/deployment/update/update-compliance-schema-waasinsiderstatus.md index b159c82ad4..9e8a73b355 100644 --- a/windows/deployment/update/update-compliance-schema-waasinsiderstatus.md +++ b/windows/deployment/update/update-compliance-schema-waasinsiderstatus.md @@ -1,7 +1,6 @@ --- title: Update Compliance Schema - WaaSInsiderStatus -ms.reviewer: -manager: aczechowski +manager: aaroncz description: WaaSInsiderStatus schema ms.prod: windows-client author: mestew diff --git a/windows/deployment/update/update-compliance-schema-waasupdatestatus.md b/windows/deployment/update/update-compliance-schema-waasupdatestatus.md index 762486f62f..3a83aad3f6 100644 --- a/windows/deployment/update/update-compliance-schema-waasupdatestatus.md +++ b/windows/deployment/update/update-compliance-schema-waasupdatestatus.md @@ -1,7 +1,6 @@ --- title: Update Compliance Schema - WaaSUpdateStatus -ms.reviewer: -manager: aczechowski +manager: aaroncz description: WaaSUpdateStatus schema ms.prod: windows-client author: mestew diff --git a/windows/deployment/update/update-compliance-schema-wudoaggregatedstatus.md b/windows/deployment/update/update-compliance-schema-wudoaggregatedstatus.md index 066c38fee1..a16ae4d5a3 100644 --- a/windows/deployment/update/update-compliance-schema-wudoaggregatedstatus.md +++ b/windows/deployment/update/update-compliance-schema-wudoaggregatedstatus.md @@ -1,7 +1,6 @@ --- title: Update Compliance Schema - WUDOAggregatedStatus -ms.reviewer: -manager: aczechowski +manager: aaroncz description: WUDOAggregatedStatus schema ms.prod: windows-client author: mestew diff --git a/windows/deployment/update/update-compliance-schema-wudostatus.md b/windows/deployment/update/update-compliance-schema-wudostatus.md index 769508bbff..60ae8e5991 100644 --- a/windows/deployment/update/update-compliance-schema-wudostatus.md +++ b/windows/deployment/update/update-compliance-schema-wudostatus.md @@ -1,7 +1,6 @@ --- title: Update Compliance Schema - WUDOStatus -ms.reviewer: -manager: aczechowski +manager: aaroncz description: WUDOStatus schema ms.prod: windows-client author: mestew diff --git a/windows/deployment/update/update-compliance-schema.md b/windows/deployment/update/update-compliance-schema.md index 9f3340f361..5c760ad6d0 100644 --- a/windows/deployment/update/update-compliance-schema.md +++ b/windows/deployment/update/update-compliance-schema.md @@ -1,7 +1,6 @@ --- title: Update Compliance Data Schema -ms.reviewer: -manager: aczechowski +manager: aaroncz description: an overview of Update Compliance data schema ms.prod: windows-client author: mestew diff --git a/windows/deployment/update/update-compliance-security-update-status.md b/windows/deployment/update/update-compliance-security-update-status.md index e20fd18105..829e562eba 100644 --- a/windows/deployment/update/update-compliance-security-update-status.md +++ b/windows/deployment/update/update-compliance-security-update-status.md @@ -1,13 +1,11 @@ --- title: Update Compliance - Security Update Status report -ms.reviewer: -manager: aczechowski +manager: aaroncz description: Learn how the Security Update Status section provides information about security updates across all devices. ms.prod: windows-client author: mestew ms.author: mstewart ms.topic: article -ms.custom: seo-marvel-apr2020 ms.technology: itpro-updates ms.date: 12/31/2017 --- diff --git a/windows/deployment/update/update-compliance-using.md b/windows/deployment/update/update-compliance-using.md index 6dbb018e21..a8eb872ebf 100644 --- a/windows/deployment/update/update-compliance-using.md +++ b/windows/deployment/update/update-compliance-using.md @@ -1,14 +1,12 @@ --- title: Using Update Compliance -ms.reviewer: -manager: aczechowski +manager: aaroncz description: Learn how to use Update Compliance to monitor your device's Windows updates. ms.prod: windows-client author: mestew ms.author: mstewart ms.localizationpriority: medium ms.topic: article -ms.custom: seo-marvel-apr2020 ms.technology: itpro-updates ms.date: 12/31/2017 --- diff --git a/windows/deployment/update/update-policies.md b/windows/deployment/update/update-policies.md index 7b93908dff..1eb791b4fd 100644 --- a/windows/deployment/update/update-policies.md +++ b/windows/deployment/update/update-policies.md @@ -1,11 +1,10 @@ --- title: Policies for update compliance, activity, and user experience -ms.reviewer: description: Explanation and recommendations for settings ms.prod: windows-client -author: aczechowski -ms.author: aaroncz -manager: dougeby +author: mestew +ms.author: mstewart +manager: aaroncz ms.localizationpriority: medium ms.topic: article ms.technology: itpro-updates diff --git a/windows/deployment/update/waas-branchcache.md b/windows/deployment/update/waas-branchcache.md index a0ce1d97fe..1329d93a6b 100644 --- a/windows/deployment/update/waas-branchcache.md +++ b/windows/deployment/update/waas-branchcache.md @@ -2,13 +2,11 @@ title: Configure BranchCache for Windows client updates description: In this article, learn how to use BranchCache to optimize network bandwidth during update deployment. ms.prod: windows-client -author: aczechowski +author: mestew ms.localizationpriority: medium -ms.author: aaroncz -ms.reviewer: -manager: dougeby +ms.author: mstewart +manager: aaroncz ms.topic: article -ms.custom: seo-marvel-apr2020 ms.technology: itpro-updates ms.date: 12/31/2017 --- diff --git a/windows/deployment/update/waas-configure-wufb.md b/windows/deployment/update/waas-configure-wufb.md index 0dec620c52..a3f6cdf2a8 100644 --- a/windows/deployment/update/waas-configure-wufb.md +++ b/windows/deployment/update/waas-configure-wufb.md @@ -1,11 +1,11 @@ --- title: Configure Windows Update for Business -manager: dougeby +manager: aaroncz description: You can use Group Policy or your mobile device management (MDM) service to configure Windows Update for Business settings for your devices. ms.prod: windows-client -author: aczechowski +author: mestew ms.localizationpriority: medium -ms.author: aaroncz +ms.author: mstewart ms.topic: article ms.technology: itpro-updates ms.date: 12/31/2017 diff --git a/windows/deployment/update/waas-integrate-wufb.md b/windows/deployment/update/waas-integrate-wufb.md index 2cfbaa9a5d..007f114627 100644 --- a/windows/deployment/update/waas-integrate-wufb.md +++ b/windows/deployment/update/waas-integrate-wufb.md @@ -2,10 +2,10 @@ title: Integrate Windows Update for Business description: Use Windows Update for Business deployments with management tools such as Windows Server Update Services (WSUS) and Microsoft Configuration Manager. ms.prod: windows-client -author: aczechowski +author: mestew ms.localizationpriority: medium -ms.author: aaroncz -manager: dougeby +ms.author: mstewart +manager: aaroncz ms.topic: article ms.technology: itpro-updates ms.date: 12/31/2017 diff --git a/windows/deployment/update/waas-manage-updates-wsus.md b/windows/deployment/update/waas-manage-updates-wsus.md index 504427dbce..1257d066aa 100644 --- a/windows/deployment/update/waas-manage-updates-wsus.md +++ b/windows/deployment/update/waas-manage-updates-wsus.md @@ -2,10 +2,10 @@ title: Deploy Windows client updates using Windows Server Update Services description: WSUS allows companies to defer, selectively approve, choose when delivered, and determine which devices receive updates. ms.prod: windows-client -author: aczechowski +author: mestew ms.localizationpriority: medium -ms.author: aaroncz -manager: dougeby +ms.author: mstewart +manager: aaroncz ms.topic: article ms.collection: highpri ms.technology: itpro-updates diff --git a/windows/deployment/update/waas-manage-updates-wufb.md b/windows/deployment/update/waas-manage-updates-wufb.md index 9adb25acae..dfe5a33f26 100644 --- a/windows/deployment/update/waas-manage-updates-wufb.md +++ b/windows/deployment/update/waas-manage-updates-wufb.md @@ -1,13 +1,12 @@ --- title: Windows Update for Business -manager: dougeby +manager: aaroncz description: Learn how Windows Update for Business lets you manage when devices receive updates from Windows Update. ms.prod: windows-client -author: aczechowski +author: mestew ms.localizationpriority: medium -ms.author: aaroncz +ms.author: mstewart ms.topic: article -ms.custom: seo-marvel-apr2020 ms.collection: highpri ms.technology: itpro-updates ms.date: 12/31/2017 diff --git a/windows/deployment/update/waas-morenews.md b/windows/deployment/update/waas-morenews.md index caa224c51d..84840a0222 100644 --- a/windows/deployment/update/waas-morenews.md +++ b/windows/deployment/update/waas-morenews.md @@ -4,10 +4,9 @@ description: The latest news for Windows as a service with resources to help you ms.prod: windows-client ms.topic: article ms.manager: elizapo -author: aczechowski -ms.author: aaroncz -ms.reviewer: -manager: dougeby +author: mestew +ms.author: mstewart +manager: aaroncz ms.localizationpriority: high ms.technology: itpro-updates ms.date: 12/31/2017 diff --git a/windows/deployment/update/waas-overview.md b/windows/deployment/update/waas-overview.md index a254a031ee..dd9bc872b4 100644 --- a/windows/deployment/update/waas-overview.md +++ b/windows/deployment/update/waas-overview.md @@ -2,10 +2,10 @@ title: Overview of Windows as a service description: Windows as a service is a way to build, deploy, and service Windows. Learn how Windows as a service works. ms.prod: windows-client -author: aczechowski +author: mestew ms.localizationpriority: medium -ms.author: aaroncz -manager: dougeby +ms.author: mstewart +manager: aaroncz ms.topic: article ms.collection: highpri ms.technology: itpro-updates diff --git a/windows/deployment/update/waas-quick-start.md b/windows/deployment/update/waas-quick-start.md index 73aa593ccf..825676e789 100644 --- a/windows/deployment/update/waas-quick-start.md +++ b/windows/deployment/update/waas-quick-start.md @@ -2,10 +2,10 @@ title: Quick guide to Windows as a service (Windows 10) description: In Windows 10, Microsoft has streamlined servicing to make operating system updates simpler to test, manage, and deploy. ms.prod: windows-client -author: aczechowski +author: mestew ms.localizationpriority: high -ms.author: aaroncz -manager: dougeby +ms.author: mstewart +manager: aaroncz ms.topic: article ms.technology: itpro-updates ms.date: 12/31/2017 diff --git a/windows/deployment/update/waas-restart.md b/windows/deployment/update/waas-restart.md index 83911247af..4ff1d88197 100644 --- a/windows/deployment/update/waas-restart.md +++ b/windows/deployment/update/waas-restart.md @@ -2,13 +2,11 @@ title: Manage device restarts after updates (Windows 10) description: Use Group Policy settings, mobile device management (MDM), or Registry to configure when devices will restart after a Windows 10 update is installed. ms.prod: windows-client -author: carmenf +author: mestew ms.localizationpriority: medium -ms.author: carmenf -manager: dougeby +ms.author: mstewart +manager: aaroncz ms.topic: article -ms.custom: - - seo-marvel-apr2020 ms.collection: highpri date: 09/22/2022 ms.technology: itpro-updates diff --git a/windows/deployment/update/waas-servicing-channels-windows-10-updates.md b/windows/deployment/update/waas-servicing-channels-windows-10-updates.md index 150ffc53ab..1b6ef429f8 100644 --- a/windows/deployment/update/waas-servicing-channels-windows-10-updates.md +++ b/windows/deployment/update/waas-servicing-channels-windows-10-updates.md @@ -2,14 +2,11 @@ title: Assign devices to servicing channels for Windows client updates description: Learn how to assign devices to servicing channels for Windows 10 updates locally, by using Group Policy, and by using MDM ms.prod: windows-client -author: aczechowski +author: mestew ms.localizationpriority: medium -ms.author: aaroncz -ms.reviewer: -manager: dougeby +ms.author: mstewart +manager: aaroncz ms.topic: article -ms.custom: - - seo-marvel-apr2020 ms.technology: itpro-updates ms.date: 12/31/2017 --- diff --git a/windows/deployment/update/waas-servicing-strategy-windows-10-updates.md b/windows/deployment/update/waas-servicing-strategy-windows-10-updates.md index 08636638a2..278ccbed60 100644 --- a/windows/deployment/update/waas-servicing-strategy-windows-10-updates.md +++ b/windows/deployment/update/waas-servicing-strategy-windows-10-updates.md @@ -2,11 +2,10 @@ title: Prepare a servicing strategy for Windows client updates description: A strong Windows client deployment strategy begins with establishing a simple, repeatable process for testing and deploying each feature update. ms.prod: windows-client -author: aczechowski +author: mestew ms.localizationpriority: medium -ms.author: aaroncz -ms.reviewer: -manager: dougeby +ms.author: mstewart +manager: aaroncz ms.topic: article ms.technology: itpro-updates ms.date: 12/31/2017 diff --git a/windows/deployment/update/waas-wufb-csp-mdm.md b/windows/deployment/update/waas-wufb-csp-mdm.md index fb55c40664..1d1bbb1115 100644 --- a/windows/deployment/update/waas-wufb-csp-mdm.md +++ b/windows/deployment/update/waas-wufb-csp-mdm.md @@ -2,11 +2,10 @@ title: Configure Windows Update for Business by using CSPs and MDM description: Walk-through demonstration of how to configure Windows Update for Business settings using Configuration Service Providers and MDM. ms.prod: windows-client -author: aczechowski +author: mestew ms.localizationpriority: medium -ms.author: aaroncz -ms.reviewer: -manager: dougeby +ms.author: mstewart +manager: aaroncz ms.topic: article ms.technology: itpro-updates ms.date: 12/31/2017 diff --git a/windows/deployment/update/waas-wufb-group-policy.md b/windows/deployment/update/waas-wufb-group-policy.md index fc123bcbb6..286ed2119c 100644 --- a/windows/deployment/update/waas-wufb-group-policy.md +++ b/windows/deployment/update/waas-wufb-group-policy.md @@ -2,12 +2,12 @@ title: Configure Windows Update for Business via Group Policy description: Walk-through demonstration of how to configure Windows Update for Business settings using Group Policy. ms.prod: windows-client -author: aczechowski +author: mestew ms.localizationpriority: medium -ms.author: aaroncz +ms.author: mstewart ms.collection: - highpri -manager: dougeby +manager: aaroncz ms.topic: article ms.technology: itpro-updates ms.date: 12/31/2017 diff --git a/windows/deployment/update/windows-as-a-service.md b/windows/deployment/update/windows-as-a-service.md index 4781231061..9ce2940f5d 100644 --- a/windows/deployment/update/windows-as-a-service.md +++ b/windows/deployment/update/windows-as-a-service.md @@ -3,11 +3,10 @@ title: Windows as a service ms.prod: windows-client ms.topic: article ms.manager: dougeby -author: aczechowski -ms.author: aaroncz +author: mestew +ms.author: mstewart description: Discover the latest news articles, videos, and podcasts about Windows as a service. Find resources for using Windows as a service within your organization. -ms.reviewer: -manager: dougeby +manager: aaroncz ms.localizationpriority: high ms.technology: itpro-updates ms.date: 12/31/2017 diff --git a/windows/deployment/update/windows-update-error-reference.md b/windows/deployment/update/windows-update-error-reference.md index 5c1e95ca70..2280794391 100644 --- a/windows/deployment/update/windows-update-error-reference.md +++ b/windows/deployment/update/windows-update-error-reference.md @@ -2,13 +2,12 @@ title: Windows Update error code list by component description: Learn about reference information for Windows Update error codes, including automatic update errors, UI errors, and reporter errors. ms.prod: windows-client -author: aczechowski -ms.author: aaroncz -manager: dougeby +author: mestew +ms.author: mstewart +manager: aaroncz ms.localizationpriority: medium ms.date: 09/18/2018 ms.topic: article -ms.custom: seo-marvel-apr2020 ms.technology: itpro-updates --- diff --git a/windows/deployment/update/windows-update-logs.md b/windows/deployment/update/windows-update-logs.md index c2bc7fce94..d1fc86d90c 100644 --- a/windows/deployment/update/windows-update-logs.md +++ b/windows/deployment/update/windows-update-logs.md @@ -2,11 +2,10 @@ title: Windows Update log files description: Learn about the Windows Update log files and how to merge and convert Windows Update trace files (.etl files) into a single readable WindowsUpdate.log file. ms.prod: windows-client -author: aczechowski -ms.author: aaroncz -manager: dougeby +author: mestew +ms.author: mstewart +manager: aaroncz ms.topic: article -ms.custom: seo-marvel-apr2020 ms.collection: highpri ms.technology: itpro-updates ms.date: 12/31/2017 diff --git a/windows/deployment/update/windows-update-overview.md b/windows/deployment/update/windows-update-overview.md index 223d10783e..cf56c12408 100644 --- a/windows/deployment/update/windows-update-overview.md +++ b/windows/deployment/update/windows-update-overview.md @@ -2,9 +2,9 @@ title: Get started with Windows Update description: An overview of learning resources for Windows Update, including documents on architecture, log files, and common errors. ms.prod: windows-client -author: aczechowski -ms.author: aaroncz -manager: dougeby +author: mestew +ms.author: mstewart +manager: aaroncz ms.date: 09/18/2018 ms.topic: article ms.technology: itpro-updates diff --git a/windows/deployment/update/windows-update-security.md b/windows/deployment/update/windows-update-security.md index 0ad5f772c7..9cf0c08919 100644 --- a/windows/deployment/update/windows-update-security.md +++ b/windows/deployment/update/windows-update-security.md @@ -1,6 +1,5 @@ --- title: Windows Update security -ms.reviewer: manager: aaroncz description: Overview of the security for Windows Update. ms.prod: windows-client diff --git a/windows/deployment/update/wufb-compliancedeadlines.md b/windows/deployment/update/wufb-compliancedeadlines.md index 05d34805c3..2c627d3a6e 100644 --- a/windows/deployment/update/wufb-compliancedeadlines.md +++ b/windows/deployment/update/wufb-compliancedeadlines.md @@ -1,13 +1,11 @@ --- title: Enforce compliance deadlines with policies in Windows Update for Business (Windows 10) description: This article contains information on how to enforce compliance deadlines using Windows Update for Business. -ms.custom: seo-marvel-apr2020 ms.prod: windows-client -author: aczechowski +author: mestew ms.localizationpriority: medium -ms.author: aaroncz -ms.reviewer: -manager: dougeby +ms.author: mstewart +manager: aaroncz ms.topic: article ms.technology: itpro-updates ms.date: 12/31/2017 diff --git a/windows/deployment/update/wufb-reports-admin-center.md b/windows/deployment/update/wufb-reports-admin-center.md index a59cc0511f..0ba338dd97 100644 --- a/windows/deployment/update/wufb-reports-admin-center.md +++ b/windows/deployment/update/wufb-reports-admin-center.md @@ -1,6 +1,6 @@ --- title: Microsoft 365 admin center software updates page -manager: dougeby +manager: aaroncz description: Microsoft admin center populates Windows Update for Business reports data into the software updates page. ms.prod: windows-client author: mestew diff --git a/windows/deployment/update/wufb-reports-configuration-intune.md b/windows/deployment/update/wufb-reports-configuration-intune.md index 5f07d75c3e..1f773ef7d8 100644 --- a/windows/deployment/update/wufb-reports-configuration-intune.md +++ b/windows/deployment/update/wufb-reports-configuration-intune.md @@ -1,6 +1,5 @@ --- title: Configuring Microsoft Intune devices for Windows Update for Business reports -ms.reviewer: manager: aaroncz description: Configuring devices that are enrolled in Microsoft Intune for Windows Update for Business reports ms.prod: windows-client diff --git a/windows/deployment/update/wufb-reports-configuration-manual.md b/windows/deployment/update/wufb-reports-configuration-manual.md index d2e5f13df1..0ee8a75bb0 100644 --- a/windows/deployment/update/wufb-reports-configuration-manual.md +++ b/windows/deployment/update/wufb-reports-configuration-manual.md @@ -1,7 +1,6 @@ --- title: Manually configuring devices for Windows Update for Business reports -ms.reviewer: -manager: dougeby +manager: aaroncz description: How to manually configure devices for Windows Update for Business reports ms.prod: windows-client author: mestew diff --git a/windows/deployment/update/wufb-reports-configuration-script.md b/windows/deployment/update/wufb-reports-configuration-script.md index c3213f8a7d..784ab095bd 100644 --- a/windows/deployment/update/wufb-reports-configuration-script.md +++ b/windows/deployment/update/wufb-reports-configuration-script.md @@ -1,7 +1,6 @@ --- title: Windows Update for Business reports configuration script -ms.reviewer: -manager: dougeby +manager: aaroncz description: Downloading and using the Windows Update for Business reports configuration script ms.prod: windows-client author: mestew diff --git a/windows/deployment/update/wufb-reports-enable.md b/windows/deployment/update/wufb-reports-enable.md index 7550754b01..4cecd5ccdd 100644 --- a/windows/deployment/update/wufb-reports-enable.md +++ b/windows/deployment/update/wufb-reports-enable.md @@ -1,7 +1,6 @@ --- title: Enable Windows Update for Business reports -ms.reviewer: -manager: dougeby +manager: aaroncz description: How to enable Windows Update for Business reports through the Azure portal ms.prod: windows-client author: mestew diff --git a/windows/deployment/update/wufb-reports-help.md b/windows/deployment/update/wufb-reports-help.md index 982e826da1..378595d1f7 100644 --- a/windows/deployment/update/wufb-reports-help.md +++ b/windows/deployment/update/wufb-reports-help.md @@ -1,7 +1,6 @@ --- title: Windows Update for Business reports feedback, support, and troubleshooting -ms.reviewer: -manager: dougeby +manager: aaroncz description: Windows Update for Business reports support information. ms.prod: windows-client author: mestew diff --git a/windows/deployment/update/wufb-reports-overview.md b/windows/deployment/update/wufb-reports-overview.md index 6653c0c587..aa140f9778 100644 --- a/windows/deployment/update/wufb-reports-overview.md +++ b/windows/deployment/update/wufb-reports-overview.md @@ -1,7 +1,6 @@ --- title: Windows Update for Business reports overview -ms.reviewer: -manager: dougeby +manager: aaroncz description: Overview of Windows Update for Business reports to explain what it's used for and the cloud services it relies on. ms.prod: windows-client author: mestew diff --git a/windows/deployment/update/wufb-reports-prerequisites.md b/windows/deployment/update/wufb-reports-prerequisites.md index 9159f0c74d..cbd081c2c7 100644 --- a/windows/deployment/update/wufb-reports-prerequisites.md +++ b/windows/deployment/update/wufb-reports-prerequisites.md @@ -1,7 +1,6 @@ --- title: Windows Update for Business reports prerequisites -ms.reviewer: -manager: dougeby +manager: aaroncz description: Prerequisites for Windows Update for Business reports ms.prod: windows-client author: mestew diff --git a/windows/deployment/update/wufb-reports-schema-ucclient.md b/windows/deployment/update/wufb-reports-schema-ucclient.md index b3606b35cc..3b460f113f 100644 --- a/windows/deployment/update/wufb-reports-schema-ucclient.md +++ b/windows/deployment/update/wufb-reports-schema-ucclient.md @@ -1,7 +1,6 @@ --- title: Windows Update for Business reports Data Schema - UCClient -ms.reviewer: -manager: dougeby +manager: aaroncz description: UCClient schema ms.prod: windows-client author: mestew diff --git a/windows/deployment/update/wufb-reports-schema-ucclientreadinessstatus.md b/windows/deployment/update/wufb-reports-schema-ucclientreadinessstatus.md index 3505563197..de73ebfc5b 100644 --- a/windows/deployment/update/wufb-reports-schema-ucclientreadinessstatus.md +++ b/windows/deployment/update/wufb-reports-schema-ucclientreadinessstatus.md @@ -1,7 +1,6 @@ --- title: Windows Update for Business reports Data Schema - UCClientReadinessStatus -ms.reviewer: -manager: dougeby +manager: aaroncz description: UCClientReadinessStatus schema ms.prod: windows-client author: mestew diff --git a/windows/deployment/update/wufb-reports-schema-ucclientupdatestatus.md b/windows/deployment/update/wufb-reports-schema-ucclientupdatestatus.md index 826add8c73..6bd8442700 100644 --- a/windows/deployment/update/wufb-reports-schema-ucclientupdatestatus.md +++ b/windows/deployment/update/wufb-reports-schema-ucclientupdatestatus.md @@ -1,7 +1,6 @@ --- title: Windows Update for Business reports Data Schema - UCClientUpdateStatus -ms.reviewer: -manager: dougeby +manager: aaroncz description: UCClientUpdateStatus schema ms.prod: windows-client author: mestew diff --git a/windows/deployment/update/wufb-reports-schema-ucdevicealert.md b/windows/deployment/update/wufb-reports-schema-ucdevicealert.md index 79f1a9ec5b..78efd1d68b 100644 --- a/windows/deployment/update/wufb-reports-schema-ucdevicealert.md +++ b/windows/deployment/update/wufb-reports-schema-ucdevicealert.md @@ -1,7 +1,6 @@ --- title: Windows Update for Business reports Data Schema - UCDeviceAlert -ms.reviewer: -manager: dougeby +manager: aaroncz description: UCDeviceAlert schema ms.prod: windows-client author: mestew diff --git a/windows/deployment/update/wufb-reports-schema-ucdoaggregatedstatus.md b/windows/deployment/update/wufb-reports-schema-ucdoaggregatedstatus.md index 796bbb75e2..25c5d1ae59 100644 --- a/windows/deployment/update/wufb-reports-schema-ucdoaggregatedstatus.md +++ b/windows/deployment/update/wufb-reports-schema-ucdoaggregatedstatus.md @@ -1,11 +1,11 @@ --- title: Windows Update for Business reports Data Schema - UCDOAggregatedStatus -ms.reviewer: -manager: naengler +ms.reviewer: carmenf +manager: aaroncz description: UCDOAggregatedStatus schema ms.prod: windows-client -author: cmknox -ms.author: carmenf +author: mestew +ms.author: mstewart ms.topic: reference ms.date: 11/17/2022 ms.technology: itpro-updates diff --git a/windows/deployment/update/wufb-reports-schema-ucdostatus.md b/windows/deployment/update/wufb-reports-schema-ucdostatus.md index 9eadfa7eb6..7897c27f1c 100644 --- a/windows/deployment/update/wufb-reports-schema-ucdostatus.md +++ b/windows/deployment/update/wufb-reports-schema-ucdostatus.md @@ -1,11 +1,11 @@ --- title: Windows Update for Business reports Data Schema - UCDOStatus -ms.reviewer: -manager: naengler +ms.reviewer: carmenf +manager: aaroncz description: UCDOStatus schema ms.prod: windows-client -author: cmknox -ms.author: carmenf +author: mestew +ms.author: mstewart ms.topic: reference ms.date: 11/17/2022 ms.technology: itpro-updates diff --git a/windows/deployment/update/wufb-reports-schema-ucserviceupdatestatus.md b/windows/deployment/update/wufb-reports-schema-ucserviceupdatestatus.md index bc5677f9d8..87184d6464 100644 --- a/windows/deployment/update/wufb-reports-schema-ucserviceupdatestatus.md +++ b/windows/deployment/update/wufb-reports-schema-ucserviceupdatestatus.md @@ -1,7 +1,6 @@ --- title: Windows Update for Business reports Data Schema - UCServiceUpdateStatus -ms.reviewer: -manager: dougeby +manager: aaroncz description: UCServiceUpdateStatus schema ms.prod: windows-client author: mestew diff --git a/windows/deployment/update/wufb-reports-schema-ucupdatealert.md b/windows/deployment/update/wufb-reports-schema-ucupdatealert.md index fa14e12358..f00e02af9e 100644 --- a/windows/deployment/update/wufb-reports-schema-ucupdatealert.md +++ b/windows/deployment/update/wufb-reports-schema-ucupdatealert.md @@ -1,7 +1,6 @@ --- title: Windows Update for Business reports Data Schema - UCUpdateAlert -ms.reviewer: -manager: dougeby +manager: aaroncz description: UCUpdateAlert schema ms.prod: windows-client author: mestew diff --git a/windows/deployment/update/wufb-reports-schema.md b/windows/deployment/update/wufb-reports-schema.md index 1afd09b646..cbcae6c319 100644 --- a/windows/deployment/update/wufb-reports-schema.md +++ b/windows/deployment/update/wufb-reports-schema.md @@ -1,7 +1,6 @@ --- title: Windows Update for Business reports data schema -ms.reviewer: -manager: dougeby +manager: aaroncz description: An overview of Windows Update for Business reports data schema ms.prod: windows-client author: mestew diff --git a/windows/deployment/update/wufb-reports-use.md b/windows/deployment/update/wufb-reports-use.md index eb4d607c10..6b58c8cffb 100644 --- a/windows/deployment/update/wufb-reports-use.md +++ b/windows/deployment/update/wufb-reports-use.md @@ -1,7 +1,6 @@ --- title: Use the Windows Update for Business reports data -ms.reviewer: -manager: dougeby +manager: aaroncz description: How to use the Windows Update for Business reports data for custom solutions using tools like Azure Monitor Logs. ms.prod: windows-client author: mestew diff --git a/windows/deployment/update/wufb-reports-workbook.md b/windows/deployment/update/wufb-reports-workbook.md index 585d03adb9..c6ddd21005 100644 --- a/windows/deployment/update/wufb-reports-workbook.md +++ b/windows/deployment/update/wufb-reports-workbook.md @@ -1,7 +1,6 @@ --- title: Use the workbook for Windows Update for Business reports -ms.reviewer: -manager: dougeby +manager: aaroncz description: How to use the Windows Update for Business reports workbook. ms.prod: windows-client author: mestew diff --git a/windows/deployment/update/wufb-wsus.md b/windows/deployment/update/wufb-wsus.md index 2d25f4fcc0..7feb6b10b2 100644 --- a/windows/deployment/update/wufb-wsus.md +++ b/windows/deployment/update/wufb-wsus.md @@ -2,10 +2,10 @@ title: Use Windows Update for Business and Windows Server Update Services (WSUS) together description: Learn how to use Windows Update for Business and WSUS together using the new scan source policy. ms.prod: windows-client -author: arcarley +author: mestew ms.localizationpriority: medium -ms.author: arcarley -manager: dougeby +ms.author: mstewart +manager: aaroncz ms.topic: article ms.technology: itpro-updates ms.date: 12/31/2017 diff --git a/windows/deployment/windows-10-subscription-activation.md b/windows/deployment/windows-10-subscription-activation.md index c34e8342eb..4f8562a41b 100644 --- a/windows/deployment/windows-10-subscription-activation.md +++ b/windows/deployment/windows-10-subscription-activation.md @@ -40,7 +40,7 @@ This article covers the following information: For more information on how to deploy Enterprise licenses, see [Deploy Windows Enterprise licenses](deploy-enterprise-licenses.md). > [!NOTE] -> Organizations that use the Subscription Activation feature to enable users to upgrade from one version of Windows to another and use Conditional Access policies to control access need to exclude the Universal Store Service APIs and Web Application, AppID 45a330b1-b1ec-4cc1-9161-9f03992aa49f, from their device compliance policy using **Select Excluded Cloud Apps**. +> Organizations that use the Subscription Activation feature to enable users to upgrade from one version of Windows to another and use Conditional Access policies to control access need to exclude the [Universal Store Service APIs and Web Application, AppID 45a330b1-b1ec-4cc1-9161-9f03992aa49f](/troubleshoot/azure/active-directory/verify-first-party-apps-sign-in#application-ids-of-commonly-used-microsoft-applications), from their device compliance policy using **Select Excluded Cloud Apps**. For more information about configuring exclusions in Conditional Access policies, see [Application exclusions](/azure/active-directory/conditional-access/howto-conditional-access-policy-all-users-mfa#application-exclusions). ## Subscription activation for Enterprise diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-fu-overview.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-fu-overview.md index 020359528b..ef3dba90f8 100644 --- a/windows/deployment/windows-autopatch/operate/windows-autopatch-fu-overview.md +++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-fu-overview.md @@ -30,8 +30,8 @@ For a device to be eligible for Windows feature updates as a part of Windows Aut | Deployed | Windows Autopatch doesn't update devices that haven't yet been deployed. | | Internet connectivity | Devices must have a steady internet connection, and access to Windows [update endpoints](../prepare/windows-autopatch-configure-network.md). | | Windows edition | Devices must be on a Windows edition supported by Windows Autopatch. For more information, see [Prerequisites](../prepare/windows-autopatch-prerequisites.md). | -| Mobile device management (MDM) policy conflict | Devices must not have deployed any policies that would prevent device management. For more information, see [Conflicting and unsupported policies](../operate/windows-autopatch-wqu-unsupported-policies.md). | -| Group policy conflict | Devices must not have group policies deployed which would prevent device management. For more information, see [Group policy](windows-autopatch-wqu-unsupported-policies.md#group-policy-and-other-policy-managers). | +| Mobile device management (MDM) policy conflict | Devices must not have deployed any policies that would prevent device management. For more information, see [Conflicting and unsupported policies](../references/windows-autopatch-wqu-unsupported-policies.md). | +| Group policy conflict | Devices must not have group policies deployed which would prevent device management. For more information, see [Group policy](../references/windows-autopatch-wqu-unsupported-policies.md#group-policy-and-other-policy-managers). | ## Windows feature update releases diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-maintain-environment.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-maintain-environment.md index c5a7514fc4..aa13524ff2 100644 --- a/windows/deployment/windows-autopatch/operate/windows-autopatch-maintain-environment.md +++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-maintain-environment.md @@ -26,7 +26,7 @@ After you've completed enrollment in Windows Autopatch, some management settings | Setting | Description | | ----- | ----- | -| Update rings for Windows 10 or later | For any update rings for Windows 10 or later policies you've created, exclude the **Modern Workplace Devices - All** Azure AD group from each policy. For more information, see [Create and assign update rings](/mem/intune/protect/windows-10-update-rings#create-and-assign-update-rings).

Windows Autopatch will also have created some update ring policies. all of which The policies will have "**Modern Workplace**" in the name. For example:

When you update your own policies, ensure that you don't exclude the **Modern Workplace Devices - All** Azure AD group from the policies that Windows Autopatch created.

**To resolve the Not ready result:**

After enrolling into Autopatch, make sure that any update ring policies you have **exclude** the **Modern Workplace Devices - All** Azure Active Directory (AD) group.For more information, see [Manage Windows 10 software updates in Intune](/mem/intune/protect/windows-update-for-business-configure).

**To resolve the Advisory result:**

  1. Make sure that any update ring policies you have **exclude** the **Modern Workplace Devices - All** Azure Active Directory (AD) group.
  2. If you have assigned Azure AD user groups to these policies, make sure that any update ring policies you have also **exclude** the **Modern Workplace - All** Azure AD group that you add your Windows Autopatch users to (or an equivalent group).

For more information, see [Manage Windows 10 software updates in Intune](/mem/intune/protect/windows-update-for-business-configure).

| +| Deployment rings for Windows 10 or later | For any deployment rings for Windows 10 or later policies you've created, exclude the **Modern Workplace Devices - All** Azure AD group from each policy. For more information, see [Create and assign deployment rings](/mem/intune/protect/windows-10-update-rings#create-and-assign-update-rings).

Windows Autopatch will also have created some update ring policies. all of which The policies will have "**Modern Workplace**" in the name. For example:

When you update your own policies, ensure that you don't exclude the **Modern Workplace Devices - All** Azure AD group from the policies that Windows Autopatch created.

**To resolve the Not ready result:**

After enrolling into Autopatch, make sure that any update ring policies you have **exclude** the **Modern Workplace Devices - All** Azure Active Directory (AD) group.For more information, see [Manage Windows 10 software updates in Intune](/mem/intune/protect/windows-update-for-business-configure).

**To resolve the Advisory result:**

  1. Make sure that any update ring policies you have **exclude** the **Modern Workplace Devices - All** Azure Active Directory (AD) group.
  2. If you have assigned Azure AD user groups to these policies, make sure that any update ring policies you have also **exclude** the **Modern Workplace - All** Azure AD group that you add your Windows Autopatch users to (or an equivalent group).

For more information, see [Manage Windows 10 software updates in Intune](/mem/intune/protect/windows-update-for-business-configure).

| ## Windows Autopatch configurations diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-microsoft-365-apps-enterprise.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-microsoft-365-apps-enterprise.md index 3089035470..ebe7cda8b7 100644 --- a/windows/deployment/windows-autopatch/operate/windows-autopatch-microsoft-365-apps-enterprise.md +++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-microsoft-365-apps-enterprise.md @@ -34,7 +34,7 @@ All devices registered for Windows Autopatch will receive updates from the [Mont Unlike Windows update, the Office CDN doesn't make the update available to all devices at once. Over the course of the release, the Office CDN gradually makes the update available to the whole population of devices. Windows Autopatch doesn't control the order in which updates are offered to devices across your estate. After the update has been downloaded, there's a seven day [update deadline](/deployoffice/configure-update-settings-microsoft-365-apps) that specifies how long the user has until the user must apply the update. -## Update rings +## Deployment rings Since the Office CDN determines when devices are offered updates, Windows Autopatch doesn't use rings to control the rollout of these updates. diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-update-management.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-update-management.md index 549d7d5bba..81dd91dbd5 100644 --- a/windows/deployment/windows-autopatch/operate/windows-autopatch-update-management.md +++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-update-management.md @@ -20,8 +20,8 @@ Keeping your devices up to date is a balance of speed and stability. Windows Aut | Software update workload | Description | | ----- | ----- | -| Windows quality update | Windows Autopatch uses four update rings to manage Windows quality updates. For more detailed information, see [Windows quality updates](../operate/windows-autopatch-wqu-overview.md). | -| Windows feature update | Windows Autopatch uses four update rings to manage Windows feature updates. For more detailed information, see [Windows feature updates](windows-autopatch-fu-overview.md). +| Windows quality update | Windows Autopatch uses four deployment rings to manage Windows quality updates. For more detailed information, see [Windows quality updates](../operate/windows-autopatch-wqu-overview.md). | +| Windows feature update | Windows Autopatch uses four deployment rings to manage Windows feature updates. For more detailed information, see [Windows feature updates](windows-autopatch-fu-overview.md). | Anti-virus definition | Updated with each scan. | | Microsoft 365 Apps for enterprise | For more information, see [Microsoft 365 Apps for enterprise](windows-autopatch-microsoft-365-apps-enterprise.md). | | Microsoft Edge | For more information, see [Microsoft Edge](../operate/windows-autopatch-edge.md). | diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-wqu-overview.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-wqu-overview.md index 2dbf3db0a5..fcf007a516 100644 --- a/windows/deployment/windows-autopatch/operate/windows-autopatch-wqu-overview.md +++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-wqu-overview.md @@ -48,7 +48,7 @@ To release updates to devices in a gradual manner, Windows Autopatch deploys a s > [!IMPORTANT] > Deploying deferral, deadline, or grace period policies which conflict with Autopatch's policies will cause a device to be considered ineligible for management, it will still receive policies from Windows Autopatch that are not in conflict, but may not function as designed. These devices will be marked as ineligible in our device reporting and will not count towards our [service level objective](#service-level-objective). -Windows Autopatch configures these policies differently across update rings to gradually release the update to devices in your estate. Devices in the Test ring receive changes first and devices in the Broad ring receive changes last. For more information, see [Windows Autopatch deployment rings](../operate/windows-autopatch-update-management.md#windows-autopatch-deployment-rings). +Windows Autopatch configures these policies differently across deployment rings to gradually release the update to devices in your estate. Devices in the Test ring receive changes first and devices in the Broad ring receive changes last. For more information, see [Windows Autopatch deployment rings](../operate/windows-autopatch-update-management.md#windows-autopatch-deployment-rings). :::image type="content" source="../media/release-process-timeline.png" alt-text="Release process timeline" lightbox="../media/release-process-timeline.png"::: diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-wqu-signals.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-wqu-signals.md index 2a4c33b67a..b27a0d0447 100644 --- a/windows/deployment/windows-autopatch/operate/windows-autopatch-wqu-signals.md +++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-wqu-signals.md @@ -1,7 +1,7 @@ --- title: Windows quality update signals description: This article explains the Windows quality update signals -ms.date: 05/30/2022 +ms.date: 01/24/2023 ms.prod: windows-client ms.technology: itpro-updates ms.topic: conceptual @@ -57,5 +57,3 @@ Autopatch monitors the following reliability signals: | Microsoft Teams reliability | Tracks the number of Microsoft Teams crashes and freezes per device. | When the update is released to the First ring, the service crosses the 500 device threshold. Therefore, Autopatch can to detect regressions, which are common to all customers. At this point in the release, we'll decide if we need to change the release schedule or pause for all customers. - -Once your tenant reaches 500 devices, Windows Autopatch starts generating recommendations specific to your devices. Based on this information, the service starts developing insights specific to your tenant allowing a customized response to what's happening in your environment. diff --git a/windows/deployment/windows-autopatch/overview/windows-autopatch-faq.yml b/windows/deployment/windows-autopatch/overview/windows-autopatch-faq.yml index fdb9b1f891..e51bf1f82a 100644 --- a/windows/deployment/windows-autopatch/overview/windows-autopatch-faq.yml +++ b/windows/deployment/windows-autopatch/overview/windows-autopatch-faq.yml @@ -81,8 +81,8 @@ sections: questions: - question: What systems does Windows Autopatch update? answer: | - - Windows 10/11 quality updates: Windows Autopatch manages all aspects of update rings. - - Windows 10/11 feature updates: Windows Autopatch manages all aspects of update rings. + - Windows 10/11 quality updates: Windows Autopatch manages all aspects of deployment rings. + - Windows 10/11 feature updates: Windows Autopatch manages all aspects of deployment rings. - Microsoft 365 Apps for enterprise updates: All devices registered for Windows Autopatch will receive updates from the Monthly Enterprise Channel. - Microsoft Edge: Windows Autopatch configures eligible devices to benefit from Microsoft Edge's progressive rollouts on the Stable channel and will provide support for issues with Microsoft Edge updates. - Microsoft Teams: Windows Autopatch allows eligible devices to benefit from the standard automatic update channels and will provide support for issues with Teams updates. diff --git a/windows/deployment/windows-autopatch/overview/windows-autopatch-overview.md b/windows/deployment/windows-autopatch/overview/windows-autopatch-overview.md index 88cdfa1b6b..8ed02530ce 100644 --- a/windows/deployment/windows-autopatch/overview/windows-autopatch-overview.md +++ b/windows/deployment/windows-autopatch/overview/windows-autopatch-overview.md @@ -27,7 +27,7 @@ Rather than maintaining complex digital infrastructure, businesses want to focus - **Optimize your IT admin resources**: By automating routine endpoint updates, IT pros have more time to create value. - **On-premises infrastructure**: Transitioning to the world of software as a service (SaaS) allows you to minimize your investment in on-premises hardware since updates are delivered from the cloud. - **Onboard new services**: Windows Autopatch is scoped to make it easy to enroll and minimizes the time investment from your IT Admins to get started. -- **Minimize end user disruption**: By releasing in sequential update rings, and responding to reliability and compatibility signals, user disruptions due to updates are minimized. +- **Minimize end user disruption**: By releasing in sequential deployment rings, and responding to reliability and compatibility signals, user disruptions due to updates are minimized. Windows Autopatch helps you minimize the involvement of your scarce IT resources in the planning and deployment of updates for Windows, Microsoft 365 Apps, Microsoft Edge or Teams. By crafting careful rollout sequences and communicating with you throughout the release, your IT Admins can focus on other activities and tasks. diff --git a/windows/deployment/windows-autopatch/prepare/windows-autopatch-enroll-tenant.md b/windows/deployment/windows-autopatch/prepare/windows-autopatch-enroll-tenant.md index 2dfa7a8912..b091a73a97 100644 --- a/windows/deployment/windows-autopatch/prepare/windows-autopatch-enroll-tenant.md +++ b/windows/deployment/windows-autopatch/prepare/windows-autopatch-enroll-tenant.md @@ -51,7 +51,7 @@ The following are the Microsoft Intune settings: | Check | Description | | ----- | ----- | -| Update rings for Windows 10 or later | Verifies that Intune's Update rings for Windows 10 or later policy doesn't target all users or all devices. Policies of this type shouldn't target any Windows Autopatch devices. For more information, see [Configure update rings for Windows 10 and later in Intune](/mem/intune/protect/windows-10-update-rings). | +| Deployment rings for Windows 10 or later | Verifies that Intune's deployment rings for Windows 10 or later policy doesn't target all users or all devices. Policies of this type shouldn't target any Windows Autopatch devices. For more information, see [Configure deployment rings for Windows 10 and later in Intune](/mem/intune/protect/windows-10-update-rings). | | Unlicensed admin | Verifies that this setting is enabled to avoid a "lack of permissions" error when we interact with your Azure Active Directory (AD) organization. For more information, see [Unlicensed admins in Microsoft Intune](/mem/intune/fundamentals/unlicensed-admins). | ### Azure Active Directory settings diff --git a/windows/deployment/windows-autopatch/prepare/windows-autopatch-fix-issues.md b/windows/deployment/windows-autopatch/prepare/windows-autopatch-fix-issues.md index 891576dd03..8e9d0f1a63 100644 --- a/windows/deployment/windows-autopatch/prepare/windows-autopatch-fix-issues.md +++ b/windows/deployment/windows-autopatch/prepare/windows-autopatch-fix-issues.md @@ -45,9 +45,9 @@ This setting must be turned on to avoid a "lack of permissions" error when we in | ----- | ----- | | Not ready | Allow access to unlicensed admins should be turned on. Without this setting enabled, errors can occur when we try to access your Azure AD organization for service. You can safely enable this setting without worrying about security implications. The scope of access is defined by the roles assigned to users, including our operations staff.

For more information, see [Unlicensed admins](/mem/intune/fundamentals/unlicensed-admins). | -### Update rings for Windows 10 or later +### Deployment rings for Windows 10 or later -Your "Windows 10 update ring" policy in Intune must not target any Windows Autopatch devices. +Your "Windows 10 deployment ring" policy in Intune must not target any Windows Autopatch devices. | Result | Meaning | | ----- | ----- | diff --git a/windows/deployment/windows-autopatch/references/windows-autopatch-changes-to-tenant.md b/windows/deployment/windows-autopatch/references/windows-autopatch-changes-to-tenant.md index ce916ff862..3b6cc306de 100644 --- a/windows/deployment/windows-autopatch/references/windows-autopatch-changes-to-tenant.md +++ b/windows/deployment/windows-autopatch/references/windows-autopatch-changes-to-tenant.md @@ -1,7 +1,7 @@ --- title: Changes made at tenant enrollment description: This reference article details the changes made to your tenant when enrolling into Windows Autopatch -ms.date: 12/01/2022 +ms.date: 01/24/2023 ms.prod: windows-client ms.technology: itpro-updates ms.topic: reference @@ -56,15 +56,13 @@ Windows Autopatch will create Azure Active Directory groups that are required to - Windows Autopatch - Set MDM to Win Over GPO - Windows Autopatch - Data Collection -- Windows Autopatch-Window Update Detection Frequency | Policy name | Policy description | Properties | Value | | ----- | ----- | ----- | ----- | | Windows Autopatch - Set MDM to Win Over GPO | Sets mobile device management (MDM) to win over GPO

Assigned to:

| [MDM Wins Over GP](/windows/client-management/mdm/policy-csp-controlpolicyconflict#controlpolicyconflict-MDMWinsOverGP) | The MDM policy is used and the GP policy is blocked | | Windows Autopatch - Data Collection | Allows diagnostic data from this device to be processed by Microsoft Managed Desktop and Telemetry settings for Windows devices.

Assigned to:

|
  1. [Configure Telemetry Opt In Change Notification](/windows/client-management/mdm/policy-csp-system#system-configuretelemetryoptinchangenotification)
  2. [Configure Telemetry Opt In Settings Ux](/windows/client-management/mdm/policy-csp-system#system-configuretelemetryoptinsettingsux)
  3. [Allow Telemetry](/windows/client-management/mdm/policy-csp-system#system-allowtelemetry)
  4. [Limit Enhanced Diagnostic Data Windows Analytics](/windows/client-management/mdm/policy-csp-system#system-limitenhanceddiagnosticdatawindowsanalytics)
  5. [Limit Dump Collection](/windows/client-management/mdm/policy-csp-system#system-limitdumpcollection)
  6. [Limit Diagnostic Log Collection](/windows/client-management/mdm/policy-csp-system#system-limitdiagnosticlogcollection)
|
  1. Enable telemetry change notifications
  2. Enable Telemetry opt-in Settings
  3. Full
  4. Enabled
  5. Enabled
  6. Enabled
| -| Windows Autopatch - Windows Update Detection Frequency | Sets Windows update detection frequency

Assigned to:

| [./Vendor/MSFT/Policy/Config/Update/DetectionFrequency](/windows/client-management/mdm/policy-csp-update#update-detectionfrequency)| 4 | -## Update rings for Windows 10 and later +## Deployment rings for Windows 10 and later - Modern Workplace Update Policy [Test]-[Windows Autopatch] - Modern Workplace Update Policy [First]-[Windows Autopatch] diff --git a/windows/deployment/windows-autopatch/references/windows-autopatch-wqu-unsupported-policies.md b/windows/deployment/windows-autopatch/references/windows-autopatch-wqu-unsupported-policies.md index 1c19a4bac4..09842260a5 100644 --- a/windows/deployment/windows-autopatch/references/windows-autopatch-wqu-unsupported-policies.md +++ b/windows/deployment/windows-autopatch/references/windows-autopatch-wqu-unsupported-policies.md @@ -14,7 +14,7 @@ msreviewer: adnich # Windows update policies -## Update rings for Windows 10 and later +## Deployment rings for Windows 10 and later The following policies contain settings which apply to both Windows quality and feature updates. After onboarding there will be four of these policies in your tenant with the following naming convention: @@ -36,7 +36,7 @@ The following policies contain settings which apply to both Windows quality and | Setting name | Test | First | Fast | Broad | | ----- | ----- | ----- | ----- | ----- | -| Automatic update behaviour | Reset to default | Reset to default | Reset to default | Reset to default | +| Automatic update behavior | Reset to default | Reset to default | Reset to default | Reset to default | | Restart checks | Allow | Allow | Allow | Allow | | Option to pause updates | Disable | Disable | Disable | Disable | | Option to check for Windows updates | Default | Default | Default | Default | diff --git a/windows/deployment/windows-autopatch/whats-new/windows-autopatch-whats-new-2023.md b/windows/deployment/windows-autopatch/whats-new/windows-autopatch-whats-new-2023.md index bb56fa10e7..cbc9b52878 100644 --- a/windows/deployment/windows-autopatch/whats-new/windows-autopatch-whats-new-2023.md +++ b/windows/deployment/windows-autopatch/whats-new/windows-autopatch-whats-new-2023.md @@ -31,4 +31,5 @@ Minor corrections such as typos, style, or formatting issues aren't listed. | Message center post number | Description | | ----- | ----- | +| [MC500889](https://admin.microsoft.com/adminportal/home#/MessageCenter) | January 2023 Windows Autopatch baseline configuration update | | [MC494386](https://admin.microsoft.com/adminportal/home#/MessageCenter) | January 2023 (2023.01 B) Windows quality update deployment | diff --git a/windows/privacy/changes-to-windows-diagnostic-data-collection.md b/windows/privacy/changes-to-windows-diagnostic-data-collection.md index 34066bed6d..3c972e9333 100644 --- a/windows/privacy/changes-to-windows-diagnostic-data-collection.md +++ b/windows/privacy/changes-to-windows-diagnostic-data-collection.md @@ -67,12 +67,7 @@ For more info, see [Configure Windows diagnostic data in your organization](conf ## Services that rely on Enhanced diagnostic data -Customers who use services that depend on Windows diagnostic data, such as Microsoft Managed Desktop or Desktop Analytics, may be impacted by the behavioral changes when they're released. These services will be updated to address these changes and guidance will be published on how to configure them properly. - -The following articles provide information on the current configurations: - -- [Microsoft Managed Desktop](/microsoft-365/managed-desktop/service-description/device-policies#windows-diagnostic-data) -- [Desktop Analytics](/mem/configmgr/desktop-analytics/overview) +Customers who use services that depend on Windows diagnostic data, such as [Microsoft Managed Desktop](/microsoft-365/managed-desktop/service-description/device-policies#windows-diagnostic-data), may be impacted by the behavioral changes when they're released. These services will be updated to address these changes and guidance will be published on how to configure them properly. ## Significant changes coming to the Windows diagnostic data processor configuration @@ -95,6 +90,7 @@ From a compliance standpoint, this change means that Microsoft will be the proce For Windows devices with diagnostic data turned on and that are joined to an [Azure AD tenant with billing address](/azure/cost-management-billing/manage/change-azure-account-profile) outside of the EU and EFTA, to enable the processor configuration option, the organization must sign up for any of the following enterprise services, which rely on diagnostic data: - [Update Compliance](/windows/deployment/update/update-compliance-monitor) +- [Windows Update for Business reports](/windows/deployment/update/wufb-reports-overview) - [Windows Update for Business deployment service](/windows/deployment/update/deployment-service-overview) - [Microsoft Managed Desktop](/managed-desktop/intro/) - [Endpoint analytics (in Microsoft Intune)](/mem/analytics/overview) @@ -129,4 +125,5 @@ As part of this change, the following policies will no longer be supported to co - Allow Desktop Analytics Processing - Allow Update Compliance Processing - Allow WUfB Cloud Processing + - Allow Microsoft Managed Desktop Processing - Configure the Commercial ID diff --git a/windows/privacy/configure-windows-diagnostic-data-in-your-organization.md b/windows/privacy/configure-windows-diagnostic-data-in-your-organization.md index ac1febdc26..669941fd55 100644 --- a/windows/privacy/configure-windows-diagnostic-data-in-your-organization.md +++ b/windows/privacy/configure-windows-diagnostic-data-in-your-organization.md @@ -25,7 +25,7 @@ ms.topic: conceptual - Surface Hub - Hololens -This topic describes the types of Windows diagnostic data sent back to Microsoft and the ways you can manage it within your organization. Microsoft uses the data to quickly identify and address issues affecting its customers. +This article describes the types of Windows diagnostic data sent back to Microsoft and the ways you can manage it within your organization. Microsoft uses the data to quickly identify and address issues affecting its customers. ## Overview @@ -301,32 +301,72 @@ Use [Policy Configuration Service Provider (CSP)](/windows/client-management/mdm ## Enable Windows diagnostic data processor configuration -> [!IMPORTANT] -> There are some significant changes planned for diagnostic data processor configuration. To learn more, [review this information](changes-to-windows-diagnostic-data-collection.md#significant-changes-coming-to-the-windows-diagnostic-data-processor-configuration). - The Windows diagnostic data processor configuration enables you to be the controller, as defined by the European Union General Data Protection Regulation (GDPR), for the Windows diagnostic data collected from your Windows devices that meet the configuration requirements. ### Prerequisites - Use a supported version of Windows 10 or Windows 11 -- The following editions are supported: +- The following editions are supported: - Enterprise - Professional - Education - The device must be joined to Azure Active Directory (can be a hybrid Azure AD join). -For the best experience, use the most current build of any operating system specified above. Configuration functionality and availability may vary on older systems. See [Lifecycle Policy](/lifecycle/products/windows-10-enterprise-and-education) +> [!NOTE] +> In all cases, enrollment in the Windows diagnostic data processor configuration requires a device to be joined to an Azure AD tenant. If a device isn't properly enrolled, Microsoft will act as the controller for Windows diagnostic data in accordance with the [Microsoft Privacy Statement](https://privacy.microsoft.com/privacystatement) and the [Data Protection Addendum](https://www.microsoft.com/licensing/docs/view/Microsoft-Products-and-Services-Data-Protection-Addendum-DPA) terms won't apply. + +For the best experience, use the most current build of any operating system specified above. Configuration functionality and availability may vary on older systems. For release information, see [Windows 10 Enterprise and Education](/lifecycle/products/windows-10-enterprise-and-education) and [Windows 11 Enterprise and Education](/lifecycle/products/windows-11-enterprise-and-education) on the Microsoft Lifecycle Policy site. The diagnostic data setting on the device should be set to Required diagnostic data or higher, and the following endpoints need to be reachable: -- v10c.events.data.microsoft.com -- umwatsonc.events.data.microsoft.com -- kmwatsonc.events.data.microsoft.com +- us-v10c.events.data.microsoft.com (eu-v10c.events.data.microsoft.com for tenants with billing address in the [EU Data Boundary](/privacy/eudb/eu-data-boundary-learn#eu-data-boundary-countries-and-datacenter-locations)) +- umwatsonc.events.data.microsoft.com (eu-watsonc.events.data.microsoft.com for tenants with billing address in the [EU Data Boundary](/privacy/eudb/eu-data-boundary-learn#eu-data-boundary-countries-and-datacenter-locations)) - settings-win.data.microsoft.com - *.blob.core.windows.net +>[!Note] +> - Windows diagnostic data collected from a device before it was enabled with Windows diagnostic data processor configuration will be deleted when this configuration is enabled. +> - When you enable devices with the Windows diagnostic data processor configuration, users may continue to submit feedback through various channels such as Windows feedback hub or Edge feedback. However, the feedback data is not subject to the terms of the Windows diagnostic data processor configuration. If this is not desired, we recommend that you disable feedback using the available policies or application management solutions. + ### Enabling Windows diagnostic data processor configuration +> [!NOTE] +> The information in this section applies to the following versions of Windows: +> - Windows 10, versions 20H2, 21H2, 22H2, and newer +> - Windows 11, versions 21H2, 22H2, and newer + +Starting with the January 2023 preview cumulative update, how you enable the processor configuration option depends on the billing address of the Azure AD tenant to which your devices are joined. + +#### Devices in Azure AD tenants with a billing address in the European Union (EU) or European Free Trade Association (EFTA) + +For Windows devices with diagnostic data turned on and that are joined to an [Azure AD tenant with billing address](/azure/cost-management-billing/manage/change-azure-account-profile) in the EU or EFTA, the Windows diagnostic data for that device will be automatically configured for the processor option. The Windows diagnostic data for those devices will be processed in Europe. + +> [!NOTE] +> The Windows diagnostic data processor configuration has components for which work is in progress to be included in the EU Data Boundary, but completion of this work is delayed beyond January 1, 2023. These components will be included in the EU Data Boundary in the coming months. In the meantime, Microsoft will temporarily transfer data out of the EU Data Boundary as part of service operations to ensure uninterrupted operation of the services customers signed up for. + +From a compliance standpoint, this change means that Microsoft will be the processor and the organization will be the controller of the Windows diagnostic data. IT admins for those organizations will become responsible for responding to their users’ [data subject requests](/compliance/regulatory/gdpr-dsr-windows). + +#### Devices in Azure AD tenants with a billing address outside of the EU and EFTA + +For Windows devices with diagnostic data turned on and that are joined to an [Azure AD tenant with billing address](/azure/cost-management-billing/manage/change-azure-account-profile) outside of the EU and EFTA, to enable the processor configuration option, the organization must sign up for any of the following enterprise services, which rely on diagnostic data: + +- [Update Compliance](/windows/deployment/update/update-compliance-monitor) +- [Windows Update for Business reports](/windows/deployment/update/wufb-reports-overview) +- [Windows Update for Business deployment service](/windows/deployment/update/deployment-service-overview) +- [Microsoft Managed Desktop](/managed-desktop/intro/) +- [Endpoint analytics (in Microsoft Intune)](/mem/analytics/overview) + +*(Additional licensing requirements may apply to use these services.)* + +If you don’t sign up for any of these enterprise services, Microsoft will act as controller for the diagnostic data. + +### Enabling Windows diagnostic data processor configuration on older versions of Windows + +> [!NOTE] +> The information in this section applies to the following versions of Windows: +> - Windows 10, versions 1809, 1903, 1909, and 2004. +> - Newer versions of Windows 10 and Windows 11 that have not updated yet to at least the January 2023 preview cumulative update. + Use the instructions below to enable Windows diagnostic data processor configuration using a single setting, through Group Policy, or an MDM solution. In Group Policy, to enable Windows diagnostic data processor configuration, go to **Computer Configuration** > **Administrative Templates** > **Windows Components** > **Data Collection and Preview Builds** and switch the **Allow commercial data pipeline** setting to **enabled**. @@ -343,38 +383,6 @@ Under **Value**, use **1** to enable the service. If you wish to disable, at any time, switch the same setting to **0**. The default value is **0**. ->[!Note] -> - If you have any additional policies that also enable you to be a controller of Windows diagnostic data, such as the services listed below, you will need to turn off all the applicable policies in order to stop being a controller for Windows diagnostic data. -> - Windows diagnostic data collected from a device before it was enabled with Windows diagnostic data processor configuration will be deleted when this configuration is enabled. -> - When you enable devices with the Windows diagnostic data processor configuration, users may continue to submit feedback through various channels such as Windows feedback hub or Edge feedback. However, the feedback data is not subject to the terms of the Windows diagnostic data processor configuration. If this is not desired, we recommend that you disable feedback using the available policies or application management solutions. - -You can also enable the Windows diagnostic data processor configuration by enrolling in services that use Windows diagnostic data. These services currently include Desktop Analytics, Update Compliance, Microsoft Managed Desktop, and Windows Update for Business. - -For information on these services and how to configure the group policies, refer to the following documentation: - -Desktop Analytics: - -- [Enable data sharing for Desktop Analytics](/mem/configmgr/desktop-analytics/enable-data-sharing) -- [Desktop Analytics data privacy](/mem/configmgr/desktop-analytics/privacy) -- [Group policy settings for Desktop Analytics](/mem/configmgr/desktop-analytics/group-policy-settings) - -Update Compliance: - -- [Privacy in Update Compliance](/windows/deployment/update/update-compliance-privacy) -- [Manually configuring devices for Update Compliance](/windows/deployment/update/update-compliance-configuration-manual#required-policies) - -Microsoft Managed Desktop: - -- [Privacy and personal data](/microsoft-365/managed-desktop/service-description/privacy-personal-data) - -Windows Update for Business: - -- [How to enable deployment protections](/windows/deployment/update/deployment-service-overview#how-to-enable-deployment-protections) - -## Limit optional diagnostic data for Desktop Analytics - -For more information about how to limit the diagnostic data to the minimum required by Desktop Analytics, see [Enable data sharing for Desktop Analytics](/mem/configmgr/desktop-analytics/enable-data-sharing). - ## Change privacy settings on a single server You can also change the privacy settings on a server running either the Azure Stack HCI operating system or Windows Server. For more information, see [Change privacy settings on individual servers](/azure-stack/hci/manage/change-privacy-settings). diff --git a/windows/privacy/enhanced-diagnostic-data-windows-analytics-events-and-fields.md b/windows/privacy/enhanced-diagnostic-data-windows-analytics-events-and-fields.md index e4880b26b9..01d4412ac3 100644 --- a/windows/privacy/enhanced-diagnostic-data-windows-analytics-events-and-fields.md +++ b/windows/privacy/enhanced-diagnostic-data-windows-analytics-events-and-fields.md @@ -18,8 +18,8 @@ ms.topic: reference - Windows 10, version 1709 and newer > [!IMPORTANT] -> The Upgrade Readiness and Device Health solutions of Windows Analytics are being retired on January 31, 2020. [Update Compliance](/windows/deployment/update/update-compliance-get-started) will continue to be supported. -> For more information, see [Windows Analytics retirement on January 31, 2020](/lifecycle/announcements/windows-analytics-retirement). +> - The Upgrade Readiness and Device Health solutions of Windows Analytics were retired on January 31, 2020. +> - Desktop Analytics is deprecated and was retired on November 30, 2022. Desktop Analytics reports are powered by diagnostic data not included in the Basic level. diff --git a/windows/privacy/windows-10-and-privacy-compliance.md b/windows/privacy/windows-10-and-privacy-compliance.md index 2e65697d6a..0dc8c28071 100644 --- a/windows/privacy/windows-10-and-privacy-compliance.md +++ b/windows/privacy/windows-10-and-privacy-compliance.md @@ -164,7 +164,7 @@ We recommend that IT administrators who have enabled the Windows diagnostic data >[!Note] >Tenant account closure will lead to the deletion of all data associated with that tenant. -Specific services that depend on Windows diagnostic data will also result in the enterprise becoming controllers of their Windows diagnostic data. These services include Update Compliance, Desktop Analytics, Windows Update for Business, and Microsoft Managed Desktop. For more information, see [Related Windows product considerations](#5-related-windows-product-considerations). +Specific services that depend on Windows diagnostic data will also result in the enterprise becoming controllers of their Windows diagnostic data. These services include Update Compliance, Windows Update for Business reports, Windows Update for Business, and Microsoft Managed Desktop. For more information, see [Related Windows product considerations](#5-related-windows-product-considerations). For more information on how Microsoft can help you honor rights and fulfill obligations under the GDPR when using Windows diagnostic data processor configurations, see [General Data Protection Regulation Summary](/compliance/regulatory/gdpr). @@ -229,18 +229,19 @@ An administrator can configure privacy-related settings, such as choosing to onl >[!Note] >The Windows diagnostic data processor configuration is not available for Surface Hub. -### 5.3 Desktop Analytics - -[Desktop Analytics](/mem/configmgr/desktop-analytics/overview) is a set of solutions for Azure portal that provide you with extensive data about the state of devices in your deployment. Desktop Analytics is a separate offering from Windows and is dependent on enabling a minimum set of data collection on the device to function. - -### 5.4 Microsoft Managed Desktop +### 5.3 Microsoft Managed Desktop [Microsoft Managed Desktop (MMD)](/microsoft-365/managed-desktop/service-description/) is a service that provides your users with a secure modern experience and always keeps devices up to date with the latest versions of Windows Enterprise edition, Office 365 ProPlus, and Microsoft security services. -### 5.5 Update Compliance +### 5.4 Update Compliance [Update Compliance](/windows/deployment/update/update-compliance-monitor) is a service that enables organizations to monitor security, quality and feature updates for Windows Professional, Education, and Enterprise editions, and view a report of device and update issues related to compliance that need attention. Update Compliance uses Windows diagnostic data for all its reporting. +### 5.5 Windows Update for Business reports + +[Windows Update for Business reports](/windows/deployment/update/wufb-reports-overview) is a cloud-based solution that provides information about an organization’s Azure Active Directory-joined devices' compliance with Windows updates. Windows Update for Business reports uses Windows diagnostic data for all its reporting. + + ## Additional Resources * [Microsoft Trust Center: GDPR Overview](https://www.microsoft.com/trust-center/privacy/gdpr-overview) diff --git a/windows/security/TOC.yml b/windows/security/TOC.yml index 26288c8351..dc04109fd8 100644 --- a/windows/security/TOC.yml +++ b/windows/security/TOC.yml @@ -310,7 +310,7 @@ href: identity-protection/windows-credential-theft-mitigation-guide-abstract.md - name: Passwordless items: - - name: Windows Hello for Business + - name: Windows Hello for Business ⇒ href: identity-protection/hello-for-business/index.yml - name: FIDO 2 security keys href: /azure/active-directory/authentication/howto-authentication-passwordless-security-key?context=/windows/security/context/context diff --git a/windows/security/identity-protection/hello-for-business/hello-aad-join-cloud-only-deploy.md b/windows/security/identity-protection/hello-for-business/hello-aad-join-cloud-only-deploy.md index 004083bb85..25100512b3 100644 --- a/windows/security/identity-protection/hello-for-business/hello-aad-join-cloud-only-deploy.md +++ b/windows/security/identity-protection/hello-for-business/hello-aad-join-cloud-only-deploy.md @@ -8,7 +8,7 @@ ms.topic: article --- # Cloud-only deployment -[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-cloud.md)] +[!INCLUDE [hello-hybrid-key-trust](./includes/hello-cloud.md)] ## Introduction @@ -47,7 +47,7 @@ We recommend that you disable or manage Windows Hello for Business provisioning ### Disable Windows Hello for Business using Intune Enrollment policy -The following method explains how to disable Windows Hello for Business enrollment without Intune. +The following method explains how to disable Windows Hello for Business enrollment using Intune. 1. Sign into the [Microsoft Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431). 2. Go to **Devices** > **Enrollment** > **Enroll devices** > **Windows enrollment** > **Windows Hello for Business**. The Windows Hello for Business pane opens. diff --git a/windows/security/identity-protection/hello-for-business/hello-cert-trust-adfs.md b/windows/security/identity-protection/hello-for-business/hello-cert-trust-adfs.md index d258d207f7..c765eb789e 100644 --- a/windows/security/identity-protection/hello-for-business/hello-cert-trust-adfs.md +++ b/windows/security/identity-protection/hello-for-business/hello-cert-trust-adfs.md @@ -1,6 +1,6 @@ --- -title: Prepare and deploy Active Directory Federation Services in an on-premises certificate trust -description: Learn how to configure Active Directory Federation Services to support the Windows Hello for Business certificate trust model. +title: Prepare and deploy Active Directory Federation Services in an on-premises certificate trust model +description: Learn how to configure Active Directory Federation Services to support the Windows Hello for Business on-premises certificate trust model. ms.date: 12/12/2022 appliesto: - ✅ Windows 10 and later @@ -9,7 +9,7 @@ ms.topic: tutorial --- # Prepare and deploy Active Directory Federation Services - on-premises certificate trust -[!INCLUDE [hello-on-premises-cert-trust](../../includes/hello-on-premises-cert-trust.md)] +[!INCLUDE [hello-on-premises-cert-trust](./includes/hello-on-premises-cert-trust.md)] Windows Hello for Business works exclusively with the Active Directory Federation Service (AD FS) role included with Windows Server. The on-premises certificate trust deployment model uses AD FS for *certificate enrollment* and *device registration*. @@ -179,11 +179,11 @@ Sign-in the AD FS server with *domain administrator* equivalent credentials. Open a **Windows PowerShell** prompt and type the following command: - ```PowerShell - Set-AdfsCertificateAuthority -EnrollmentAgent -EnrollmentAgentCertificateTemplate WHFBEnrollmentAgent -WindowsHelloCertificateTemplate WHFBAuthentication +```PowerShell +Set-AdfsCertificateAuthority -EnrollmentAgent -EnrollmentAgentCertificateTemplate WHFBEnrollmentAgent -WindowsHelloCertificateTemplate WHFBAuthentication ``` - >[!NOTE] - > If you gave your Windows Hello for Business Enrollment Agent and Windows Hello for Business Authentication certificate templates different names, then replace *WHFBEnrollmentAgent* and *WHFBAuthentication* in the above command with the name of your certificate templates. +>[!NOTE] +> If you gave your Windows Hello for Business Enrollment Agent and Windows Hello for Business Authentication certificate templates different names, then replace *WHFBEnrollmentAgent* and *WHFBAuthentication* in the above command with the name of your certificate templates. It's important that you use the template name rather than the template display name. You can view the template name on the **General** tab of the certificate template by using the **Certificate Template** management console (certtmpl.msc). Or, you can view the template name by using the `Get-CATemplate` PowerShell cmdlet on a CA. ### Enrollment agent certificate enrollment diff --git a/windows/security/identity-protection/hello-for-business/hello-cert-trust-policy-settings.md b/windows/security/identity-protection/hello-for-business/hello-cert-trust-policy-settings.md index 870fc37596..a73ef3f3f2 100644 --- a/windows/security/identity-protection/hello-for-business/hello-cert-trust-policy-settings.md +++ b/windows/security/identity-protection/hello-for-business/hello-cert-trust-policy-settings.md @@ -11,7 +11,7 @@ ms.topic: tutorial --- # Configure Windows Hello for Business group policy settings - on-premises certificate Trust -[!INCLUDE [hello-on-premises-cert-trust](../../includes/hello-on-premises-cert-trust.md)] +[!INCLUDE [hello-on-premises-cert-trust](./includes/hello-on-premises-cert-trust.md)] On-premises certificate-based deployments of Windows Hello for Business need three Group Policy settings: - Enable Windows Hello for Business diff --git a/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-ad-prereq.md b/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-ad-prereq.md index bac1a4e528..629e59b1e2 100644 --- a/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-ad-prereq.md +++ b/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-ad-prereq.md @@ -9,7 +9,7 @@ ms.topic: tutorial --- # Validate Active Directory prerequisites - on-premises certificate trust -[!INCLUDE [hello-on-premises-cert-trust](../../includes/hello-on-premises-cert-trust.md)] +[!INCLUDE [hello-on-premises-cert-trust](./includes/hello-on-premises-cert-trust.md)] The key registration process for the on-premises deployment of Windows Hello for Business requires the Windows Server 2016 Active Directory or later schema. diff --git a/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-deploy-mfa.md b/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-deploy-mfa.md index e5c4b9a2a4..c7c5b09a61 100644 --- a/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-deploy-mfa.md +++ b/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-deploy-mfa.md @@ -10,7 +10,7 @@ ms.topic: tutorial # Validate and deploy multi-factor authentication - on-premises certificate trust -[!INCLUDE [hello-on-premises-cert-trust](../../includes/hello-on-premises-cert-trust.md)] +[!INCLUDE [hello-on-premises-cert-trust](./includes/hello-on-premises-cert-trust.md)] Windows Hello for Business requires users perform multi-factor authentication (MFA) prior to enroll in the service. On-premises deployments can use, as MFA option: @@ -20,9 +20,9 @@ Windows Hello for Business requires users perform multi-factor authentication (M > [!IMPORTANT] > As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who would like to require multi-factor authentication from their users should use cloud-based Azure AD Multi-Factor Authentication. Existing customers who have activated MFA Server prior to July 1 will be able to download the latest version, future updates and generate activation credentials as usual. -For information on available third-party authentication methods see [Configure Additional Authentication Methods for AD FS](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs). For creating a custom authentication method see [Build a Custom Authentication Method for AD FS in Windows Server](/windows-server/identity/ad-fs/development/ad-fs-build-custom-auth-method) +For information about third-party authentication methods, see [Configure Additional Authentication Methods for AD FS](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs). To create a custom authentication method, see [Build a Custom Authentication Method for AD FS in Windows Server](/windows-server/identity/ad-fs/development/ad-fs-build-custom-auth-method). -Follow the integration and deployment guide for the authentication provider you select to integrate and deploy it to AD FS. Make sure that the authentication provider is selected as a multi-factor authentication option in the AD FS authentication policy. For information on configuring AD FS authentication policies see [Configure Authentication Policies](/windows-server/identity/ad-fs/operations/configure-authentication-policies). +Follow the integration and deployment guide for the authentication provider you plan to integrate to AD FS. Make sure that the authentication provider is selected as a multi-factor authentication option in the AD FS authentication policy. For information on configuring AD FS authentication policies, see [Configure Authentication Policies](/windows-server/identity/ad-fs/operations/configure-authentication-policies). > [!div class="nextstepaction"] > [Next: configure Windows Hello for Business Policy settings](hello-cert-trust-policy-settings.md) \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-pki.md b/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-pki.md index f543372332..27f2375bae 100644 --- a/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-pki.md +++ b/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-pki.md @@ -9,261 +9,27 @@ ms.topic: tutorial --- # Configure and validate the Public Key Infrastructure - on-premises certificate trust -[!INCLUDE [hello-on-premises-cert-trust](../../includes/hello-on-premises-cert-trust.md)] +[!INCLUDE [hello-on-premises-cert-trust](./includes/hello-on-premises-cert-trust.md)] Windows Hello for Business must have a Public Key Infrastructure (PKI) when using the *key trust* or *certificate trust* models. The domain controllers must have a certificate, which serves as a root of trust for clients. The certificate ensures that clients don't communicate with rogue domain controllers. The certificate trust model extends certificate issuance to client computers. During Windows Hello for Business provisioning, the user receives a sign-in certificate. -## Deploy an enterprise certification authority +[!INCLUDE [lab-based-pki-deploy](includes/lab-based-pki-deploy.md)] -This guide assumes most enterprises have an existing public key infrastructure. Windows Hello for Business depends on an enterprise PKI running the Windows Server *Active Directory Certificate Services* role. +## Configure the enterprise PKI -### Lab-based PKI +[!INCLUDE [dc-certificate-template](includes/dc-certificate-template.md)] -The following instructions may be used to deploy simple public key infrastructure that is suitable **for a lab environment**. +[!INCLUDE [dc-certificate-template-supersede](includes/dc-certificate-supersede.md)] -Sign in using *Enterprise Administrator* equivalent credentials on a Windows Server where you want the certification authority (CA) installed. +[!INCLUDE [web-server-certificate-template](includes/web-server-certificate-template.md)] ->[!NOTE] ->Never install a certification authority on a domain controller in a production environment. +[!INCLUDE [enrollment-agent-certificate-template](includes/enrollment-agent-certificate-template.md)] -1. Open an elevated Windows PowerShell prompt -1. Use the following command to install the Active Directory Certificate Services role. - ```PowerShell - Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools - ``` -3. Use the following command to configure the CA using a basic certification authority configuration - ```PowerShell - Install-AdcsCertificationAuthority - ``` +[!INCLUDE [auth-certificate-template](includes/auth-certificate-template.md)] -## Configure a PKI +[!INCLUDE [unpublish-superseded-templates](includes/unpublish-superseded-templates.md)] -If you have an existing PKI, review [Certification Authority Guidance](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831574(v=ws.11)) to properly design your infrastructure. Then, consult the [Test Lab Guide: Deploying an AD CS Two-Tier PKI Hierarchy](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831348(v=ws.11)) for instructions on how to configure your PKI using the information from your design session. - -Expand the following sections to configure the PKI for Windows Hello for Business. - -
-
-Configure domain controller certificates - -Clients must trust the domain controllers, and to it each domain controller must have a *Kerberos Authentication* certificate. Installing a certificate on the domain controllers enables the Key Distribution Center (KDC) to prove its identity to other members of the domain. The certificates provide clients a root of trust external to the domain, namely the *enterprise certification authority*. - -Domain controllers automatically request a domain controller certificate (if published) when they discover an enterprise CA is added to Active Directory. However, certificates based on the Domain Controller and Domain Controller Authentication certificate templates don't include the *KDC Authentication* object identifier (OID), which was later added to the Kerberos RFC. Therefore, domain controllers need to request a certificate based on the *Kerberos Authentication* certificate template. - -By default, the Active Directory CA provides and publishes the *Kerberos Authentication* certificate template. The cryptography configuration included in the template is based on older and less performant cryptography APIs. To ensure domain controllers request the proper certificate with the best available cryptography, use the *Kerberos Authentication* certificate template as a *baseline* to create an updated domain controller certificate template. - -Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials. - -1. Open the **Certification Authority** management console -1. Right-click **Certificate Templates > Manage** -1. In the **Certificate Template Console**, right-click the **Kerberos Authentication** template in the details pane and select **Duplicate Template** -1. On the **Compatibility** tab: - - Clear the **Show resulting changes** check box - - Select **Windows Server 2016** from the **Certification Authority** list - - Select **Windows 10 / Windows Server 2016** from the **Certificate Recipient** list -1. On the **General** tab - - Type *Domain Controller Authentication (Kerberos)* in Template display name - - Adjust the validity and renewal period to meet your enterprise's needs - > [!NOTE] - > If you use different template names, you'll need to remember and substitute these names in different portions of the lab. -1. On the **Subject Name** tab: - - Select the **Build from this Active Directory information** button if it isn't already selected - - Select **None** from the **Subject name format** list - - Select **DNS name** from the **Include this information in alternate subject** list - - Clear all other items -1. On the **Cryptography** tab: - - select **Key Storage Provider** from the **Provider Category** list - - Select **RSA** from the **Algorithm name** list - - Type *2048* in the **Minimum key size** text box - - Select **SHA256** from the **Request hash** list -1. Select **OK** -1. Close the console - -
- -
-
-Supersede existing domain controller certificates - -The domain controllers may have an existing domain controller certificate. The Active Directory Certificate Services provides a default certificate template for domain controllers called *domain controller certificate*. Later releases of Windows Server provided a new certificate template called *domain controller authentication certificate*. These certificate templates were provided prior to the update of the Kerberos specification that stated Key Distribution Centers (KDCs) performing certificate authentication needed to include the *KDC Authentication* extension. - -The *Kerberos Authentication* certificate template is the most current certificate template designated for domain controllers, and should be the one you deploy to all your domain controllers.\ -The *autoenrollment* feature allows you to replace the domain controller certificates. Use the following configuration to replace older domain controller certificates with new ones, using the *Kerberos Authentication* certificate template. - -Sign in to a CA or management workstations with *Enterprise Administrator* equivalent credentials. - -1. Open the **Certification Authority** management console -1. Right-click **Certificate Templates > Manage** -1. In the **Certificate Template Console**, right-click the *Domain Controller Authentication (Kerberos)* (or the name of the certificate template you created in the previous section) template in the details pane and select **Properties** -1. Select the **Superseded Templates** tab. Select **Add** -1. From the **Add Superseded Template** dialog, select the *Domain Controller* certificate template and select **OK > Add** -1. From the **Add Superseded Template** dialog, select the *Domain Controller Authentication* certificate template and select **OK** -1. From the **Add Superseded Template** dialog, select the *Kerberos Authentication* certificate template and select **OK** -1. Add any other enterprise certificate templates that were previously configured for domain controllers to the **Superseded Templates** tab -1. Select **OK** and close the **Certificate Templates** console - -The certificate template is configured to supersede all the certificate templates provided in the certificate templates superseded templates list. However, the certificate template and the superseding of certificate templates isn't active until the certificate template is published to one or more certificate authorities. - -
- -
-
-Configure an internal web server certificate template - -Windows clients use the https protocol when communicating with Active Directory Federation Services (AD FS). To meet this need, you must issue a server authentication certificate to all the nodes in the AD FS farm. On-premises deployments can use a server authentication certificate issued by their enterprise PKI. You must configure a server authentication certificate template so the host running theAD FS can request the certificate. - -Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials. - -1. Open the **Certification Authority** management console -1. Right-click **Certificate Templates** and select **Manage** -1. In the **Certificate Template Console**, right-click the **Web Server** template in the details pane and select **Duplicate Template** -1. On the **Compatibility** tab: - - Clear the **Show resulting changes** check box - - Select **Windows Server 2016** from the **Certification Authority** list - - Select **Windows 10 / Windows Server 2016** from the **Certificate recipient** list -1. On the **General** tab: - - Type *Internal Web Server* in **Template display name** - - Adjust the validity and renewal period to meet your enterprise's needs - > [!NOTE] - > If you use different template names, you'll need to remember and substitute these names in different portions of the lab. -1. On the **Request Handling** tab, select **Allow private key to be exported** -1. On the **Subject** tab, select the **Supply in the request** button if it isn't already selected -1. On the **Security** tab: - - Select **Add** - - Type **Domain Computers** in the **Enter the object names to select** box - - Select **OK** - - Select the **Allow** check box next to the **Enroll** permission -1. On the **Cryptography** tab: - - Select **Key Storage Provider** from the **Provider Category** list - - Select **RSA** from the **Algorithm name** list - - Type *2048* in the **Minimum key size** text box - - Select **SHA256** from the **Request hash** list - - Select **OK** -1. Close the console - -
- -
-
-Configure a certificate registration authority template - -A certificate registration authority (CRA) is a trusted authority that validates certificate request. Once it validates the request, it presents the request to the certification authority (CA) for issuance. The CA issues the certificate, returns it to the CRA, which returns the certificate to the requesting user. The Windows Hello for Business on-premises certificate-based deployment uses AD FS as the CRA. - -The CRA enrolls for an *enrollment agent* certificate. Once the CRA verifies the certificate request, it signs the certificate request using its enrollment agent certificate and sends it to the CA. The Windows Hello for Business Authentication certificate template is configured to only issue certificates to certificate requests that have been signed with an enrollment agent certificate. The CA only issues a certificate for that template if the registration authority signs the certificate request. - -Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials. - -1. Open the **Certification Authority** management console -1. Right-click **Certificate Templates** and select **Manage** -1. In the **Certificate Template Console**, right-click on the **Exchange Enrollment Agent (Offline request)** template details pane and select **Duplicate Template** -1. On the **Compatibility** tab: - - Clear the **Show resulting changes** check box - - Select **Windows Server 2016** from the **Certification Authority** list. - - Select **Windows 10 / Windows Server 2016** from the **Certificate Recipient** list -1. On the **General** tab: - - Type *WHFB Enrollment Agent* in **Template display name** - - Adjust the validity and renewal period to meet your enterprise's needs -1. On the **Subject** tab, select the **Supply in the request** button if it is not already selected - - > [!NOTE] - > Group Managed Service Accounts (GMSA) do not support the *Build from this Active Directory information* option and will result in the AD FS server failing to enroll the enrollment agent certificate. You must configure the certificate template with *Supply in the request* to ensure that AD FS servers can perform the automatic enrollment and renewal of the enrollment agent certificate. - -1. On the **Cryptography** tab: - - Select **Key Storage Provider** from the **Provider Category** list - - Select **RSA** from the **Algorithm name** list - - Type *2048* in the **Minimum key size** text box - - Select **SHA256** from the **Request hash** list -1. On the **Security** tab, select **Add** -1. Select **Object Types** and select the **Service Accounts** check box. Select **OK** -1. Type *adfssvc* in the **Enter the object names to select** text box and select **OK** -1. Select the **adfssvc** from the **Group or users names** list. In the **Permissions for adfssvc** section: - - In the **Permissions for adfssvc** section, select the **Allow** check box for the **Enroll** permission - - Excluding the **adfssvc** user, clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other items in the **Group or users names** list if the check boxes are not already cleared - - Select **OK** -1. Close the console - -
- -
-
-Configure a Windows Hello for Business authentication certificate template - -During Windows Hello for Business provisioning, Windows clients request an authentication certificate from AD FS, which requests the authentication certificate on behalf of the user. This task configures the Windows Hello for Business authentication certificate template. - -Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials. - -1. Open the **Certification Authority** management console -1. Right-click **Certificate Templates** and select **Manage** -1. Right-click the **Smartcard Logon** template and choose **Duplicate Template** -1. On the **Compatibility** tab: - - Clear the **Show resulting changes** check box - - Select **Windows Server 2016** from the **Certification Authority** list - - Select **Windows 10 / Windows Server 2016** from the **Certificate Recipient** list -1. On the **General** tab: - - Type *WHFB Authentication* in **Template display name** - - Adjust the validity and renewal period to meet your enterprise's needs - > [!NOTE] - > If you use different template names, you'll need to remember and substitute these names in different portions of the deployment. -1. On the **Cryptography** tab - - Select **Key Storage Provider** from the **Provider Category** list - - Select **RSA** from the **Algorithm name** list - - Type *2048* in the **Minimum key size** text box - - Select **SHA256** from the **Request hash** list -1. On the **Extensions** tab, verify the **Application Policies** extension includes **Smart Card Logon** -1. On the **Issuance Requirements** tab, - - Select the **This number of authorized signatures** check box. Type *1* in the text box - - Select **Application policy** from the **Policy type required in signature** - - Select **Certificate Request Agent** from in the **Application policy** list - - Select the **Valid existing certificate** option -1. On the **Subject** tab, - - Select the **Build from this Active Directory information** button - - Select **Fully distinguished name** from the **Subject name format** list - - Select the **User Principal Name (UPN)** check box under **Include this information in alternative subject name** -1. On the **Request Handling** tab, select the **Renew with same key** check box -1. On the **Security** tab, select **Add**. Type *Window Hello for Business Users* in the **Enter the object names to select** text box and select **OK** -1. Select the **Windows Hello for Business Users** from the **Group or users names** list. In the **Permissions for Windows Hello for Business Users** section: - - Select the **Allow** check box for the **Enroll** permission - - Excluding the **Windows Hello for Business Users** group, clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other entries in the **Group or users names** section if the check boxes are not already cleared - - Select **OK** -1. If you previously issued Windows Hello for Business sign-in certificates using Configuration Manger and are switching to an AD FS registration authority, then on the **Superseded Templates** tab, add the previously used **Windows Hello for Business Authentication** template(s), so they will be superseded by this template for the users that have Enroll permission for this template -1. Select on the **Apply** to save changes and close the console - -#### Mark the template as the Windows Hello Sign-in template - -Sign in to a CA or management workstations with *Enterprise Administrator* equivalent credentials - -Open an elevated command prompt end execute the following command - -```cmd -certutil.exe -dsTemplate WHFBAuthentication msPKI-Private-Key-Flag +CTPRIVATEKEY_FLAG_HELLO_LOGON_KEY -``` - ->[!NOTE] ->If you gave your Windows Hello for Business Authentication certificate template a different name, then replace *WHFBAuthentication* in the above command with the name of your certificate template. It's important that you use the template name rather than the template display name. You can view the template name on the **General** tab of the certificate template using the Certificate Template management console (certtmpl.msc). Or, you can view the template name using the **Get-CATemplate** ADCS Administration Windows PowerShell cmdlet on your certification authority. - - -
- -
-
-Unpublish Superseded Certificate Templates - -The certification authority only issues certificates based on published certificate templates. For security, it's a good practice to unpublish certificate templates that the CA isn't configured to issue. This includes the pre-published certificate template from the role installation and any superseded certificate templates. - -The newly created *domain controller authentication* certificate template supersedes previous domain controller certificate templates. Therefore, you need to unpublish these certificate templates from all issuing certificate authorities. - -Sign in to the CA or management workstation with *Enterprise Administrator* equivalent credentials. - -1. Open the **Certification Authority** management console -1. Expand the parent node from the navigation pane > **Certificate Templates** -1. Right-click the *Domain Controller* certificate template and select **Delete**. Select **Yes** on the **Disable certificate templates** window -1. Repeat step 3 for the *Domain Controller Authentication* and *Kerberos Authentication* certificate templates - -
- -
-
-Publish certificate templates to the CA +### Publish certificate templates to the CA A certification authority can only issue certificates for certificate templates that are published to it. If you have more than one CA, and you want more CAs to issue certificates based on the certificate template, then you must publish the certificate template to them. @@ -278,71 +44,13 @@ Sign in to the CA or management workstations with **Enterprise Admin** equivalen - To unpublish a certificate template, right-click the certificate template you want to unpublish and select **Delete**. Select **Yes** to confirm the operation 1. Close the console -
+## Configure and deploy certificates to domain controllers -### Configure automatic certificate enrollment for the domain controllers - -Domain controllers automatically request a certificate from the *Domain controller certificate* template. However, domain controllers are unaware of newer certificate templates or superseded configurations on certificate templates. To continue automatic enrollment and renewal of domain controller certificates, create and configure a Group Policy Object (GPO) for automatic certificate enrollment, linking the Group Policy object to the *Domain Controllers* Organizational Unit (OU). - -1. Open the **Group Policy Management Console** (gpmc.msc) -1. Expand the domain and select the **Group Policy Object** node in the navigation pane -1. Right-click **Group Policy object** and select **New** -1. Type *Domain Controller Auto Certificate Enrollment* in the name box and select **OK** -1. Right-click the **Domain Controller Auto Certificate Enrollment** Group Policy object and select **Edit** -1. In the navigation pane, expand **Policies** under **Computer Configuration** -1. Expand **Windows Settings > Security Settings > Public Key Policies** -1. In the details pane, right-click **Certificate Services Client - Auto-Enrollment** and select **Properties** -1. Select **Enabled** from the **Configuration Model** list -1. Select the **Renew expired certificates, update pending certificates, and remove revoked certificates** check box -1. Select the **Update certificates that use certificate templates** check box -1. Select **OK** -1. Close the **Group Policy Management Editor** - -### Deploy the domain controller auto certificate enrollment GPO - -Sign in to domain controller or management workstations with *Domain Administrator* equivalent credentials. - -1. Start the **Group Policy Management Console** (gpmc.msc) -1. In the navigation pane, expand the domain and expand the node with the Active Directory domain name. Right-click the **Domain Controllers** organizational unit and select **Link an existing GPO…** -1. In the **Select GPO** dialog box, select *Domain Controller Auto Certificate Enrollment* or the name of the domain controller certificate enrollment Group Policy object you previously created -1. Select **OK** +[!INCLUDE [dc-certificate-deployment](includes/dc-certificate-deployment.md)] ## Validate the configuration -Windows Hello for Business is a distributed system, which on the surface appears complex and difficult. The key to a successful Windows Hello for Business deployment is to validate phases of work prior to moving to the next phase. - -You want to confirm your domain controllers enroll the correct certificates and not any unnecessary (superseded) certificate templates. You need to check each domain controller that autoenrollment for the computer occurred. - -### Use the event logs - -Sign in to domain controller or management workstations with *Domain Administrator* equivalent credentials. - -1. Using the Event Viewer, navigate to the **Application and Services > Microsoft > Windows > CertificateServices-Lifecycles-System** event log -1. Look for an event indicating a new certificate enrollment (autoenrollment): - - The details of the event include the certificate template on which the certificate was issued - - The name of the certificate template used to issue the certificate should match the certificate template name included in the event - - The certificate thumbprint and EKUs for the certificate are also included in the event - - The EKU needed for proper Windows Hello for Business authentication is Kerberos Authentication, in addition to other EKUs provide by the certificate template - -Certificates superseded by your new domain controller certificate generate an archive event in the event log. The archive event contains the certificate template name and thumbprint of the certificate that was superseded by the new certificate. - -### Certificate Manager - -You can use the Certificate Manager console to validate the domain controller has the properly enrolled certificate based on the correct certificate template with the proper EKUs. Use **certlm.msc** to view certificate in the local computers certificate stores. Expand the **Personal** store and view the certificates enrolled for the computer. Archived certificates don't appear in Certificate Manager. - -### Certutil.exe - -You can use `certutil.exe` command to view enrolled certificates in the local computer. Certutil shows enrolled and archived certificates for the local computer. From an elevated command prompt, run `certutil.exe -q -store my` to view locally enrolled certificates. - -To view detailed information about each certificate in the store, use `certutil.exe -q -v -store my` to validate automatic certificate enrollment enrolled the proper certificates. - -### Troubleshooting - -Windows triggers automatic certificate enrollment for the computer during boot, and when Group Policy updates. You can refresh Group Policy from an elevated command prompt using `gpupdate.exe /force`. - -Alternatively, you can forcefully trigger automatic certificate enrollment using `certreq.exe -autoenroll -q` from an elevated command prompt. - -Use the event logs to monitor certificate enrollment and archive. Review the configuration, such as publishing certificate templates to issuing certification authority and the allow auto enrollment permissions. +[!INCLUDE [dc-certificate-validate](includes/dc-certificate-validate.md)] > [!div class="nextstepaction"] > [Next: prepare and deploy AD FS >](hello-cert-trust-adfs.md) \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/hello-deployment-cert-trust.md b/windows/security/identity-protection/hello-for-business/hello-deployment-cert-trust.md index d19452cbd8..0775ea4e9d 100644 --- a/windows/security/identity-protection/hello-for-business/hello-deployment-cert-trust.md +++ b/windows/security/identity-protection/hello-for-business/hello-deployment-cert-trust.md @@ -9,7 +9,7 @@ ms.topic: tutorial --- # Deployment guide overview - on-premises certificate trust -[!INCLUDE [hello-on-premises-cert-trust](../../includes/hello-on-premises-cert-trust.md)] +[!INCLUDE [hello-on-premises-cert-trust](./includes/hello-on-premises-cert-trust.md)] Windows Hello for Business replaces username and password authentication to Windows with an asymmetric key pair. This deployment guide provides the information to deploy Windows Hello for Business in an on-premises environment: diff --git a/windows/security/identity-protection/hello-for-business/hello-deployment-key-trust.md b/windows/security/identity-protection/hello-for-business/hello-deployment-key-trust.md index 34d860c531..6104c34401 100644 --- a/windows/security/identity-protection/hello-for-business/hello-deployment-key-trust.md +++ b/windows/security/identity-protection/hello-for-business/hello-deployment-key-trust.md @@ -9,7 +9,7 @@ ms.topic: tutorial --- # Deployment guide overview - on-premises key trust -[!INCLUDE [hello-on-premises-key-trust](../../includes/hello-on-premises-key-trust.md)] +[!INCLUDE [hello-on-premises-key-trust](./includes/hello-on-premises-key-trust.md)] Windows Hello for Business replaces username and password authentication to Windows with an asymmetric key pair. This deployment guide provides the information to deploy Windows Hello for Business in an on-premises environment:: diff --git a/windows/security/identity-protection/hello-for-business/hello-deployment-rdp-certs.md b/windows/security/identity-protection/hello-for-business/hello-deployment-rdp-certs.md index 5fe62506a6..424f82c737 100644 --- a/windows/security/identity-protection/hello-for-business/hello-deployment-rdp-certs.md +++ b/windows/security/identity-protection/hello-for-business/hello-deployment-rdp-certs.md @@ -12,9 +12,9 @@ appliesto: # Deploy certificates for remote desktop (RDP) sign-in This document describes Windows Hello for Business functionalities or scenarios that apply to: -- **Deployment type:** [!INCLUDE [hybrid](../../includes/hello-deployment-hybrid.md)] -- **Trust type:** [!INCLUDE [cloud-kerberos](../../includes/hello-trust-cloud-kerberos.md)], [!INCLUDE [key](../../includes/hello-trust-key.md)] -- **Join type:** [!INCLUDE [hello-join-aadj](../../includes/hello-join-aad.md)], [!INCLUDE [hello-join-hybrid](../../includes/hello-join-hybrid.md)] +- **Deployment type:** [!INCLUDE [hybrid](./includes/hello-deployment-hybrid.md)] +- **Trust type:** [!INCLUDE [cloud-kerberos](./includes/hello-trust-cloud-kerberos.md)], [!INCLUDE [key](./includes/hello-trust-key.md)] +- **Join type:** [!INCLUDE [hello-join-aadj](./includes/hello-join-aad.md)], [!INCLUDE [hello-join-hybrid](./includes/hello-join-hybrid.md)] --- Windows Hello for Business supports using a certificate as the supplied credential, when establishing a remote desktop connection to another Windows device. This document discusses three approaches for *cloud Kerberos trust* and *key trust* deployments, where authentication certificates can be deployed to an existing Windows Hello for Business user: @@ -30,11 +30,7 @@ Windows Hello for Business supports using a certificate as the supplied credenti To deploy certificates using an on-premises Active Directory Certificate Services enrollment policy, you must first create a *certificate template*, and then deploy certificates based on that template. -Expand the following sections to learn more about the process. - -
-
-Create a Windows Hello for Business certificate template +### Create a Windows Hello for Business certificate template Follow these steps to create a certificate template: @@ -81,11 +77,7 @@ Follow these steps to create a certificate template: 1. From the list of templates, select the template you previously created (**WHFB Certificate Authentication**) and select **OK**. It can take some time for the template to replicate to all servers and become available in this list 1. After the template replicates, in the MMC, right-click in the Certification Authority list, select **All Tasks > Stop Service**. Right-click the name of the CA again, select **All Tasks > Start Service** -
- -
-
-Request a certificate +### Request a certificate 1. Sign in to a client that is hybrid Azure AD joined, ensuring that the client has line of sight to a domain controller and the issuing CA 1. Open the **Certificates - Current User** Microsoft Management Console (MMC). To do so, you can execute the command `certmgr.msc` @@ -95,8 +87,6 @@ Follow these steps to create a certificate template: 1. Under *Request Certificates*, select the check-box for the certificate template you created in the previous section (*WHfB Certificate Authentication*) and then select **Enroll** 1. After a successful certificate request, select **Finish** on the Certificate Installation Results screen -
- ## Deploy certificates via Intune > [!NOTE] @@ -111,9 +101,7 @@ Next, you should deploy the root CA certificate (and any other intermediate cert Once these requirements are met, a policy can be configured in Intune that provisions certificates for the users on the targeted device. -
-
-Create a policy in Intune +### Create a policy in Intune This section describes how to configure a SCEP policy in Intune. Similar steps can be followed to configure a PKCS policy. @@ -147,11 +135,8 @@ This section describes how to configure a SCEP policy in Intune. Similar steps c For more information how to configure SCEP policies, see [Configure SCEP certificate profiles in Intune][MEM-3]. To configure PKCS policies, see [Configure and use PKCS certificate with Intune][MEM-4]. -
+### Request a certificate for Intune clients -
-
-Request a certificate Once the Intune policy is created, targeted clients will request a certificate during their next policy refresh cycle. To validate that the certificate is present in the user store, follow these steps: 1. Sign in to a client targeted by the Intune policy @@ -159,8 +144,6 @@ Once the Intune policy is created, targeted clients will request a certificate d 1. In the left pane of the MMC, expand **Personal** and select **Certificates** 1. In the right-hand pane of the MMC, check for the new certificate -
- ## Use third-party certification authorities If you're using a non-Microsoft PKI, the certificate templates published to the on-premises Active Directory may not be available. For guidance with integration of Intune/SCEP with non-Microsoft PKI deployments, refer to [Use third-party certification authorities (CA) with SCEP in Microsoft Intune][MEM-6]. diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md deleted file mode 100644 index a53b5977d6..0000000000 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md +++ /dev/null @@ -1,336 +0,0 @@ ---- -title: Configure Azure AD-joined devices for On-premises Single-Sign On using Windows Hello for Business -description: Before adding Azure Active Directory (Azure AD) joined devices to your existing hybrid deployment, you need to verify the existing deployment can support them. -ms.date: 01/14/2021 -appliesto: -- ✅ Windows 10 and later -ms.topic: article ---- -# Configure Azure AD-joined devices for On-premises Single-Sign On using Windows Hello for Business - -[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-keycert-trust-aad.md)] - -## Prerequisites - -Before adding Azure Active Directory (Azure AD) joined devices to your existing hybrid deployment, you need to verify the existing deployment can support Azure AD-joined devices. Unlike hybrid Azure AD-joined devices, Azure AD-joined devices don't have a relationship with your Active Directory domain. This factor changes the way in which users authenticate to Active Directory. Validate the following configurations to ensure they support Azure AD-joined devices. - -- Azure Active Directory Connect synchronization -- Device Registration -- Certificate Revocation List (CRL) Distribution Point (CDP) -- 2016 Domain Controllers -- Domain Controller certificate -- Network infrastructure in place to reach your on-premises domain controller. If the machines are external, you can use any VPN solution. - -### Azure Active Directory Connect synchronization -Azure AD join, and hybrid Azure AD join devices register the user's Windows Hello for Business credential with Azure. To enable on-premises authentication, the credential must be synchronized to the on-premises Active Directory, regardless whether you're using a key or a certificate. Ensure you have Azure AD Connect installed and functioning properly. To learn more about Azure AD Connect, read [Integrate your on-premises directories with Azure Active Directory](/azure/active-directory/connect/active-directory-aadconnect). - -If you upgraded your Active Directory schema to the Windows Server 2016 schema after installing Azure AD Connect, run Azure AD Connect and run **Refresh directory schema** from the list of tasks. -![Azure AD Connect Schema Refresh.](images/aadj/aadconnectschema.png) - -### Azure Active Directory Device Registration -A fundamental prerequisite of all cloud and hybrid Windows Hello for Business deployments is device registration. A user can't provision Windows Hello for Business unless the device from which they're trying to provision has registered with Azure Active Directory. For more information about device registration, read [Introduction to device management in Azure Active Directory](/azure/active-directory/devices/overview). - -You can use the **dsregcmd.exe** command to determine if your device is registered to Azure Active Directory. -![dsregcmd output.](images/aadj/dsregcmd.png) - -### CRL Distribution Point (CDP) - -Certificates issued by a certificate authority can be revoked. When a certificate authority revokes as certificate, it writes information about the certificate into a revocation list. During certificate validation, Windows consults the CRL distribution point within the certificate to get a list of revoked certificates. Validation compares the current certificate with information in the certificate revocation list to determine if the certificate remains valid. - -![Domain Controller Certificate with LDAP CDP.](images/aadj/Certificate-CDP.png) - -The preceding domain controller certificate shows a CRL distribution path (CDP) using Active Directory. The value in the URL begins with **ldap**. Using Active Directory for domain joined devices provides a highly available CRL distribution point. However, Azure Active Directory-joined devices and users on Azure Active Directory-joined devices can't read data from Active Directory, and certificate validation doesn't provide an opportunity to authenticate prior to reading the certificate revocation list. The authentication becomes a circular problem. The user is attempting to authenticate, but must read Active Directory to complete the authentication, but the user can't read Active Directory because they haven't authenticated. - -To resolve this issue, the CRL distribution point must be a location that is accessible by Azure Active Directory-joined devices that doesn't require authentication. The easiest solution is to publish the CRL distribution point on a web server that uses HTTP (not HTTPS). - -If your CRL distribution point doesn't list an HTTP distribution point, then you need to reconfigure the issuing certificate authority to include an HTTP CRL distribution point, preferably first in the list of distribution points. - -> [!NOTE] -> If your CA has published both the Base and the Delta CRL, please make sure you have included publishing the Delta CRL in the HTTP path. Include web server to fetch the Delta CRL by allowing double escaping in the (IIS) web server. - -### Windows Server 2016 Domain Controllers - -If you're interested in configuring your environment to use the Windows Hello for Business key rather than a certificate, then your environment must have an adequate number of Windows Server 2016 domain controllers. Only Windows Server 2016 domain controllers are capable of authenticating user with a Windows Hello for Business key. What do we mean by adequate? We're glad you asked. Read [Planning an adequate number of Windows Server 2016 Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more. - -If you're interested in configuring your environment to use the Windows Hello for Business certificate rather than key, then you're the right place. The same certificate configuration on the domain controllers is needed, whether you're using Windows Server 2016 domain controllers or domain controllers running earlier versions of Windows Server. You can ignore the Windows Server 2016 domain controller requirement. - -### Domain Controller Certificates - -Certificate authorities write CRL distribution points in certificates as they're issued. If the distribution point changes, then previously issued certificates must be reissued for the certificate authority to include the new CRL distribution point. The domain controller certificate is one the critical components of Azure AD-joined devices authenticating to Active Directory - -#### Why does Windows need to validate the domain controller certificate? - -Windows Hello for Business enforces the strict KDC validation security feature when authenticating from an Azure AD joined device to a domain. This enforcement imposes more restrictive criteria that must be met by the Key Distribution Center (KDC). When authenticating using Windows Hello for Business on an Azure AD joined device, the Windows client validates the reply from the domain controller by ensuring all of the following are met: - -- The domain controller has the private key for the certificate provided. -- The root CA that issued the domain controller's certificate is in the device's **Trusted Root Certificate Authorities**. -- Use the **Kerberos Authentication certificate template** instead of any other older template. -- The domain controller's certificate has the **KDC Authentication** enhanced key usage (EKU). -- The domain controller's certificate's subject alternate name has a DNS Name that matches the name of the domain. -- The domain controller's certificate's signature hash algorithm is **sha256**. -- The domain controller's certificate's public key is **RSA (2048 Bits)**. - -Authenticating from a Hybrid Azure AD joined device to a domain using Windows Hello for Business doesn't enforce that the domain controller certificate includes the **KDC Authentication** EKU. If you're adding Azure AD-joined devices to an existing domain environment, make sure to verify that your domain controller certificate has been updated to include the **KDC Authentication** EKU. If you need to update your domain controller certificate to include the **KDC Authentication** EKU, follow the instructions in [Configure Hybrid Windows Hello for Business: Public Key Infrastructure](hello-hybrid-key-whfb-settings-pki.md) - -> [!Tip] -> If you are using Windows Server 2008, **Kerberos Authentication** is not the default template, so make sure to use the correct template when issuing or re-issuing the certificate. - -## Configuring a CRL Distribution Point for an issuing certificate authority - -Use this set of procedures to update your certificate authority that issues your domain controller certificates to include an http-based CRL distribution point. - -Steps you'll perform include: - -- [Configure Internet Information Services to host CRL distribution point](#configure-internet-information-services-to-host-crl-distribution-point) -- [Prepare a file share to host the certificate revocation list](#prepare-a-file-share-to-host-the-certificate-revocation-list) -- [Configure the new CRL distribution point and Publishing location in the issuing certificate authority](#configure-the-new-crl-distribution-point-and-publishing-location-in-the-issuing-certificate-authority) -- [Publish CRL](#publish-a-new-crl) -- [Reissue domain controller certificates](#reissue-domain-controller-certificates) - - -### Configure Internet Information Services to host CRL distribution point - -You need to host your new certificate revocation list of a web server so Azure AD-joined devices can easily validate certificates without authentication. You can host these files on web servers many ways. The following steps are just one and may be useful for admins unfamiliar with adding a new CRL distribution point. - -> [!IMPORTANT] -> Do not configure the IIS server hosting your CRL distribution point to use https or a server authentication certificate. Clients should access the distribution point using http. - -#### Installing the Web Server - -1. Sign-in to your server as a local administrator and start **Server Manager** if it didn't start during your sign in. -2. Select the **Local Server** node in the navigation pane. Select **Manage** and select **Add Roles and Features**. -3. In the **Add Role and Features Wizard**, select **Server Selection**. Verify the selected server is the local server. Select **Server Roles**. Select the check box next to **Web Server (IIS)**. -4. Select **Next** through the remaining options in the wizard, accepting the defaults, and install the Web Server role. - -#### Configure the Web Server - -1. From **Windows Administrative Tools**, Open **Internet Information Services (IIS) Manager**. -2. Expand the navigation pane to show **Default Web Site**. Select and then right-click **Default Web site** and select **Add Virtual Directory...**. -3. In the **Add Virtual Directory** dialog box, type **cdp** in **alias**. For physical path, type or browse for the physical file location where you'll host the certificate revocation list. For this example, the path **c:\cdp** is used. Select **OK**. - ![Add Virtual Directory.](images/aadj/iis-add-virtual-directory.png) - > [!NOTE] - > Make note of this path as you will use it later to configure share and file permissions. - -4. Select **CDP** under **Default Web Site** in the navigation pane. Double-click **Directory Browsing** in the content pane. Select **Enable** in the details pane. -5. Select **CDP** under **Default Web Site** in the navigation pane. Double-click **Configuration Editor**. -6. In the **Section** list, navigate to **system.webServer/security/requestFiltering**. - ![IIS Configuration Editor requestFiltering.](images/aadj/iis-config-editor-requestFiltering.png) - In the list of named value-pairs in the content pane, configure **allowDoubleEscaping** to **True**. Select **Apply** in the actions pane. - ![IIS Configuration Editor double escaping.](images/aadj/iis-config-editor-allowDoubleEscaping.png) -7. Close **Internet Information Services (IIS) Manager**. - -#### Create a DNS resource record for the CRL distribution point URL - -1. On your DNS server or from an administrative workstation, open **DNS Manager** from **Administrative Tools**. -2. Expand **Forward Lookup Zones** to show the DNS zone for your domain. Right-click your domain name in the navigation pane and select **New Host (A or AAAA)...**. -3. In the **New Host** dialog box, type **crl** in **Name**. Type the IP address of the web server you configured in **IP Address**. Select **Add Host**. Select **OK** to close the **DNS** dialog box. Select **Done**. -![Create DNS host record.](images/aadj/dns-new-host-dialog.png) -4. Close the **DNS Manager**. - -### Prepare a file share to host the certificate revocation list - -These procedures configure NTFS and share permissions on the web server to allow the certificate authority to automatically publish the certificate revocation list. - -#### Configure the CDP file share - -1. On the web server, open **Windows Explorer** and navigate to the **cdp** folder you created in step 3 of [Configure the Web Server](#configure-the-web-server). -2. Right-click the **cdp** folder and select **Properties**. Select the **Sharing** tab. Select **Advanced Sharing**. -3. Select **Share this folder**. Type **cdp$** in **Share name**. Select **Permissions**. -![cdp sharing.](images/aadj/cdp-sharing.png) -4. In the **Permissions for cdp$** dialog box, select **Add**. -5. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, select **Object Types**. In the **Object Types** dialog box, select **Computers**, and then select **OK**. -7. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, in **Enter the object names to select**, type the name of the server running the certificate authority issuing the certificate revocation list, and then select **Check Names**. Select **OK**. -8. In the **Permissions for cdp$** dialog box, select the certificate authority from the **Group or user names list**. In the **Permissions for** section, select **Allow** for **Full control**. Select **OK**. -![CDP Share Permissions.](images/aadj/cdp-share-permissions.png) -9. In the **Advanced Sharing** dialog box, select **OK**. - -> [!Tip] -> Make sure that users can access **\\\Server FQDN\sharename**. - -#### Disable Caching -1. On the web server, open **Windows Explorer** and navigate to the **cdp** folder you created in step 3 of [Configure the Web Server](#configure-the-web-server). -2. Right-click the **cdp** folder and select **Properties**. Select the **Sharing** tab. Select **Advanced Sharing**. -3. Select **Caching**. Select **No files or programs from the shared folder are available offline**. -![CDP disable caching.](images/aadj/cdp-disable-caching.png) -4. Select **OK**. - -#### Configure NTFS permission for the CDP folder - -1. On the web server, open **Windows Explorer** and navigate to the **cdp** folder you created in step 3 of [Configure the Web Server](#configure-the-web-server). -2. Right-click the **cdp** folder and select **Properties**. Select the **Security** tab. -3. On the **Security** tab, select Edit. -5. In the **Permissions for cdp** dialog box, select **Add**. -![CDP NTFS Permissions.](images/aadj/cdp-ntfs-permissions.png) -6. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, select **Object Types**. In the **Object Types** dialog box, select **Computers**. Select **OK**. -7. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, in **Enter the object names to select**, type the name of the certificate authority, and then select **Check Names**. Select **OK**. -8. In the **Permissions for cdp** dialog box, select the name of the certificate authority from the **Group or user names** list. In the **Permissions for** section, select **Allow** for **Full control**. Select **OK**. -9. Select **Close** in the **cdp Properties** dialog box. - - -### Configure the new CRL distribution point and Publishing location in the issuing certificate authority - -The web server is ready to host the CRL distribution point. Now, configure the issuing certificate authority to publish the CRL at the new location and to include the new CRL distribution point - - -#### Configure the CRL distribution Point -1. On the issuing certificate authority, sign-in as a local administrator. Start the **Certificate Authority** console from **Administrative Tools**. -2. In the navigation pane, right-click the name of the certificate authority and select **Properties** -3. Select **Extensions**. On the **Extensions** tab, select **CRL Distribution Point (CDP)** from the **Select extension** list. -4. On the **Extensions** tab, select **Add**. Type http://crl.[domainname]/cdp/ in **location**. For example, `` or `` (don't forget the trailing forward slash). - ![CDP New Location dialog box.](images/aadj/cdp-extension-new-location.png) -5. Select **\** from the **Variable** list and select **Insert**. Select **\** from the **Variable** list and select **Insert**. Select **\** from the **Variable** list and select **Insert**. -6. Type **.crl** at the end of the text in **Location**. Select **OK**. -7. Select the CDP you just created. - ![CDP complete http.](images/aadj/cdp-extension-complete-http.png) -8. Select **Include in CRLs. Clients use this to find Delta CRL locations**. -9. Select **Include in the CDP extension of issued certificates**. -10. Select **Apply** save your selections. Select **No** when ask to restart the service. - -> [!NOTE] -> Optionally, you can remove unused CRL distribution points and publishing locations. - -#### Configure the CRL publishing location - -1. On the issuing certificate authority, sign-in as a local administrator. Start the **Certificate Authority** console from **Administrative Tools**. -2. In the navigation pane, right-click the name of the certificate authority and select **Properties** -3. Select **Extensions**. On the **Extensions** tab, select **CRL Distribution Point (CDP)** from the **Select extension** list. -4. On the **Extensions** tab, select **Add**. Type the computer and share name you create for your CRL distribution point in [Configure the CDP file share](#configure-the-cdp-file-share). For example, **\\\app\cdp$\\** (don't forget the trailing backwards slash). -5. Select **\** from the **Variable** list and select **Insert**. Select **\** from the **Variable** list and select **Insert**. Select **\** from the **Variable** list and select **Insert**. -6. Type **.crl** at the end of the text in **Location**. Select **OK**. -7. Select the CDP you just created.
- ![CDP publishing location.](images/aadj/cdp-extension-complete-unc.png) -8. Select **Publish CRLs to this location**. -9. Select **Publish Delta CRLs to this location**. -10. Select **Apply** save your selections. Select **Yes** when ask to restart the service. Select **OK** to close the properties dialog box. - -### Publish a new CRL - -1. On the issuing certificate authority, sign-in as a local administrator. Start the **Certificate Authority** console from **Administrative Tools**. -2. In the navigation pane, right-click **Revoked Certificates**, hover over **All Tasks**, and select **Publish** -![Publish a New CRL.](images/aadj/publish-new-crl.png) -3. In the **Publish CRL** dialog box, select **New CRL** and select **OK**. - -#### Validate CDP Publishing - -Validate your new CRL distribution point is working. - -1. Open a web browser. Navigate to `http://crl.[yourdomain].com/cdp`. You should see two files created from publishing your new CRL. - ![Validate the new CRL.](images/aadj/validate-cdp-using-browser.png) - -### Reissue domain controller certificates - -With the CA properly configured with a valid HTTP-based CRL distribution point, you need to reissue certificates to domain controllers as the old certificate doesn't have the updated CRL distribution point. - -1. Sign-in a domain controller using administrative credentials. -2. Open the **Run** dialog box. Type **certlm.msc** to open the **Certificate Manager** for the local computer. -3. In the navigation pane, expand **Personal**. Select **Certificates**. In the details pane, select the existing domain controller certificate includes **KDC Authentication** in the list of **Intended Purposes**. -![Certificate Manager Personal store.](images/aadj/certlm-personal-store.png) -4. Right-click the selected certificate. Hover over **All Tasks** and then select **Renew Certificate with New Key...**. In the **Certificate Enrollment** wizard, select **Next**. -![Renew with New key.](images/aadj/certlm-renew-with-new-key.png) -5. In the **Request Certificates** page of the wizard, verify the selected certificate has the correct certificate template and ensure the status is available. Select **Enroll**. -6. After the enrollment completes, select **Finish** to close the wizard. -7. Repeat this procedure on all your domain controllers. - -> [!NOTE] -> You can configure domain controllers to automatically enroll and renew their certificates. Automatic certificate enrollment helps prevent authentication outages due to expired certificates. Refer to the [Windows Hello Deployment Guides](./hello-deployment-guide.md) to learn how to deploy automatic certificate enrollment for domain controllers. - -> [!IMPORTANT] -> If you are not using automatic certificate enrollment, create a calendar reminder to alert you two months before the certificate expiration date. Send the reminder to multiple people in the organization to ensure more than one or two people know when these certificates expire. - -#### Validate CDP in the new certificate - -1. Sign-in a domain controller using administrative credentials. -2. Open the **Run** dialog box. Type **certlm.msc** to open the **Certificate Manager** for the local computer. -3. In the navigation pane, expand **Personal**. Select **Certificates**. In the details pane, double-click the existing domain controller certificate includes **KDC Authentication** in the list of **Intended Purposes**. -4. Select the **Details** tab. Scroll down the list until **CRL Distribution Points** is visible in the **Field** column of the list. Select **CRL Distribution Point**. -5. Review the information below the list of fields to confirm the new URL for the CRL distribution point is present in the certificate. Select **OK**.
-![New Certificate with updated CDP.](images/aadj/dc-cert-with-new-cdp.png) - -## Configure and Assign a Trusted Certificate Device Configuration Profile - -Your domain controllers have new certificates that include the new CRL distribution point. Next, you need your enterprise root certificate so you can deploy it to Azure AD-joined devices. When you deploy the enterprise root certificates to the device, it ensures the device trusts any certificates issued by the certificate authority. Without the certificate, Azure AD-joined devices don't trust domain controller certificates and authentication fails. - -Steps you'll perform include: -- [Export Enterprise Root certificate](#export-enterprise-root-certificate) -- [Create and Assign a Trust Certificate Device Configuration Profile](#create-and-assign-a-trust-certificate-device-configuration-profile) - -### Export Enterprise Root certificate - -1. Sign-in a domain controller using administrative credentials. -2. Open the **Run** dialog box. Type **certlm.msc** to open the **Certificate Manager** for the local computer. -3. In the navigation pane, expand **Personal**. Select **Certificates**. In the details pane, double-click the existing domain controller certificate includes **KDC Authentication** in the list of **Intended Purposes**. -4. Select the **Certification Path** tab. In the **Certification path** view, select the topmost node and select **View Certificate**. -![Certificate Path.](images/aadj/certlm-cert-path-tab.png) -5. In the new **Certificate** dialog box, select the **Details** tab. Select **Copy to File**. -![Details tab and copy to file.](images/aadj/certlm-root-cert-details-tab.png) -6. In the **Certificate Export Wizard**, select **Next**. -7. On the **Export File Format** page of the wizard, select **Next**. -8. On the **File to Export** page in the wizard, type the name and location of the root certificate and select **Next**. Select **Finish** and then select **OK** to close the success dialog box.
-![Export root certificate.](images/aadj/certlm-export-root-certificate.png) -9. Select **OK** two times to return to the **Certificate Manager** for the local computer. Close the **Certificate Manager**. - -### Create and Assign a Trust Certificate Device Configuration Profile - -A **Trusted Certificate** device configuration profile is how you deploy trusted certificates to Azure AD-joined devices. - -1. Sign-in to the [Microsoft Azure portal](https://portal.azure.com) and select **Microsoft Intune**. -2. Select **Device configuration**. In the **Device Configuration** blade, select **Create profile**. -![Intune Create Profile.](images/aadj/intune-create-device-config-profile.png) -3. In the **Create profile** blade, type **Enterprise Root Certificate** in **Name**. Provide a description. Select **Windows 10 and later** from the **Platform** list. Select **Trusted certificate** from the **Profile type** list. Select **Configure**. -4. In the **Trusted Certificate** blade, use the folder icon to browse for the location of the enterprise root certificate file you created in step 8 of [Export Enterprise Root certificate](#export-enterprise-root-certificate). Select **OK**. Select **Create**. -![Intune Trusted Certificate Profile.](images/aadj/intune-create-trusted-certificate-profile.png) -5. In the **Enterprise Root Certificate** blade, select **Assignments**. In the **Include** tab, select **All Devices** from the **Assign to** list. Select **Save**. -![Intune Profile assignment.](images/aadj/intune-device-config-enterprise-root-assignment.png) -6. Sign out of the Microsoft Azure portal. -> [!NOTE] -> After the creation, the **supported platform** parameter of the profile will contain the value "Windows 8.1 and later", as the certificate configuration for Windows 8.1 and Windows 10 is the same. - -## Configure Windows Hello for Business Device Enrollment - -Sign-in a workstation with access equivalent to a _domain user_. - -1. Sign in to the [Microsoft Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431). -2. Select **Devices**. -3. Choose **Enroll devices**. -4. Select **Windows enrollment**. -5. Under **Windows enrollment**, select **Windows Hello for Business**. - ![Create Windows Hello for Business Policy.](images/aadj/MEM.png) -6. Select **Enabled** from the **Configure Windows Hello for Business** list. -7. Select **Required** next to **Use a Trusted Platform Module (TPM)**. By default, Windows Hello for Business prefers TPM 2.0 or falls backs to software. Choosing **Required** forces Windows Hello for Business to only use TPM 2.0 or TPM 1.2 and doesn't allow fall back to software-based keys. -8. Enter the desired **Minimum PIN length** and **Maximum PIN length**. - > [!IMPORTANT] - > The default minimum PIN length for Windows Hello for Business on Windows 10 and Windows 11 is six. Microsoft Intune defaults the minimum PIN length to four, which reduces the security of the user's PIN. If you do not have a desired PIN length, set the minimum PIN length to six. - -9. Select the appropriate configuration for the following settings: - * **Lowercase letters in PIN** - * **Uppercase letters in PIN** - * **Special characters in PIN** - * **PIN expiration (days)** - * **Remember PIN history** - - > [!NOTE] - > The Windows Hello for Business PIN is not a symmetric key (a password). A copy of the current PIN is not stored locally or on a server like in the case of passwords. Making the PIN as complex and changed frequently as a password increases the likelihood of forgotten PINs. Additionally, enabling PIN history is the only scenario that requires Windows to store older PIN combinations (protected to the current PIN). Windows Hello for Business combined with a TPM provides anti-hammering functionality that prevents brute force attacks of the user's PIN. If you are concerned with user-to-user shoulder surfacing, rather that forcing complex PIN that change frequently, consider using the [Multifactor Unlock](feature-multifactor-unlock.md) feature. - -10. Select **Yes** next to **Allow biometric authentication** if you want to allow users to use biometrics (fingerprint and/or facial recognition) to unlock the device. To further secure the use of biometrics, select **Yes** to **Use enhanced anti-spoofing, when available**. -11. Select **No** to **Allow phone sign-in**. This feature has been deprecated. -12. Choose **Save**. -13. Sign out of the Microsoft Endpoint Manager admin center. - -> [!IMPORTANT] -> For more details about the actual experience after everything has been configured, please see [Windows Hello for Business and Authentication](./hello-how-it-works-authentication.md). - -> [!NOTE] -> For access issues in the context of VPN, make sure to check the resolution and workaround described in [Workaround for user security context and access control](/troubleshoot/windows-client/group-policy/group-membership-changes-not-updating-over-some-vpn-connections#workarounds). - -## Section Review -> [!div class="checklist"] -> * Configure Internet Information Services to host CRL distribution point -> * Prepare a file share to host the certificate revocation list -> * Configure the new CRL distribution point in the issuing certificate authority -> * Publish CRL -> * Reissue domain controller certificates -> * Export Enterprise Root certificate -> * Create and Assign a Trust Certificate Device Configuration Profile -> * Configure Windows Hello for Business Device Enrollment - -If you plan on using certificates for on-premises single-sign on, perform the additional steps in [Using Certificates for On-premises Single-sign On](hello-hybrid-aadj-sso-cert.md). diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md index e8e87a1d23..2cc6e81fff 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md @@ -4,12 +4,12 @@ description: If you want to use certificates for on-premises single-sign on for ms.date: 08/19/2018 appliesto: - ✅ Windows 10 and later -ms.topic: article +ms.topic: how-to --- # Using Certificates for AADJ On-premises Single-sign On -[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cert-trust-aad.md)] +[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-cert-trust-aad.md)] If you plan to use certificates for on-premises single-sign on, then follow these **additional** steps to configure the environment to enroll Windows Hello for Business certificates for Azure AD-joined devices. diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso.md index 1acc6aa213..22d0a585f9 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso.md @@ -1,37 +1,255 @@ --- -title: Azure AD Join Single Sign-on Deployment -description: Learn how to provide single sign-on to your on-premises resources for Azure Active Directory-joined devices, using Windows Hello for Business. -ms.date: 08/19/2018 +title: Configure single sign-on (SSO) for Azure AD joined devices +description: Learn how to configure single sign-on to on-premises resources for Azure AD-joined devices, using Windows Hello for Business. +ms.date: 12/30/2022 appliesto: - ✅ Windows 10 and later ms.topic: article --- -# Azure AD Join Single Sign-on Deployment +# Configure single sign-on for Azure AD joined devices -[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-keycert-trust-aad.md)] +[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-keycert-trust-aad.md)] -Windows Hello for Business combined with Azure Active Directory-joined devices makes it easy for users to securely access cloud-based resources using a strong, two-factor credential. Some resources may remain on-premises as enterprises transition resources to the cloud and Azure AD-joined devices may need to access these resources. With additional configurations to your current hybrid deployment, you can provide single sign-on to your on-premises resources for Azure Active Directory-joined devices using Windows Hello for Business, using a key or a certificate. +Windows Hello for Business combined with Azure AD-joined devices makes it easy for users to securely access cloud-based resources using a strong, two-factor credential. Some resources may remain on-premises as enterprises transition resources to the cloud and Azure AD-joined devices may need to access these resources. With additional configurations to the hybrid deployment, you can provide single sign-on to on-premises resources for Azure AD-joined devices using Windows Hello for Business, using a key or a certificate. -## Key vs. Certificate +> [!NOTE] +> These steps are not needed when using the cloud Kerberos trust model. -Enterprises can use either a key or a certificate to provide single-sign on for on-premises resources. Both types of authentication provide the same security; one is not more secure than the other. +## Prerequisites -When using a key, the on-premises environment needs an adequate distribution of Windows Server 2016 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 Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more. +Unlike hybrid Azure AD-joined devices, Azure AD-joined devices don't have a relationship with your Active Directory domain. This factor changes the way in which users authenticate to Active Directory. Validate the following configurations to ensure they support Azure AD-joined devices: -When using a certificate, the on-premises environment can use Windows Server 2008 R2 and later domain controllers, which removes the Windows Server 2016 domain controller requirement. However, single-sign on using a certificate requires additional infrastructure to issue a certificate when the user enrolls for Windows Hello for Business. Azure AD-joined devices enroll certificates using Microsoft Intune or a compatible Mobile Device Management (MDM). Microsoft Intune and Windows Hello for Business use the Network Device Enrollment Services (NDES) role and support Microsoft Intune connector. +> [!div class="checklist"] +> - Certificate Revocation List (CRL) Distribution Point +> - Domain controller certificates +> - Network infrastructure in place to reach the on-premises domain controllers. If the machines are external, you can use any VPN solution -To deploy single sign-on for Azure AD-joined devices using keys, read and follow [Configure Azure AD-joined devices for On-premises Single-Sign On using Windows Hello for Business](hello-hybrid-aadj-sso-base.md). -To deploy single sign-on for Azure AD-joined devices using certificates, read and follow [Configure Azure AD-joined devices for On-premises Single-Sign On using Windows Hello for Business](hello-hybrid-aadj-sso-base.md) and then [Using Certificates for Azure Active Directory-joined On-premises Single-sign On](hello-hybrid-aadj-sso-cert.md). +### CRL Distribution Point (CDP) -## Related topics +Certificates issued by a certificate authority can be revoked. When a certificate authority revokes as certificate, it writes information about the certificate into a *certificate revocation list* (CRL).\ +During certificate validation, Windows compares the current certificate with information in the CRL to determine if the certificate is valid. -- [Windows Hello for Business](hello-identity-verification.md) -- [How Windows Hello for Business works](hello-how-it-works.md) -- [Manage Windows Hello for Business in your organization](hello-manage-in-organization.md) -- [Why a PIN is better than a password](hello-why-pin-is-better-than-password.md) -- [Prepare people to use Windows Hello](hello-prepare-people-to-use.md) -- [Windows Hello errors during PIN creation](hello-errors-during-pin-creation.md) -- [Event ID 300 - Windows Hello successfully created](hello-event-300.md) -- [Windows Hello biometrics in the enterprise](hello-biometrics-in-enterprise.md) +![Domain Controller Certificate with LDAP CDP.](images/aadj/Certificate-CDP.png) +The preceding domain controller certificate shows a *CRL distribution point* (CDP) in Active Directory. The value in the URL begins with *ldap*. Using Active Directory for domain joined devices provides a highly available CRL distribution point. However, Azure AD joined devices can't read data from Active Directory, and certificate validation doesn't provide an opportunity to authenticate prior to reading the CRL. The authentication becomes a circular problem: the user is attempting to authenticate, but must read Active Directory to complete the authentication, but the user can't read Active Directory because they haven't authenticated. +To resolve this issue, the CRL distribution point must be a location accessible by Azure AD joined devices that doesn't require authentication. The easiest solution is to publish the CRL distribution point on a web server that uses HTTP (not HTTPS). + +If your CRL distribution point doesn't list an HTTP distribution point, then you need to reconfigure the issuing certificate authority to include an HTTP CRL distribution point, preferably first, in the list of distribution points. + +> [!NOTE] +> If your CA has published both the *Base* and the *Delta CRL*, make sure to publish the *Delta CRL* in the HTTP path. Include web server to fetch the *Delta CRL* by allowing **double escaping** in the (IIS) web server. + +### Domain controller certificates + +Certificate authorities write CDP information in certificates as they're issued. If the distribution point changes, then previously issued certificates must be reissued for the certificate authority to include the new CDP. The domain controller certificate is one the critical components of Azure AD-joined devices authenticating to Active Directory. + +#### Why does Windows need to validate the domain controller certificate? + +Windows Hello for Business enforces the strict KDC validation security feature when authenticating from an Azure AD joined device to a domain. This enforcement imposes more restrictive criteria that must be met by the Key Distribution Center (KDC). When authenticating using Windows Hello for Business on an Azure AD joined device, the Windows client validates the reply from the domain controller by ensuring all of the following are met: + +- The domain controller has the private key for the certificate provided +- The root CA that issued the domain controller's certificate is in the device's *Trusted Root Certificate Authorities* +- Use the *Kerberos Authentication certificate template* instead of any other older template +- The domain controller's certificate has the *KDC Authentication* extended key usage (EKU) +- The domain controller's certificate's subject alternate name has a DNS Name that matches the name of the domain +- The domain controller's certificate's signature hash algorithm is **sha256** +- The domain controller's certificate's public key is **RSA (2048 Bits)** + +Authenticating from a Hybrid Azure AD joined device to a domain using Windows Hello for Business doesn't enforce that the domain controller certificate includes the *KDC Authentication* EKU. If you're adding Azure AD-joined devices to an existing domain environment, make sure to verify that your domain controller certificate has been updated to include the *KDC Authentication* EKU. + +## Configure a CRL distribution point for an issuing CA + +Use this set of procedures to update the CA that issues domain controller certificates to include an http-based CRL distribution point. + +### Configure Internet Information Services to host CRL distribution point + +You need to host your new certificate revocation list on a web server so Azure AD-joined devices can easily validate certificates without authentication. You can host these files on web servers many ways. The following steps are just one and may be useful for admins unfamiliar with adding a new CRL distribution point. + +> [!IMPORTANT] +> Do not configure the IIS server hosting your CRL distribution point to use https or a server authentication certificate. Clients should access the distribution point using http. + +### Install the web server + +1. Sign-in to your server as a local administrator and start **Server Manager** if it didn't start during your sign in +1. Select the **Local Server** node in the navigation pane. Select **Manage** and select **Add Roles and Features** +1. In the **Add Role and Features Wizard**, select **Server Selection**. Verify the selected server is the local server. Select **Server Roles**. Select the check box next to **Web Server (IIS)** +1. Select **Next** through the remaining options in the wizard, accepting the defaults, and install the Web Server role + +### Configure the web server + +1. From **Windows Administrative Tools**, Open **Internet Information Services (IIS) Manager** +1. Expand the navigation pane to show **Default Web Site**. Select and then right-click **Default Web site** and select **Add Virtual Directory...** +1. In the **Add Virtual Directory** dialog box, type **cdp** in **alias**. For physical path, type or browse for the physical file location where you'll host the certificate revocation list. For this example, the path `c:\cdp` is used. Select **OK** + ![Add Virtual Directory.](images/aadj/iis-add-virtual-directory.png) + > [!NOTE] + > Make note of this path as you will use it later to configure share and file permissions. + +1. Select **CDP** under **Default Web Site** in the navigation pane. Open **Directory Browsing** in the content pane. Select **Enable** in the details pane +1. Select **CDP** under **Default Web Site** in the navigation pane. Open **Configuration Editor** +1. In the **Section** list, navigate to **system.webServer/security/requestFiltering** + ![IIS Configuration Editor requestFiltering.](images/aadj/iis-config-editor-requestFiltering.png) +1. In the list of named value-pairs in the content pane, configure **allowDoubleEscaping** to **True**. Select **Apply** in the actions pane + ![IIS Configuration Editor double escaping.](images/aadj/iis-config-editor-allowDoubleEscaping.png) +1. Close **Internet Information Services (IIS) Manager** + +### Create a DNS resource record for the CRL distribution point URL + +1. On your DNS server or from an administrative workstation, open **DNS Manager** from **Administrative Tools** +1. Expand **Forward Lookup Zones** to show the DNS zone for your domain. Right-click your domain name in the navigation pane and select **New Host (A or AAAA)...** +1. In the **New Host** dialog box, type **crl** in **Name**. Type the IP address of the web server you configured in **IP Address**. Select **Add Host**. Select **OK** to close the **DNS** dialog box. Select **Done** + ![Create DNS host record.](images/aadj/dns-new-host-dialog.png) +1. Close the **DNS Manager** + +### Prepare a file share to host the certificate revocation list + +These procedures configure NTFS and share permissions on the web server to allow the certificate authority to automatically publish the certificate revocation list. + +### Configure the CDP file share + +1. On the web server, open **Windows Explorer** and navigate to the **cdp** folder you created in step 3 of [Configure the Web Server](#configure-the-web-server) +1. Right-click the **cdp** folder and select **Properties**. Select the **Sharing** tab. Select **Advanced Sharing** +1. Select **Share this folder**. Type **cdp$** in **Share name**. Select **Permissions** + ![cdp sharing.](images/aadj/cdp-sharing.png) +1. In the **Permissions for cdp$** dialog box, select **Add** +1. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, select **Object Types**. In the **Object Types** dialog box, select **Computers**, and then select **OK** +1. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, in **Enter the object names to select**, type the name of the server running the certificate authority issuing the certificate revocation list, and then select **Check Names**. Select **OK** +1. In the **Permissions for cdp$** dialog box, select the certificate authority from the **Group or user names list**. In the **Permissions for** section, select **Allow** for **Full control**. Select **OK** + ![CDP Share Permissions.](images/aadj/cdp-share-permissions.png) +1. In the **Advanced Sharing** dialog box, select **OK** + +> [!Tip] +> Make sure that users can access **\\\Server FQDN\sharename**. + +### Disable Caching +1. On the web server, open **Windows Explorer** and navigate to the **cdp** folder you created in step 3 of [Configure the Web Server](#configure-the-web-server) +1. Right-click the **cdp** folder and select **Properties**. Select the **Sharing** tab. Select **Advanced Sharing** +1. Select **Caching**. Select **No files or programs from the shared folder are available offline** + ![CDP disable caching.](images/aadj/cdp-disable-caching.png) +1. Select **OK** + +### Configure NTFS permission for the CDP folder + +1. On the web server, open **Windows Explorer** and navigate to the **cdp** folder you created in step 3 of [Configure the Web Server](#configure-the-web-server) +1. Right-click the **cdp** folder and select **Properties**. Select the **Security** tab +1. On the **Security** tab, select Edit +1. In the **Permissions for cdp** dialog box, select **Add** + ![CDP NTFS Permissions.](images/aadj/cdp-ntfs-permissions.png) +1. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, select **Object Types**. In the **Object Types** dialog box, select **Computers**. Select **OK** +1. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, in **Enter the object names to select**, type the name of the certificate authority, and then select **Check Names**. Select **OK** +1. In the **Permissions for cdp** dialog box, select the name of the certificate authority from the **Group or user names** list. In the **Permissions for** section, select **Allow** for **Full control**. Select **OK** +1. Select **Close** in the **cdp Properties** dialog box + +### Configure the new CDP and publishing location in the issuing CA + +The web server is ready to host the CRL distribution point. Now, configure the issuing certificate authority to publish the CRL at the new location and to include the new CRL distribution point. + +#### Configure the CRL distribution Point + +1. On the issuing certificate authority, sign-in as a local administrator. Start the **Certification Authority** console from **Administrative Tools** +1. In the navigation pane, right-click the name of the certificate authority and select **Properties** +1. Select **Extensions**. On the **Extensions** tab, select **CRL Distribution Point (CDP)** from the **Select extension** list +1. On the **Extensions** tab, select **Add**. Type http://crl.[domainname]/cdp/ in **location**. For example, `` or `` (don't forget the trailing forward slash) + ![CDP New Location dialog box.](images/aadj/cdp-extension-new-location.png) +1. Select **\** from the **Variable** list and select **Insert**. Select **\** from the **Variable** list and select **Insert**. Select **\** from the **Variable** list and select **Insert** +1. Type **.crl** at the end of the text in **Location**. Select **OK** +1. Select the CDP you just created + ![CDP complete http.](images/aadj/cdp-extension-complete-http.png) +1. Select **Include in CRLs. Clients use this to find Delta CRL locations** +1. Select **Include in the CDP extension of issued certificates** +1. Select **Apply** save your selections. Select **No** when ask to restart the service + +> [!NOTE] +> Optionally, you can remove unused CRL distribution points and publishing locations. + +#### Configure the CRL publishing location + +1. On the issuing certificate authority, sign-in as a local administrator. Start the **Certificate Authority** console from **Administrative Tools** +1. In the navigation pane, right-click the name of the certificate authority and select **Properties** +1. Select **Extensions**. On the **Extensions** tab, select **CRL Distribution Point (CDP)** from the **Select extension** list +1. On the **Extensions** tab, select **Add**. Type the computer and share name you create for your CRL distribution point in [Configure the CDP file share](#configure-the-cdp-file-share). For example, **\\\app\cdp$\\** (don't forget the trailing backwards slash) +1. Select **\** from the **Variable** list and select **Insert**. Select **\** from the **Variable** list and select **Insert**. Select **\** from the **Variable** list and select **Insert** +1. Type **.crl** at the end of the text in **Location**. Select **OK** +1. Select the CDP you just created + ![CDP publishing location.](images/aadj/cdp-extension-complete-unc.png) +1. Select **Publish CRLs to this location** +1. Select **Publish Delta CRLs to this location** +1. Select **Apply** save your selections. Select **Yes** when ask to restart the service. Select **OK** to close the properties dialog box + +#### Publish a new CRL + +1. On the issuing certificate authority, sign-in as a local administrator. Start the **Certificate Authority** console from **Administrative Tools** +1. In the navigation pane, right-click **Revoked Certificates**, hover over **All Tasks**, and select **Publish** + ![Publish a New CRL.](images/aadj/publish-new-crl.png) +1. In the **Publish CRL** dialog box, select **New CRL** and select **OK** + +#### Validate CDP Publishing + +Validate the new CRL distribution point is working. + +1. Open a web browser. Navigate to `http://crl.[yourdomain].com/cdp`. You should see two files created from publishing the new CRL + ![Validate the new CRL.](images/aadj/validate-cdp-using-browser.png) + +#### Reissue domain controller certificates + +With the CA properly configured with a valid HTTP-based CRL distribution point, you need to reissue certificates to domain controllers as the old certificate doesn't have the updated CRL distribution point. + +1. Sign-in a domain controller using administrative credentials +1. Open the **Run** dialog box. Type **certlm.msc** to open the **Certificate Manager** for the local computer +1. In the navigation pane, expand **Personal**. Select **Certificates**. In the details pane, select the existing domain controller certificate that includes **KDC Authentication** in the list of **Intended Purposes** + ![Certificate Manager Personal store.](images/aadj/certlm-personal-store.png) +1. Right-click the selected certificate. Hover over **All Tasks** and then select **Renew Certificate with New Key...**. In the **Certificate Enrollment** wizard, select **Next** + ![Renew with New key.](images/aadj/certlm-renew-with-new-key.png) +1. In the **Request Certificates** page of the wizard, verify the selected certificate has the correct certificate template and ensure the status is available. Select **Enroll** +1. After the enrollment completes, select **Finish** to close the wizard +1. Repeat this procedure on all your domain controllers + +> [!NOTE] +> You can configure domain controllers to automatically enroll and renew their certificates. Automatic certificate enrollment helps prevent authentication outages due to expired certificates. Refer to the [Windows Hello Deployment Guides](./hello-deployment-guide.md) to learn how to deploy automatic certificate enrollment for domain controllers. + +> [!IMPORTANT] +> If you are not using automatic certificate enrollment, create a calendar reminder to alert you two months before the certificate expiration date. Send the reminder to multiple people in the organization to ensure more than one or two people know when these certificates expire. + +#### Validate CDP in the new certificate + +1. Sign-in a domain controller using administrative credentials +1. Open the **Run** dialog box. Type **certlm.msc** to open the **Certificate Manager** for the local computer +1. In the navigation pane, expand **Personal**. Select **Certificates**. In the details pane, double-click the existing domain controller certificate includes **KDC Authentication** in the list of **Intended Purposes** +1. Select the **Details** tab. Scroll down the list until **CRL Distribution Points** is visible in the **Field** column of the list. Select **CRL Distribution Point** +1. Review the information below the list of fields to confirm the new URL for the CRL distribution point is present in the certificate. Select **OK** + ![New Certificate with updated CDP.](images/aadj/dc-cert-with-new-cdp.png) + +## Deploy the root CA certificate to Azure AD-joined devices + +The domain controllers have a certificate that includes the new CRL distribution point. Next, you need the enterprise root certificate so you can deploy it to Azure AD-joined devices. When you deploy the enterprise root certificates to a device, it ensures the device trusts any certificates issued by the certificate authority. Without the certificate, Azure AD-joined devices don't trust domain controller certificates and authentication fails. + +### Export the enterprise root certificate + +1. Sign-in a domain controller using administrative credentials +1. Open the **Run** dialog box. Type **certlm.msc** to open the **Certificate Manager** for the local computer +1. In the navigation pane, expand **Personal**. Select **Certificates**. In the details pane, double-click the existing domain controller certificate includes **KDC Authentication** in the list of **Intended Purposes** +1. Select the **Certification Path** tab. In the **Certification path** view, select the topmost node and select **View Certificate** + ![Certificate Path.](images/aadj/certlm-cert-path-tab.png) +1. In the new **Certificate** dialog box, select the **Details** tab. Select **Copy to File** + ![Details tab and copy to file.](images/aadj/certlm-root-cert-details-tab.png) +1. In the **Certificate Export Wizard**, select **Next** +1. On the **Export File Format** page of the wizard, select **Next** +1. On the **File to Export** page in the wizard, type the name and location of the root certificate and select **Next**. Select **Finish** and then select **OK** to close the success dialog box + ![Export root certificate.](images/aadj/certlm-export-root-certificate.png) +1. Select **OK** two times to return to the **Certificate Manager** for the local computer. Close the **Certificate Manager** + +### Deploy the certificate via Intune + +To configure devices with Microsoft Intune, use a custom policy: + +1. Go to the Microsoft Endpoint Manager admin center +1. Select **Devices > Configuration profiles > Create profile** +1. Select **Platform > Windows 8.1 and later** and **Profile type > Trusted certificate** +1. Select **Create** +1. In **Configuration settings**, select the folder icon and browse for the enterprise root certificate file. Once the file is selected, select **Open** to upload it to Intune +1. Under **Destination store** dropdown, select **Computer certificate store - Root** +1. Select **Next** +1. Under **Assignment**, select a security group that contains as members the devices or users that you want to configure > **Next** +1. Review the policy configuration and select **Create** + +If you plan on using certificates for on-premises single-sign on, perform the additional steps in [Using Certificates for On-premises Single-sign On](hello-hybrid-aadj-sso-cert.md). Otherwise, you can sign in to an Azure AD joined device with Windows Hello for Business and test SSO to an on-premises resource. diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-new-install.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-new-install.md deleted file mode 100644 index 234f257566..0000000000 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-new-install.md +++ /dev/null @@ -1,138 +0,0 @@ ---- -title: Hybrid Azure AD joined Windows Hello for Business Trust New Installation (Windows Hello for Business) -description: Learn about new installations for Windows Hello for Business certificate trust and the various technologies hybrid certificate trust deployments rely on. -ms.date: 4/30/2021 -appliesto: -- ✅ Windows 10 and later -ms.topic: article ---- -# Hybrid Azure AD joined Windows Hello for Business Certificate Trust New Installation - -[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cert-trust.md)] - -Windows Hello for Business involves configuring distributed technologies that may or may not exist in your current infrastructure. Hybrid certificate trust deployments of Windows Hello for Business rely on these technologies - -- [Active Directory](#active-directory) -- [Public Key Infrastructure](#public-key-infrastructure) -- [Azure Active Directory](#azure-active-directory) -- [Multifactor Authentication Services](#multifactor-authentication-services) - -New installations are considerably more involved than existing implementations because you are building the entire infrastructure. Microsoft recommends you review the new installation baseline to validate your existing environment has all the needed configurations to support your hybrid certificate trust Windows Hello for Business deployment. If your environment meets these needs, you can read the [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md) section to prepare your Windows Hello for Business deployment by configuring Azure device registration. - -The new installation baseline begins with a basic Active Directory deployment and enterprise PKI. This document expects you have Active Directory deployed using Windows Server 2008 R2 or later domain controllers. - -## Active Directory ## - -Production environments should follow Active Directory best practices regarding the number and placement of domain controllers to ensure adequate authentication throughout the organization. - -Lab environments and isolated proof of concepts may want to limit the number of domain controllers. The purpose of these environments is to experiment and learn. Reducing the number of domain controllers can prevent troubleshooting issue, such as Active Directory replication, which is unrelated to activity's goal. - -### Section Review - -> [!div class="checklist"] -> * Minimum Windows Server 2008 R2 domain controllers -> * Minimum Windows Server 2008 R2 domain and forest functional level -> * Functional networking, name resolution, and Active Directory replication - -## Public Key Infrastructure - -Windows Hello for Business must have a public key infrastructure regardless of the deployment or trust model. All trust models depend on the domain controllers having a certificate. The certificate serves as a root of trust for clients to ensure they are not communicating with a rogue domain controller. The certificate trust model extends certificate issuance to client computers. During Windows Hello for Business provisioning, the user receives a sign-in certificate. - -This guide assumes most enterprises have an existing public key infrastructure. Windows Hello for Business depends on a Windows enterprise public key infrastructure running the Active Directory Certificate Services role from Windows Server 2012 or later. - -For more details about configuring a Windows enterprise public key infrastructure and installing Active Directory Certificate Services, see [Follow the Windows Hello for Business hybrid key trust deployment guide](/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-pki#follow-the-windows-hello-for-business-hybrid-key-trust-deployment-guide) and [Install the Certification Authority](/windows-server/networking/core-network-guide/cncg/server-certs/install-the-certification-authority). - -> [!NOTE] -> Never install a certificate authority on a domain controller in a production environment. - -### Lab-based public key infrastructure - -The following instructions may be used to deploy simple public key infrastructure that is suitable for a lab environment. - -Sign-in using _Enterprise Admin_ equivalent credentials on Windows Server 2012 or later server where you want the certificate authority installed. - -1. Open an elevated Windows PowerShell prompt. -2. Use the following command to install the Active Directory Certificate Services role. - ```PowerShell - Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools - ``` - -3. Use the following command to configure the Certificate Authority using a basic certificate authority configuration. - ```PowerShell - Install-AdcsCertificationAuthority - ``` - -### Configure a Production Public Key Infrastructure - -If you do have an existing public key infrastructure, please review [Certification Authority Guidance](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831574(v=ws.11)) from Microsoft TechNet to properly design your infrastructure. Then, consult the [Test Lab Guide: Deploying an AD CS Two-Tier PKI Hierarchy](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831348(v=ws.11)) for instructions on how to configure your public key infrastructure using the information from your design session. - -### Section Review ### - -> [!div class="checklist"] -> * Minimum Windows Server 2012 Certificate Authority. -> * Enterprise Certificate Authority. -> * Functioning public key infrastructure. - -## Azure Active Directory ## -You’ve prepared your Active Directory. Hybrid Windows Hello for Business deployment needs Azure Active Directory to host your cloud-based identities. - -The next step of the deployment is to follow the [Creating an Azure AD tenant](/azure/active-directory/develop/active-directory-howto-tenant) process to provision an Azure tenant for your organization. - -### Section Review - -> [!div class="checklist"] -> * Review the different ways to establish an Azure Active Directory tenant. -> * Create an Azure Active Directory Tenant. -> * Purchase the appropriate Azure Active Directory subscription or licenses, if necessary. - -## Multifactor Authentication Services -Windows Hello for Business uses multi-factor authentication during provisioning and during user initiated PIN reset scenarios, such as when a user forgets their PIN. There are two preferred multi-factor authentication configurations with hybrid deployments—Azure MFA and AD FS using Azure MFA - -Review the [What is Azure AD Multi-Factor Authentication](/azure/multi-factor-authentication/multi-factor-authentication) topic to familiarize yourself its purpose and how it works. - -### Azure AD Multi-Factor Authentication (MFA) Cloud ### -> [!IMPORTANT] -> As long as your users have licenses that include Azure AD Multi-Factor Authentication, there's nothing that you need to do to turn on Azure MFA. You can start requiring two-step verification on an individual user basis. The licenses that enable Azure MFA are: -> * Azure AD Multi-Factor Authentication -> * Azure Active Directory Premium -> * Enterprise Mobility + Security -> -> If you have one of these subscriptions or licenses, skip the Azure MFA Adapter section. - -#### Azure MFA Provider #### -If your organization uses Azure MFA on a per-consumption model (no licenses), then review the [Create a Multifactor Authentication Provider](/azure/multi-factor-authentication/multi-factor-authentication-get-started-auth-provider) section to create an Azure MFA Authentication provider and associate it with your Azure tenant. - -#### Configure Azure MFA Settings #### -Once you have created your Azure MFA authentication provider and associated it with an Azure tenant, you need to configure the multi-factor authentication settings. Review the [Configure Azure AD Multi-Factor Authentication settings](/azure/multi-factor-authentication/multi-factor-authentication-whats-next) section to configure your settings. - -#### Azure MFA User States #### -After you have completed configuring your Azure MFA settings, you want to review configure [User States](/azure/multi-factor-authentication/multi-factor-authentication-get-started-user-states) to understand user states. User states determine how you enable Azure MFA for your users. - -### Azure MFA via ADFS 2016 ### -Alternatively, you can configure Windows Server 2016 Active Directory Federation Services (AD FS) to provide additional multi-factor authentication. To configure, read the [Configure AD FS 2016 and Azure MFA](/windows-server/identity/ad-fs/operations/configure-ad-fs-2016-and-azure-mfa) section - -### Section Review - -> [!div class="checklist"] - -> * Review the overview and uses of Azure AD Multi-Factor Authentication Authentication. -> * Review your Azure Active Directory subscription for Azure AD Multi-Factor Authentication. -> * Create an Azure AD Multi-Factor Authentication Provider, if necessary. -> * Configure Azure AD Multi-Factor Authentication features and settings. -> * Understand the different User States and their effect on Azure AD Multi-Factor Authentication. -> * Consider using Azure AD Multi-Factor Authentication or a third-party multifactor authentication provider with Windows Server 2016 Active Directory Federation Services, if necessary. - -> [!div class="nextstepaction"] -> [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md) - -

- -
- -## Follow the Windows Hello for Business hybrid certificate trust deployment guide -1. [Overview](hello-hybrid-cert-trust.md) -2. [Prerequisites](hello-hybrid-cert-trust-prereqs.md) -3. New Installation Baseline (*You are here*) -4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md) -5. [Configure Windows Hello for Business settings](hello-hybrid-cert-whfb-settings.md) -6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md) diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-devreg.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-devreg.md deleted file mode 100644 index 997dbea6e9..0000000000 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-devreg.md +++ /dev/null @@ -1,553 +0,0 @@ ---- -title: Configure Device Registration for Hybrid Azure AD joined Windows Hello for Business -description: Azure Device Registration for Hybrid Certificate Trust Deployment (Windows Hello for Business) -ms.date: 4/30/2021 -appliesto: -- ✅ Windows 10 and later -ms.topic: article ---- -# Configure Device Registration for Hybrid Azure AD joined Windows Hello for Business - -[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cert-trust-ad.md)] - -Your environment is federated and you're ready to configure device registration for your hybrid environment. Hybrid Windows Hello for Business deployment needs device registration and device write-back to enable proper device authentication. - -> [!IMPORTANT] -> If your environment is not federated, review the [New Installation baseline](hello-hybrid-cert-new-install.md) section of this deployment document to learn how to federate your environment for your Windows Hello for Business deployment. - ->[!TIP] ->Refer to the [Tutorial: Configure hybrid Azure Active Directory join for federated domains](/azure/active-directory/devices/hybrid-azuread-join-federated-domains) to learn more about setting up Azure Active Directory Connect for a simplified join flow for Azure AD device registration. - -Use this three-phased approach for configuring device registration. - -1. [Configure devices to register in Azure](#configure-hybrid-azure-ad-join) -2. [Synchronize devices to on-premises Active Directory](#configure-active-directory-to-support-azure-device-synchronization) -3. [Configure AD FS to use cloud devices](#configure-ad-fs-to-use-azure-registered-devices) - -> [!NOTE] -> Before proceeding, you should familiarize yourself with device registration concepts such as: -> -> - Azure AD registered devices -> - Azure AD-joined devices -> - Hybrid Azure AD-joined devices -> -> You can learn about this and more by reading [Introduction to Device Management in Azure Active Directory.](/azure/active-directory/device-management-introduction) - ->[!IMPORTANT] -> To use hybrid identity with Azure Active Directory and device WriteBack features, you must use the built-in GUI with the [latest updates for ADConnect](https://www.microsoft.com/download/details.aspx?id=47594). - -## Configure Hybrid Azure AD join - -To support hybrid Windows Hello for Business, configure hybrid Azure AD join. - -Follow the guidance on [How to configure hybrid Azure Active Directory-joined devices](/azure/active-directory/devices/hybrid-azuread-join-plan) page. In the **Select your scenario based on your identity infrastructure** section, identify your configuration (either **Managed environment** or **Federated environment**) and perform only the steps applicable to your environment. - -If the user principal name (UPN) in your on-premises Active Directory is different from the UPN in Azure AD, you also need to complete the following steps: - -- Configure Azure AD Connect to sync the user's on-premises UPN to the `onPremisesUserPrincipalName attribute` in Azure AD. -- Add the domain name of the on-premises UPN as a [verified domain](/azure/active-directory/fundamentals/add-custom-domain) in Azure AD. - -You can learn more about this scenario by reading [Review on-premises UPN support for Hybrid Azure Ad join](/azure/active-directory/devices/hybrid-azuread-join-plan#review-on-premises-ad-users-upn-support-for-hybrid-azure-ad-join). - -> [!NOTE] -> Windows Hello for Business Hybrid key trust is not supported, if your users' on-premises domain cannot be added as a verified domain in Azure AD. - -## Configure Active Directory to support Azure device synchronization - -Azure Active Directory is now configured for device registration. Next, you need to configure the on-premises Active Directory to support synchronizing hybrid Azure AD-joined devices. Begin with upgrading the Active Directory Schema - -### Upgrading Active Directory to the Windows Server 2016 or later Schema - -To use Windows Hello for Business with Hybrid Azure AD-joined devices, you must first upgrade your Active Directory schema to Windows Server 2016 or later. - -> [!IMPORTANT] -> If you already have a Windows Server 2016 or later domain controller in your forest, you can skip **Upgrading Active Directory to the Windows Server 2016 or later Schema** (this section). - -#### Identify the schema role domain controller - -To locate the schema master role holder, open and command prompt and type: - -```Netdom query fsmo | findstr -i schema``` - -![Netdom example output.](images/hello-cmd-netdom.png) - -The command should return the name of the domain controller where you need to run adprep.exe. Update the schema locally on the domain controller hosting the Schema master role. - -#### Updating the Schema - -Windows Hello for Business uses asymmetric keys as user credentials (rather than passwords). During enrollment, the public key is registered in an attribute on the user object in Active Directory. The schema update adds this new attribute to Active Directory. - -Manually updating Active Directory uses the command-line utility **adprep.exe** located at **\:\support\adprep** on the Windows Server 2016 or later DVD or ISO. Before running adprep.exe, you must identify the domain controller hosting the schema master role. - -Sign-in to the domain controller hosting the schema master operational role using enterprise administrator equivalent credentials. - -1. Open an elevated command prompt. -2. Type ```cd /d x:\support\adprep``` where *x* is the drive letter of the DVD or mounted ISO. -3. To update the schema, type ```adprep /forestprep```. -4. Read the Adprep Warning. Type the letter **C*** and press **Enter** to update the schema. -5. Close the Command Prompt and sign out. - -> [!NOTE] -> If you installed Azure AD Connect prior to upgrading the schema, you will need to re-run the Azure AD Connect installation and refresh the on-premises AD schema to ensure the synchronization rule for msDS-KeyCredentialLink is configured. - -### Setup Active Directory Federation Services - -If you're new to AD FS and federation services, you should review [Understanding Key AD FS Concepts](/windows-server/identity/ad-fs/technical-reference/understanding-key-ad-fs-concepts) to prior to designing and deploying your federation service. -Review the [AD FS Design guide](/windows-server/identity/ad-fs/design/ad-fs-design-guide-in-windows-server-2012-r2) to plan your federation service. - -Once you have your AD FS design ready, review [Deploying a Federation Server farm](/windows-server/identity/ad-fs/deployment/deploying-a-federation-server-farm) to configure AD FS in your environment. -> [!IMPORTANT] -> During your AD FS deployment, skip the **Configure a federation server with Device Registration Service** and the **Configure Corporate DNS for the Federation Service and DRS** procedures. - -The AD FS farm used with Windows Hello for Business must be Windows Server 2016 with minimum update of [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889). If your AD FS farm is not running the AD FS role with updates from Windows Server 2016, then read [Upgrading to AD FS in Windows Server 2016](/windows-server/identity/ad-fs/deployment/upgrading-to-ad-fs-in-windows-server-2016) - -#### ADFS Web Proxy ### - -Federation server proxies are computers that run AD FS software that have been configured manually to act in the proxy role. You can use federation server proxies in your organization to provide intermediary services between an Internet client and a federation server that is behind a firewall on your corporate network. -Use the [Setting of a Federation Proxy](/windows-server/identity/ad-fs/deployment/checklist--setting-up-a-federation-server-proxy) checklist to configure AD FS proxy servers in your environment. - -### Deploy Azure AD Connect - -Next, you need to synchronize the on-premises Active Directory with Azure Active Directory. To do this, first review the [Integrating on-prem directories with Azure Active Directory](/azure/active-directory/connect/active-directory-aadconnect) and [hardware and prerequisites](/azure/active-directory/connect/active-directory-aadconnect-prerequisites) needed and then [download the software](https://go.microsoft.com/fwlink/?LinkId=615771). - -When you're ready to install, follow the **Configuring federation with AD FS** section of [Custom installation of Azure AD Connect](/azure/active-directory/connect/active-directory-aadconnect-get-started-custom). Select the **Federation with AD FS** option on the **User sign-in** page. At the **AD FS Farm** page, select the use an existing option and click **Next**. - -### Create AD objects for AD FS Device Authentication - -If your AD FS farm isn't already configured for Device Authentication (you can see this in the AD FS Management console under Service -> Device Registration), use the following steps to create the correct AD DS objects and configuration. -![Device Registration: AD FS](images/hybridct/device1.png) - -> [!NOTE] -> The below commands require Active Directory administration tools, so if your federation server is not also a domain controller, first install the tools using step 1 below. Otherwise you can skip step 1. - -1. Run the **Add Roles & Features** wizard and select feature **Remote Server Administration Tools** -> **Role Administration Tools** -> **AD DS and AD LDS Tools** -> Choose both the **Active Directory module for Windows PowerShell** and the **AD DS Tools**. - ![Device Registration: Overview](images/hybridct/device2.png) -2. On your AD FS primary server, ensure you're logged in as AD DS user with enterprise administrator privileges and open an elevated Windows PowerShell prompt. Then, run the following commands: - `Import-module activedirectory` - `PS C:\> Initialize-ADDeviceRegistration -ServiceAccountName ""` -3. On the pop-up window, click **Yes**. - - > [!NOTE] - > If your AD FS service is configured to use a GMSA account, enter the account name in the format "domain\accountname$" - - ![Device Registration: Domain](images/hybridct/device3.png) - The above PSH creates the following objects: - - - RegisteredDevices container under the AD domain partition - - Device Registration Service container and object under Configuration --> Services --> Device Registration Configuration - - Device Registration Service DKM container and object under Configuration --> Services --> Device Registration Configuration - - ![Device Registration: Tests](images/hybridct/device4.png)
-4. Once this is done, you'll see a successful completion message. - - ![Device Registration: Completion](images/hybridct/device5.png) - -### Create Service Connection Point (SCP) in Active Directory -If you plan to use Windows domain join (with automatic registration to Azure AD) as described here, execute the following commands to create a service connection point in AD DS - -1. Open Windows PowerShell and execute the following: - - `PS C:>Import-Module -Name "C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1"` - - > [!NOTE] - > If necessary, copy the AdSyncPrep.psm1 file from your Azure AD Connect server. This file is located in Program Files\Microsoft Azure Active Directory Connect\AdPrep - - ![Device Registration AdPrep](images/hybridct/device6.png) -2. Provide your Azure AD global administrator credentials - - `PS C:>$aadAdminCred = Get-Credential` - - ![Device Registration: Credential](images/hybridct/device7.png) -3. Run the following PowerShell command - - `PS C:>Initialize-ADSyncDomainJoinedComputerSync -AdConnectorAccount [AD connector account name] -AzureADCredentials $aadAdminCred` - - Where the [AD connector account name] is the name of the account you configured in Azure AD Connect when adding your on-premises AD DS directory. - -The above commands enable Windows clients to find the correct Azure AD domain to join by creating the serviceConnectionpoint object in AD DS. - -### Prepare AD for Device Write Back -To ensure AD DS objects and containers are in the correct state for write back of devices from Azure AD, do the following. - -1. Open Windows PowerShell and execute the following: - - `PS C:>Initialize-ADSyncDeviceWriteBack -DomainName -AdConnectorAccount [AD connector account name]` - - Where the [AD connector account name] is the name of the account you configured in Azure AD Connect when adding your on-premises AD DS directory in domain\accountname format - -The above command creates the following objects for device write back to AD DS, if they don't exist already, and allows access to the specified AD connector account name - -- RegisteredDevices container in the AD domain partition -- Device Registration Service container and object under Configuration --> Services --> Device Registration Configuration - -### Enable Device Write Back in Azure AD Connect - -If you haven't done so before, enable device write back in Azure AD Connect by running the wizard a second time and selecting **"Customize Synchronization Options"**, then checking the box for device write back and selecting the forest in which you have run the above cmdlets - -## Configure AD FS to use Azure registered devices - -### Configure issuance of claims - -In a federated Azure AD configuration, devices rely on Active Directory Federation Services (AD FS) or a third party on-premises federation service to authenticate to Azure AD. Devices authenticate to get an access token to register against the Azure Active Directory Device Registration Service (Azure DRS). - -Windows current devices authenticate using Integrated Windows Authentication to an active WS-Trust endpoint (either 1.3 or 2005 versions) hosted by the on-premises federation service. - -When you're using AD FS, you need to enable the following WS-Trust endpoints: -`/adfs/services/trust/2005/windowstransport` -`/adfs/services/trust/13/windowstransport` -`/adfs/services/trust/2005/usernamemixed` -`/adfs/services/trust/13/usernamemixed` -`/adfs/services/trust/2005/certificatemixed` -`/adfs/services/trust/13/certificatemixed` - -> [!WARNING] -> Both **adfs/services/trust/2005/windowstransport** and **adfs/services/trust/13/windowstransport** should be enabled as intranet facing endpoints only and must NOT be exposed as extranet facing endpoints through the Web Application Proxy. To learn more on how to disable WS-Trust Windows endpoints, see [Disable WS-Trust Windows endpoints on the proxy](/windows-server/identity/ad-fs/deployment/best-practices-securing-ad-fs#disable-ws-trust-windows-endpoints-on-the-proxy-ie-from-extranet). You can see what endpoints are enabled through the AD FS management console under **Service** > **Endpoints**. - -> [!NOTE] ->If you don’t have AD FS as your on-premises federation service, follow the instructions from your vendor to make sure they support WS-Trust 1.3 or 2005 endpoints and that these are published through the Metadata Exchange file (MEX). - -The following claims must exist in the token received by Azure DRS for device registration to complete. Azure DRS will create a device object in Azure AD with some of this information that is then used by Azure AD Connect to associate the newly created device object with the computer account on-premises. - -- `http://schemas.microsoft.com/ws/2012/01/accounttype` -- `http://schemas.microsoft.com/identity/claims/onpremobjectguid` -- `http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid` - -If you've more than one verified domain name, you need to provide the following claim for computers: - -- `http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid` - -If you're already issuing an ImmutableID claim (for example, alternate sign in ID) you need to provide one corresponding claim for computers: - -- `http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID` - -In the following sections, you find information about: - -- The values each claim should have -- How a definition would look like in AD FS - -The definition helps you to verify whether the values are present or if you need to create them. - -> [!NOTE] -> If you don't use AD FS for your on-premises federation server, follow your vendor's instructions to create the appropriate configuration to issue these claims. - -#### Issue account type claim - -**`http://schemas.microsoft.com/ws/2012/01/accounttype`** - This claim must contain a value of **DJ**, which identifies the device as a domain-joined computer. In AD FS, you can add an issuance transform rule that looks like this: - -```powershell - - @RuleName = "Issue account type for domain-joined computers" - c:[ - Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", - Value =~ "-515$", - Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" - ] - => issue( - Type = "http://schemas.microsoft.com/ws/2012/01/accounttype", - Value = "DJ" - ); -``` - -#### Issue objectGUID of the computer account on-premises - -**`http://schemas.microsoft.com/identity/claims/onpremobjectguid`** - This claim must contain the **objectGUID** value of the on-premises computer account. In AD FS, you can add an issuance transform rule that looks like this: - -```powershell - - @RuleName = "Issue object GUID for domain-joined computers" - c1:[ - Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", - Value =~ "-515$", - Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" - ] - && - c2:[ - Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", - Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" - ] - => issue( - store = "Active Directory", - types = ("http://schemas.microsoft.com/identity/claims/onpremobjectguid"), - query = ";objectguid;{0}", - param = c2.Value - ); -``` - -#### Issue objectSID of the computer account on-premises - -**`http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid`** - This claim must contain the **objectSid** value of the on-premises computer account. In AD FS, you can add an issuance transform rule that looks like this: - -```powershell - - @RuleName = "Issue objectSID for domain-joined computers" - c1:[ - Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", - Value =~ "-515$", - Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" - ] - && - c2:[ - Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid", - Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" - ] - => issue(claim = c2); -``` - -#### Issue issuerID for computer when multiple verified domain names in Azure AD - -**`http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid`** - This claim must contain the Uniform Resource Identifier (URI) of any of the verified domain names that connect with the on-premises federation service (AD FS or third party) issuing the token. In AD FS, you can add issuance transform rules that look like the ones below in that specific order after the ones above. Note that one rule to explicitly issue the rule for users is necessary. In the rules below, a first rule identifying user vs. computer authentication is added. - -```powershell - - @RuleName = "Issue account type with the value User when it is not a computer" - - NOT EXISTS( - [ - Type == "http://schemas.microsoft.com/ws/2012/01/accounttype", - Value == "DJ" - ] - ) - => add( - Type = "http://schemas.microsoft.com/ws/2012/01/accounttype", - Value = "User" - ); - - @RuleName = "Capture UPN when AccountType is User and issue the IssuerID" - c1:[ - Type == "http://schemas.xmlsoap.org/claims/UPN" - ] - && - c2:[ - Type == "http://schemas.microsoft.com/ws/2012/01/accounttype", - Value == "User" - ] - => issue( - Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", - Value = regexreplace( - c1.Value, - ".+@(?.+)", - "http://${domain}/adfs/services/trust/" - ) - ); - - @RuleName = "Issue issuerID for domain-joined computers" - c:[ - Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", - Value =~ "-515$", - Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" - ] - => issue( - Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", - Value = "http:///adfs/services/trust/" - ); -``` - -In the claim above, - -- `$` is the AD FS service URL -- `` is a placeholder you need to replace with one of your verified domain names in Azure AD - -For more information about verified domain names, see [Add a custom domain name to Azure Active Directory](/azure/active-directory/active-directory-add-domain). -To get a list of your verified company domains, you can use the [Get-MsolDomain](/powershell/module/msonline/get-msoldomain?view=azureadps-1.0&preserve-view=true) cmdlet. - -#### Issue ImmutableID for computer when one for users exist (for example, alternate login ID is set) - -**`http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID`** - This claim must contain a valid value for computers. In AD FS, you can create an issuance transform rule as follows: - -```powershell - - @RuleName = "Issue ImmutableID for computers" - c1:[ - Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", - Value =~ "-515$", - Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" - ] - && - c2:[ - Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", - Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" - ] - => issue( - store = "Active Directory", - types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), - query = ";objectguid;{0}", - param = c2.Value - ); -``` - -#### Helper script to create the AD FS issuance transform rules - -The following script helps you with the creation of the issuance transform rules described above. - -```powershell - - $multipleVerifiedDomainNames = $false - $immutableIDAlreadyIssuedforUsers = $false - $oneOfVerifiedDomainNames = 'example.com' # Replace example.com with one of your verified domains - - $rule1 = '@RuleName = "Issue account type for domain-joined computers" - c:[ - Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", - Value =~ "-515$", - Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" - ] - => issue( - Type = "http://schemas.microsoft.com/ws/2012/01/accounttype", - Value = "DJ" - );' - - $rule2 = '@RuleName = "Issue object GUID for domain-joined computers" - c1:[ - Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", - Value =~ "-515$", - Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" - ] - && - c2:[ - Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", - Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" - ] - => issue( - store = "Active Directory", - types = ("http://schemas.microsoft.com/identity/claims/onpremobjectguid"), - query = ";objectguid;{0}", - param = c2.Value - );' - - $rule3 = '@RuleName = "Issue objectSID for domain-joined computers" - c1:[ - Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", - Value =~ "-515$", - Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" - ] - && - c2:[ - Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid", - Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" - ] - => issue(claim = c2);' - - $rule4 = '' - if ($multipleVerifiedDomainNames -eq $true) { - $rule4 = '@RuleName = "Issue account type with the value User when it is not a computer" - NOT EXISTS( - [ - Type == "http://schemas.microsoft.com/ws/2012/01/accounttype", - Value == "DJ" - ] - ) - => add( - Type = "http://schemas.microsoft.com/ws/2012/01/accounttype", - Value = "User" - ); - - @RuleName = "Capture UPN when AccountType is User and issue the IssuerID" - c1:[ - Type == "http://schemas.xmlsoap.org/claims/UPN" - ] - && - c2:[ - Type == "http://schemas.microsoft.com/ws/2012/01/accounttype", - Value == "User" - ] - => issue( - Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", - Value = regexreplace( - c1.Value, - ".+@(?.+)", - "http://${domain}/adfs/services/trust/" - ) - ); - - @RuleName = "Issue issuerID for domain-joined computers" - c:[ - Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", - Value =~ "-515$", - Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" - ] - => issue( - Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", - Value = "http://' + $oneOfVerifiedDomainNames + '/adfs/services/trust/" - );' - } - - $rule5 = '' - if ($immutableIDAlreadyIssuedforUsers -eq $true) { - $rule5 = '@RuleName = "Issue ImmutableID for computers" - c1:[ - Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", - Value =~ "-515$", - Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" - ] - && - c2:[ - Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", - Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" - ] - => issue( - store = "Active Directory", - types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), - query = ";objectguid;{0}", - param = c2.Value - );' - } - - $existingRules = (Get-ADFSRelyingPartyTrust -Identifier urn:federation:MicrosoftOnline).IssuanceTransformRules - - $updatedRules = $existingRules + $rule1 + $rule2 + $rule3 + $rule4 + $rule5 - - $crSet = New-ADFSClaimRuleSet -ClaimRule $updatedRules - - Set-AdfsRelyingPartyTrust -TargetIdentifier urn:federation:MicrosoftOnline -IssuanceTransformRules $crSet.ClaimRulesString -``` - -#### Remarks - -- This script appends the rules to the existing rules. Don't run the script twice because the set of rules would be added twice. Make sure that no corresponding rules exist for these claims (under the corresponding conditions) before running the script again. - -- If you have multiple verified domain names (as shown in the Azure AD portal or via the Get-MsolDomains cmdlet), set the value of **$multipleVerifiedDomainNames** in the script to **$true**. Also make sure that you remove any existing issuerid claim that might have been created by Azure AD Connect or via other means. Here's an example for this rule: - - ```Claims Rule Language - c:[Type == "http://schemas.xmlsoap.org/claims/UPN"] - => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c.Value, ".+@(?.+)", "http://${domain}/adfs/services/trust/")); - ``` - -- If you've already issued an **ImmutableID** claim for user accounts, set the value of **$immutableIDAlreadyIssuedforUsers** in the script to **$true**. - -#### Configure Device Authentication in AD FS - -Using an elevated PowerShell command window, configure AD FS policy by executing the following command - -`PS C:>Set-AdfsGlobalAuthenticationPolicy -DeviceAuthenticationEnabled $true -DeviceAuthenticationMethod SignedToken` - -#### Check your configuration - -For your reference, below is a comprehensive list of the AD DS devices, containers and permissions required for device write-back and authentication to work - -- object of type ms-DS-DeviceContainer at CN=RegisteredDevices,DC=<domain> - - read access to the AD FS service account - - read/write access to the Azure AD Connect sync AD connector account -- Container CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=<domain> -- Container Device Registration Service DKM under the above container - - ![Device Registration: Container](images/hybridct/device8.png) - -- object of type serviceConnectionpoint at CN=<guid>, CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=<domain> - - read/write access to the specified AD connector account name on the new object -- object of type msDS-DeviceRegistrationServiceContainer at CN=Device Registration Services,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=<domain> -- object of type msDS-DeviceRegistrationService in the above container - -> [!div class="nextstepaction"] -> [Configure Windows Hello for Business settings](hello-hybrid-cert-whfb-settings.md) - -
-
- -## Follow the Windows Hello for Business hybrid certificate trust deployment guide - -1. [Overview](hello-hybrid-cert-trust.md) -2. [Prerequisites](hello-hybrid-cert-trust-prereqs.md) -3. [New Installation Baseline](hello-hybrid-cert-new-install.md) -4. Configure Azure Device Registration (*You are here*) -5. [Configure Windows Hello for Business settings](hello-hybrid-cert-whfb-settings.md) -6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md) diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-prereqs.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-prereqs.md deleted file mode 100644 index 56e0d50918..0000000000 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-prereqs.md +++ /dev/null @@ -1,157 +0,0 @@ ---- -title: Hybrid Azure AD joined Windows Hello for Business Prerequisites -description: Learn these prerequisites for hybrid Windows Hello for Business deployments using certificate trust. -ms.date: 4/30/2021 -appliesto: -- ✅ Windows 10 and later -ms.topic: article ---- -# Hybrid Azure AD joined Windows Hello for Business Prerequisites - -[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cert-trust.md)] - -Hybrid environments are distributed systems that enable organizations to use on-premises and Azure-based identities and resources. Windows Hello for Business uses the existing distributed system as a foundation on which organizations can provide two-factor authentication that provides a single sign-in like experience to modern resources. - -The distributed systems on which these technologies were built involved several pieces of on-premises and cloud infrastructure. High-level pieces of the infrastructure include: - -- [Directories](#directories) -- [Public Key Infrastructure](#public-key-infrastructure) -- [Directory Synchronization](#directory-synchronization) -- [Federation](#federation) -- [Multifactor Authentication](#multifactor-authentication) -- [Device Registration](#device-registration) - -## Directories ## - -Hybrid Windows Hello for Business needs two directories: on-premises Active Directory and a cloud Azure Active Directory. The minimum required domain controller, domain functional level, and forest functional level for Windows Hello for Business deployment is Windows Server 2008 R2. - -A hybrid Windows Hello for Business deployment needs an Azure Active Directory subscription. Different deployment configurations are supported by different Azure subscriptions. The hybrid-certificate trust deployment needs an Azure Active Directory premium subscription because it uses the device write-back synchronization feature. Other deployments, such as the hybrid key-trust deployment, may not require Azure Active Directory premium subscription. - -Windows Hello for Business can be deployed in any environment with Windows Server 2012 or later domain controllers. Azure device registration and Windows Hello for Business require the Windows Server 2016 Active Directory or later schema. - -Review these requirements and those from the Windows Hello for Business planning guide and worksheet. Based on your deployment decisions you may need to upgrade your on-premises Active Directory or your Azure Active Directory subscription to meet your needs. - -### Section Review ### - -> [!div class="checklist"] -> * Active Directory Domain Functional Level -> * Active Directory Forest Functional Level -> * Domain Controller version -> * Windows Server 2016 or later Schema -> * Azure Active Directory subscription -> * Correct subscription for desired features and outcomes - -
- -## Public Key Infrastructure ## - -The Windows Hello for Business deployment depends on an enterprise public key infrastructure as trust anchor for authentication. Domain controllers for hybrid deployments need a certificate in order for Windows devices to trust the domain controller. - -Certificate trust deployments need an enterprise public key infrastructure and a certificate registration authority to issue authentication certificates to users. When using Group Policy, hybrid certificate trust deployment uses the Windows Server 2016 Active Directory Federation Server (AD FS) as a certificate registration authority. - -The minimum required enterprise certificate authority that can be used with Windows Hello for Business is Windows Server 2012. - -### Section Review - -> [!div class="checklist"] -> * Windows Server 2012 Issuing Certificate Authority -> * Windows Server 2016 Active Directory Federation Services - -
- -## Directory Synchronization ## - -The two directories used in hybrid deployments must be synchronized. You need Azure Active Directory Connect to synchronize user accounts in the on-premises Active Directory with Azure Active Directory. - -Organizations using older directory synchronization technology, such as DirSync or Azure AD sync, need to upgrade to Azure AD Connect. In case the schema of your local AD DS was changed since the last directory synchronization, you may need to [refresh directory schema](/azure/active-directory/hybrid/how-to-connect-installation-wizard#refresh-directory-schema). - -> [!NOTE] -> User accounts enrolling for Windows Hello for Business in a Hybrid Certificate Trust scenario must have a UPN matching a verified domain name in Azure AD. For more details, see [Troubleshoot Post-Join issues](/azure/active-directory/devices/troubleshoot-hybrid-join-windows-current#troubleshoot-post-join-issues). - -> [!NOTE] -> Windows Hello for Business is tied between a user and a device. Both the user and device need to be synchronized between Azure Active Directory and Active Directory. - -### Section Review - -> [!div class="checklist"] -> * Azure Active Directory Connect directory synchronization -> * [Upgrade from DirSync](/azure/active-directory/connect/active-directory-aadconnect-dirsync-upgrade-get-started) -> * [Upgrade from Azure AD Sync](/azure/active-directory/connect/active-directory-aadconnect-upgrade-previous-version) - -
- -## Federation ## - -Windows Hello for Business hybrid certificate trust requires Active Directory being federated with Azure Active Directory and needs Windows Server 2016 Active Directory Federation Services or newer. Windows Hello for Business hybrid certificate trust doesn’t support Managed Azure Active Directory using Pass-through authentication or password hash sync. All nodes in the AD FS farm must run the same version of AD FS. Additionally, you need to configure your AD FS farm to support Azure registered devices. - -The AD FS farm used with Windows Hello for Business must be Windows Server 2016 with minimum update of [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889). If your AD FS farm is not running the AD FS role with updates from Windows Server 2016, then read [Upgrading to AD FS in Windows Server 2016](/windows-server/identity/ad-fs/deployment/upgrading-to-ad-fs-in-windows-server-2016) - -### Section Review ### - -> [!div class="checklist"] -> * Windows Server 2016 Active Directory Federation Services -> * Minimum update of [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889) - -
- -## Multifactor Authentication ## - -Windows Hello for Business is a strong, two-factor credential the helps organizations reduce their dependency on passwords. The provisioning process lets a user enroll in Windows Hello for Business using their username and password as one factor. but needs a second factor of authentication. - -Hybrid Windows Hello for Business deployments can use Azure’s Multifactor Authentication service, or they can use multifactor authentication provides by Windows Server 2016 Active Directory Federation Services, which includes an adapter model that enables third parties to integrate their multifactor authentication into AD FS. - -### Section Review - -> [!div class="checklist"] -> * Azure MFA Service -> * Windows Server 2016 AD FS and Azure -> * Windows Server 2016 AD FS and third party MFA Adapter - -
- -## Device Registration ## - -Organizations wanting to deploy hybrid certificate trust need their domain joined devices to register to Azure Active Directory. Just as a computer has an identity in Active Directory, that same computer has an identity in the cloud. This ensures that only approved computers are used with that Azure Active Directory. Each computer registers its identity in Azure Active Directory. - -Hybrid certificate trust deployments need the device write back feature. Authentication to the Windows Server 2016 Active Directory Federation Services needs both the user and the computer to authenticate. Typically the users are synchronized, but not devices. This prevents AD FS from authenticating the computer and results in Windows Hello for Business certificate enrollment failures. For this reason, Windows Hello for Business deployments need device writeback, which is an Azure Active Directory premium feature. - -> [!NOTE] -> Windows Hello for Business is tied between a user and a device. Both the user and device need to be synchronized between Azure Active Directory and Active Directory, and therefore the device writeback is used to update the msDS-KeyCredentialLink on the computer object. - -## Provisioning - -You need to allow access to the URL account.microsoft.com to initiate Windows Hello for Business provisioning. This URL launches the subsequent steps in the provisioning process and is required to successfully complete Windows Hello for Business provisioning. This URL does not require any authentication and as such, does not collect any user data. - - -### Section Checklist ### - -> [!div class="checklist"] -> * Azure Active Directory Device writeback -> * Azure Active Directory Premium subscription - -
- -### Next Steps ### -Follow the Windows Hello for Business hybrid certificate trust deployment guide. For proof-of-concepts, labs, and new installations, choose the **New Installation Baseline**. - -If your environment is already federated, but does not include Azure device registration, choose **Configure Azure Device Registration**. - -If your environment is already federated and supports Azure device registration, choose **Configure Windows Hello for Business settings**. - -> [!div class="op_single_selector"] -> - [New Installation Baseline](hello-hybrid-cert-new-install.md) -> - [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md) -> - [Configure Windows Hello for Business settings](hello-hybrid-cert-whfb-settings.md) - -

- -
- -## Follow the Windows Hello for Business hybrid certificate trust deployment guide - -1. [Overview](hello-hybrid-cert-trust.md) -2. Prerequisites (*You are here*) -3. [New Installation Baseline](hello-hybrid-cert-new-install.md) -4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md) -5. [Configure Windows Hello for Business settings](hello-hybrid-cert-whfb-settings.md) -6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md) diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-validate-pki.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-validate-pki.md new file mode 100644 index 0000000000..788cd8af15 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-validate-pki.md @@ -0,0 +1,82 @@ +--- +title: Configure and validate the Public Key Infrastructure in an hybrid certificate trust model +description: Configure and validate the Public Key Infrastructure when deploying Windows Hello for Business in a hybrid certificate trust model. +ms.date: 01/03/2023 +appliesto: +- ✅ Windows 10 and later +- ✅ Windows Server 2016 and later +ms.topic: tutorial +--- +# Configure and validate the Public Key Infrastructure - hybrid certificate trust + +[!INCLUDE [hello-hybrid-cert-trust](./includes/hello-hybrid-cert-trust.md)] + +Windows Hello for Business must have a Public Key Infrastructure (PKI) when using the *key trust* or *certificate trust* models. The domain controllers must have a certificate, which serves as a *root of trust* for clients. The certificate ensures that clients don't communicate with rogue domain controllers. + +Hybrid certificate trust deployments issue users a sign-in certificate, enabling them to authenticate to Active Directory using Windows Hello for Business credentials. Additionally, hybrid certificate trust deployments issue certificates to registration authorities to provide defense-in-depth security when issuing user authentication certificates. + +[!INCLUDE [lab-based-pki-deploy](includes/lab-based-pki-deploy.md)] + +## Configure the enterprise PKI + +[!INCLUDE [dc-certificate-template](includes/dc-certificate-template.md)] + +> [!NOTE] +> Inclusion of the *KDC Authentication* OID in domain controller certificate is not required for hybrid Azure AD-joined devices. The OID is required for enabling authentication with Windows Hello for Business to on-premises resources by Azure AD-joined devices. + +> [!IMPORTANT] +> For Azure AD joined devices to authenticate to on-premises resources, ensure to: +> - Install the root CA certificate in the device's trusted root certificate store. See [how to deploy a trusted certificate profile](/mem/intune/protect/certificates-trusted-root#to-create-a-trusted-certificate-profile) via Intune +> - Publish your certificate revocation list to a location that is available to Azure AD-joined devices, such as a web-based URL + +[!INCLUDE [dc-certificate-template-supersede](includes/dc-certificate-supersede.md)] + +[!INCLUDE [enrollment-agent-certificate-template](includes/enrollment-agent-certificate-template.md)] + +[!INCLUDE [auth-certificate-template](includes/auth-certificate-template.md)] + +[!INCLUDE [unpublish-superseded-templates](includes/unpublish-superseded-templates.md)] + +### Publish the certificate templates to the CA + +A certification authority can only issue certificates for certificate templates that are published to it. If you have more than one CA, and you want more CAs to issue certificates based on the certificate template, then you must publish the certificate template to them. + +Sign in to the CA or management workstations with **Enterprise Admin** equivalent credentials. + +1. Open the **Certification Authority** management console +1. Expand the parent node from the navigation pane +1. Select **Certificate Templates** in the navigation pane +1. Right-click the **Certificate Templates** node. Select **New > Certificate Template to issue** +1. In the **Enable Certificates Templates** window, select the *Domain Controller Authentication (Kerberos)*, *WHFB Enrollment Agent* and *WHFB Authentication* templates you created in the previous steps > select **OK** +1. Close the console + +> [!IMPORTANT] +> If you plan to deploy **Azure AD joined** devices, and require single sign-on (SSO) to on-premises resources when signing in with Windows Hello for Business, follow the procedures to [update your CA to include an http-based CRL distribution point](hello-hybrid-aadj-sso.md). + +## Configure and deploy certificates to domain controllers + +[!INCLUDE [dc-certificate-deployment](includes/dc-certificate-deployment.md)] + +## Validate the configuration + +[!INCLUDE [dc-certificate-validate](includes/dc-certificate-validate.md)] + +## Section review and next steps + +Before moving to the next section, ensure the following steps are complete: + +> [!div class="checklist"] +> - Configure domain controller certificates +> - Supersede existing domain controller certificates +> - Unpublish superseded certificate templates +> - Configure an enrollment agent certificate template +> - Configure an authentication certificate template +> - Publish the certificate templates to the CA +> - Deploy certificates to the domain controllers +> - Validate the domain controllers configuration + +> [!div class="nextstepaction"] +> [Next: configure AD FS >](hello-hybrid-cert-whfb-settings-adfs.md) + + +[SERV-1]: /troubleshoot/windows-server/windows-security/requirements-domain-controller \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust.md index caf8cfe867..b8a7d72fe0 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust.md @@ -1,45 +1,132 @@ --- -title: Hybrid Certificate Trust Deployment (Windows Hello for Business) -description: Learn the information you need to successfully deploy Windows Hello for Business in a hybrid certificate trust scenario. -ms.date: 09/08/2017 +title: Windows Hello for Business hybrid certificate trust deployment +description: Learn how to deploy Windows Hello for Business in a hybrid certificate trust scenario. +ms.date: 12/28/2022 appliesto: - ✅ Windows 10 and later -ms.topic: article +- ✅ Windows Server 2016 and later +ms.topic: how-to --- -# Hybrid Azure AD joined Certificate Trust Deployment -[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cert-trust.md)] +# Hybrid certificate trust deployment -Windows Hello for Business replaces username and password sign-in to Windows with strong user authentication based on asymmetric key pair. The following deployment guide provides the information needed to successfully deploy Windows Hello for Business in a hybrid certificate trust scenario. +[!INCLUDE [hello-hybrid-cert-trust](./includes/hello-hybrid-cert-trust.md)] -It is recommended that you review the Windows Hello for Business planning guide prior to using the deployment guide. The planning guide helps you make decisions by explaining the available options with each aspect of the deployment and explains the potential outcomes based on each of these decisions. You can review the [planning guide](/windows/access-protection/hello-for-business/hello-planning-guide) and download the [planning worksheet](https://go.microsoft.com/fwlink/?linkid=852514). +Hybrid environments are distributed systems that enable organizations to use on-premises and Azure AD-protected resources. Windows Hello for Business uses the existing distributed system as a foundation on which organizations can provide two-factor authentication and single sign-on to modern resources. -This deployment guide provides guidance for new deployments and customers who are already federated with Azure AD. These two scenarios provide a baseline from which you can begin your deployment. +This deployment guide describes how to deploy Windows Hello for Business in a hybrid certificate trust scenario. -## New Deployment Baseline +> [!IMPORTANT] +> Windows Hello for Business *cloud Kerberos trust* is the recommended deployment model when compared to the *key trust model*. It is also the recommended deployment model if you don't need to deploy certificates to the end users. For more information, see [cloud Kerberos trust deployment](hello-hybrid-cloud-kerberos-trust.md). -The new deployment baseline helps organizations who are moving to Azure AD to include Windows Hello for Business as part of their deployments. This baseline is good for organizations who are looking to deploy proof of concepts as well as IT professionals who want to familiarize themselves Windows Hello for Business by deploying a lab environment. +It is recommended that you review the [Windows Hello for Business planning guide](hello-planning-guide.md) prior to using the deployment guide. The planning guide helps you make decisions by explaining the available options with each aspect of the deployment and explains the potential outcomes based on each of these decisions. -This baseline provides detailed procedures to move your environment from an on-premises only environment to a hybrid environment using Windows Hello for Business to authenticate to Azure Active Directory and to your on-premises Active Directory using a single Windows sign-in. +## Prerequisites +The following prerequisites must be met for a hybrid certificate trust deployment: -## Federated Baseline +> [!div class="checklist"] +> * Directories and directory synchronization +> * Federated authentication to Azure AD +> * Device registration +> * Public Key Infrastructure +> * Multi-factor authentication +> * Device management -The federated baseline helps organizations that have completed their federation with Azure Active Directory and enables them to introduce Windows Hello for Business into their hybrid environment. This baseline exclusively focuses on the procedures needed to add Azure Device Registration and Windows Hello for Business to an existing hybrid deployment. +### Directories and directory synchronization -Regardless of the baseline you choose, your next step is to familiarize yourself with the prerequisites needed for the deployment. Many of the prerequisites will be new for organizations and individuals pursuing the new deployment baseline. Organizations and individuals starting from the federated baseline will likely be familiar with most of the prerequisites, but should validate they are using the proper versions that include the latest updates. +Hybrid Windows Hello for Business needs two directories: + +- An on-premises Active Directory +- An Azure Active Directory tenant with an Azure AD Premium subscription + +The two directories must be synchronized with [Azure AD Connect Sync][AZ-1], which synchronizes user accounts from the on-premises Active Directory to Azure AD. +The hybrid-certificate trust deployment needs an *Azure Active Directory Premium* subscription because it uses the device write-back synchronization feature. + +> [!NOTE] +> Windows Hello for Business hybrid certificate trust is not supported if the users' on-premises UPN suffix cannot be added as a verified domain in Azure AD. + +> [!IMPORTANT] +> Windows Hello for Business is tied between a user and a device. Both the user and device object must be synchronized between Azure Active Directory and Active Directory. + +### Federated authentication to Azure AD + +Windows Hello for Business hybrid certificate trust doesn't support Azure AD *Pass-through Authentication* (PTA) or *password hash sync* (PHS).\ +Windows Hello for Business hybrid certificate trust requires Active Directory to be federated with Azure Active Directory using AD FS. Additionally, you need to configure your AD FS farm to support Azure registered devices. + +If you're new to AD FS and federation services: + +- Review [key AD FS concepts][SER-3] prior to deploying the AD FS farm +- Review the [AD FS design guide][SER-4] to design and plan your federation service + +Once you have your AD FS design ready: + +- Review [deploying a federation server farm][SER-2] to configure AD FS in your environment + +The AD FS farm used with Windows Hello for Business must be Windows Server 2016 with minimum update of [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889). + +### Device registration + +Windows devices must be registered in Azure AD. Devices can be registered in Azure AD using either *Azure AD join* or *hybrid Azure AD join*.\ +For *hybrid Azure AD joined* devices, review the guidance on the [plan your hybrid Azure Active Directory join implementation][AZ-8] page. + +Hybrid certificate trust deployments need the device write back feature. Authentication to AD FS needs both the user and the computer to authenticate. Typically the users are synchronized, but not devices. This prevents AD FS from authenticating the computer and results in Windows Hello for Business certificate enrollment failures. For this reason, Windows Hello for Business deployments need device write-back. + +> [!NOTE] +> Windows Hello for Business is tied between a user and a device. Both the user and device need to be synchronized between Azure Active Directory and Active Directory. Device write-back is used to update the msDS-KeyCredentialLink attribute on the computer object. + +Refer to the [configure hybrid Azure Active Directory join for federated domains][AZ-10] guide to learn more about setting up Azure AD Connect Sync to support Azure AD device registration. +For a manual configuration of your AD FS farm to support device registration, review the [Configure AD FS for Azure AD device registration][AZ-11] guide. + +### Public Key Infrastructure + +An enterprise public key infrastructure (PKI) is required as *trust anchor* for authentication. Domain controllers require a certificate for Windows clients to trust them.\ +The enterprise PKI and a certificate registration authority (CRA) are required to issue authentication certificates to users. Hybrid certificate trust deployment uses AD FS as a CRA. + +During Windows Hello for Business provisioning, users receive a sign-in certificate through the CRA. + +### Multi-factor authentication + +The Windows Hello for Business provisioning process lets a user enroll in Windows Hello for Business using their user name and password as one factor, but requires a second factor of authentication.\ +Hybrid deployments can use: + +- [Azure AD Multi-Factor Authentication][AZ-2] +- A multi-factor authentication provided by AD FS, which includes an adapter model that enables third parties to integrate their MFA into AD FS + +For more information how to configure Azure AD Multi-Factor Authentication, see [Configure Azure AD Multi-Factor Authentication settings][AZ-3].\ +For more information how to configure AD FS to provide multi-factor authentication, see [Configure Azure MFA as authentication provider with AD FS][SER-1]. + +### Device management + +To configure Windows Hello for Business, devices can be configured through a mobile device management (MDM) solution like Intune, or via group policy. + +## Next steps + +Once the prerequisites are met, deploying Windows Hello for Business with a hybrid key trust model consists of the following steps: + +> [!div class="checklist"] +> * Configure and validate the PKI +> * Configure AD FS +> * Configure Windows Hello for Business settings +> * Provision Windows Hello for Business on Windows clients +> * Configure single sign-on (SSO) for Azure AD joined devices > [!div class="nextstepaction"] -> [Prerequisites](hello-hybrid-cert-trust-prereqs.md) +> [Next: configure and validate the Public Key Infrastructure >](hello-hybrid-cert-trust-validate-pki.md) -

+ +[AZ-1]: /azure/active-directory/hybrid/how-to-connect-sync-whatis +[AZ-2]: /azure/multi-factor-authentication/multi-factor-authentication +[AZ-3]: /azure/multi-factor-authentication/multi-factor-authentication-whats-next +[AZ-4]: /azure/active-directory/devices/troubleshoot-device-dsregcmd +[AZ-5]: /azure/active-directory/connect/active-directory-aadconnectsync-feature-scheduler +[AZ-6]: /azure/active-directory/hybrid/whatis-phs +[AZ-7]: /azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication +[AZ-8]: /azure/active-directory/devices/hybrid-azuread-join-plan +[AZ-9]: /azure/active-directory/devices/hybrid-azuread-join-federated-domains +[AZ-10]: /azure/active-directory/devices/howto-hybrid-azure-ad-join#federated-domains +[AZ-11]: /azure/active-directory/devices/hybrid-azuread-join-manual -
- -## Follow the Windows Hello for Business hybrid certificate trust deployment guide - -1. Overview (*You are here*) -2. [Prerequisites](hello-hybrid-cert-trust-prereqs.md) -3. [New Installation Baseline](hello-hybrid-cert-new-install.md) -4. [Device Registration](hello-hybrid-cert-trust-devreg.md) -5. [Configure Windows Hello for Business settings](hello-hybrid-cert-whfb-settings.md) -6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md) \ No newline at end of file +[SER-1]: /windows-server/identity/ad-fs/operations/configure-ad-fs-2016-and-azure-mfa +[SER-2]: /windows-server/identity/ad-fs/deployment/deploying-a-federation-server-farm +[SER-3]: /windows-server/identity/ad-fs/technical-reference/understanding-key-ad-fs-concepts +[SER-4]: /windows-server/identity/ad-fs/design/ad-fs-design-guide-in-windows-server-2012-r2 \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md index fa4284edd5..205970b978 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md @@ -1,43 +1,173 @@ --- -title: Hybrid Azure AD joined Windows Hello for Business Certificate Trust Provisioning (Windows Hello for Business) -description: In this article, learn about provisioning for hybrid certificate trust deployments of Windows Hello for Business. -ms.date: 4/30/2021 +title: Windows Hello for Business hybrid certificate trust clients configuration and enrollment +description: Learn how to configure devices and enroll them in Windows Hello for Business in a hybrid certificate trust scenario. +ms.date: 01/03/2023 appliesto: - ✅ Windows 10 and later -ms.topic: article +ms.topic: tutorial --- -# Hybrid Azure AD joined Windows Hello for Business Certificate Trust Provisioning -[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cert-trust.md)] +# Configure and provision Windows Hello for Business - hybrid certificate trust -## Provisioning +[!INCLUDE [hello-hybrid-certificate-trust](./includes/hello-hybrid-cert-trust.md)] -The Windows Hello for Business provisioning begins immediately after the user has signed in, after the user profile is loaded, but before the user receives their desktop. Windows only launches the provisioning experience if all the prerequisite checks pass. You can determine the status of the prerequisite checks by viewing the **User Device Registration** in the **Event Viewer** under **Applications and Services Logs\Microsoft\Windows**. +## Policy Configuration -![Event358 from User Device Registration log showing Windows Hello for Business prerequisite check result.](images/Event358.png) +After the prerequisites are met and the PKI and AD FS configurations are validated, Windows Hello for business must be enabled on the Windows devices. Follow the instructions below to configure your devices using either Microsoft Intune or group policy (GPO). -The first thing to validate is the computer has processed device registration. You can view this from the User device registration logs where the check **Device is Azure Active Directory-joined (AADJ or DJ++): Yes** appears. Additionally, you can validate this using the **dsregcmd /status** command from a console prompt where the value for **AzureADJoined** reads **Yes**. +#### [:::image type="icon" source="../../images/icons/group-policy.svg"::: **GPO**](#tab/gpo) -Windows Hello for Business provisioning begins with a full screen page with the title **Setup a PIN** and button with the same name. The user clicks **Setup a PIN**. +> [!IMPORTANT] +> The information in this section applies to hybrid Azure AD joined devices only. -![Setup a PIN Provisioning.](images/setupapin.png) +For hybrid Azure AD joined devices, you can use group policies to configure Windows Hello for Business. +It is suggested to create a security group (for example, *Windows Hello for Business Users*) to make it easy to deploy Windows Hello for Business in phases. You assign the **Group Policy** and **Certificate template permissions** to this group to simplify the deployment by adding the users to the group. This provides users with the proper permissions to provision Windows Hello for Business and to enroll in the Windows Hello for Business authentication certificate. -The provisioning flow proceeds to the Multi-Factor authentication portion of the enrollment. Provisioning informs the user that it is actively attempting to contact the user through their configured form of MFA. The provisioning process does not proceed until authentication succeeds, fails or times out. A failed or timeout MFA results in an error and asks the user to retry. - -![MFA prompt during provisioning.](images/mfa.png) +### Enable Windows Hello for Business group policy setting -After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe any PIN complexity requirements that you deployed to the environment. +The *Enable Windows Hello for Business* group policy setting is the configuration needed for Windows to determine if a user should attempt to enroll for Windows Hello for Business. A user will only attempt enrollment if this policy setting is configured to **enabled**.\ +You can configure the *Enable Windows Hello for Business* setting for computer or users: -![Create a PIN during provisioning.](images/createPin.png) +- Deploying this policy setting to computers (or group of computers) results in all users that sign-in that computer to attempt a Windows Hello for Business enrollment +- Deploying this policy setting to a user (or group of users), results in only that user attempting a Windows Hello for Business enrollment -The provisioning flow has all the information it needs to complete the Windows Hello for Business enrollment. +If both user and computer policy settings are deployed, the user policy setting has precedence. -- A successful single factor authentication (username and password at sign-in) -- A device that has successfully completed device registration -- A fresh, successful multi-factor authentication -- A validated PIN that meets the PIN complexity requirements +### Use certificate for on-premises authentication group policy setting -The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with Azure Active Directory to register the public key. Azure Active Directory Connect synchronizes the user's key to the on-premises Active Directory. +The *Use certificate for on-premises authentication* group policy setting determines if the deployment uses the *key-trust* or *certificate trust* authentication model. You must configure this Group Policy setting to configure Windows to enroll for a Windows Hello for Business authentication certificate. If you do not configure this policy setting, Windows considers the deployment to use key-trust authentication. + +### Enable automatic enrollment of certificates group policy setting + +Windows Hello for Business provisioning performs the initial enrollment of the Windows Hello for Business authentication certificate. This certificate expires based on the duration configured in the Windows Hello for Business *authentication certificate* template. + +The process requires no user interaction, provided the user signs-in using Windows Hello for Business. The certificate is renewed in the background before it expires. + +### Enable and configure Windows Hello for Business + +Sign-in a domain controller or management workstations with *Domain Admin* equivalent credentials. + +1. Start the **Group Policy Management Console** (gpmc.msc) +1. Expand the domain and select the **Group Policy Object** node in the navigation pane +1. Right-click **Group Policy object** and select **New** +1. Type *Enable Windows Hello for Business* in the name box and select **OK** +1. In the content pane, right-click the **Enable Windows Hello for Business** group policy object and select **Edit** +1. In the navigation pane, expand **Policies** under **User Configuration** +1. Expand **Administrative Templates > Windows Component**, and select **Windows Hello for Business** +1. In the content pane, open **Use Windows Hello for Business**. Select **Enable > OK** +1. Open **Use certificate for on-premises authentication**. Select **Enable > OK** +1. Expand **Windows Settings > Security Settings > Public Key Policies** +1. In the details pane, right-click **Certificate Services Client - Auto-Enrollment** and select **Properties** +1. Select **Enabled** from the **Configuration Model** list +1. Select the **Renew expired certificates**, **update pending certificates**, and **remove revoked certificates** check boxes +1. Select the **Update certificates that use certificate templates** check box +1. Select **OK** +1. Close the **Group Policy Management Editor** + +> [!NOTE] +> Windows Hello for Business can be configured using different policies. These policies are optional to configure, but it's recommended to enable *Use a hardware security device*. +> +> For more information about these policies, see [Group Policy settings for Windows Hello for Business](hello-manage-in-organization.md#group-policy-settings-for-windows-hello-for-business). + +### Configure security for GPO + +The best way to deploy the Windows Hello for Business GPO is to use security group filtering. Only members of the targeted security group will provision Windows Hello for Business, enabling a phased rollout. + +1. Start the **Group Policy Management Console** (gpmc.msc) +1. Expand the domain and select the **Group Policy Object** node in the navigation pane +1. Open the **Enable Windows Hello for Business** GPO +1. In the **Security Filtering** section of the content pane, select **Add**. Type the name of the security group you previously created (for example, *Windows Hello for Business Users*) and select **OK** +1. Select the **Delegation** tab. Select **Authenticated Users > Advanced** +1. In the **Group or User names** list, select **Authenticated Users**. In the **Permissions for Authenticated Users** list, clear the **Allow** check box for the **Apply Group Policy** permission. Select **OK** + +### Deploy the Windows Hello for Business Group Policy object + +The application of Group Policy object uses security group filtering. This solution allows linking the GPO to the domain, ensuring the GPO is scoped to all users. The security group filtering ensures that only the members of the *Windows Hello for Business Users* global group receive and apply the GPO, which results in the provisioning of Windows Hello for Business. + +1. Start the **Group Policy Management Console** (gpmc.msc) +1. In the navigation pane, expand the domain and right-click the node that has your Active Directory domain name and select **Link an existing GPO** +1. In the **Select GPO** dialog box, select *Enable Windows Hello for Business* or the name of the Windows Hello for Business Group Policy object you previously created and select **OK** + +### Add members to the targeted group + +Users (or devices) must receive the Windows Hello for Business group policy settings and have the proper permission to provision Windows Hello for Business. You can provide users with these settings and permissions by adding members to the *Windows Hello for Business Users* group. Users and groups who aren't members of this group won't attempt to enroll for Windows Hello for Business. + +#### [:::image type="icon" source="../../images/icons/intune.svg"::: **Intune**](#tab/intune) + +## Configure Windows Hello for Business using Microsoft Intune + +> [!IMPORTANT] +> The information in this section applies to Azure AD joined devices managed by Intune. Before proceeding, ensure that you completed the steps described in: +> - [Configure single sign-on for Azure AD joined devices](hello-hybrid-aadj-sso.md) +> - [Using Certificates for AADJ On-premises Single-sign On](hello-hybrid-aadj-sso-cert.md) + +For Azure AD joined devices enrolled in Intune, you can use Intune policies to manage Windows Hello for Business. + +There are different ways to enable and configure Windows Hello for Business in Intune: + +- Using a policy applied at the tenant level. The tenant policy: + - Is only applied at enrollment time, and any changes to its configuration won't apply to devices already enrolled in Intune + - It applies to *all devices* getting enrolled in Intune. For this reason, the policy is usually disabled and Windows Hello for Business is enabled using a policy targeted to a security group +- A device configuration policy that is applied *after* device enrollment. Any changes to the policy will be applied to the devices during regular policy refresh intervals. Chose from the following policy types: + - [Settings catalog][MEM-1] + - [Security baselines][MEM-2] + - [Custom policy][MEM-3], via the [PassportForWork CSP][MEM-4] + - [Account protection policy][MEM-5] + - [Identity protection policy template][MEM-6] + +### Verify the tenant-wide policy + +To check the Windows Hello for Business policy applied at enrollment time: + +1. Sign in to the Microsoft Endpoint Manager admin center +1. Select **Devices** > **Windows** > **Windows Enrollment** +1. Select **Windows Hello for Business** +1. Verify the status of **Configure Windows Hello for Business** and any settings that may be configured + +:::image type="content" source="images/whfb-intune-disable.png" alt-text="Disablement of Windows Hello for Business from Microsoft Endpoint Manager admin center." border="true" lightbox="images/whfb-intune-disable.png"::: + +If the tenant-wide policy is enabled and configured to your needs, you can skip to [Enroll in Windows Hello for Business](#enroll-in-windows-hello-for-business). Otherwise, follow the instructions below to create a policy using an *account protection* policy. + +### Enable and configure Windows Hello for Business + +To configure Windows Hello for Business using an *account protection* policy: + +1. Go to the Microsoft Endpoint Manager admin center +1. Select **Endpoint security** > **Account protection** +1. Select **+ Create Policy** +1. For *Platform**, select **Windows 10 and later** and for *Profile* select **Account protection** +1. Select **Create** +1. Specify a **Name** and, optionally, a **Description** > **Next** +1. Under *Block Windows Hello for Business*, select **Disabled** and multiple policies become available + - These policies are optional to configure, but it's recommended to configure *Enable to use a Trusted Platform Module (TPM)* to **Yes** + - For more information about these policies, see [MDM policy settings for Windows Hello for Business](hello-manage-in-organization.md#mdm-policy-settings-for-windows-hello-for-business) +1. Under *Enable to certificate for on-premises resources*, select **Disabled** and multiple policies become available +1. Select **Next** +1. Optionally, add *scope tags* > **Next** +1. Assign the policy to a security group that contains as members the devices or users that you want to configure > **Next** +1. Review the policy configuration and select **Create** + +:::image type="content" source="images/whfb-intune-account-protection-cert-enable.png" alt-text="Enablement of Windows Hello for Business from Microsoft Endpoint Manager admin center using an account protection policy." border="true" lightbox="images/whfb-intune-account-protection-cert-enable.png"::: + +--- + +## Enroll in Windows Hello for Business + +The Windows Hello for Business provisioning process begins immediately after the user profile is loaded and before the user receives their desktop. For the provisioning process to begin, all prerequisite checks must pass. + +You can determine the status of the prerequisite checks by viewing the **User Device Registration** admin log under **Applications and Services Logs > Microsoft > Windows**.\ +This information is also available using the `dsregcmd /status` command from a console. For more information, see [dsregcmd][AZ-4]. + +### PIN Setup + +This is the process that occurs after a user signs in, to enroll in Windows Hello for Business: + +1. The user is prompted with a full screen page to use Windows Hello with the organization account. The user selects **OK** +1. The provisioning flow proceeds to the multi-factor authentication portion of the enrollment. Provisioning informs the user that it's actively attempting to contact the user through their configured form of MFA. The provisioning process doesn't proceed until authentication succeeds, fails or times out. A failed or timeout MFA results in an error and asks the user to retry +1. After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe any PIN complexity policies configured on the device +1. The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with Azure Active Directory to register the public key. When key registration completes, Windows Hello for Business provisioning informs the user they can use their PIN to sign-in. The user may close the provisioning application and see their desktop. While the user has completed provisioning, Azure AD Connect synchronizes the user's key to Active Directory + +:::image type="content" source="images/haadj-whfb-pin-provisioning.gif" alt-text="Animation showing a user logging on to an HAADJ device with a password, and being prompted to enroll in Windows Hello for Business."::: > [!IMPORTANT] > The following is the enrollment behavior prior to Windows Server 2016 update [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889). @@ -48,25 +178,23 @@ The remainder of the provisioning includes Windows Hello for Business requesting > > [!NOTE] > Windows Server 2016 update [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889) provides synchronous certificate enrollment during hybrid certificate trust provisioning. With this update, users no longer need to wait for Azure AD Connect to sync their public key on-premises. Users enroll their certificate during provisioning and can use the certificate for sign-in immediately after completing the provisioning. The update needs to be installed on the federation servers. - + After a successful key registration, Windows creates a certificate request using the same key pair to request a certificate. Windows send the certificate request to the AD FS server for certificate enrollment. - + The AD FS registration authority verifies the key used in the certificate request matches the key that was previously registered. On a successful match, the AD FS registration authority signs the certificate request using its enrollment agent certificate and sends it to the certificate authority. > [!NOTE] > In order for AD FS to verify the key used in the certificate request, it needs to be able to access the ```https://enterpriseregistration.windows.net``` endpoint. -The certificate authority validates the certificate was signed by the registration authority. On successful validation of the signature, it issues a certificate based on the request and returns the certificate to the AD FS registration authority. The registration authority returns the certificate to Windows where it then installs the certificate in the current user’s certificate store. Once this process completes, the Windows Hello for Business provisioning workflow informs the user that they can use their PIN to sign-in through the Windows Action Center. +The certificate authority validates the certificate was signed by the registration authority. On successful validation of the signature, it issues a certificate based on the request and returns the certificate to the AD FS registration authority. The registration authority returns the certificate to Windows where it then installs the certificate in the current user's certificate store. Once this process completes, the Windows Hello for Business provisioning workflow informs the user that they can use their PIN to sign-in through the Windows Action Center. -

+ +[AZ-4]: /azure/active-directory/devices/troubleshoot-device-dsregcmd +[AZ-5]: /azure/active-directory/connect/active-directory-aadconnectsync-feature-scheduler -
- -## Follow the Windows Hello for Business hybrid certificate trust deployment guide - -1. [Overview](hello-hybrid-cert-trust.md) -2. [Prerequisites](hello-hybrid-cert-trust-prereqs.md) -3. [New Installation Baseline](hello-hybrid-cert-new-install.md) -4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md) -5. [Configure Windows Hello for Business policy settings](hello-hybrid-cert-whfb-settings-policy.md) -6. Sign-in and Provision (*You are here*) +[MEM-1]: /mem/intune/configuration/settings-catalog +[MEM-2]: /mem/intune/protect/security-baselines +[MEM-3]: /mem/intune/configuration/custom-settings-configure +[MEM-4]: /windows/client-management/mdm/passportforwork-csp +[MEM-5]: /mem/intune/protect/endpoint-security-account-protection-policy +[MEM-6]: /mem/intune/protect/identity-protection-configure \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-ad.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-ad.md deleted file mode 100644 index 748cc46a44..0000000000 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-ad.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -title: Configure Hybrid Azure AD joined Windows Hello for Business - Active Directory (AD) -description: Discussing the configuration of Active Directory (AD) in a Hybrid deployment of Windows Hello for Business -ms.date: 4/30/2021 -appliesto: -- ✅ Windows 10 and later -ms.topic: article ---- -# Configure Hybrid Azure AD joined Windows Hello for Business: Active Directory - -[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cert-trust.md)] - -The key synchronization process for the hybrid deployment of Windows Hello for Business needs the Windows Server 2016 Active Directory schema. - -### Creating Security Groups - -Windows Hello for Business uses several security groups to simplify the deployment and management. - -> [!Important] -> If your environment has one or more Windows Server 2016 domain controllers in the domain to which you are deploying Windows Hello for Business, then skip the **Create the KeyCredentials Admins Security Group**. Domains that include Windows Server 2016 domain controllers use the KeyAdmins group, which is created during the installation of the first Windows Server 2016 domain controller. - -#### Create the KeyCredential Admins Security Group - -Azure Active Directory Connect synchronizes the public key on the user object created during provisioning. You assign write and read permission to this group to the Active Directory attribute to ensure the Azure AD Connect service can add and remove keys as part of its normal workflow. - -Sign-in a domain controller or management workstation with *Domain Admin* equivalent credentials. - -1. Open **Active Directory Users and Computers**. -2. Click **View** and click **Advance Features**. -3. Expand the domain node from the navigation pane. -4. Right-click the **Users** container. Click **New**. Click **Group**. -5. Type **KeyCredential Admins** in the **Group Name** text box. -6. Click **OK**. - -#### Create the Windows Hello for Business Users Security Group - -The Windows Hello for Business Users group is used to make it easy to deploy Windows Hello for Business in phases. You assign Group Policy and Certificate template permissions to this group to simplify the deployment by simply adding the users to the group. This provides users with the proper permissions to provision Windows Hello for Business and to enroll in the Windows Hello for Business authentication certificate. - -Sign-in a domain controller or management workstation with *Domain Admin* equivalent credentials. - -1. Open **Active Directory Users and Computers**. -2. Click **View** and click **Advanced Features**. -3. Expand the domain node from the navigation pane. -4. Right-click the **Users** container. Click **New**. Click **Group**. -5. Type **Windows Hello for Business Users** in the **Group Name** text box. -6. Click **OK**. - -### Section Review - -> [!div class="checklist"] -> * Create the KeyCredential Admins Security group (optional) -> * Create the Windows Hello for Business Users group -> -> [!div class="step-by-step"] -> [< Configure Windows Hello for Business](hello-hybrid-cert-whfb-settings.md) -> [Configure Azure AD Connect >](hello-hybrid-cert-whfb-settings-dir-sync.md) - -

- -
- -## Follow the Windows Hello for Business hybrid certificate trust deployment guide -1. [Overview](hello-hybrid-cert-trust.md) -2. [Prerequisites](hello-hybrid-cert-trust-prereqs.md) -3. [New Installation Baseline](hello-hybrid-cert-new-install.md) -4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md) -5. Configure Windows Hello for Business settings: Active Directory (*You are here*) -6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md) diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-adfs.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-adfs.md index 83988357c9..80f86ef481 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-adfs.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-adfs.md @@ -1,90 +1,80 @@ --- -title: Configuring Hybrid Azure AD joined Windows Hello for Business - Active Directory Federation Services (ADFS) -description: Discussing the configuration of Active Directory Federation Services (ADFS) in a Hybrid deployment of Windows Hello for Business -ms.date: 4/30/2021 +title: Configure Active Directory Federation Services in a hybrid certificate trust model +description: Learn how to configure Active Directory Federation Services to support the Windows Hello for Business hybrid certificate trust model. +ms.date: 01/03/2023 appliesto: - ✅ Windows 10 and later -ms.topic: article +- ✅ Windows Server 2016 and later +ms.topic: tutorial --- -# Configure Hybrid Azure AD joined Windows Hello for Business: Active Directory Federation Services +# Configure Active Directory Federation Services - hybrid certificate trust -[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cert-trust.md)] +[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-cert-trust.md)] -## Federation Services - -The Windows Server 2016 Active Directory Federation Server Certificate Registration Authority (AD FS RA) enrolls for an enrollment agent certificate. Once the registration authority verifies the certificate request, it signs the certificate request using its enrollment agent certificate and sends it to the certificate authority. - -The Windows Hello for Business Authentication certificate template is configured to only issue certificates to certificate requests that have been signed with an enrollment agent certificate. +The Windows Hello for Business certificate-based deployments use AD FS as the certificate registration authority (CRA). +The CRA is responsible for issuing and revoking certificates to users. Once the registration authority verifies the certificate request, it signs the certificate request using its enrollment agent certificate and sends it to the certificate authority.\ +The CRA enrolls for an *enrollment agent certificate*, and the Windows Hello for Business *authentication certificate template* is configured to only issue certificates to certificate requests that have been signed with an enrollment agent certificate. > [!NOTE] -> In order for AD FS to verify user certificate requests for Windows Hello for Business, it needs to be able to access the ```https://enterpriseregistration.windows.net``` endpoint. +> In order for AD FS to verify user certificate requests for Windows Hello for Business, it needs to be able to access the `https://enterpriseregistration.windows.net` endpoint. -### Configure the Registration Authority +## Configure the certificate registration authority -Sign-in the AD FS server with *Domain Admin* equivalent credentials. +Sign-in the AD FS server with *domain administrator* equivalent credentials. -1. Open a **Windows PowerShell** prompt. -2. Enter the following command: +Open a **Windows PowerShell** prompt and type the following command: - ```PowerShell - Set-AdfsCertificateAuthority -EnrollmentAgent -EnrollmentAgentCertificateTemplate WHFBEnrollmentAgent -WindowsHelloCertificateTemplate WHFBAuthentication -WindowsHelloCertificateProxyEnabled $true - ``` +```PowerShell +Set-AdfsCertificateAuthority -EnrollmentAgent -EnrollmentAgentCertificateTemplate WHFBEnrollmentAgent -WindowsHelloCertificateTemplate WHFBAuthentication -WindowsHelloCertificateProxyEnabled $true +``` - >[!NOTE] - > If you gave your Windows Hello for Business Enrollment Agent and Windows Hello for Business Authentication certificate templates different names, then replace **WHFBEnrollmentAgent** and WHFBAuthentication in the preceding command with the name of your certificate templates. It's important that you use the template name rather than the template display name. You can view the template name on the **General** tab of the certificate template by using the **Certificate Template** management console (certtmpl.msc). Or, you can view the template name by using the **Get-CATemplate** ADCS Administration Windows PowerShell cmdlet on a Windows Server 2012 or later certificate authority. +>[!NOTE] +> If you gave your Windows Hello for Business Enrollment Agent and Windows Hello for Business Authentication certificate templates different names, then replace *WHFBEnrollmentAgent* and *WHFBAuthentication* in the above command with the name of your certificate templates. It's important that you use the template name rather than the template display name. You can view the template name on the **General** tab of the certificate template by using the **Certificate Template** management console (certtmpl.msc). Or, you can view the template name by using the `Get-CATemplate` PowerShell cmdlet on a CA. -### Group Memberships for the AD FS Service Account +## Enrollment agent certificate enrollment -The Windows Hello for Business group provides the AD FS service with the permissions needed to enroll a Windows Hello for Business authentication certificate on behalf of the provisioning user. +AD FS performs its own certificate lifecycle management. Once the registration authority is configured with the proper certificate template, the AD FS server attempts to enroll the certificate on the first certificate request or when the service first starts. + +Approximately 60 days prior to enrollment agent certificate's expiration, the AD FS service attempts to renew the certificate until it is successful. If the certificate fails to renew, and the certificate expires, the AD FS server will request a new enrollment agent certificate. You can view the AD FS event logs to determine the status of the enrollment agent certificate. + +### Group Memberships for the AD FS service account + +The AD FS service account must be member of the security group targeted by the authentication certificate template auto-enrollment (e.g. *Window Hello for Business Users*). The security group provides the AD FS service with the permissions needed to enroll a Windows Hello for Business authentication certificate on behalf of the provisioning user. > [!TIP] > The adfssvc account is the AD FS service account. Sign-in a domain controller or management workstation with _Domain Admin_ equivalent credentials. -1. Open **Active Directory Users and Computers**. -2. Click the **Users** container in the navigation pane. -3. Right-click **Windows Hello for Business Users** group. -4. Click the **Members** tab and click **Add**. -5. In the **Enter the object names to select** text box, type **adfssvc** or substitute the name of the AD FS service account in your AD FS deployment. Click **OK**. -6. Click **OK** to return to **Active Directory Users and Computers**. -7. Restart the AD FS server. +1. Open **Active Directory Users and Computers** +1. Search for the security group targeted by the authentication certificate template auto-enrollment (e.g. *Window Hello for Business Users*) +1. Select the **Members** tab and select **Add** +1. In the **Enter the object names to select** text box, type **adfssvc** or substitute the name of the AD FS service account in your AD FS deployment > **OK** +1. Select **OK** to return to **Active Directory Users and Computers** +1. Restart the AD FS server -> [!NOTE] -> For AD FS 2019, if Windows Hello for Business with a Hybrid Certificate trust is performed, a known PRT issue exists. You may encounter this error in ADFS Admin event logs: Received invalid Oauth request. The client 'NAME' is forbidden to access the resource with scope 'ugs'. To remediate this error: +> [!NOTE] +> For AD FS 2019 in a hybrid certificate trust model, a PRT issue exists. You may encounter this error in the AD FS Admin event logs: *Received invalid Oauth request. The client 'NAME' is forbidden to access the resource with scope 'ugs'*. To remediate this error: > -> 1. Launch AD FS management console. Browse to "Services > Scope Descriptions". -> 2. Right click "Scope Descriptions" and select "Add Scope Description". -> 3. Under name type "ugs" and Click Apply > OK. -> 4. Launch PowerShell as an administrator. -> 5. Get the ObjectIdentifier of the application permission with the ClientRoleIdentifier parameter equal to "38aa3b87-a06d-4817-b275-7a316988d93b": +> 1. Launch AD FS management console and browse to **Services > Scope Descriptions** +> 1. Right click **Scope Descriptions** and select **Add Scope Description** +> 1. Under name type `ugs` and select **Apply > OK** +> 1. Launch PowerShell as an administrator +> 1. Obtain the *ObjectIdentifier* of the application permission with the `ClientRoleIdentifier` parameter equal to `38aa3b87-a06d-4817-b275-7a316988d93b`: > ```PowerShell > (Get-AdfsApplicationPermission -ServerRoleIdentifiers 'http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope' | ?{ $_.ClientRoleIdentifier -eq '38aa3b87-a06d-4817-b275-7a316988d93b' }).ObjectIdentifier > ``` -> 6. Execute the command `Set-AdfsApplicationPermission -TargetIdentifier -AddScope 'ugs'`. -> 7. Restart the AD FS service. -> 8. On the client: Restart the client. User should be prompted to provision Windows Hello for Business. +> 1. Execute the command `Set-AdfsApplicationPermission -TargetIdentifier -AddScope 'ugs'`. +> 1. Restart the AD FS service +> 1. On the client: Restart the client. User should be prompted to provision Windows Hello for Business -### Section Review +## Section review and next steps + +Before moving to the next section, ensure the following steps are complete: > [!div class="checklist"] -> * Configure the registration authority. -> * Update group memberships for the AD FS service account. -> -> -> [!div class="step-by-step"] -> [< Configure PKI >](hello-hybrid-cert-whfb-settings-pki.md) -> [Configure policy settings >](hello-hybrid-cert-whfb-settings-policy.md) - -

- -
- -## Follow the Windows Hello for Business hybrid certificate trust deployment guide -1. [Overview](hello-hybrid-cert-trust.md) -2. [Prerequisites](hello-hybrid-cert-trust-prereqs.md) -3. [New Installation Baseline](hello-hybrid-cert-new-install.md) -4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md) -5. Configure Windows Hello for Business settings: AD FS (*You are here*) -6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md) +> - Configure the certificate registration authority +> - Update group memberships for the AD FS service account +> [!div class="nextstepaction"] +> [Next: configure policy settings >](hello-hybrid-cert-whfb-settings-policy.md) \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-dir-sync.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-dir-sync.md deleted file mode 100644 index 5002843385..0000000000 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-dir-sync.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: Configure Hybrid Azure AD joined Windows Hello for Business Directory Synch -description: Discussing Directory Synchronization in a Hybrid deployment of Windows Hello for Business -ms.date: 4/30/2021 -appliesto: -- ✅ Windows 10 and later -ms.topic: article ---- - -# Configure Hybrid Azure AD joined Windows Hello for Business- Directory Synchronization - -[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cert-trust.md)] - -## Directory Synchronization - -In hybrid deployments, users register the public portion of their Windows Hello for Business credential with Azure. Azure AD Connect synchronizes the Windows Hello for Business public key to Active Directory. - -The key-trust model needs Windows Server 2016 domain controllers, which configure the key registration permissions automatically; however, the certificate-trust model does not and requires you to add the permissions manually. - -> [!IMPORTANT] -> If you already have a Windows Server 2016 domain controller in your domain, you can skip **Configure Permissions for Key Synchronization**. In this case, you should use the pre-created group KeyAdmins in step 3 of the "Group Memberships for the Azure AD Connect Service Account" section of this article. - -### Configure Permissions for Key Synchronization - -Sign-in a domain controller or management workstations with *Domain Admin* equivalent credentials. - -1. Open **Active Directory Users and Computers**. -2. Right-click your domain name from the navigation pane and click **Properties**. -3. Click **Security** (if the Security tab is missing, turn on Advanced Features from the View menu). -4. Click **Advanced**. Click **Add**. Click **Select a principal**. -5. The **Select User, Computer, Service Account, or Group** dialog box appears. In the **Enter the object name to select** text box, type **KeyCredential Admins**. Click **OK**. -6. In the **Applies to** list box, select **Descendant User objects**. -7. Using the scroll bar, scroll to the bottom of the page and click **Clear all**. -8. In the **Properties** section, select **Read msDS-KeyCredentialLink** and **Write msDS-KeyCredentialLink**. -9. Click **OK** three times to complete the task. - - -### Group Memberships for the Azure AD Connect Service Account - -The KeyAdmins or KeyCredential Admins global group provides the Azure AD Connect service with the permissions needed to read and write the public key to Active Directory. - -Sign-in a domain controller or management workstation with _Domain Admin_ equivalent credentials. - -1. Open **Active Directory Users and Computers**. -2. Click the **Users** container in the navigation pane. -3. Right-click either the **KeyAdmins** or **KeyCredential Admins** in the details pane and click **Properties**. -4. Click the **Members** tab and click **Add** -5. In the **Enter the object names to select** text box, type the name of the Azure AD Connect service account. Click **OK**. -6. Click **OK** to return to **Active Directory Users and Computers**. - -> [!NOTE] -> If your AD forest has multiple domains, make sure you add the ADConnect sync service account (ie. MSOL_12121212) into "Enterprise Key Admins" group to gain permission across the domains in the forest. - -> [!NOTE] -> Transfer the PDC emulator FSMO role to a domain controller running Windows Server 2016 (or later) to be able to search the Key Admins and Enterprise Key Admins groups (domain controllers running previous versions of Windows Server cannot translate the security identifier to a name for these groups). - -### Section Review - -> [!div class="checklist"] -> * Configure Permissions for Key Synchronization -> * Configure group membership for Azure AD Connect -> -> [!div class="step-by-step"] -> [< Configure Active Directory](hello-hybrid-cert-whfb-settings-ad.md) -> [Configure PKI >](hello-hybrid-cert-whfb-settings-pki.md) - -

- -
- -## Follow the Windows Hello for Business hybrid certificate trust deployment guide -1. [Overview](hello-hybrid-cert-trust.md) -2. [Prerequisites](hello-hybrid-cert-trust-prereqs.md) -3. [New Installation Baseline](hello-hybrid-cert-new-install.md) -4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md) -5. Configure Windows Hello for Business settings: Directory Synchronization (*You are here*) -6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md) diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-pki.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-pki.md deleted file mode 100644 index 2b43ffad0a..0000000000 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-pki.md +++ /dev/null @@ -1,289 +0,0 @@ ---- -title: Configuring Hybrid Azure AD joined Windows Hello for Business - Public Key Infrastructure (PKI) -description: Discussing the configuration of the Public Key Infrastructure (PKI) in a Hybrid deployment of Windows Hello for Business -ms.date: 4/30/2021 -appliesto: -- ✅ Windows 10 and later -ms.topic: article ---- - -# Configure Hybrid Azure AD joined Windows Hello for Business - Public Key Infrastructure - -[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cert-trust.md)] - -Windows Hello for Business deployments rely on certificates. Hybrid deployments use publicly-issued server authentication certificates to validate the name of the server to which they are connecting and to encrypt the data that flows between them and the client computer. - -All deployments use enterprise issued certificates for domain controllers as a root of trust. Hybrid certificate trust deployments issue users with a sign-in certificate that enables them to authenticate using Windows Hello for Business credentials to non-Windows Server 2016 domain controllers. Additionally, hybrid certificate trust deployments issue certificates to registration authorities to provide defense-in-depth security when issuing user authentication certificates. - -## Certificate Templates - -This section has you configure certificate templates on your Windows Server 2012 (or later) Active Directory Certificate Services issuing certificate authority. - -### Domain Controller certificate template - -Clients need to trust domain controllers and the best way to do this is to ensure each domain controller has a Kerberos Authentication certificate. Installing a certificate on the domain controller enables the Key Distribution Center (KDC) to prove its identity to other members of the domain. This provides clients a root of trust external to the domain - namely the enterprise certificate authority. - -Domain controllers automatically request a domain controller certificate (if published) when they discover an enterprise certificate authority is added to Active Directory. However, certificates based on the *Domain Controller* and *Domain Controller Authentication* certificate templates do not include the **KDC Authentication** object identifier (OID), which was later added to the Kerberos RFC. Inclusion of the **KDC Authentication** OID in domain controller certificate is not required for key trust authentication from Hybrid Azure AD-joined devices. The OID is required for enabling authentication with Windows Hello for Business to on-premises resources by Azure AD-joined devices. The steps below to *Create a Domain Controller Authentication (Kerberos) Certificate Template* and *Configure Certificate Superseding for the Domain Controller Authentication (Kerberos) Certificate Template* to include the **KDC Authentication** OID in the domain controller certificate may be skipped if you only have Hybrid Azure AD Joined devices in your environment, but we recommend completing these steps if you are considering adding Azure AD-joined devices to your environment in the future. - -By default, the Active Directory Certificate Authority provides and publishes the Kerberos Authentication certificate template. However, the cryptography configuration included in the provided template is based on older and less performant cryptography APIs. To ensure domain controllers request the proper certificate with the best available cryptography, use the **Kerberos Authentication** certificate template as a baseline to create an updated domain controller certificate template. - -#### Create a Domain Controller Authentication (Kerberos) Certificate Template - -Sign-in a certificate authority or management workstations with _Domain Admin_ equivalent credentials. - -1. Open the **Certification Authority** management console. - -2. Right-click **Certificate Templates** and click **Manage**. - -3. In the **Certificate Template Console**, right-click the **Kerberos Authentication** template in the details pane and click **Duplicate Template**. - -4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2008 R2** from the **Certification Authority** list. Select **Windows 7.Server 2008 R2** from the **Certificate Recipient** list. - -5. On the **General** tab, type **Domain Controller Authentication (Kerberos)** in Template display name. Adjust the validity and renewal period to meet your enterprise's needs. - - > [!NOTE] - > If you use different template names, you'll need to remember and substitute these names in different portions of the lab. - -6. On the **Subject** tab, select the **Build from this Active Directory information** button if it is not already selected. Select **None** from the **Subject name format** list. Select **DNS name** from the **Include this information in alternate subject** list. Clear all other items. - -7. On the **Cryptography** tab, select **Key Storage Provider** from the **Provider Category** list. Select **RSA** from the **Algorithm name** list. Type **2048** in the **Minimum key size** text box. Select **SHA256** from the **Request hash** list. Click **OK**. - -8. Close the console. - -#### Configure Certificate Superseding for the Domain Controller Authentication (Kerberos) Certificate Template - -Many domain controllers may have an existing domain controller certificate. Active Directory Certificate Services provides a default certificate template for domain controllers--the Domain Controller certificate template. Later releases provided a new certificate template--the Domain Controller Authentication certificate template. These certificate templates were provided prior to update of the Kerberos specification that stated Key Distribution Centers (KDCs) performing certificate authentication needed to include the **KDC Authentication** extension. - -The Kerberos Authentication certificate template is the most current certificate template designated for domain controllers, and should be the one you deploy to all your domain controllers (2008 or later). - -The auto-enrollment feature in Windows enables you to effortlessly replace these domain controller certificates. You can use the following configuration to replace older domain controller certificates with a new certificate based on the Kerberos Authentication certificate template. - -Sign-in a certificate authority or management workstations with _Enterprise Admin_ equivalent credentials. - -1. Open the **Certification Authority** management console. - -2. Right-click **Certificate Templates** and click **Manage**. - -3. In the **Certificate Template Console**, right-click the **Domain Controller Authentication (Kerberos)** (or the name of the certificate template you created in the previous section) template in the details pane and click **Properties**. - -4. Click the **Superseded Templates** tab. Click **Add**. - -5. From the **Add Superseded Template** dialog, select the **Domain Controller** certificate template and click **OK**. Click **Add**. - -6. From the **Add Superseded Template** dialog, select the **Domain Controller Authentication** certificate template and click **OK**. - -7. From the **Add Superseded Template dialog**, select the **Kerberos Authentication** certificate template, and click **OK**. - -8. Add any other enterprise certificate templates that were previously configured for domain controllers to the **Superseded Templates** tab. - -9. Click **OK** and close the **Certificate Templates** console. - -The certificate template is configured to supersede all the certificate templates listed in the superseded templates list. However, the certificate template and the superseding of certificate templates is not active until you publish the certificate template to one or more certificate authorities. - -> [!NOTE] -> A domain controller's certificate must chain to a certificate in the NTAuth store in Active Directory. By default, online "Enterprise" Active Directory Certificate Authority certificates are added to the NTAuth store at installation time. If you are using a third-party CA, this is not done by default. If the domain controller certificate does not chain to a trusted CA in the NTAuth store, user authentication will fail. -> You can view an AD forest's NTAuth store (NTAuthCertificates) using PKIVIEW.MSC from an ADCS CA. Open PKIView.msc, then click the Action menu -> Manage AD Containers. - -### Enrollment Agent certificate template - -Active Directory Federation Server used for Windows Hello for Business certificate enrollment performs its own certificate lifecycle management. Once the registration authority is configured with the proper certificate template, the AD FS server attempts to enroll the certificate on the first certificate request, or when the service first starts. - -Approximately 60 days prior to the enrollment agent certificate's expiration, the AD FS service attempts to renew the certificate until it is successful. If the certificate fails to renew and expires, the AD FS server will request a new enrollment agent certificate. You can view the AD FS event logs to determine the status of the enrollment agent certificate. - -> [!IMPORTANT] -> Follow the procedures below based on the AD FS service account used in your environment. - -#### Creating an Enrollment Agent certificate for Group Managed Service Accounts - -Sign-in to a certificate authority or management workstation with _Domain Admin_ equivalent credentials. - -1. Open the **Certification Authority Management** console. - -2. Right-click **Certificate Templates** and click **Manage**. - -3. In the **Certificate Template Console**, right click on the **Exchange Enrollment Agent (Offline request)** template details pane and click **Duplicate Template**. - -4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certificate Recipient** list. - -5. On the **General** tab, type **WHFB Enrollment Agent** in **Template display name**. Adjust the validity and renewal period to meet your enterprise's needs. - -6. On the **Subject** tab, select the **Supply in the request** button if it is not already selected. - - > [!NOTE] - > The preceding step is very important. Group Managed Service Accounts (GMSA) do not support the _Build from this Active Directory information_ option, which will result in the AD FS server failing to enroll the enrollment agent certificate. You must configure the certificate template with _Supply in the request_ to ensure that AD FS servers can perform the automatic enrollment and renewal of the enrollment agent certificate. - -7. On the **Cryptography** tab, select **Key Storage Provider** from the **Provider Category** list. Select **RSA** from the **Algorithm name** list. Type **2048** in the **Minimum key size** text box. Select **SHA256** from the **Request hash** list. - -8. On the **Security** tab, click **Add**. - -9. Click **Object Types**. Select the **Service Accounts** check box and click **OK**. - -10. Type **adfssvc** in the **Enter the object names to select** text box and click **OK**. - -11. Click the **adfssvc** from the **Group or users names** list. In the **Permissions for adfssvc** section, select the **Allow** check box for the **Enroll** permission. Excluding the **adfssvc** user, clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other items in the **Group or users names** list if the check boxes are not already cleared. Click **OK**. - -12. Close the console. - -#### Creating an Enrollment Agent certificate for typical Service Accounts - -Sign-in to a certificate authority or management workstation with *Domain Admin* equivalent credentials. - -1. Open the **Certification Authority** management console. - -2. Right-click **Certificate Templates** and click **Manage**. - -3. In the **Certificate Template** console, right-click the **Exchange Enrollment Agent (Offline request)** template in the details pane and click **Duplicate Template**. - -4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certificate Recipient** list. - -5. On the **General** tab, type **WHFB Enrollment Agent** in **Template display name**. Adjust the validity and renewal period to meet your enterprise's needs. - -6. On the **Subject** tab, select the **Build from this Active Directory information** button if it is not already selected. Select **Fully distinguished name** from the **Subject name format** list if **Fully distinguished name** is not already selected. Select the **User Principal Name (UPN)** check box under **Include this information in alternative subject name**. - -7. On the **Cryptography** tab, select **Key Storage Provider** from the **Provider Category** list. Select **RSA** from the **Algorithm name** list. Type **2048** in the **Minimum key size** text box. Select **SHA256** from the **Request hash** list. - -8. On the **Security** tab, click **Add**. Type **adfssvc** in the **Enter the object names to select text box** and click **OK**. - -9. Click the **adfssvc** from the **Group or users names** list. In the **Permissions for adfssvc** section, select the **Allow** check box for the **Enroll** permission. Excluding the **adfssvc** user, clear the **Allow** check boxes for the **Enroll** and **Autoenroll** permissions for all other items in the **Group or users names** list if the check boxes are not already cleared. Click **OK**. - -10. Close the console. - -### Creating Windows Hello for Business authentication certificate template - -During Windows Hello for Business provisioning, a Windows client requests an authentication certificate from the Active Directory Federation Service, which requests an authentication certificate on behalf of the user. This task configures the Windows Hello for Business authentication certificate template. You set the name of the certificate template when configuring it. - -Sign-in to a certificate authority or management workstation with _Domain Admin equivalent_ credentials. - -1. Open the **Certification Authority** management console. - -2. Right-click **Certificate Templates** and click **Manage**. - -3. Right-click the **Smartcard Logon** template and choose **Duplicate Template**. - -4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certificate Recipient** list. - -5. On the **General** tab, type **WHFB Authentication** or your choice of template name in **Template display name**. Note the short template name for later use with CertUtil. Adjust the validity and renewal period to meet your enterprise's needs. - - > [!NOTE] - > If you use different template names, you'll need to remember and substitute these names in the relevant portions of the deployment. - -6. On the **Cryptography** tab, select **Key Storage Provider** from the **Provider Category** list. Select **RSA** from the **Algorithm name** list. Type **2048** in the **Minimum key size** text box. Select **SHA256** from the **Request hash** list. - -7. On the **Extensions** tab, verify the **Application Policies** extension includes **Smart Card Logon**. - -8. On the **Issuance Requirements** tab, select the **This number of authorized signatures** check box. Type **1** in the text box. - - Select **Application policy** from the **Policy type required in signature**. Select **Certificate Request Agent** from in the **Application policy** list. Select the **Valid existing certificate** option. - -9. On the **Subject** tab, select the **Build from this Active Directory information** button if it is not already selected. Select **Fully distinguished name** from the **Subject name format** list if **Fully distinguished name** is not already selected. Select the **User Principal Name (UPN)** check box under **Include this information in alternative subject name**. - -10. On the **Request Handling** tab, select the **Renew with same key** check box. - -11. On the **Security** tab, click **Add**. Type **Windows Hello for Business Users** in the **Enter the object names to select** text box and click **OK**. - -12. Click the **Windows Hello for Business Users** from the **Group or users names** list. In the **Permissions for Windows Hello for Business Users** section, select the **Allow** check box for the **Read**, **Enroll**, and **AutoEnroll** permissions. Excluding the **Windows Hello for Business Users** group, clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other entries in the **Group or users names** section if the check boxes are not already cleared. Click **OK**. - -13. If you previously issued Windows Hello for Business sign-in certificates using Configuration Manger and are switching to an AD FS registration authority, then on the **Superseded Templates** tab, add the previously used **Windows Hello for Business Authentication** template(s), so they will be superseded by this template for the users that have Enroll permission for this template. - -14. Click on the **Apply** to save changes and close the console. - -#### Mark the template as the Windows Hello Sign-in template - -Sign-in to an **AD FS Windows Server 2016** computer with _Enterprise Admin_ equivalent credentials. - -1. Open an elevated command prompt. - -2. Run `certutil -dsTemplate WHFBAuthentication msPKI-Private-Key-Flag +CTPRIVATEKEY_FLAG_HELLO_LOGON_KEY` - -If the template was changed successfully, the output of the command will contain old and new values of the template parameters. The new value must contain the **CTPRIVATEKEY_FLAG_HELLO_LOGON_KEY** parameter. Example: - -```console -CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=[yourdomain]:WHFBAuthentication - -Old Value: -msPKI-Private-Key-Flag REG_DWORD = 5050080 (84213888) -CTPRIVATEKEY_FLAG_REQUIRE_SAME_KEY_RENEWAL -- 80 (128) -CTPRIVATEKEY_FLAG_ATTEST_NONE -- 0 -TEMPLATE_SERVER_VER_WINBLUE< [!NOTE] -> If you gave your Windows Hello for Business Authentication certificate template a different name, then replace **WHFBAuthentication** in the above command with the name of your certificate template. It's important that you use the template name rather than the template display name. You can view the template name on the **General** tab of the certificate template using the Certificate Template management console (certtmpl.msc). Or, you can view the template name using the **Get-CATemplate** ADCS Administration Windows PowerShell cmdlet on a Windows Server 2012 or later certificate authority. - -## Publish Templates - -### Publish Certificate Templates to a Certificate Authority - -The certificate authority only issues certificates for certificate templates which are published by that certificate authority. If you have more than one certificate authority and you want that certificate authority to issue certificates based on a specific certificate template, then you must publish the certificate template to all certificate authorities that are expected to issue the certificate. - -#### Publish Certificate Templates to the Certificate Authority - -Sign-in to the certificate authority or management workstations with an _Enterprise Admin_ equivalent credentials. - -1. Open the **Certification Authority** management console. - -2. Expand the parent node from the navigation pane. - -3. Click **Certificate Templates** in the navigation pane. - -4. Right-click the **Certificate Templates** node. Click **New**, and click **Certificate Template to issue**. - -5. In the **Enable Certificates Templates** window, Ctrl-select the **Domain Controller Authentication (Kerberos)**, **WHFB Enrollment Agent** and **WHFB Authentication** templates you created in the previous steps. Click **OK** to publish the selected certificate templates to the certificate authority. - -6. Close the console. - -#### Unpublish Superseded Certificate Templates - -The certificate authority only issues certificates based on published certificate templates. For defense-in-depth security, it is a good practice to unpublish certificate templates that the certificate authority is not configured to issue. This includes any pre-published certificate templates from the role installation and any superseded certificate templates. - -The newly-created Kerberos authentication-based Domain Controller certificate template supersedes any previous domain controller certificate templates. Therefore, you should unpublish these certificate templates from all issuing certificate authorities. - -Sign-in to each certificate authority, or a management workstation with _Enterprise Admin_ equivalent credentials. - -1. Open the **Certification Authority** management console. - -2. Expand the parent node from the navigation pane. - -3. Click **Certificate Templates** in the navigation pane. - -4. Right-click the **Domain Controller** certificate template in the content pane and select **Delete**. Click **Yes** on the **Disable certificate templates** window. - -5. Repeat step 4 for the **Domain Controller Authentication** and **Kerberos Authentication** certificate templates. - -### Section Review - -> [!div class="checklist"] -> * Domain Controller certificate template -> * Configure superseded domain controller certificate templates -> * Enrollment Agent certificate template -> * Windows Hello for Business Authentication certificate template -> * Mark the certificate template as Windows Hello for Business sign-in template -> * Publish Certificate templates to certificate authorities -> * Unpublish superseded certificate templates -> -> [!div class="step-by-step"] -> [< Configure Azure AD Connect](hello-hybrid-cert-whfb-settings-dir-sync.md) -> [Configure AD FS >](hello-hybrid-cert-whfb-settings-adfs.md) - -

- -
- -## Follow the Windows Hello for Business hybrid certificate trust deployment guide - -1. [Overview](hello-hybrid-cert-trust.md) -2. [Prerequisites](hello-hybrid-cert-trust-prereqs.md) -3. [New Installation Baseline](hello-hybrid-cert-new-install.md) -4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md) -5. Configure Windows Hello for Business settings: PKI (*You are here*) -6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md) diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-policy.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-policy.md deleted file mode 100644 index ad8ff6984f..0000000000 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-policy.md +++ /dev/null @@ -1,192 +0,0 @@ ---- -title: Configuring Hybrid Azure AD joined Windows Hello for Business - Group Policy -description: Discussing the configuration of Group Policy in a Hybrid deployment of Windows Hello for Business -ms.date: 4/30/2021 -appliesto: -- ✅ Windows 10 and later -ms.topic: article ---- -# Configure Hybrid Azure AD joined Windows Hello for Business - Group Policy - -[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cert-trust-ad.md)] - -## Policy Configuration - -You need at least a Windows 10, version 1703 workstation to run the Group Policy Management Console, which provides the latest Windows Hello for Business and PIN Complexity Group Policy settings. To run the Group Policy Management Console, you need to install the Remote Server Administration Tools for Windows. You can download these tools from the [Microsoft Download Center](https://www.microsoft.com/download/details.aspx?id=45520). -Install the Remote Server Administration Tools for Windows on a computer running Windows 10, version 1703 or later. - -Alternatively, you can create copy the .ADMX and .ADML files from a Windows 10 Creators Edition (1703) to their respective language folder on a Windows Server or you can create a Group Policy Central Store and copy them their respective language folder. See [How to create and manage the Central Store for Group Policy Administrative Templates in Windows](/troubleshoot/windows-client/group-policy/create-and-manage-central-store) for more information. - -Domain controllers of Windows Hello for Business deployments need one Group Policy setting, which enables automatic certificate enrollment for the newly create domain controller authentication certificate. This policy setting ensures domain controllers (new and existing) automatically request and renew the correct domain controller certificate. - -Domain joined clients of hybrid certificate-based deployments of Windows Hello for Business needs three Group Policy settings: - -- Enable Windows Hello for Business -- Use certificate for on-premises authentication -- Enable automatic enrollment of certificates - -### Configure Domain Controllers for Automatic Certificate Enrollment - -Domain controllers automatically request a certificate from the *Domain Controller* certificate template. However, the domain controller is unaware of newer certificate templates or superseded configurations on certificate templates. - -To continue automatic enrollment and renewal of domain controller certificates that understand newer certificate template and superseded certificate template configurations, create and configure a Group Policy object for automatic certificate enrollment and link the Group Policy object to the Domain Controllers OU. - -#### Create a Domain Controller Automatic Certificate Enrollment Group Policy object - -Sign-in a domain controller or management workstations with _Domain Admin_ equivalent credentials. - -1. Start the **Group Policy Management Console** (gpmc.msc) -2. Expand the domain and select the **Group Policy Object** node in the navigation pane. -3. Right-click **Group Policy object** and select **New** -4. Type *Domain Controller Auto Certificate Enrollment* in the name box and click **OK**. -5. Right-click the **Domain Controller Auto Certificate Enrollment** Group Policy object and click **Edit**. -6. In the navigation pane, expand **Policies** under **Computer Configuration**. -7. Expand **Windows Settings**, **Security Settings**, and click **Public Key Policies**. -8. In the details pane, right-click **Certificate Services Client - Auto-Enrollment** and select **Properties**. -9. Select **Enabled** from the **Configuration Model** list. -10. Select the **Renew expired certificates**, **update pending certificates**, and **remove revoked certificates** check box. -11. Select the **Update certificates that use certificate templates** check box. -12. Click **OK**. Close the **Group Policy Management Editor**. - -#### Deploy the Domain Controller Auto Certificate Enrollment Group Policy Object - -Sign-in a domain controller or management workstations with _Domain Admin_ equivalent credentials. - -1. Start the **Group Policy Management Console** (gpmc.msc) -2. In the navigation pane, expand the domain and expand the node that has your Active Directory domain name. Right-click the **Domain Controllers** organizational unit and click **Link an existing GPO** -3. In the **Select GPO** dialog box, select **Domain Controller Auto Certificate Enrollment** or the name of the domain controller certificate enrollment Group Policy object you previously created and click **OK**. - -### Windows Hello for Business Group Policy - -The Windows Hello for Business Group Policy object delivers the correct Group Policy settings to the user, which enables them to enroll and use Windows Hello for Business to authenticate to Azure and Active Directory - -#### Enable Windows Hello for Business - -The Enable Windows Hello for Business Group Policy setting is the configuration needed for Windows to determine if a user should be attempt to enroll for Windows Hello for Business. A user will only attempt enrollment if this policy setting is configured to enabled. - -You can configure the Enable Windows Hello for Business Group Policy setting for computer or users. Deploying this policy setting to computers results in ALL users that sign-in that computer to attempt a Windows Hello for Business enrollment. Deploying this policy setting to a user results in only that user attempting a Windows Hello for Business enrollment. Additionally, you can deploy the policy setting to a group of users so only those users attempt a Windows Hello for Business enrollment. If both user and computer policy settings are deployed, the user policy setting has precedence. - -#### Use certificate for on-premises authentication - -The Use certificate for on-premises authentication Group Policy setting determines if the on-premises deployment uses the key-trust or certificate trust on-premises authentication model. You must configure this Group Policy setting to configure Windows to enroll for a Windows Hello for Business authentication certificate. If you do not configure this policy setting, Windows considers the deployment to use key-trust on-premises authentication, which requires a sufficient number of Windows Server 2016 domain controllers to handle the Windows Hello for Business key-trust authentication requests. - -You can configure this Group Policy setting for computer or users. Deploying this policy setting to computers results in ALL users requesting a Windows Hello for Business authentication certificate. Deploying this policy setting to a user results in only that user requesting a Windows Hello for Business authentication certificate. Additionally, you can deploy the policy setting to a group of users so only those users request a Windows Hello for Business authentication certificate. If both user and computer policy settings are deployed, the user policy setting has precedence. - -#### Enable automatic enrollment of certificates - -Windows Hello for Business provisioning performs the initial enrollment of the Windows Hello for Business authentication certificate. This certificate expires based on the duration configured in the Windows Hello for Business authentication certificate template. The Windows 10, version 1703 certificate auto enrollment was updated to renew these certificates before they expire, which significantly reduces user authentication failures from expired user certificates. - -The process requires no user interaction provided the user signs-in using Windows Hello for Business. The certificate is renewed in the background before it expires. - -#### Create the Windows Hello for Business Group Policy object - -The Group Policy object contains the policy settings needed to trigger Windows Hello for Business provisioning and to ensure Windows Hello for Business authentication certificates are automatically renewed. - -Sign-in a domain controller or management workstations with _Domain Admin_ equivalent credentials. - -1. Start the **Group Policy Management Console** (gpmc.msc) -2. Expand the domain and select the **Group Policy Object** node in the navigation pane. -3. Right-click **Group Policy object** and select **New**. -4. Type *Enable Windows Hello for Business* in the name box and click **OK**. -5. In the content pane, right-click the **Enable Windows Hello for Business** Group Policy object and click **Edit**. -6. In the navigation pane, expand **Policies** under **User Configuration**. -7. Expand **Administrative Templates > Windows Component**, and select **Windows Hello for Business**. -8. In the content pane, double-click **Use Windows Hello for Business**. Click **Enable** and click **OK**. -9. Double-click **Use certificate for on-premises authentication**. Click **Enable** and click **OK**. Close the **Group Policy Management Editor**. - -#### Configure Automatic Certificate Enrollment - -1. Start the **Group Policy Management Console** (gpmc.msc). -2. Expand the domain and select the **Group Policy Object** node in the navigation pane. -3. Right-click the **Enable Windows Hello for Business** Group Policy object and click **Edit**. -4. In the navigation pane, expand **Policies** under **User Configuration**. -5. Expand **Windows Settings > Security Settings**, and click **Public Key Policies**. -6. In the details pane, right-click **Certificate Services Client - Auto-Enrollment** and select **Properties**. -7. Select **Enabled** from the **Configuration Model** list. -8. Select the **Renew expired certificates**, **update pending certificates**, and **remove revoked certificates** check box. -9. Select the **Update certificates that use certificate templates** check box. -10. Click **OK**. Close the **Group Policy Management Editor**. - -#### Configure Security in the Windows Hello for Business Group Policy object - -The best way to deploy the Windows Hello for Business Group Policy object is to use security group filtering. The enables you to easily manage the users that should receive Windows Hello for Business by simply adding them to a group. This enables you to deploy Windows Hello for Business in phases. -1. Start the **Group Policy Management Console** (gpmc.msc) -2. Expand the domain and select the **Group Policy Object** node in the navigation pane. -3. Double-click the **Enable Windows Hello for Business** Group Policy object. -4. In the **Security Filtering** section of the content pane, click **Add**. Type *Windows Hello for Business Users* or the name of the security group you previously created and click **OK**. -5. Click the **Delegation** tab. Select **Authenticated Users** and click **Advanced**. -6. In the **Group or User names** list, select **Authenticated Users**. In the **Permissions for Authenticated Users** list, clear the **Allow** check box for the **Apply Group Policy** permission. Click **OK**. - -#### Deploy the Windows Hello for Business Group Policy object - -The application of the Windows Hello for Business Group Policy object uses security group filtering. This enables you to link the Group Policy object at the domain, ensuring the Group Policy object is within scope to all users. However, the security group filtering ensures only the users included in the *Windows Hello for Business Users* global group receive and apply the Group Policy object, which results in the provisioning of Windows Hello for Business. -1. Start the **Group Policy Management Console** (gpmc.msc) -2. In the navigation pane, expand the domain and right-click the node that has your Active Directory domain name and click **Link an existing GPO** -3. In the **Select GPO** dialog box, select **Enable Windows Hello for Business** or the name of the Windows Hello for Business Group Policy object you previously created and click **OK**. - -Just to reassure, linking the **Windows Hello for Business** Group Policy object to the domain ensures the Group Policy object is in scope for all domain users. However, not all users will have the policy settings applied to them. Only users who are members of the Windows Hello for Business group receive the policy settings. All others users ignore the Group Policy object. - -## Other Related Group Policy settings - -### Windows Hello for Business - -There are other Windows Hello for Business policy settings you can configure to manage your Windows Hello for Business deployment. These policy settings are computer-based policy setting; so they are applicable to any user that sign-in from a computer with these policy settings. - -#### Use a hardware security device - -The default configuration for Windows Hello for Business is to prefer hardware protected credentials; however, not all computers are able to create hardware protected credentials. When Windows Hello for Business enrollment encounters a computer that cannot create a hardware protected credential, it will create a software-based credential. - -You can enable and deploy the **Use a hardware security device** Group Policy Setting to force Windows Hello for Business to only create hardware protected credentials. Users that sign-in from a computer incapable of creating a hardware protected credential do not enroll for Windows Hello for Business. - -Another policy setting becomes available when you enable the **Use a hardware security device** Group Policy setting that enables you to prevent Windows Hello for Business enrollment from using version 1.2 Trusted Platform Modules (TPM). Version 1.2 TPMs typically perform cryptographic operations slower than version 2.0 TPMs and are more unforgiving during anti-hammering and PIN lockout activities. Therefore, some organization may not want slow sign-in performance and management overhead associated with version 1.2 TPMs. To prevent Windows Hello for Business from using version 1.2 TPMs, simply select the TPM 1.2 check box after you enable the Use a hardware security device Group Policy object. - -#### Use biometrics - -Windows Hello for Business provides a great user experience when combined with the use of biometrics. Rather than providing a PIN to sign-in, a user can use a fingerprint or facial recognition to sign-in to Windows, without sacrificing security. - -The default Windows Hello for Business enables users to enroll and use biometrics. However, some organization may want more time before using biometrics and want to disable their use until they are ready. To not allow users to use biometrics, configure the **Use biometrics** Group Policy setting to disabled and apply it to your computers. The policy setting disabled all biometrics. Currently, Windows does not provide granular policy setting that enable you to disable specific modalities of biometrics such as allow facial recognition, but disallow fingerprint. - -### PIN Complexity - -PIN complexity is not specific to Windows Hello for Business. Windows enables users to use PINs outside of Windows Hello for Business. PIN Complexity Group Policy settings apply to all uses of PINs, even when Windows Hello for Business is not deployed. - -Windows provides eight PIN Complexity Group Policy settings that give you granular control over PIN creation and management. You can deploy these policy settings to computers, where they affect all users creating PINs on that computer; or, you can deploy these settings to users, where they affect those users creating PINs regardless of the computer they use. If you deploy both computer and user PIN complexity Group Policy settings, the user policy settings have precedence over computer policy settings. Also, this conflict resolution is based on the last applied policy. Windows does not merge the policy settings automatically; however, you can deploy Group Policy to provide to accomplish a variety of configurations. The policy settings included are: -* Require digits -* Require lowercase letters -* Maximum PIN length -* Minimum PIN length -* Expiration -* History -* Require special characters -* Require uppercase letters - -Starting with Windows 10, version 1703, the PIN complexity Group Policy settings have moved to remove misunderstanding that PIN complexity policy settings were exclusive to Windows Hello for Business. The new location of these Group Policy settings is under **Computer Configuration\Administrative Templates\System\PIN Complexity** of the Group Policy editor. - -## Add users to the Windows Hello for Business Users group - -Users must receive the Windows Hello for Business group policy settings and have the proper permission to enroll for the Windows Hello for Business Authentication certificate. You can provide users with these settings and permissions by adding the group used synchronize users to the Windows Hello for Business Users group. Users and groups who are not members of this group will not attempt to enroll for Windows Hello for Business. - -### Section Review -> [!div class="checklist"] -> * Configure domain controllers for automatic certificate enrollment. -> * Create Windows Hello for Business Group Policy object. -> * Enable the Use Windows Hello for Business policy setting. -> * Enable the Use certificate for on-premises authentication policy setting. -> * Enable user automatic certificate enrollment. -> * Add users or groups to the Windows Hello for Business group -> -> -> [!div class="nextstepaction"] -> [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md) - -

- -
- -## Follow the Windows Hello for Business hybrid certificate trust deployment guide -1. [Overview](hello-hybrid-cert-trust.md) -2. [Prerequisites](hello-hybrid-cert-trust-prereqs.md) -3. [New Installation Baseline](hello-hybrid-cert-new-install.md) -4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md) -5. Configure Windows Hello for Business policy settings (*You are here*) -6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md) diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings.md deleted file mode 100644 index 360f679614..0000000000 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: Configure Hybrid Windows Hello for Business Settings (Windows Hello for Business) -description: Learn how to configure Windows Hello for Business settings in hybrid certificate trust deployment. -ms.date: 4/30/2021 -appliesto: -- ✅ Windows 10 and later -ms.topic: article ---- -# Configure Hybrid Azure AD joined Windows Hello for Business - -[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cert-trust.md)] - -Your environment is federated and you are ready to configure your hybrid environment for Windows Hello for business using the certificate trust model. -> [!IMPORTANT] -> If your environment is not federated, review the [New Installation baseline](hello-hybrid-cert-new-install.md) section of this deployment document to learn how to federate your environment for your Windows Hello for Business deployment. - -The configuration for Windows Hello for Business is grouped in four categories. These categories are: - -- [Active Directory](hello-hybrid-cert-whfb-settings-ad.md) -- [Public Key Infrastructure](hello-hybrid-cert-whfb-settings-pki.md) -- [Active Directory Federation Services](hello-hybrid-cert-whfb-settings-adfs.md) -- [Group Policy](hello-hybrid-cert-whfb-settings-policy.md) - -For the most efficient deployment, configure these technologies in order beginning with the Active Directory configuration - -> [!div class="step-by-step"] -> [Configure Active Directory >](hello-hybrid-cert-whfb-settings-ad.md) - -

- -
- -## Follow the Windows Hello for Business hybrid certificate trust deployment guide -1. [Overview](hello-hybrid-cert-trust.md) -2. [Prerequisites](hello-hybrid-cert-trust-prereqs.md) -3. [New Installation Baseline](hello-hybrid-cert-new-install.md) -4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md) -5. Configure Windows Hello for Business settings (*You are here*) -6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md) diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md index ebcff732f3..0bcb259d6a 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md @@ -1,5 +1,5 @@ --- -title: Windows Hello for Business Cloud Kerberos trust deployment +title: Windows Hello for Business cloud Kerberos trust deployment description: Learn how to deploy Windows Hello for Business in a cloud Kerberos trust scenario. ms.date: 11/1/2022 appliesto: @@ -8,7 +8,7 @@ ms.topic: article --- # Cloud Kerberos trust deployment -[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cloudkerb-trust.md)] +[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-cloudkerb-trust.md)] Windows Hello for Business replaces password sign-in with strong authentication, using an asymmetric key pair. This deployment guide provides the information to successfully deploy Windows Hello for Business in a cloud Kerberos trust scenario. @@ -189,7 +189,7 @@ The cloud Kerberos trust prerequisite check detects whether the user has a parti This is the process that occurs after a user signs in, to enroll in Windows Hello for Business: 1. The user is prompted with a full screen page to use Windows Hello with the organization account. The user selects **OK** -1. The provisioning flow proceeds to the multi-factor authentication portion of the enrollment. Provisioning informs the user that it's actively attempting to contact the user through their configured form of MFA. The provisioning process doesn't proceed until authentication succeeds, fails or times out. A failed or timeout MFA results in an error and asks the user to retry +1. The provisioning flow proceeds to the multi-factor authentication portion of the enrollment. Provisioning informs the user that it's actively attempting to contact the user through their configured form of MFA. The provisioning process doesn't proceed until authentication succeeds, fails or times out. A failed or timeout MFA results in an error and asks the user to retry 1. After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe any PIN complexity policies configured on the device :::image type="content" source="images/haadj-whfb-pin-provisioning.gif" alt-text="Animation showing a user logging on to an HAADJ device with a password, and being prompted to enroll in Windows Hello for Business."::: @@ -261,7 +261,7 @@ Windows Hello for Business cloud Kerberos trust can't be used as a supplied cred No, only the number necessary to handle the load from all cloud Kerberos trust devices. ---- + [AZ-1]: /azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises [AZ-2]: /azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises#install-the-azure-ad-kerberos-powershell-module diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-new-install.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-new-install.md deleted file mode 100644 index 32f0d91fc6..0000000000 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-new-install.md +++ /dev/null @@ -1,144 +0,0 @@ ---- -title: Windows Hello for Business Hybrid Azure AD joined Key Trust New Installation -description: Learn how to configure a hybrid key trust deployment of Windows Hello for Business for systems with no previous installations. -ms.date: 4/30/2021 -appliesto: -- ✅ Windows 10 and later -ms.topic: article ---- -# Windows Hello for Business Hybrid Azure AD joined Key Trust New Installation - -[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-key-trust.md)] - -Windows Hello for Business involves configuring distributed technologies that may or may not exist in your current infrastructure. Hybrid key trust deployments of Windows Hello for Business rely on these technologies - -- [Active Directory](#active-directory) -- [Public Key Infrastructure](#public-key-infrastructure) -- [Azure Active Directory](#azure-active-directory) -- [Multifactor Authentication Services](#multifactor-authentication-services) - -New installations are considerably more involved than existing implementations because you are building the entire infrastructure. Microsoft recommends you review the new installation baseline to validate your existing environment has all the needed configurations to support your hybrid certificate trust Windows Hello for Business deployment. If your environment meets these needs, you can read the [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md) section to prepare your Windows Hello for Business deployment by configuring directory synchronization. - -The new installation baseline begins with a basic Active Directory deployment and enterprise PKI. - -## Active Directory -This document expects you have Active Directory deployed with an _adequate_ number of Windows Server 2016 or later domain controllers for each site. Read the [Planning an adequate number of Windows Server 2016 Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more. - -> [!NOTE] ->There was an issue with key trust authentication on Windows Server 2019. If you are planning to use Windows Server 2019 domain controllers refer to [KB4487044](https://support.microsoft.com/en-us/help/4487044/windows-10-update-kb4487044) to fix this issue. - -Lab environments and isolated proof of concepts may want to limit the number of domain controllers. The purpose of these environments is to experiment and learn. Reducing the number of domain controllers can prevent troubleshooting issue, such as Active Directory replication, which is unrelated to activity's goal. - -### Section Review - -> [!div class="checklist"] -> * An adequate number of Windows Server 2016 domain controllers -> * Minimum Windows Server 2008 R2 domain and forest functional level -> * Functional networking, name resolution, and Active Directory replication - -## Public Key Infrastructure - -Windows Hello for Business must have a public key infrastructure regardless of the deployment or trust model. All trust models depend on the domain controllers having a certificate. The certificate serves as a root of trust for clients to ensure they are not communicating with a rogue domain controller. - -This guide assumes most enterprises have an existing public key infrastructure. Windows Hello for Business depends on a Windows enterprise public key infrastructure running the Active Directory Certificate Services role from Windows Server 2012 or later. - -### Lab-based public key infrastructure - -The following instructions may be used to deploy simple public key infrastructure that is suitable for a lab environment. - -Sign-in using _Enterprise Admin_ equivalent credentials on Windows Server 2012 or later server where you want the certificate authority installed. - ->[!NOTE] ->Never install a certificate authority on a domain controller in a production environment. - -1. Open an elevated Windows PowerShell prompt. -2. Use the following command to install the Active Directory Certificate Services role. - ```PowerShell - add-windowsfeature adcs-cert-authority -IncludeManagementTools - ``` - -3. Use the following command to configure the Certificate Authority using a basic certificate authority configuration. - ```PowerShell - Install-AdcsCertificationAuthority - ``` - -## Configure a Production Public Key Infrastructure - -If you do not have an existing public key infrastructure, please review [Certification Authority Guidance](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831574(v=ws.11)) from Microsoft TechNet to properly design your infrastructure. Then, consult the [Test Lab Guide: Deploying an AD CS Two-Tier PKI Hierarchy](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831348(v=ws.11)) for instructions on how to configure your public key infrastructure using the information from your design session. - -> [!IMPORTANT] -> For Azure AD joined device to authenticate to and use on-premises resources, ensure you: -> * Install the root certificate authority certificate for your organization in the user's trusted root certificate store. -> * Publish your certificate revocation list to a location that is available to Azure AD-joined devices, such as a web-based URL. - -### Section Review - -> [!div class="checklist"] -> * Minimum Windows Server 2012 Certificate Authority. -> * Enterprise Certificate Authority. -> * Functioning public key infrastructure. -> * Root certificate authority certificate (Azure AD Joined devices). -> * Highly available certificate revocation list (Azure AD Joined devices). - -## Azure Active Directory -You've prepared your Active Directory. Hybrid Windows Hello for Business deployment needs Azure Active Directory to host your cloud-based identities. - -The next step of the deployment is to follow the [Creating an Azure AD tenant](/azure/active-directory/develop/active-directory-howto-tenant) process to provision an Azure tenant for your organization. - -### Section Review - -> [!div class="checklist"] -> * Review the different ways to establish an Azure Active Directory tenant. -> * Create an Azure Active Directory Tenant. -> * Purchase the appropriate Azure Active Directory subscription or licenses, if necessary. - -## Multifactor Authentication Services -Windows Hello for Business uses multifactor authentication during provisioning and during user initiated PIN reset scenarios, such as when a user forgets their PIN. There are two preferred multifactor authentication configurations with hybrid deployments—Azure MFA and AD FS using Azure MFA or a third-party MFA adapter - -Review the [What is Azure AD Multi-Factor Authentication](/azure/multi-factor-authentication/multi-factor-authentication) topic to familiarize yourself its purpose and how it works. - -### Azure AD Multi-Factor Authentication (MFA) Cloud - -> [!IMPORTANT] -> As long as your users have licenses that include Azure AD Multi-Factor Authentication, there's nothing that you need to do to turn on Azure MFA. You can start requiring two-step verification on an individual user basis. The licenses that enable Azure MFA are: -> * Azure AD Multi-Factor Authentication -> * Azure Active Directory Premium -> * Enterprise Mobility + Security -> -> If you have one of these subscriptions or licenses, skip the Azure MFA Adapter section. - - -#### Configure Azure MFA Settings -Review the [Configure Azure AD Multi-Factor Authentication settings](/azure/multi-factor-authentication/multi-factor-authentication-whats-next) section to configure your settings. - -#### Azure MFA User States -After you have completed configuring your Azure MFA settings, you want to review [How to require two-step verification for a user](/azure/multi-factor-authentication/multi-factor-authentication-get-started-user-states) to understand user states. User states determine how you enable Azure MFA for your users. - -### Azure MFA via ADFS -Alternatively, you can configure Windows Server 2016 Active Directory Federation Services (AD FS) to provide additional multi-factor authentication. To configure, read the [Configure AD FS 2016 and Azure MFA](/windows-server/identity/ad-fs/operations/configure-ad-fs-2016-and-azure-mfa) section. - -### Section Review - -> [!div class="checklist"] -> * Review the overview and uses of Azure AD Multi-Factor Authentication. -> * Review your Azure Active Directory subscription for Azure AD Multi-Factor Authentication. -> * Create an Azure AD Multi-Factor Authentication Provider, if necessary. -> * Configure Azure AD Multi-Factor Authentication features and settings. -> * Understand the different User States and their effect on Azure AD Multi-Factor Authentication. -> * Consider using Azure AD Multi-Factor Authentication or a third-party multifactor authentication provider with Windows Server Active Directory Federation Services, if necessary. - -> [!div class="nextstepaction"] -> [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md) - -

- -
- -## Follow the Windows Hello for Business hybrid key trust deployment guide -1. [Overview](hello-hybrid-key-trust.md) -2. [Prerequisites](hello-hybrid-key-trust-prereqs.md) -3. New Installation Baseline (*You are here*) -4. [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md) -5. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md) -6. [Configure Windows Hello for Business settings](hello-hybrid-key-whfb-settings.md) -7. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md) \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-devreg.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-devreg.md deleted file mode 100644 index e6d1d3275c..0000000000 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-devreg.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: Configure Device Registration for Hybrid Azure AD joined key trust Windows Hello for Business -description: Azure Device Registration for Hybrid Certificate Key Deployment (Windows Hello for Business) -ms.date: 05/04/2022 -appliesto: -- ✅ Windows 10 and later -ms.topic: article ---- -# Configure Device Registration for Hybrid Azure AD joined key trust Windows Hello for Business - -[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-key-trust.md)] - -You're ready to configure device registration for your hybrid environment. Hybrid Windows Hello for Business deployment needs device registration to enable proper device authentication. - -> [!NOTE] -> Before proceeding, you should familiarize yourself with device registration concepts such as: -> * Azure AD registered devices -> * Azure AD-joined devices -> * Hybrid Azure AD-joined devices -> -> You can learn about this and more by reading [What is a device identity](/azure/active-directory/devices/overview) - -## Configure Hybrid Azure AD join - -Begin configuring device registration to support Hybrid Windows Hello for Business by configuring device registration capabilities in Azure AD. - -Follow the guidance on the [How to configure hybrid Azure Active Directory-joined devices](/azure/active-directory/devices/hybrid-azuread-join-plan) page. In the **Select your scenario based on your identity infrastructure** section, identify your configuration (either **Managed environment** or **Federated environment**) and perform only the steps applicable to your environment. - -If the user principal name (UPN) in your on-premises Active Directory is different from the UPN in Azure AD, you also need to complete the following steps: - -- Configure Azure AD Connect to sync the user's on-premises UPN to the onPremisesUserPrincipalName attribute in Azure AD. -- Add the domain name of the on-premises UPN as a [verified domain](/azure/active-directory/fundamentals/add-custom-domain) in Azure AD. - -You can learn more about this scenario by reading [Review on-premises UPN support for Hybrid Azure Ad join](/azure/active-directory/devices/hybrid-azuread-join-plan#review-on-premises-ad-users-upn-support-for-hybrid-azure-ad-join). - -> [!NOTE] -> Windows Hello for Business Hybrid key trust is not supported if your users' on-premises domain cannot be added as a verified domain in Azure AD. - -## Follow the Windows Hello for Business hybrid key trust deployment guide - -1. [Overview](hello-hybrid-cert-trust.md) -2. [Prerequisites](hello-hybrid-cert-trust-prereqs.md) -3. [New installation baseline](hello-hybrid-key-new-install.md) -4. [Configure directory synchronization](hello-hybrid-key-trust-dirsync.md) -5. Configure Azure Device Registration (*you're here*) -6. [Configure Windows Hello for Business settings](hello-hybrid-key-whfb-settings.md) -7. [Sign-in and provision](hello-hybrid-key-whfb-provision.md) diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-dirsync.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-dirsync.md deleted file mode 100644 index 18df532ca9..0000000000 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-dirsync.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: Configure Directory Synchronization for Hybrid Azure AD joined key trust Windows Hello for Business -description: Azure Directory Synchronization for Hybrid Certificate Key Deployment (Windows Hello for Business) -ms.date: 4/30/2021 -appliesto: -- ✅ Windows 10 and later -ms.topic: article ---- -# Configure Directory Synchronization for Hybrid Azure AD joined key trust Windows Hello for Business - -[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-key-trust.md)] - -You are ready to configure directory synchronization for your hybrid environment. Hybrid Windows Hello for Business deployment needs both a cloud and an on-premises identity to authenticate and access resources in the cloud or on-premises. - -## Deploy Azure AD Connect - -Next, you need to synchronize the on-premises Active Directory with Azure Active Directory. To do this, first review the [Integrating on-prem directories with Azure Active Directory](/azure/active-directory/connect/active-directory-aadconnect) and [hardware and prerequisites](/azure/active-directory/connect/active-directory-aadconnect-prerequisites) needed and then [download the software](https://go.microsoft.com/fwlink/?LinkId=615771). - -> [!NOTE] -> If you installed Azure AD Connect prior to upgrading the schema, you will need to re-run the Azure AD Connect installation and refresh the on-premises AD schema to ensure the synchronization rule for msDS-KeyCredentialLink is configured. - -
- -If the user principal name (UPN) in your on-premises Active Directory is different from the UPN in Azure AD, you also need to complete the following steps: -- Configure Azure AD Connect to sync the user's on-premises UPN to the onPremisesUserPrincipalName attribute in Azure AD. -- Add the domain name of the on-premises UPN as a [verified domain](/azure/active-directory/fundamentals/add-custom-domain) in Azure AD. - -> [!NOTE] -> Windows Hello for Business Hybrid key trust is not supported if your users' on-premises domain cannot be added as a verified domain in Azure AD. - -
- -## Follow the Windows Hello for Business hybrid key trust deployment guide - -1. [Overview](hello-hybrid-key-trust.md) -2. [Prerequisites](hello-hybrid-key-trust-prereqs.md) -3. [New Installation Baseline](hello-hybrid-key-new-install.md) -4. Configure Directory Synchronization (*You are here*) -5. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md) -6. [Configure Windows Hello for Business settings](hello-hybrid-key-whfb-settings.md) -7. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md) diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-prereqs.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-prereqs.md deleted file mode 100644 index 17e3fe7e61..0000000000 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-prereqs.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -title: Hybrid Azure AD joined Key trust Windows Hello for Business Prerequisites (Windows Hello for Business) -description: Learn about the prerequisites for hybrid Windows Hello for Business deployments using key trust and what the next steps are in the deployment process. -ms.date: 4/30/2021 -appliesto: -- ✅ Windows 10 and later -ms.topic: article ---- -# Hybrid Azure AD joined Key trust Windows Hello for Business Prerequisites - -[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-key-trust.md)] - -Hybrid environments are distributed systems that enable organizations to use on-premises and Azure AD-based identities and resources. Windows Hello for Business uses the existing distributed system as a foundation on which organizations can provide two-factor authentication that provides a single sign-in like experience to modern resources. - -The distributed systems on which these technologies were built involved several pieces of on-premises and cloud infrastructure. High-level pieces of the infrastructure include: - -- [Directories](#directories) -- [Public Key Infrastructure](#public-key-infrastructure) -- [Directory Synchronization](#directory-synchronization) -- [Federation](#federation-with-azure) -- [Multifactor authentication](#multifactor-authentication) -- [Device Registration](#device-registration) - -## Directories - -Hybrid Windows Hello for Business needs two directories: on-premises Active Directory and a cloud Azure Active Directory. The minimum required domain functional and forest functional levels for Windows Hello for Business deployment is Windows Server 2008 R2. - -A hybrid Windows Hello for Business deployment requires Azure Active Directory. The hybrid key trust deployment does not need a premium Azure Active Directory subscription. - -You can deploy Windows Hello for Business in any environment with Windows Server 2008 R2 or later domain controllers. -If using the key trust deployment model, you MUST ensure that you have adequate (1 or more, depending on your authentication load) Windows Server 2016 or later Domain Controllers in each Active Directory site where users will be authenticating for Windows Hello for Business. -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. - -> [!NOTE] ->There was an issue with key trust authentication on Windows Server 2019. If you are planning to use Windows Server 2019 domain controllers refer to [KB4487044](https://support.microsoft.com/en-us/help/4487044/windows-10-update-kb4487044) to fix this issue. - -Review these requirements and those from the Windows Hello for Business planning guide and worksheet. Based on your deployment decisions you may need to upgrade your on-premises Active Directory or your Azure Active Directory subscription to meet your needs. - -### Section Review - -> [!div class="checklist"] -> * Active Directory Domain Functional Level -> * Active Directory Forest Functional Level -> * Domain Controller version -> * Azure Active Directory subscription -> * Correct subscription for desired features and outcomes - -
- -## Public Key Infrastructure - -The Windows Hello for Business deployment depends on an enterprise public key infrastructure as trust anchor for authentication. Domain controllers for hybrid deployments need a certificate in order for Windows devices to trust the domain controller. - -Key trust deployments do not need client issued certificates for on-premises authentication. Active Directory user accounts are automatically configured for public key mapping by Azure AD Connect synchronizing the public key of the registered Windows Hello for Business credential to an attribute on the user's Active Directory object. - -The minimum required Enterprise certificate authority that can be used with Windows Hello for Business is Windows Server 2012, but you can also use a third-party Enterprise certification authority. The requirements for the domain controller certificate are shown below. For more details, see [Requirements for domain controller certificates from a third-party CA](/troubleshoot/windows-server/windows-security/requirements-domain-controller). - -- The certificate must have a Certificate Revocation List (CRL) distribution point extension that points to a valid CRL, or an Authority Information Access (AIA) extension that points to an Online Certificate Status Protocol (OCSP) responder. -- Optionally, the certificate Subject section could contain the directory path of the server object (the distinguished name). -- The certificate Key Usage section must contain Digital Signature and Key Encipherment. -- Optionally, the certificate Basic Constraints section should contain: [Subject Type=End Entity, Path Length Constraint=None]. -- The certificate Enhanced Key Usage section must contain Client Authentication (1.3.6.1.5.5.7.3.2), Server Authentication (1.3.6.1.5.5.7.3.1), and KDC Authentication (1.3.6.1.5.2.3.5). -- The certificate Subject Alternative Name section must contain the Domain Name System (DNS) name. -- The certificate template must have an extension that has the value "DomainController", encoded as a [BMPstring](/windows/win32/seccertenroll/about-bmpstring). If you are using Windows Server Enterprise Certificate Authority, this extension is already included in the domain controller certificate template. -- The domain controller certificate must be installed in the local computer's certificate store. See [Configure Hybrid Windows Hello for Business: Public Key Infrastructure](./hello-hybrid-key-whfb-settings-pki.md) for details. - - -> [!IMPORTANT] -> For Azure AD joined device to authenticate to and use on-premises resources, ensure you: -> * Install the root certificate authority certificate for your organization in the user's trusted root certificate store. -> * Publish your certificate revocation list to a location that is available to Azure AD-joined devices, such as a web-based url. - -### Section Review -> [!div class="checklist"] -> * Windows Server 2012 Issuing Certificate Authority - -
- -## Directory Synchronization - -The two directories used in hybrid deployments must be synchronized. You need Azure Active Directory Connect to synchronize user accounts in the on-premises Active Directory with Azure Active Directory. - -Organizations using older directory synchronization technology, such as DirSync or Azure AD sync, need to upgrade to Azure AD Connect. - -### Section Review - -> [!div class="checklist"] -> * Azure Active Directory Connect directory synchronization -> * [Upgrade from DirSync](/azure/active-directory/connect/active-directory-aadconnect-dirsync-upgrade-get-started) -> * [Upgrade from Azure AD Sync](/azure/active-directory/connect/active-directory-aadconnect-upgrade-previous-version) - -
- -## Federation with Azure - -You can deploy Windows Hello for Business key trust in non-federated and federated environments. For non-federated environments, key trust deployments work in environments that have deployed [Password Synchronization with Azure AD Connect](/azure/active-directory/hybrid/whatis-phs) or [Azure Active Directory Pass-through-Authentication](/azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication). For federated environments, you can deploy Windows Hello for Business key trust using Active Directory Federation Services (AD FS) 2012 R2 or later. - -> [!div class="checklist"] -> * Non-federated environments -> * Federated environments - -
- -## Multifactor Authentication - -Windows Hello for Business is a strong, two-factor credential the helps organizations reduce their dependency on passwords. The provisioning process lets a user enroll in Windows Hello for Business using their user name and password as one factor, but needs a second factor of authentication. - -Hybrid Windows Hello for Business deployments can use Azure's Multifactor Authentication (MFA) service or they can use multifactor authentication provided by AD FS, which includes an adapter model that enables third parties to integrate their MFA into AD FS. - -### Section Review - -> [!div class="checklist"] -> * Azure MFA Service -> * Windows Server 2016 AD FS and Azure (optional, if federated) -> * Windows Server 2016 AD FS and third party MFA Adapter (optional, if federated) - -
- -## Device Registration - -Organizations wanting to deploy hybrid key trust need their domain joined devices to register to Azure Active Directory. Just as a computer has an identity in Active Directory, that same computer has an identity in the cloud. This ensures that only approved computers are used with that Azure Active Directory. Each computer registers its identity in Azure Active Directory. - -## Provisioning - -You need to allow access to the URL account.microsoft.com to initiate Windows Hello for Business provisioning. This URL launches the subsequent steps in the provisioning process and is required to successfully complete Windows Hello for Business provisioning. This URL does not require any authentication and as such, does not collect any user data. - -### Section Checklist - -> [!div class="checklist"] -> * Device Registration with Azure Device Registration - -
- -### Next Steps - -Follow the Windows Hello for Business hybrid key trust deployment guide. For proof-of-concepts, labs, and new installations, choose the **New Installation Baseline**. - -For environments transitioning from on-premises to hybrid, start with **Configure Azure Directory Synchronization**. - -For federated and non-federated environments, start with **Configure Windows Hello for Business settings**. - -> [!div class="op_single_selector"] -> - [New Installation Baseline](hello-hybrid-key-new-install.md) -> - [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md) -> - [Configure Windows Hello for Business settings](hello-hybrid-key-whfb-settings.md) - -

- -
- -## Follow the Windows Hello for Business hybrid key trust deployment guide - -1. [Overview](hello-hybrid-key-trust.md) -2. Prerequisites (*You are here*) -3. [New Installation Baseline](hello-hybrid-key-new-install.md) -4. [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md) -5. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md) -6. [Configure Windows Hello for Business settings](hello-hybrid-key-whfb-settings.md) -7. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md) diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-provision.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-provision.md new file mode 100644 index 0000000000..a165084a61 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-provision.md @@ -0,0 +1,167 @@ +--- +title: Windows Hello for Business hybrid key trust clients configuration and enrollment +description: Learn how to configure devices and enroll them in Windows Hello for Business in a hybrid key trust scenario. +ms.date: 01/03/2023 +appliesto: +- ✅ Windows 10 and later +ms.topic: tutorial +--- + +# Configure and enroll in Windows Hello for Business - hybrid key trust + +[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-key-trust.md)] + +After the prerequisites are met and the PKI configuration is validated, Windows Hello for business must be enabled on the Windows devices. Follow the instructions below to configure your devices using either Microsoft Intune or group policy (GPO). + +#### [:::image type="icon" source="../../images/icons/intune.svg"::: **Intune**](#tab/intune) + +## Configure Windows Hello for Business using Microsoft Intune + +For Azure AD joined devices and hybrid Azure AD joined devices enrolled in Intune, you can use Intune policies to manage Windows Hello for Business. + +There are different ways to enable and configure Windows Hello for Business in Intune: + +- Using a policy applied at the tenant level. The tenant policy: + - Is only applied at enrollment time, and any changes to its configuration won't apply to devices already enrolled in Intune + - It applies to *all devices* getting enrolled in Intune. For this reason, the policy is usually disabled and Windows Hello for Business is enabled using a policy targeted to a security group +- A device configuration policy that is applied *after* device enrollment. Any changes to the policy will be applied to the devices during regular policy refresh intervals. There are different policy types to choose from: + - [Settings catalog][MEM-1] + - [Security baselines][MEM-2] + - [Custom policy][MEM-3], via the [PassportForWork CSP][MEM-4] + - [Account protection policy][MEM-5] + - [Identity protection policy template][MEM-6] + +### Verify the tenant-wide policy + +To check the Windows Hello for Business policy applied at enrollment time: + +1. Sign in to the Microsoft Endpoint Manager admin center +1. Select **Devices** > **Windows** > **Windows Enrollment** +1. Select **Windows Hello for Business** +1. Verify the status of **Configure Windows Hello for Business** and any settings that may be configured + +:::image type="content" source="images/whfb-intune-disable.png" alt-text="Disablement of Windows Hello for Business from Microsoft Endpoint Manager admin center." border="true" lightbox="images/whfb-intune-disable.png"::: + +If the tenant-wide policy is enabled and configured to your needs, you can skip to [Enroll in Windows Hello for Business](#enroll-in-windows-hello-for-business). Otherwise, follow the instructions below to create a policy using an *account protection* policy. + +### Enable and configure Windows Hello for Business + +To configure Windows Hello for Business using an *account protection* policy: + +1. Go to the Microsoft Endpoint Manager admin center +1. Select **Endpoint security** > **Account protection** +1. Select **+ Create Policy** +1. For *Platform**, select **Windows 10 and later** and for *Profile* select **Account protection** +1. Select **Create** +1. Specify a **Name** and, optionally, a **Description** > **Next** +1. Under *Block Windows Hello for Business*, select **Disabled** and multiple policies become available + - These policies are optional to configure, but it's recommended to configure *Enable to use a Trusted Platform Module (TPM)* to **Yes** + - For more information about these policies, see [MDM policy settings for Windows Hello for Business](hello-manage-in-organization.md#mdm-policy-settings-for-windows-hello-for-business) +1. Select **Next** +1. Optionally, add *scope tags* > **Next** +1. Assign the policy to a security group that contains as members the devices or users that you want to configure > **Next** +1. Review the policy configuration and select **Create** + +:::image type="content" source="images/whfb-intune-account-protection-enable.png" alt-text="Enablement of Windows Hello for Business from Microsoft Endpoint Manager admin center using an account protection policy." border="true" lightbox="images/whfb-intune-account-protection-enable.png"::: + +#### [:::image type="icon" source="../../images/icons/group-policy.svg"::: **GPO**](#tab/gpo) + +## Configure Windows Hello for Business using group policies + +For hybrid Azure AD joined devices, you can use group policies to configure Windows Hello for Business. +It's suggested to create a security group (for example, *Windows Hello for Business Users*) to make it easy to deploy Windows Hello for Business in phases. You assign **Group Policy permissions** to this group to simplify the deployment by adding the users to the group. + +The Windows Hello for Business Group Policy object delivers the correct Group Policy settings to the user, which enables them to enroll and use Windows Hello for Business to authenticate to Azure and Active Directory + +> [!NOTE] +> If you deployed Windows Hello for Business configuration using both Group Policy and Intune, Group Policy settings will take precedence and Intune settings will be ignored. For more information about policy conflicts, see [Policy conflicts from multiple policy sources](./hello-manage-in-organization.md#policy-conflicts-from-multiple-policy-sources) + +### Enable Windows Hello for Business group policy setting + +The *Enable Windows Hello for Business* group policy setting is the configuration needed for Windows to determine if a user should attempt to enroll for Windows Hello for Business. A user will only attempt enrollment if this policy setting is configured to **enabled**.\ +You can configure the *Enable Windows Hello for Business* setting for computer or users: + +- Deploying this policy setting to computers (or group of computers) results in all users that sign-in that computer to attempt a Windows Hello for Business enrollment +- Deploying this policy setting to a user (or group of users), results in only that user attempting a Windows Hello for Business enrollment + +If both user and computer policy settings are deployed, the user policy setting has precedence. + +### Enable and configure Windows Hello for Business + +Sign-in a domain controller or management workstations with *Domain Admin* equivalent credentials. + +1. Start the **Group Policy Management Console** (gpmc.msc) +1. Expand the domain and select the **Group Policy Object** node in the navigation pane +1. Right-click **Group Policy object** and select **New** +1. Type *Enable Windows Hello for Business* in the name box and select **OK** +1. In the content pane, right-click the **Enable Windows Hello for Business** group policy object and select **Edit** +1. In the navigation pane, expand **Policies** under **User Configuration** +1. Expand **Administrative Templates > Windows Component**, and select **Windows Hello for Business** +1. In the content pane, open **Use Windows Hello for Business**. Select **Enable > OK** +1. Close the **Group Policy Management Editor** + +> [!NOTE] +> Windows Hello for Business can be configured using different policies. These policies are optional to configure, but it's recommended to enable *Use a hardware security device*. +> +> For more information about these policies, see [Group Policy settings for Windows Hello for Business](hello-manage-in-organization.md#group-policy-settings-for-windows-hello-for-business). + +### Configure security for GPO + +The best way to deploy the Windows Hello for Business GPO is to use security group filtering. Only members of the targeted security group will provision Windows Hello for Business, enabling a phased rollout. + +1. Start the **Group Policy Management Console** (gpmc.msc) +1. Expand the domain and select the **Group Policy Object** node in the navigation pane +1. Open the **Enable Windows Hello for Business** GPO +1. In the **Security Filtering** section of the content pane, select **Add**. Type the name of the security group you previously created (for example, *Windows Hello for Business Users*) and select **OK** +1. Select the **Delegation** tab. Select **Authenticated Users > Advanced** +1. In the **Group or User names** list, select **Authenticated Users**. In the **Permissions for Authenticated Users** list, clear the **Allow** check box for the **Apply Group Policy** permission. Select **OK** + +### Deploy the Windows Hello for Business Group Policy object + +The application of Group Policy object uses security group filtering. This solution allows linking the GPO to the domain, ensuring the GPO is scoped to all users. The security group filtering ensures that only the members of the *Windows Hello for Business Users* global group receive and apply the GPO, which results in the provisioning of Windows Hello for Business. + +1. Start the **Group Policy Management Console** (gpmc.msc) +1. In the navigation pane, expand the domain and right-click the node that has your Active Directory domain name and select **Link an existing GPO** +1. In the **Select GPO** dialog box, select *Enable Windows Hello for Business* or the name of the Windows Hello for Business Group Policy object you previously created and select **OK** + +### Add members to the targeted group + +Users (or devices) must receive the Windows Hello for Business group policy settings and have the proper permission to provision Windows Hello for Business. You can provide users with these settings and permissions by adding members to the *Windows Hello for Business Users* group. Users and groups who aren't members of this group won't attempt to enroll for Windows Hello for Business. + +--- + +## Enroll in Windows Hello for Business + +The Windows Hello for Business provisioning process begins immediately after the user profile is loaded and before the user receives their desktop. For the provisioning process to begin, all prerequisite checks must pass. + +You can determine the status of the prerequisite checks by viewing the **User Device Registration** admin log under **Applications and Services Logs > Microsoft > Windows**.\ +This information is also available using the `dsregcmd /status` command from a console. For more information, see [dsregcmd][AZ-4]. + +:::image type="content" source="images/Event358.png" alt-text="Details about event ID 358 showing that the device is ready to enroll in Windows Hello for Business." border="false" lightbox="images/Event358.png"::: + +### PIN Setup + +The following process occurs after a user signs in, to enroll in Windows Hello for Business: + +1. The user is prompted with a full screen page to use Windows Hello with the organization account. The user selects **OK** +1. The enrollment flow proceeds to the multi-factor authentication phase. The process informs the user that there's an MFA contact attempt, using the configured form of MFA. The provisioning process doesn't proceed until authentication succeeds, fails or times out. A failed or timeout MFA results in an error and asks the user to retry +1. After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe any PIN complexity policies configured on the device +1. The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with Azure Active Directory to register the public key. When key registration completes, Windows Hello for Business provisioning informs the user they can use their PIN to sign-in. The user may close the provisioning application and see their desktop. While the user has completed provisioning, Azure AD Connect synchronizes the user's key to Active Directory + +:::image type="content" source="images/haadj-whfb-pin-provisioning.gif" alt-text="Animation showing a user logging on to an HAADJ device with a password, and being prompted to enroll in Windows Hello for Business."::: + +> [!IMPORTANT] +> The minimum time needed to synchronize the user's public key from Azure Active Directory to the on-premises Active Directory is 30 minutes. The Azure AD Connect scheduler controls the synchronization interval. +> **This synchronization latency delays the user's ability to authenticate and use on-premises resources until the user's public key has synchronized to Active Directory.** Once synchronized, the user can authenticate and use on-premises resources. +> Read [Azure AD Connect sync: Scheduler][AZ-5] to view and adjust the **synchronization cycle** for your organization. + + +[AZ-4]: /azure/active-directory/devices/troubleshoot-device-dsregcmd +[AZ-5]: /azure/active-directory/connect/active-directory-aadconnectsync-feature-scheduler + +[MEM-1]: /mem/intune/configuration/settings-catalog +[MEM-2]: /mem/intune/protect/security-baselines +[MEM-3]: /mem/intune/configuration/custom-settings-configure +[MEM-4]: /windows/client-management/mdm/passportforwork-csp +[MEM-5]: /mem/intune/protect/endpoint-security-account-protection-policy +[MEM-6]: /mem/intune/protect/identity-protection-configure \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md new file mode 100644 index 0000000000..19c9df7d89 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-validate-pki.md @@ -0,0 +1,102 @@ +--- +title: Configure and validate the Public Key Infrastructure in an hybrid key trust model +description: Configure and validate the Public Key Infrastructure when deploying Windows Hello for Business in an hybrid key trust model. +ms.date: 01/03/2023 +appliesto: +- ✅ Windows 10 and later +- ✅ Windows Server 2016 and later +ms.topic: tutorial +--- +# Configure and validate the Public Key Infrastructure - hybrid key trust + +[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-key-trust.md)] + +Windows Hello for Business must have a Public Key Infrastructure (PKI) when using the *key trust* model. The domain controllers must have a certificate, which serves as a *root of trust* for clients. The certificate ensures that clients don't communicate with rogue domain controllers. + +Key trust deployments do not need client-issued certificates for on-premises authentication. Active Directory user accounts are configured for public key mapping by *Azure AD Connect Sync*, which synchronizes the public key of the Windows Hello for Business credential to an attribute on the user's Active Directory object (`msDS-KeyCredentialLink`). + +A Windows Server-based PKI or a third-party Enterprise certification authority can be used. The requirements for the domain controller certificate are shown below. For more details, see [Requirements for domain controller certificates from a third-party CA][SERV-1]. + +## Deploy an enterprise certification authority + +This guide assumes most enterprises have an existing public key infrastructure. Windows Hello for Business depends on an enterprise PKI running the Windows Server *Active Directory Certificate Services* role.\ +If you don't have an existing PKI, review [Certification Authority Guidance][PREV-1] to properly design your infrastructure. Then, consult the [Test Lab Guide: Deploying an AD CS Two-Tier PKI Hierarchy][PREV-2] for instructions on how to configure your PKI using the information from your design session. + +### Lab-based PKI + +The following instructions may be used to deploy simple public key infrastructure that is suitable **for a lab environment**. + +Sign in using *Enterprise Administrator* equivalent credentials on a Windows Server where you want the certification authority (CA) installed. + +>[!NOTE] +>Never install a certification authority on a domain controller in a production environment. + +1. Open an elevated Windows PowerShell prompt +1. Use the following command to install the Active Directory Certificate Services role. + ```PowerShell + Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools + ``` +1. Use the following command to configure the CA using a basic certification authority configuration + ```PowerShell + Install-AdcsCertificationAuthority + ``` + +## Configure the enterprise PKI + +[!INCLUDE [dc-certificate-template](includes/dc-certificate-template.md)] + +> [!NOTE] +> Inclusion of the *KDC Authentication* OID in domain controller certificate is not required for hybrid Azure AD-joined devices. The OID is required for enabling authentication with Windows Hello for Business to on-premises resources by Azure AD-joined devices. + +> [!IMPORTANT] +> For Azure AD joined devices to authenticate to on-premises resources, ensure to: +> - Install the root CA certificate in the device's trusted root certificate store. See [how to deploy a trusted certificate profile](/mem/intune/protect/certificates-trusted-root#to-create-a-trusted-certificate-profile) via Intune +> - Publish your certificate revocation list to a location that is available to Azure AD-joined devices, such as a web-based URL + +[!INCLUDE [dc-certificate-template-supersede](includes/dc-certificate-supersede.md)] + +[!INCLUDE [unpublish-superseded-templates](includes/unpublish-superseded-templates.md)] + +### Publish the certificate template to the CA + +A certification authority can only issue certificates for certificate templates that are published to it. If you have more than one CA, and you want more CAs to issue certificates based on the certificate template, then you must publish the certificate template to them. + +Sign in to the CA or management workstations with **Enterprise Admin** equivalent credentials. + +1. Open the **Certification Authority** management console +1. Expand the parent node from the navigation pane +1. Select **Certificate Templates** in the navigation pane +1. Right-click the **Certificate Templates** node. Select **New > Certificate Template to issue** +1. In the **Enable Certificates Templates** window, select the *Domain Controller Authentication (Kerberos)* template you created in the previous steps > select **OK** +1. Close the console + +> [!IMPORTANT] +> If you plan to deploy **Azure AD joined** devices, and require single sign-on (SSO) to on-premises resources when signing in with Windows Hello for Business, follow the procedures to [update your CA to include an http-based CRL distribution point](hello-hybrid-aadj-sso.md). + +## Configure and deploy certificates to domain controllers + +[!INCLUDE [dc-certificate-deployment](includes/dc-certificate-deployment.md)] + +## Validate the configuration + +[!INCLUDE [dc-certificate-validate](includes/dc-certificate-validate.md)] + +## Section review and next steps + +Before moving to the next section, ensure the following steps are complete: + +> [!div class="checklist"] +> - Configure domain controller certificates +> - Supersede existing domain controller certificates +> - Unpublish superseded certificate templates +> - Publish the certificate template to the CA +> - Deploy certificates to the domain controllers +> - Validate the domain controllers configuration + +> [!div class="nextstepaction"] +> [Next: configure and provision Windows Hello for Business >](hello-hybrid-key-trust-provision.md) + + +[SERV-1]: /troubleshoot/windows-server/windows-security/requirements-domain-controller +[PREV-1]: /previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831574(v=ws.11) +[PREV-2]: /previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831348(v=ws.11) diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md index 9ab687ded9..042fe747a8 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md @@ -1,40 +1,102 @@ --- -title: Hybrid Key Trust Deployment (Windows Hello for Business) -description: Review this deployment guide to successfully deploy Windows Hello for Business in a hybrid key trust scenario. -ms.date: 08/20/2018 +title: Windows Hello for Business hybrid key trust deployment +description: Learn how to deploy Windows Hello for Business in a hybrid key trust scenario. +ms.date: 12/28/2022 appliesto: - ✅ Windows 10 and later -ms.topic: article +- ✅ Windows Server 2016 and later +ms.topic: how-to --- -# Hybrid Azure AD joined Key Trust Deployment +# Hybrid key trust deployment -[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-key-trust.md)] +[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-key-trust.md)] -Windows Hello for Business replaces username and password sign-in to Windows with strong user authentication based on asymmetric key pair. The following deployment guide provides the information needed to successfully deploy Windows Hello for Business in a hybrid key trust scenario. +Hybrid environments are distributed systems that enable organizations to use on-premises and Azure AD-protected resources. Windows Hello for Business uses the existing distributed system as a foundation on which organizations can provide two-factor authentication and single sign-on to modern resources. -It is recommended that you review the Windows Hello for Business planning guide prior to using the deployment guide. The planning guide helps you make decisions by explaining the available options with each aspect of the deployment and explains the potential outcomes based on each of these decisions. You can review the [planning guide](/windows/access-protection/hello-for-business/hello-planning-guide) and download the [planning worksheet](https://go.microsoft.com/fwlink/?linkid=852514). +This deployment guide describes how to deploy Windows Hello for Business in a hybrid key trust scenario. -This deployment guide provides guidance for new deployments and customers who are already federated with Azure AD. These two scenarios provide a baseline from which you can begin your deployment. +> [!IMPORTANT] +> Windows Hello for Business *cloud Kerberos trust* is the recommended deployment model when compared to the *key trust model*. For more information, see [cloud Kerberos trust deployment](hello-hybrid-cloud-kerberos-trust.md). -## New Deployment Baseline ## +It is recommended that you review the [Windows Hello for Business planning guide](hello-planning-guide.md) prior to using the deployment guide. The planning guide helps you make decisions by explaining the available options with each aspect of the deployment and explains the potential outcomes based on each of these decisions. -The new deployment baseline helps organizations who are moving to Azure AD to include Windows Hello for Business as part of their deployments. This baseline is good for organizations who are looking to deploy proof of concepts as well as IT professionals who want to familiarize themselves Windows Hello for Business by deploying a lab environment. +## Prerequisites -This baseline provides detailed procedures to move your environment from an on-premises only environment to a hybrid environment using Windows Hello for Business to authenticate to Azure Active Directory and to your on-premises Active Directory using a single Windows sign-in. +The following prerequisites must be met for a hybrid key trust deployment: -Your next step is to familiarize yourself with the prerequisites needed for the deployment. Many of the prerequisites will be new for organizations and individuals pursuing the new deployment baseline. Organizations and individuals starting from the federated baseline will likely be familiar with most of the prerequisites, but should validate they are using the proper versions that include the latest updates. +> [!div class="checklist"] +> * Directories and directory synchronization +> * Authentication to Azure AD +> * Device registration +> * Public Key Infrastructure +> * Multi-factor authentication +> * Device management + +### Directories and directory synchronization + +Hybrid Windows Hello for Business needs two directories: + +- An on-premises Active Directory +- An Azure Active Directory tenant + +The two directories must be synchronized with [Azure AD Connect Sync][AZ-1], which synchronizes user accounts from the on-premises Active Directory to Azure AD.\ +During the Window Hello for Business provisioning process, users register the public portion of their Windows Hello for Business credential with Azure AD. *Azure AD Connect Sync* synchronizes the Windows Hello for Business public key to Active Directory. + +> [!NOTE] +> Windows Hello for Business hybrid key trust is not supported if the users' on-premises UPN suffix cannot be added as a verified domain in Azure AD. + +### Authentication to Azure AD + +Authentication to Azure AD can be configured with or without federation: + +- [Password hash synchronization][AZ-6] or [Azure Active Directory pass-through-authentication][AZ-7] is required for non-federated environments +- Active Directory Federation Services (AD FS) or a third-party federation service is required for federated environments + +### Device registration + +The Windows devices must be registered in Azure AD. Devices can be registered in Azure AD using either *Azure AD join* or *hybrid Azure AD join*.\ +For *hybrid Azure AD joined* devices, review the guidance on the [Plan your hybrid Azure Active Directory join implementation][AZ-8] page. + +### Public Key Infrastructure + +An enterprise PKI is required as *trust anchor* for authentication. Domain controllers require a certificate for Windows clients to trust them. + +### Multi-factor authentication + +The Windows Hello for Business provisioning process lets a user enroll in Windows Hello for Business using their user name and password as one factor, but requires a second factor of authentication.\ +Hybrid deployments can use: + +- [Azure AD Multi-Factor Authentication][AZ-2] +- A multi-factor authentication provided by AD FS, which includes an adapter model that enables third parties to integrate their MFA into AD FS + +For more information how to configure Azure AD Multi-Factor Authentication, see [Configure Azure AD Multi-Factor Authentication settings][AZ-3].\ +For more information how to configure AD FS to provide multi-factor authentication, see [Configure Azure MFA as authentication provider with AD FS][SER-1]. + +### Device management + +To configure Windows Hello for Business, devices can be configured through a mobile device management (MDM) solution like Intune, or via group policy. + +## Next steps + +Once the prerequisites are met, deploying Windows Hello for Business with a hybrid key trust model consists of the following steps: + +> [!div class="checklist"] +> * Configure and validate the PKI +> * Configure Windows Hello for Business settings +> * Provision Windows Hello for Business on Windows clients +> * Configure single sign-on (SSO) for Azure AD joined devices > [!div class="nextstepaction"] -> [Prerequisites](hello-hybrid-key-trust-prereqs.md) +> [Next: configure and validate the Public Key Infrastructure >](hello-hybrid-key-trust-validate-pki.md) -

+ +[AZ-1]: /azure/active-directory/hybrid/how-to-connect-sync-whatis +[AZ-2]: /azure/multi-factor-authentication/multi-factor-authentication +[AZ-3]: /azure/multi-factor-authentication/multi-factor-authentication-whats-next +[AZ-4]: /azure/active-directory/devices/troubleshoot-device-dsregcmd +[AZ-5]: /azure/active-directory/connect/active-directory-aadconnectsync-feature-scheduler +[AZ-6]: /azure/active-directory/hybrid/whatis-phs +[AZ-7]: /azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication +[AZ-8]: /azure/active-directory/devices/hybrid-azuread-join-plan -## Follow the Windows Hello for Business hybrid key trust deployment guide - -1. Overview (*You are here*) -2. [Prerequisites](hello-hybrid-key-trust-prereqs.md) -3. [New Installation Baseline](hello-hybrid-key-new-install.md) -4. [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md) -5. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md) -6. [Configure Windows Hello for Business settings](hello-hybrid-key-whfb-settings.md) -7. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md) \ No newline at end of file +[SER-1]: /windows-server/identity/ad-fs/operations/configure-ad-fs-2016-and-azure-mfa \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-provision.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-provision.md deleted file mode 100644 index b5c704fb93..0000000000 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-provision.md +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: Hybrid Azure AD joined Windows Hello for Business key trust Provisioning (Windows Hello for Business) -description: Learn about provisioning for hybrid key trust deployments of Windows Hello for Business and learn where to find the hybrid key trust deployment guide. -ms.date: 4/30/2021 -appliesto: -- ✅ Windows 10 and later -ms.topic: article ---- -# Hybrid Azure AD joined Windows Hello for Business Key Trust Provisioning - -[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-key-trust.md)] - -## Provisioning - -The Windows Hello for Business provisioning begins immediately after the user has signed in, after the user profile is loaded, but before the user receives their desktop. Windows only launches the provisioning experience if all the prerequisite checks pass. You can determine the status of the prerequisite checks by viewing the **User Device Registration** in the **Event Viewer** under **Applications and Services Logs\Microsoft\Windows**. - -![Event358.](images/Event358-2.png) - -The first thing to validate is the computer has processed device registration. You can view this from the User device registration logs where the check **Device is Azure Active Directory-joined (AADJ or DJ++): Yes** appears. Additionally, you can validate this using the **dsregcmd /status** command from a console prompt where the value for **AzureADJoined** reads **Yes**. - -Windows Hello for Business provisioning begins with a full screen page with the title **Setup a PIN** and button with the same name. The user clicks **Setup a PIN**. - -![Setup a PIN Provisioning.](images/setupapin.png) - -The provisioning flow proceeds to the Multi-Factor authentication portion of the enrollment. Provisioning informs the user that it is actively attempting to contact the user through their configured form of MFA. The provisioning process does not proceed until authentication succeeds, fails or times out. A failed or timeout MFA results in an error and asks the user to retry. - -![MFA prompt during provisioning.](images/mfa.png) - -After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe any PIN complexity requirements that you deployed to the environment. - -![Create a PIN during provisioning.](images/createPin.png) - -The provisioning flow has all the information it needs to complete the Windows Hello for Business enrollment. - -- A successful single factor authentication (username and password at sign-in) -- A device that has successfully completed device registration -- A fresh, successful multi-factor authentication -- A validated PIN that meets the PIN complexity requirements - -The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with Azure Active Directory to register the public key. When key registration completes, Windows Hello for Business provisioning informs the user they can use their PIN to sign-in. The user may close the provisioning application and see their desktop. While the user has completed provisioning, Azure AD Connect synchronizes the user's key to Active Directory. - -> [!IMPORTANT] -> The minimum time needed to synchronize the user's public key from Azure Active Directory to the on-premises Active Directory is 30 minutes. The Azure AD Connect scheduler controls the synchronization interval. -> **This synchronization latency delays the user's ability to authenticate and use on-premises resources until the user's public key has synchronized to Active Directory.** Once synchronized, the user can authenticate and use on-premises resources. -> Read [Azure AD Connect sync: Scheduler](/azure/active-directory/connect/active-directory-aadconnectsync-feature-scheduler) to view and adjust the **synchronization cycle** for your organization. - -

- -
- -## Follow the Windows Hello for Business hybrid key trust deployment guide - -1. [Overview](hello-hybrid-key-trust.md) -2. [Prerequisites](hello-hybrid-key-trust-prereqs.md) -3. [New Installation Baseline](hello-hybrid-key-new-install.md) -4. [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md) -5. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md) -6. [Configure Windows Hello for Business settings](hello-hybrid-key-whfb-settings.md) -7. Sign-in and Provision(*You are here*) diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-ad.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-ad.md deleted file mode 100644 index cb30af909d..0000000000 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-ad.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: Configuring Hybrid Azure AD joined key trust Windows Hello for Business - Active Directory (AD) -description: Configuring Hybrid key trust Windows Hello for Business - Active Directory (AD) -ms.date: 4/30/2021 -appliesto: -- ✅ Windows 10 and later -ms.topic: article ---- -# Configuring Hybrid Azure AD joined key trust Windows Hello for Business: Active Directory - -[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-key-trust-ad.md)] - -Configure the appropriate security groups to efficiently deploy Windows Hello for Business to users. - -### Creating Security Groups - -Windows Hello for Business uses a security group to simplify the deployment and management. - -#### Create the Windows Hello for Business Users Security Group - -The Windows Hello for Business Users group is used to make it easy to deploy Windows Hello for Business in phases. You assign Group Policy and Certificate template permissions to this group to simplify the deployment by simply adding the users to the group. This provides users with the proper permissions to provision Windows Hello for Business and to enroll in the Windows Hello for Business authentication certificate. - -Sign-in a domain controller or management workstation with *Domain Admin* equivalent credentials. - -1. Open **Active Directory Users and Computers**. -2. Click **View** and click **Advanced Features**. -3. Expand the domain node from the navigation pane. -4. Right-click the **Users** container. Click **New**. Click **Group**. -5. Type **Windows Hello for Business Users** in the **Group Name** text box. -6. Click **OK**. - -### Section Review - -> [!div class="checklist"] -> * Create the Windows Hello for Business Users group -> -> [!div class="step-by-step"] -> [< Configure Windows Hello for Business](hello-hybrid-key-whfb-settings.md) -> [Configure Azure AD Connect >](hello-hybrid-key-whfb-settings-dir-sync.md) - -

- -
- -## Follow the Windows Hello for Business hybrid key trust deployment guide - -1. [Overview](hello-hybrid-cert-trust.md) -2. [Prerequisites](hello-hybrid-key-trust-prereqs.md) -3. [New Installation Baseline](hello-hybrid-key-new-install.md) -4. [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md) -5. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md) -6. Configure Windows Hello for Business settings: Active Directory (*You are here*) -7. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md) diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-dir-sync.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-dir-sync.md deleted file mode 100644 index f19aab257d..0000000000 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-dir-sync.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: Hybrid Azure AD joined Windows Hello for Business - Directory Synchronization -description: How to configure Hybrid key trust Windows Hello for Business - Directory Synchronization -ms.date: 4/30/2021 -appliesto: -- ✅ Windows 10 and later -ms.topic: article ---- -# Configure Hybrid Azure AD joined Windows Hello for Business: Directory Synchronization - -[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-key-trust.md)] - -## Directory Synchronization - -In hybrid deployments, users register the public portion of their Windows Hello for Business credential with Azure AD. Azure AD Connect synchronizes the Windows Hello for Business public key to Active Directory. - -### Group Memberships for the Azure AD Connect Service Account ->[!IMPORTANT] -> If you already have a Windows Server 2016 domain controller in your domain, you can skip **Configure Permissions for Key Synchronization**. For more detail see [Configure Hybrid Windows Hello for Business: Directory Synchronization](./hello-hybrid-cert-whfb-settings-dir-sync.md). - -The KeyAdmins global group provides the Azure AD Connect service with the permissions needed to read and write the public key to Active Directory. - -Sign-in a domain controller or management workstation with _Domain Admin_ equivalent credentials. - -1. Open **Active Directory Users and Computers**. -2. Click the **Users** container in the navigation pane. -3. Right-click **Key Admins** in the details pane and click **Properties**. -4. Click the **Members** tab and click **Add** -5. In the **Enter the object names to select** text box, type the name of the service account used as an AD DS Connector account and click **OK**. -6. Click **OK** to return to **Active Directory Users and Computers**. - -> [!NOTE] -> If your Active Directory forest has multiple domains, your ADConnect accounts need to be members of the **Enterprise Key Admins** group. This membership is needed to write the keys to other domain users. - -### Section Review - -> [!div class="checklist"] -> * Configure group membership for Azure AD Connect - -> [!div class="step-by-step"] -> [< Configure Active Directory](hello-hybrid-key-whfb-settings-ad.md) -> [Configure PKI >](hello-hybrid-key-whfb-settings-pki.md) - -
- -## Follow the Windows Hello for Business hybrid key trust deployment guide - -1. [Overview](hello-hybrid-cert-trust.md) -2. [Prerequisites](hello-hybrid-key-trust-prereqs.md) -3. [New Installation Baseline](hello-hybrid-key-new-install.md) -4. [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md) -5. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md) -6. Configure Windows Hello for Business settings: Directory Synchronization (*You are here*) -7. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md) diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-pki.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-pki.md deleted file mode 100644 index 9e36481b2a..0000000000 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-pki.md +++ /dev/null @@ -1,128 +0,0 @@ ---- -title: Configure Hybrid Azure AD joined key trust Windows Hello for Business -description: Configuring Hybrid key trust Windows Hello for Business - Public Key Infrastructure (PKI) -ms.date: 04/30/2021 -appliesto: -- ✅ Windows 10 and later -ms.topic: article ---- -# Configure Hybrid Azure AD joined Windows Hello for Business: Public Key Infrastructure - -[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-key-trust.md)] - -Windows Hello for Business deployments rely on certificates. Hybrid deployments use publicly issued server authentication certificates to validate the name of the server to which they are connecting and to encrypt the data that flows them and the client computer. - -All deployments use enterprise issued certificates for domain controllers as a root of trust. - -## Certificate Templates - -This section has you configure certificate templates on your Windows Server 2012 or later issuing certificate authority. - -### Domain Controller certificate template - -Clients need to trust domain controllers and the best way to do this is to ensure each domain controller has a Kerberos Authentication certificate. Installing a certificate on the domain controller enables the Key Distribution Center (KDC) to prove its identity to other members of the domain. This provides clients a root of trust external to the domain - namely the enterprise certificate authority. - -Domain controllers automatically request a domain controller certificate (if published) when they discover an enterprise certificate authority is added to Active Directory. However, certificates based on the *Domain Controller* and *Domain Controller Authentication* certificate templates do not include the **KDC Authentication** object identifier (OID), which was later added to the Kerberos RFC. Inclusion of the **KDC Authentication** OID in domain controller certificate is not required for key trust authentication from Hybrid Azure AD-joined devices. The OID is required for enabling authentication with Windows Hello for Business to on-premises resources by Azure AD-joined devices. The steps below to update the domain controller certificate to include the **KDC Authentication** OID may be skipped if you only have Hybrid Azure AD Joined devices in your environment, but we recommend completing these steps if you are considering adding Azure AD-joined devices to your environment in the future. - -By default, the Active Directory Certificate Authority provides and publishes the Kerberos Authentication certificate template. However, the cryptography configuration included in the provided template is based on older and less performant cryptography APIs. To ensure domain controllers request the proper certificate with the best available cryptography, use the **Kerberos Authentication** certificate template a baseline to create an updated domain controller certificate template. - -#### Create a Domain Controller Authentication (Kerberos) Certificate Template - -Sign-in a certificate authority or management workstations with _Domain Admin_ equivalent credentials. - -1. Open the **Certificate Authority** management console. -2. Right-click **Certificate Templates** and click **Manage**. -3. In the **Certificate Template Console**, right-click the **Kerberos Authentication** template in the details pane and click **Duplicate Template**. -4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2008 R2** from the **Certification Authority** list. Select **Windows 7.Server 2008 R2** from the **Certificate Recipient** list. -5. On the **General** tab, type **Domain Controller Authentication (Kerberos)** in Template display name. Adjust the validity and renewal period to meet your enterprise's needs. - > [!NOTE] - > If you use different template names, you'll need to remember and substitute these names in different portions of the lab. -6. On the **Subject Name** tab, select the **Build from this Active Directory information** button if it is not already selected. Select **None** from the **Subject name format** list. Select **DNS name** from the **Include this information in alternate subject** list. Clear all other items. -7. On the **Cryptography** tab, select **Key Storage Provider** from the **Provider Category** list. Select **RSA** from the **Algorithm name** list. Type **2048** in the **Minimum key size** text box. Select **SHA256** from the **Request hash** list. Click **OK**. -8. Close the console. - ->[!NOTE] ->Don't confuse the **Request hash** algorithm with the hash argorithm of the certificate. - -#### Configure Certificate Superseding for the Domain Controller Authentication (Kerberos) Certificate Template - -Many domain controllers may have an existing domain controller certificate. The Active Directory Certificate Services provides a default certificate template for domain controllers--the domain controller certificate template. Later releases provided a new certificate template--the domain controller authentication certificate template. These certificate templates were provided prior to update of the Kerberos specification that stated Key Distribution Centers (KDCs) performing certificate authentication needed to include the **KDC Authentication** extension. - -The Kerberos Authentication certificate template is the most current certificate template designated for domain controllers and should be the one you deploy to all your domain controllers (2008 or later). - -The autoenrollment feature in Windows enables you to effortlessly replace these domain controller certificates. You can use the following configuration to replace older domain controller certificates with a new certificate using the Kerberos Authentication certificate template. - -Sign-in a certificate authority or management workstations with _Enterprise Admin_ equivalent credentials. - -1. Open the **Certificate Authority** management console. -2. Right-click **Certificate Templates** and click **Manage**. -3. In the **Certificate Template Console**, right-click the **Domain Controller Authentication (Kerberos)** (or the name of the certificate template you created in the previous section) template in the details pane and click **Properties**. -4. Click the **Superseded Templates** tab. Click **Add**. -5. From the **Add Superseded Template** dialog, select the **Domain Controller** certificate template and click **OK**. Click **Add**. -6. From the **Add Superseded Template** dialog, select the **Domain Controller Authentication** certificate template and click **OK**. -7. From the **Add Superseded Template dialog**, select the **Kerberos Authentication** certificate template and click **OK**. -8. Add any other enterprise certificate templates that were previously configured for domain controllers to the **Superseded Templates** tab. -9. Click **OK** and close the **Certificate Templates** console. - -The certificate template is configured to supersede all the certificate templates provided in the certificate templates superseded templates list. However, the certificate template and the superseding of certificate templates is not active until you publish the certificate template to one or more certificate authorities. - -> [!NOTE] -> The domain controller's certificate must chain to a root in the NTAuth store. By default, the Active Directory Certificate Authority's root certificate is added to the NTAuth store. If you are using a third-party CA, this may not be done by default. If the domain controller certificate does not chain to a root in the NTAuth store, user authentication will fail. ->To see all certificates in the NTAuth store, use the following command: -> -> `Certutil -viewstore -enterprise NTAuth` - -### Publish Certificate Templates to a Certificate Authority - -The certificate authority may only issue certificates for certificate templates that are published to that certificate authority. If you have more than one certificate authority and you want that certificate authority to issue certificates based on a specific certificate template, then you must publish the certificate template to all certificate authorities that are expected to issue the certificate. - -Sign-in to the certificate authority or management workstations with _enterprise administrator_ equivalent credentials. - -1. Open the **Certificate Authority** management console. -2. Expand the parent node from the navigation pane. -3. Click **Certificate Templates** in the navigation pane. -4. Right-click the **Certificate Templates** node. Click **New**, and click **Certificate Template** to issue. -5. In the **Enable Certificates Templates** window, select the **Domain Controller Authentication (Kerberos)** template you created in the previous steps. Click **OK** to publish the selected certificate templates to the certificate authority. -6. If you published the **Domain Controller Authentication (Kerberos)** certificate template, then you should unpublish the certificate templates you included in the superseded templates list. - - To unpublish a certificate template, right-click the certificate template you want to unpublish in the details pane of the Certificate Authority console and select **Delete**. Click **Yes** to confirm the operation. -7. Close the console. - -### Unpublish Superseded Certificate Templates - -The certificate authority only issues certificates based on published certificate templates. For defense in depth security, it is a good practice to unpublish certificate templates that the certificate authority is not configured to issue. This includes the pre-published certificate template from the role installation and any superseded certificate templates. - -The newly created domain controller authentication certificate template supersedes previous domain controller certificate templates. Therefore, you need to unpublish these certificate templates from all issuing certificate authorities. - -Sign-in to the certificate authority or management workstation with _Enterprise Admin_ equivalent credentials. - -1. Open the **Certificate Authority** management console. -2. Expand the parent node from the navigation pane. -3. Click **Certificate Templates** in the navigation pane. -4. Right-click the **Domain Controller** certificate template in the content pane and select **Delete**. Click **Yes** on the **Disable certificate templates** window. -5. Repeat step 4 for the **Domain Controller Authentication** and **Kerberos Authentication** certificate templates. - -### Section Review - -> [!div class="checklist"] -> * Domain Controller certificate template -> * Configure superseded domain controller certificate templates -> * Publish Certificate templates to certificate authorities -> * Unpublish superseded certificate templates -> s -> [!div class="step-by-step"] -> [< Configure Azure AD Connect](hello-hybrid-key-whfb-settings-dir-sync.md) -> [Configure policy settings >](hello-hybrid-key-whfb-settings-policy.md) - -

- -
- -## Follow the Windows Hello for Business hybrid key trust deployment guide - -1. [Overview](hello-hybrid-cert-trust.md) -2. [Prerequisites](hello-hybrid-key-trust-prereqs.md) -3. [New Installation Baseline](hello-hybrid-key-new-install.md) -4. [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md) -5. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md) -6. Configure Windows Hello for Business settings: PKI (*You are here*) -7. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md) diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-policy.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-policy.md deleted file mode 100644 index 333f505d95..0000000000 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-policy.md +++ /dev/null @@ -1,169 +0,0 @@ ---- -title: Configure Hybrid Azure AD joined Windows Hello for Business - Group Policy -description: Configuring Hybrid key trust Windows Hello for Business - Group Policy -ms.date: 4/30/2021 -appliesto: -- ✅ Windows 10 and later -ms.topic: article ---- -# Configure Hybrid Azure AD joined Windows Hello for Business: Group Policy - -[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-key-trust-ad.md)] - -## Policy Configuration - -You need at least a Windows 10, version 1703 workstation to run the Group Policy Management Console, which provides the latest Windows Hello for Business and PIN Complexity Group Policy settings. To run the Group Policy Management Console, you need to install the Remote Server Administration Tools for Windows. You can download these tools from the [Microsoft Download Center](https://www.microsoft.com/download/details.aspx?id=45520). -Install the Remote Server Administration Tools for Windows on a computer running Windows 10, version 1703 or later. - -Alternatively, you can create copy the .ADMX and .ADML files from a Windows 10 Creators Edition (1703) to their respective language folder on a Windows Server or you can create a Group Policy Central Store and copy them their respective language folder. See [How to create and manage the Central Store for Group Policy Administrative Templates in Windows](/troubleshoot/windows-client/group-policy/create-and-manage-central-store) for more information. - -Domain controllers of Windows Hello for Business deployments need one Group Policy setting, which enables automatic certificate enrollment for the newly create domain controller authentication certificate. This policy setting ensures domain controllers (new and existing) automatically request and renew the correct domain controller certificate. - -Hybrid Azure AD-joined devices need one Group Policy setting: -* Enable Windows Hello for Business - -### Configure Domain Controllers for Automatic Certificate Enrollment - -Domain controllers automatically request a certificate from the *Domain Controller* certificate template. However, the domain controller is unaware of newer certificate templates or superseded configurations on certificate templates. - -To continue automatic enrollment and renewal of domain controller certificates that understand newer certificate template and superseded certificate template configurations, create and configure a Group Policy object for automatic certificate enrollment and link the Group Policy object to the Domain Controllers OU. - -#### Create a Domain Controller Automatic Certificate Enrollment Group Policy object - -Sign-in a domain controller or management workstations with _Domain Admin_ equivalent credentials. - -1. Start the **Group Policy Management Console** (gpmc.msc) -2. Expand the domain and select the **Group Policy Object** node in the navigation pane. -3. Right-click **Group Policy object** and select **New** -4. Type *Domain Controller Auto Certificate Enrollment* in the name box and click **OK**. -5. Right-click the **Domain Controller Auto Certificate Enrollment** Group Policy object and click **Edit**. -6. In the navigation pane, expand **Policies** under **Computer Configuration**. -7. Expand **Windows Settings**, **Security Settings**, and click **Public Key Policies**. -8. In the details pane, right-click **Certificate Services Client � Auto-Enrollment** and select **Properties**. -9. Select **Enabled** from the **Configuration Model** list. -10. Select the **Renew expired certificates**, **update pending certificates**, and **remove revoked certificates** check box. -11. Select the **Update certificates that use certificate templates** check box. -12. Click **OK**. Close the **Group Policy Management Editor**. - -#### Deploy the Domain Controller Auto Certificate Enrollment Group Policy Object - -Sign-in a domain controller or management workstations with _Domain Admin_ equivalent credentials. - -1. Start the **Group Policy Management Console** (gpmc.msc) -2. In the navigation pane, expand the domain and expand the node that has your Active Directory domain name. Right-click the **Domain Controllers** organizational unit and click **Link an existing GPO�** -3. In the **Select GPO** dialog box, select **Domain Controller Auto Certificate Enrollment** or the name of the domain controller certificate enrollment Group Policy object you previously created and click **OK**. - ->[!IMPORTANT] ->If you don't find options in GPO, you have to load the [PolicyDefinitions folder](/troubleshoot/windows-client/group-policy/create-and-manage-central-store). - -### Windows Hello for Business Group Policy - -The Windows Hello for Business Group Policy object delivers the correct Group Policy settings to the user, which enables them to enroll and use Windows Hello for Business to authenticate to Azure and Active Directory - -> [!NOTE] -> If you deployed Windows Hello for Business configuration using both Group Policy and Microsoft Intune, Group Policy settings will take precedence and Intune settings will be ignored. For more details about deploying Windows Hello for Business configuration using Microsoft Intune, see [Windows device settings to enable Windows Hello for Business in Intune](/mem/intune/protect/identity-protection-windows-settings) and [PassportForWork CSP](/windows/client-management/mdm/passportforwork-csp). For more details about policy conflicts, see [Policy conflicts from multiple policy sources](./hello-manage-in-organization.md#policy-conflicts-from-multiple-policy-sources) - -#### Enable Windows Hello for Business - -The Enable Windows Hello for Business Group Policy setting is the configuration needed for Windows to determine if a user should attempt to enroll for Windows Hello for Business. A user will only attempt enrollment if this policy setting is configured to enabled. - -You can configure the Enable Windows Hello for Business Group Policy setting for computer or users. Deploying this policy setting to computers results in ALL users that sign-in that computer to attempt a Windows Hello for Business enrollment. Deploying this policy setting to a user results in only that user attempting a Windows Hello for Business enrollment. Additionally, you can deploy the policy setting to a group of users so only those users attempt a Windows Hello for Business enrollment. If both user and computer policy settings are deployed, the user policy setting has precedence. - -#### Create the Windows Hello for Business Group Policy object - -The Group Policy object contains the policy setting needed to trigger Windows Hello for Business provisioning. - -Sign-in a domain controller or management workstations with _Domain Admin_ equivalent credentials. - -1. Start the **Group Policy Management Console** (gpmc.msc) -2. Expand the domain and select the **Group Policy Object** node in the navigation pane. -3. Right-click **Group Policy object** and select **New**. -4. Type *Enable Windows Hello for Business* in the name box and click **OK**. -5. In the content pane, right-click the **Enable Windows Hello for Business** Group Policy object and click **Edit**. -6. In the navigation pane, expand **Policies** under **User Configuration**. -7. Expand **Administrative Templates > Windows Component**, and select **Windows Hello for Business**. -8. In the content pane, double-click **Use Windows Hello for Business**. Click **Enable** and click **OK**. Close the **Group Policy Management Editor**. - -#### Configure Security in the Windows Hello for Business Group Policy object - -The best way to deploy the Windows Hello for Business Group Policy object is to use security group filtering. The enables you to easily manage the users that should receive Windows Hello for Business by simply adding them to a group. This enables you to deploy Windows Hello for Business in phases. -1. Start the **Group Policy Management Console** (gpmc.msc) -2. Expand the domain and select the **Group Policy Object** node in the navigation pane. -3. Double-click the **Enable Windows Hello for Business** Group Policy object. -4. In the **Security Filtering** section of the content pane, click **Add**. Type *Windows Hello for Business Users* or the name of the security group you previously created and click **OK**. -5. Click the **Delegation** tab. Select **Authenticated Users** and click **Advanced**. -6. In the **Group or User names** list, select **Authenticated Users**. In the **Permissions for Authenticated Users** list, clear the **Allow** check box for the **Apply Group Policy** permission. Click **OK**. - -#### Deploy the Windows Hello for Business Group Policy object - -The application of the Windows Hello for Business Group Policy object uses security group filtering. This enables you to link the Group Policy object at the domain, ensuring the Group Policy object is within scope to all users. However, the security group filtering ensures only the users included in the *Windows Hello for Business Users* global group receive and apply the Group Policy object, which results in the provisioning of Windows Hello for Business. -1. Start the **Group Policy Management Console** (gpmc.msc) -2. In the navigation pane, expand the domain and right-click the node that has your Active Directory domain name and click **Link an existing GPO** -3. In the **Select GPO** dialog box, select **Enable Windows Hello for Business** or the name of the Windows Hello for Business Group Policy object you previously created and click **OK**. - -Just to reassure, linking the **Windows Hello for Business** Group Policy object to the domain ensures the Group Policy object is in scope for all domain users. However, not all users will have the policy settings applied to them. Only users who are members of the Windows Hello for Business group receive the policy settings. All others users ignore the Group Policy object. - -## Other Related Group Policy settings - -### Windows Hello for Business - -There are other Windows Hello for Business policy settings you can configure to manage your Windows Hello for Business deployment. These policy settings are computer-based policy setting; so they are applicable to any user that sign-in from a computer with these policy settings. - -#### Use a hardware security device - -The default configuration for Windows Hello for Business is to prefer hardware protected credentials; however, not all computers are able to create hardware protected credentials. When Windows Hello for Business enrollment encounters a computer that cannot create a hardware protected credential, it will create a software-based credential. - -You can enable and deploy the **Use a hardware security device** Group Policy Setting to force Windows Hello for Business to only create hardware protected credentials. Users that sign-in from a computer incapable of creating a hardware protected credential do not enroll for Windows Hello for Business. - -Another policy setting becomes available when you enable the **Use a hardware security device** Group Policy setting that enables you to prevent Windows Hello for Business enrollment from using version 1.2 Trusted Platform Modules (TPM). Version 1.2 TPMs typically perform cryptographic operations slower than version 2.0 TPMs and are more unforgiving during anti-hammering and PIN lockout activities. Some organizations may not want slow sign-in performance and management overhead associated with version 1.2 TPMs. To prevent Windows Hello for Business from using version 1.2 TPMs, select the TPM 1.2 check box after you enable the Use a hardware security device Group Policy object. - -#### Use biometrics - -Windows Hello for Business provides a great user experience when combined with the use of biometrics. Rather than providing a PIN to sign-in, a user can use a fingerprint or facial recognition to sign-in to Windows, without sacrificing security. - -The default Windows Hello for Business enables users to enroll and use biometrics. However, some organization may want more time before using biometrics and want to disable their use until they are ready. To not allow users to use biometrics, configure the **Use biometrics** Group Policy setting to disabled and apply it to your computers. The policy setting disabled all biometrics. Currently, Windows doesn't provide the ability to set granular policies that enable you to disable specific modalities of biometrics, such as allowing facial recognition but disallowing fingerprint recognition. - -### PIN Complexity - -PIN complexity is not specific to Windows Hello for Business. Windows enables users to use PINs outside of Windows Hello for Business. PIN Complexity Group Policy settings apply to all uses of PINs, even when Windows Hello for Business is not deployed. - ->[!IMPORTANT] -> Starting from Windows 10, version 1703, the PIN complexity Group Policy settings have moved to remove misunderstanding that PIN complexity policy settings were exclusive to Windows Hello for Business. The new location of these Group Policy settings is under **Computer Configuration\Administrative Templates\System\PIN Complexity** of the Group Policy editor. - -Windows provides eight PIN Complexity Group Policy settings that give you granular control over PIN creation and management. You can deploy these policy settings to computers, where they affect all users creating PINs on that computer; or, you can deploy these settings to users, where they affect those users creating PINs regardless of the computer they use. If you deploy both computer and user PIN complexity Group Policy settings, the user policy settings have precedence over computer policy settings. Also, this conflict resolution is based on the last applied policy. Windows does not merge the policy settings automatically; however, you can deploy Group Policy to provide to accomplish a variety of configurations. The policy settings included are: -* Require digits -* Require lowercase letters -* Maximum PIN length -* Minimum PIN length -* Expiration -* History -* Require special characters -* Require uppercase letters - -## Add users to the Windows Hello for Business Users group - -Users must receive the Windows Hello for Business group policy settings and have the proper permission to provision Windows Hello for Business. You can provide users with these settings and permissions by adding the users or groups to the **Windows Hello for Business Users** group. Users and groups who are not members of this group will not attempt to enroll for Windows Hello for Business. - -### Section Review -> [!div class="checklist"] -> * Configure domain controllers for automatic certificate enrollment. -> * Create Windows Hello for Business Group Policy object. -> * Enable the Use Windows Hello for Business policy setting. -> * Add users or groups to the Windows Hello for Business group -> -> -> [!div class="nextstepaction"] -> [Sign-in and Provision](hello-hybrid-key-whfb-provision.md) - -

- -
- -## Follow the Windows Hello for Business hybrid key trust deployment guide -1. [Overview](hello-hybrid-cert-trust.md) -2. [Prerequisites](hello-hybrid-key-trust-prereqs.md) -3. [New Installation Baseline](hello-hybrid-key-new-install.md) -4. [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md) -5. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md) -6. Configure Windows Hello for Business policy settings (*You are here*) -7. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md) diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings.md deleted file mode 100644 index 5e24b6de2c..0000000000 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: Configure Hybrid Azure AD joined Windows Hello for Business key trust Settings -description: Begin the process of configuring your hybrid key trust environment for Windows Hello for Business. Start with your Active Directory configuration. -ms.date: 4/30/2021 -appliesto: -- ✅ Windows 10 and later -ms.topic: article ---- -# Configure Hybrid Azure AD joined Windows Hello for Business key trust settings - -[!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-key-trust.md)] - -You are ready to configure your hybrid Azure AD joined key trust environment for Windows Hello for Business. - -> [!IMPORTANT] -> Ensure your environment meets all the [prerequisites](hello-hybrid-key-trust-prereqs.md) before proceeding. Review the [New Installation baseline](hello-hybrid-key-new-install.md) section of this deployment document to learn how to prepare your environment for your Windows Hello for Business deployment. - -The configuration for Windows Hello for Business is grouped in four categories. These categories are: -* [Active Directory](hello-hybrid-key-whfb-settings-ad.md) -* [Azure AD Connect](hello-hybrid-key-whfb-settings-dir-sync.md) -* [Public Key Infrastructure](hello-hybrid-key-whfb-settings-pki.md) -* [Group Policy](hello-hybrid-key-whfb-settings-policy.md) - -For the most efficient deployment, configure these technologies in order beginning with the Active Directory configuration - -> [!div class="step-by-step"] -> [Configure Active Directory >](hello-hybrid-key-whfb-settings-ad.md) - -## Follow the Windows Hello for Business hybrid key trust deployment guide - -1. [Overview](hello-hybrid-key-trust.md) -2. [Prerequisites](hello-hybrid-key-trust-prereqs.md) -3. [New Installation Baseline](hello-hybrid-key-new-install.md) -4. [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md) -5. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md) -6. Configure Windows Hello for Business settings (*You are here*) -7. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md) diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-adfs.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-adfs.md index b08abdb82d..b0cf1c66b8 100644 --- a/windows/security/identity-protection/hello-for-business/hello-key-trust-adfs.md +++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-adfs.md @@ -9,7 +9,7 @@ ms.topic: tutorial --- # Prepare and deploy Active Directory Federation Services - on-premises key trust -[!INCLUDE [hello-on-premises-key-trust](../../includes/hello-on-premises-key-trust.md)] +[!INCLUDE [hello-on-premises-key-trust](./includes/hello-on-premises-key-trust.md)] Windows Hello for Business works exclusively with the Active Directory Federation Service (AD FS) role included with Windows Server. The on-premises key trust deployment model uses AD FS for *key registration* and *device registration*. diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-policy-settings.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-policy-settings.md index 03e7dbfe38..d9446b6eec 100644 --- a/windows/security/identity-protection/hello-for-business/hello-key-trust-policy-settings.md +++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-policy-settings.md @@ -9,7 +9,7 @@ ms.topic: tutorial --- # Configure Windows Hello for Business group policy settings - on-premises key trust -[!INCLUDE [hello-on-premises-key-trust](../../includes/hello-on-premises-key-trust.md)] +[!INCLUDE [hello-on-premises-key-trust](./includes/hello-on-premises-key-trust.md)] On-premises key trust deployments of Windows Hello for Business need one Group Policy setting: *Enable Windows Hello for Business*. The Group Policy setting determines whether users are allowed, and prompted, to enroll for Windows Hello for Business. It can be configured for computers or users. diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-ad-prereq.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-ad-prereq.md index e53e1d194f..07673151d3 100644 --- a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-ad-prereq.md +++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-ad-prereq.md @@ -9,7 +9,7 @@ ms.topic: tutorial --- # Validate Active Directory prerequisites - on-premises key trust -[!INCLUDE [hello-on-premises-key-trust](../../includes/hello-on-premises-key-trust.md)] +[!INCLUDE [hello-on-premises-key-trust](./includes/hello-on-premises-key-trust.md)] Key trust deployments need an adequate number of domain controllers to ensure successful user authentication with Windows Hello for Business. To learn more about domain controller planning for key trust deployments, read the [Windows Hello for Business planning guide](hello-planning-guide.md) and the [Planning an adequate number of Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) section. diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-deploy-mfa.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-deploy-mfa.md index 6088986d1e..65f12b5274 100644 --- a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-deploy-mfa.md +++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-deploy-mfa.md @@ -10,7 +10,7 @@ ms.topic: tutorial # Validate and deploy multi-factor authentication - on-premises key trust -[!INCLUDE [hello-on-premises-key-trust](../../includes/hello-on-premises-key-trust.md)] +[!INCLUDE [hello-on-premises-key-trust](./includes/hello-on-premises-key-trust.md)] Windows Hello for Business requires users perform multi-factor authentication (MFA) prior to enroll in the service. On-premises deployments can use, as MFA option: diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md index dac396577a..96505087ec 100644 --- a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md +++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md @@ -9,161 +9,23 @@ ms.topic: tutorial --- # Configure and validate the Public Key Infrastructure - on-premises key trust -[!INCLUDE [hello-on-premises-key-trust](../../includes/hello-on-premises-key-trust.md)] +[!INCLUDE [hello-on-premises-key-trust](./includes/hello-on-premises-key-trust.md)] Windows Hello for Business must have a Public Key Infrastructure (PKI) when using the *key trust* or *certificate trust* models. The domain controllers must have a certificate, which serves as a root of trust for clients. The certificate ensures that clients don't communicate with rogue domain controllers. -## Deploy an enterprise certification authority +[!INCLUDE [lab-based-pki-deploy](includes/lab-based-pki-deploy.md)] -This guide assumes most enterprises have an existing public key infrastructure. Windows Hello for Business depends on an enterprise PKI running the Windows Server *Active Directory Certificate Services* role. +## Configure the enterprise PKI -### Lab-based PKI +[!INCLUDE [dc-certificate-template](includes/dc-certificate-template.md)] -The following instructions may be used to deploy simple public key infrastructure that is suitable **for a lab environment**. +[!INCLUDE [dc-certificate-template-supersede](includes/dc-certificate-supersede.md)] -Sign in using *Enterprise Administrator* equivalent credentials on a Windows Server where you want the certification authority (CA) installed. +[!INCLUDE [web-server-certificate-template](includes/web-server-certificate-template.md)] ->[!NOTE] ->Never install a certification authority on a domain controller in a production environment. +[!INCLUDE [unpublish-superseded-templates](includes/unpublish-superseded-templates.md)] -1. Open an elevated Windows PowerShell prompt -1. Use the following command to install the Active Directory Certificate Services role. - ```PowerShell - Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools - ``` -3. Use the following command to configure the CA using a basic certification authority configuration - ```PowerShell - Install-AdcsCertificationAuthority - ``` - -## Configure a PKI - -If you have an existing PKI, review [Certification Authority Guidance](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831574(v=ws.11)) to properly design your infrastructure. Then, consult the [Test Lab Guide: Deploying an AD CS Two-Tier PKI Hierarchy](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831348(v=ws.11)) for instructions on how to configure your PKI using the information from your design session. - -Expand the following sections to configure the PKI for Windows Hello for Business. - -
-
-Configure domain controller certificates - -Clients must trust the domain controllers, and to it each domain controller must have a *Kerberos Authentication* certificate. Installing a certificate on the domain controllers enables the Key Distribution Center (KDC) to prove its identity to other members of the domain. The certificates provide clients a root of trust external to the domain, namely the *enterprise certification authority*. - -Domain controllers automatically request a domain controller certificate (if published) when they discover an enterprise CA is added to Active Directory. However, certificates based on the Domain Controller and Domain Controller Authentication certificate templates don't include the *KDC Authentication* object identifier (OID), which was later added to the Kerberos RFC. Therefore, domain controllers need to request a certificate based on the *Kerberos Authentication* certificate template. - -By default, the Active Directory CA provides and publishes the *Kerberos Authentication* certificate template. The cryptography configuration included in the template is based on older and less performant cryptography APIs. To ensure domain controllers request the proper certificate with the best available cryptography, use the *Kerberos Authentication* certificate template as a *baseline* to create an updated domain controller certificate template. - -Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials. - -1. Open the **Certification Authority** management console -1. Right-click **Certificate Templates > Manage** -1. In the **Certificate Template Console**, right-click the **Kerberos Authentication** template in the details pane and select **Duplicate Template** -1. On the **Compatibility** tab: - - Clear the **Show resulting changes** check box - - Select **Windows Server 2016** from the **Certification Authority** list - - Select **Windows 10 / Windows Server 2016** from the **Certificate Recipient** list -1. On the **General** tab - - Type *Domain Controller Authentication (Kerberos)* in Template display name - - Adjust the validity and renewal period to meet your enterprise's needs - > [!NOTE] - > If you use different template names, you'll need to remember and substitute these names in different portions of the lab. -1. On the **Subject Name** tab: - - Select the **Build from this Active Directory information** button if it isn't already selected - - Select **None** from the **Subject name format** list - - Select **DNS name** from the **Include this information in alternate subject** list - - Clear all other items -1. On the **Cryptography** tab: - - select **Key Storage Provider** from the **Provider Category** list - - Select **RSA** from the **Algorithm name** list - - Type *2048* in the **Minimum key size** text box - - Select **SHA256** from the **Request hash** list -1. Select **OK** -1. Close the console - -
- - -
-
-Supersede existing domain controller certificates - -The domain controllers may have an existing domain controller certificate. The Active Directory Certificate Services provides a default certificate template for domain controllers called *domain controller certificate*. Later releases of Windows Server provided a new certificate template called *domain controller authentication certificate*. These certificate templates were provided prior to the update of the Kerberos specification that stated Key Distribution Centers (KDCs) performing certificate authentication needed to include the *KDC Authentication* extension. - -The *Kerberos Authentication* certificate template is the most current certificate template designated for domain controllers, and should be the one you deploy to all your domain controllers.\ -The *autoenrollment* feature allows you to replace the domain controller certificates. Use the following configuration to replace older domain controller certificates with new ones, using the *Kerberos Authentication* certificate template. - -Sign in to a CA or management workstations with *Enterprise Administrator* equivalent credentials. - -1. Open the **Certification Authority** management console -1. Right-click **Certificate Templates > Manage** -1. In the **Certificate Template Console**, right-click the *Domain Controller Authentication (Kerberos)* (or the name of the certificate template you created in the previous section) template in the details pane and select **Properties** -1. Select the **Superseded Templates** tab. Select **Add** -1. From the **Add Superseded Template** dialog, select the *Domain Controller* certificate template and select **OK > Add** -1. From the **Add Superseded Template** dialog, select the *Domain Controller Authentication* certificate template and select **OK** -1. From the **Add Superseded Template** dialog, select the *Kerberos Authentication* certificate template and select **OK** -1. Add any other enterprise certificate templates that were previously configured for domain controllers to the **Superseded Templates** tab -1. Select **OK** and close the **Certificate Templates** console - -The certificate template is configured to supersede all the certificate templates provided in the certificate templates superseded templates list. However, the certificate template and the superseding of certificate templates isn't active until the certificate template is published to one or more certificate authorities. - -
- -
-
-Configure an internal web server certificate template - -Windows clients use the https protocol when communicating with Active Directory Federation Services (AD FS). To meet this need, you must issue a server authentication certificate to all the nodes in the AD FS farm. On-premises deployments can use a server authentication certificate issued by their enterprise PKI. You must configure a server authentication certificate template so the host running theAD FS can request the certificate. - -Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials. - -1. Open the **Certification Authority** management console -1. Right-click **Certificate Templates** and select **Manage** -1. In the **Certificate Template Console**, right-click the **Web Server** template in the details pane and select **Duplicate Template** -1. On the **Compatibility** tab: - - Clear the **Show resulting changes** check box - - Select **Windows Server 2016** from the **Certification Authority** list - - Select **Windows 10 / Windows Server 2016** from the **Certificate Recipient** list -1. On the **General** tab: - - Type *Internal Web Server* in **Template display name** - - Adjust the validity and renewal period to meet your enterprise's needs - > [!NOTE] - > If you use different template names, you'll need to remember and substitute these names in different portions of the lab. -1. On the **Request Handling** tab, select **Allow private key to be exported** -1. On the **Subject** tab, select the **Supply in the request** button if it isn't already selected -1. On the **Security** tab: - - Select **Add** - - Type **Domain Computers** in the **Enter the object names to select** box - - Select **OK** - - Select the **Allow** check box next to the **Enroll** permission -1. On the **Cryptography** tab: - - Select **Key Storage Provider** from the **Provider Category** list - - Select **RSA** from the **Algorithm name** list - - Type *2048* in the **Minimum key size** text box - - Select **SHA256** from the **Request hash** list - - Select **OK** -1. Close the console - -
- -
-
-Unpublish Superseded Certificate Templates - -The certification authority only issues certificates based on published certificate templates. For security, it's a good practice to unpublish certificate templates that the CA isn't configured to issue. This includes the pre-published certificate template from the role installation and any superseded certificate templates. - -The newly created *domain controller authentication* certificate template supersedes previous domain controller certificate templates. Therefore, you need to unpublish these certificate templates from all issuing certificate authorities. - -Sign in to the CA or management workstation with *Enterprise Administrator* equivalent credentials. - -1. Open the **Certification Authority** management console -1. Expand the parent node from the navigation pane > **Certificate Templates** -1. Right-click the *Domain Controller* certificate template and select **Delete**. Select **Yes** on the **Disable certificate templates** window -1. Repeat step 3 for the *Domain Controller Authentication* and *Kerberos Authentication* certificate templates - -
- -
-
-Publish certificate templates to the CA +### Publish certificate templates to the CA A certification authority can only issue certificates for certificate templates that are published to it. If you have more than one CA, and you want more CAs to issue certificates based on the certificate template, then you must publish the certificate template to them. @@ -178,71 +40,13 @@ Sign in to the CA or management workstations with **Enterprise Admin** equivalen - To unpublish a certificate template, right-click the certificate template you want to unpublish and select **Delete**. Select **Yes** to confirm the operation 1. Close the console -
+## Configure and deploy certificates to domain controllers -### Configure automatic certificate enrollment for the domain controllers - -Domain controllers automatically request a certificate from the *Domain controller certificate* template. However, domain controllers are unaware of newer certificate templates or superseded configurations on certificate templates. To continue automatic enrollment and renewal of domain controller certificates, create and configure a Group Policy Object (GPO) for automatic certificate enrollment, linking the Group Policy object to the *Domain Controllers* Organizational Unit (OU). - -1. Open the **Group Policy Management Console** (gpmc.msc) -1. Expand the domain and select the **Group Policy Object** node in the navigation pane -1. Right-click **Group Policy object** and select **New** -1. Type *Domain Controller Auto Certificate Enrollment* in the name box and select **OK** -1. Right-click the **Domain Controller Auto Certificate Enrollment** Group Policy object and select **Edit** -1. In the navigation pane, expand **Policies** under **Computer Configuration** -1. Expand **Windows Settings > Security Settings > Public Key Policies** -1. In the details pane, right-click **Certificate Services Client - Auto-Enrollment** and select **Properties** -1. Select **Enabled** from the **Configuration Model** list -1. Select the **Renew expired certificates, update pending certificates, and remove revoked certificates** check box -1. Select the **Update certificates that use certificate templates** check box -1. Select **OK** -1. Close the **Group Policy Management Editor** - -### Deploy the domain controller auto certificate enrollment GPO - -Sign in to domain controller or management workstations with *Domain Administrator* equivalent credentials. - -1. Start the **Group Policy Management Console** (gpmc.msc) -1. In the navigation pane, expand the domain and expand the node with the Active Directory domain name. Right-click the **Domain Controllers** organizational unit and select **Link an existing GPO…** -1. In the **Select GPO** dialog box, select *Domain Controller Auto Certificate Enrollment* or the name of the domain controller certificate enrollment Group Policy object you previously created -1. Select **OK** +[!INCLUDE [dc-certificate-deployment](includes/dc-certificate-deployment.md)] ## Validate the configuration -Windows Hello for Business is a distributed system, which on the surface appears complex and difficult. The key to a successful Windows Hello for Business deployment is to validate phases of work prior to moving to the next phase. - -You want to confirm your domain controllers enroll the correct certificates and not any unnecessary (superseded) certificate templates. You need to check each domain controller that autoenrollment for the computer occurred. - -### Use the event logs - -Sign in to domain controller or management workstations with *Domain Administrator* equivalent credentials. - -1. Using the Event Viewer, navigate to the **Application and Services > Microsoft > Windows > CertificateServices-Lifecycles-System** event log -1. Look for an event indicating a new certificate enrollment (autoenrollment): - - The details of the event include the certificate template on which the certificate was issued - - The name of the certificate template used to issue the certificate should match the certificate template name included in the event - - The certificate thumbprint and EKUs for the certificate are also included in the event - - The EKU needed for proper Windows Hello for Business authentication is Kerberos Authentication, in addition to other EKUs provide by the certificate template - -Certificates superseded by your new domain controller certificate generate an archive event in the event log. The archive event contains the certificate template name and thumbprint of the certificate that was superseded by the new certificate. - -### Certificate Manager - -You can use the Certificate Manager console to validate the domain controller has the properly enrolled certificate based on the correct certificate template with the proper EKUs. Use **certlm.msc** to view certificate in the local computers certificate stores. Expand the **Personal** store and view the certificates enrolled for the computer. Archived certificates don't appear in Certificate Manager. - -### Certutil.exe - -You can use `certutil.exe` command to view enrolled certificates in the local computer. Certutil shows enrolled and archived certificates for the local computer. From an elevated command prompt, run `certutil.exe -q -store my` to view locally enrolled certificates. - -To view detailed information about each certificate in the store, use `certutil.exe -q -v -store my` to validate automatic certificate enrollment enrolled the proper certificates. - -### Troubleshooting - -Windows triggers automatic certificate enrollment for the computer during boot, and when Group Policy updates. You can refresh Group Policy from an elevated command prompt using `gpupdate.exe /force`. - -Alternatively, you can forcefully trigger automatic certificate enrollment using `certreq.exe -autoenroll -q` from an elevated command prompt. - -Use the event logs to monitor certificate enrollment and archive. Review the configuration, such as publishing certificate templates to issuing certification authority and the allow auto enrollment permissions. +[!INCLUDE [dc-certificate-validate](includes/dc-certificate-validate.md)] > [!div class="nextstepaction"] > [Next: prepare and deploy AD FS >](hello-key-trust-adfs.md) \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/hello-manage-in-organization.md b/windows/security/identity-protection/hello-for-business/hello-manage-in-organization.md index a548960eab..8c3bfe995d 100644 --- a/windows/security/identity-protection/hello-for-business/hello-manage-in-organization.md +++ b/windows/security/identity-protection/hello-for-business/hello-manage-in-organization.md @@ -131,28 +131,4 @@ All PIN complexity policies are grouped separately from feature enablement and a >- MinimumPINLength - 8 >- Digits - 1 >- LowercaseLetters - 1 ->- SpecialCharacters - 1 - - +>- SpecialCharacters - 1 \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/images/aadj/AADConnectSchema.png b/windows/security/identity-protection/hello-for-business/images/aadj/AADConnectSchema.png index 2a5658b1a9..93085b03a8 100644 Binary files a/windows/security/identity-protection/hello-for-business/images/aadj/AADConnectSchema.png and b/windows/security/identity-protection/hello-for-business/images/aadj/AADConnectSchema.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/aadj/dsregcmd.png b/windows/security/identity-protection/hello-for-business/images/aadj/dsregcmd.png deleted file mode 100644 index cacbcf0737..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/aadj/dsregcmd.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/event358-2.png b/windows/security/identity-protection/hello-for-business/images/event358-2.png deleted file mode 100644 index 53fd554323..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/event358-2.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/event358.png b/windows/security/identity-protection/hello-for-business/images/event358.png index 70376c35a1..f95e6130e6 100644 Binary files a/windows/security/identity-protection/hello-for-business/images/event358.png and b/windows/security/identity-protection/hello-for-business/images/event358.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/whfb-intune-account-protection-cert-enable.png b/windows/security/identity-protection/hello-for-business/images/whfb-intune-account-protection-cert-enable.png new file mode 100644 index 0000000000..ec2ba07684 Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/whfb-intune-account-protection-cert-enable.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/whfb-intune-account-protection-enable.png b/windows/security/identity-protection/hello-for-business/images/whfb-intune-account-protection-enable.png new file mode 100644 index 0000000000..b5ff9bbb58 Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/whfb-intune-account-protection-enable.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/whfb-intune-disable.png b/windows/security/identity-protection/hello-for-business/images/whfb-intune-disable.png new file mode 100644 index 0000000000..97177965e3 Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/whfb-intune-disable.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/whfb-intune-reset-pin.jpg b/windows/security/identity-protection/hello-for-business/images/whfb-intune-reset-pin.jpg deleted file mode 100644 index 0eae3a4546..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/whfb-intune-reset-pin.jpg and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/includes/auth-certificate-template.md b/windows/security/identity-protection/hello-for-business/includes/auth-certificate-template.md new file mode 100644 index 0000000000..c3f30f246e --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/auth-certificate-template.md @@ -0,0 +1,83 @@ +--- +ms.date: 12/28/2022 +ms.topic: include +--- + +### Configure a Windows Hello for Business authentication certificate template + +During Windows Hello for Business provisioning, Windows clients request an authentication certificate from AD FS, which requests the authentication certificate on behalf of the user. This task configures the Windows Hello for Business authentication certificate template. + +Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials. + +1. Open the **Certification Authority** management console +1. Right-click **Certificate Templates** and select **Manage** +1. Right-click the **Smartcard Logon** template and choose **Duplicate Template** +1. On the **Compatibility** tab: + - Clear the **Show resulting changes** check box + - Select **Windows Server 2016** from the **Certification Authority** list + - Select **Windows 10 / Windows Server 2016** from the **Certificate Recipient** list +1. On the **General** tab: + - Type *WHFB Authentication* in **Template display name** + - Adjust the validity and renewal period to meet your enterprise's needs + > [!NOTE] + > If you use different template names, you'll need to remember and substitute these names in different portions of the deployment. +1. On the **Cryptography** tab + - Select **Key Storage Provider** from the **Provider Category** list + - Select **RSA** from the **Algorithm name** list + - Type *2048* in the **Minimum key size** text box + - Select **SHA256** from the **Request hash** list +1. On the **Extensions** tab, verify the **Application Policies** extension includes **Smart Card Logon** +1. On the **Issuance Requirements** tab, + - Select the **This number of authorized signatures** check box. Type *1* in the text box + - Select **Application policy** from the **Policy type required in signature** + - Select **Certificate Request Agent** from in the **Application policy** list + - Select the **Valid existing certificate** option +1. On the **Subject** tab, + - Select the **Build from this Active Directory information** button + - Select **Fully distinguished name** from the **Subject name format** list + - Select the **User Principal Name (UPN)** check box under **Include this information in alternative subject name** +1. On the **Request Handling** tab, select the **Renew with same key** check box +1. On the **Security** tab, select **Add**. Target an Active Directory security group that contains the users that you want to enroll in Windows Hello for Business. For example, if you have a group called *Window Hello for Business Users*, type it in the **Enter the object names to select** text box and select **OK** +1. Select the **Windows Hello for Business Users** from the **Group or users names** list. In the **Permissions for Windows Hello for Business Users** section: + - Select the **Allow** check box for the **Enroll** permission + - Excluding the group above (for example, *Window Hello for Business Users*), clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other entries in the **Group or users names** section if the check boxes aren't already cleared + - Select **OK** +1. If you previously issued Windows Hello for Business sign-in certificates using Configuration Manger and are switching to an AD FS registration authority, then on the **Superseded Templates** tab, add the previously used **Windows Hello for Business Authentication** template(s), so they'll be superseded by this template for the users that have Enroll permission for this template +1. Select on the **Apply** to save changes and close the console + +#### Mark the template as the Windows Hello Sign-in template + +Sign in to a CA or management workstations with *Enterprise Administrator* equivalent credentials + +Open an elevated command prompt end execute the following command + +```cmd +certutil.exe -dsTemplate WHFBAuthentication msPKI-Private-Key-Flag +CTPRIVATEKEY_FLAG_HELLO_LOGON_KEY +``` + +If the template was changed successfully, the output of the command will contain old and new values of the template parameters. The new value must contain the `CTPRIVATEKEY_FLAG_HELLO_LOGON_KEY` parameter. Example: + +```cmd +CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=[yourdomain]:WHFBAuthentication + +Old Value: +msPKI-Private-Key-Flag REG_DWORD = 5050080 (84213888) +CTPRIVATEKEY_FLAG_REQUIRE_SAME_KEY_RENEWAL -- 80 (128) +CTPRIVATEKEY_FLAG_ATTEST_NONE -- 0 +TEMPLATE_SERVER_VER_WINBLUE<[!NOTE] +>If you gave your Windows Hello for Business Authentication certificate template a different name, then replace `WHFBAuthentication` in the above command with the name of your certificate template. It's important that you use the template name rather than the template display name. You can view the template name on the **General** tab of the certificate template using the Certificate Template management console (certtmpl.msc). Or, you can view the template name using the `Get-CATemplate` ADCS Administration Windows PowerShell cmdlet on your certification authority. + + \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/includes/dc-certificate-deployment.md b/windows/security/identity-protection/hello-for-business/includes/dc-certificate-deployment.md new file mode 100644 index 0000000000..6059c8bb03 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/dc-certificate-deployment.md @@ -0,0 +1,32 @@ +--- +ms.date: 12/28/2022 +ms.topic: include +--- + +### Configure automatic certificate enrollment for the domain controllers + +Domain controllers automatically request a certificate from the *Domain controller certificate* template. However, domain controllers are unaware of newer certificate templates or superseded configurations on certificate templates. For domain controllers to automatically enroll and renew of certificates, configure a GPO for automatic certificate enrollment, and link it to the *Domain Controllers* OU. + +1. Open the **Group Policy Management Console** (gpmc.msc) +1. Expand the domain and select the **Group Policy Object** node in the navigation pane +1. Right-click **Group Policy object** and select **New** +1. Type *Domain Controller Auto Certificate Enrollment* in the name box and select **OK** +1. Right-click the **Domain Controller Auto Certificate Enrollment** Group Policy object and select **Edit** +1. In the navigation pane, expand **Policies** under **Computer Configuration** +1. Expand **Windows Settings > Security Settings > Public Key Policies** +1. In the details pane, right-click **Certificate Services Client - Auto-Enrollment** and select **Properties** +1. Select **Enabled** from the **Configuration Model** list +1. Select the **Renew expired certificates, update pending certificates, and remove revoked certificates** check box +1. Select the **Update certificates that use certificate templates** check box +1. Select **OK** +1. Close the **Group Policy Management Editor** + +### Deploy the domain controller auto certificate enrollment GPO + +Sign in to domain controller or management workstations with *Domain Administrator* equivalent credentials. + +1. Start the **Group Policy Management Console** (gpmc.msc) +1. In the navigation pane, expand the domain and expand the node with the Active Directory domain name. Right-click the **Domain Controllers** organizational unit and select **Link an existing GPO…** +1. In the **Select GPO** dialog box, select *Domain Controller Auto Certificate Enrollment* or the name of the domain controller certificate enrollment Group Policy object you previously created +1. Select **OK** + diff --git a/windows/security/identity-protection/hello-for-business/includes/dc-certificate-supersede.md b/windows/security/identity-protection/hello-for-business/includes/dc-certificate-supersede.md new file mode 100644 index 0000000000..20f8012d88 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/dc-certificate-supersede.md @@ -0,0 +1,33 @@ +--- +ms.date: 12/28/2022 +ms.topic: include +--- + +### Supersede existing domain controller certificates + +The domain controllers may have an existing domain controller certificate. The Active Directory Certificate Services provides a default certificate template for domain controllers called *domain controller certificate*. Later releases of Windows Server provided a new certificate template called *domain controller authentication certificate*. These certificate templates were provided prior to the update of the Kerberos specification that stated Key Distribution Centers (KDCs) performing certificate authentication needed to include the *KDC Authentication* extension. + +The *Kerberos Authentication* certificate template is the most current certificate template designated for domain controllers, and should be the one you deploy to all your domain controllers.\ +The *autoenrollment* feature allows you to replace the domain controller certificates. Use the following configuration to replace older domain controller certificates with new ones, using the *Kerberos Authentication* certificate template. + +Sign in to a CA or management workstations with *Enterprise Administrator* equivalent credentials. + +1. Open the **Certification Authority** management console +1. Right-click **Certificate Templates > Manage** +1. In the **Certificate Template Console**, right-click the *Domain Controller Authentication (Kerberos)* (or the name of the certificate template you created in the previous section) template in the details pane and select **Properties** +1. Select the **Superseded Templates** tab. Select **Add** +1. From the **Add Superseded Template** dialog, select the *Domain Controller* certificate template and select **OK > Add** +1. From the **Add Superseded Template** dialog, select the *Domain Controller Authentication* certificate template and select **OK** +1. From the **Add Superseded Template** dialog, select the *Kerberos Authentication* certificate template and select **OK** +1. Add any other enterprise certificate templates that were previously configured for domain controllers to the **Superseded Templates** tab +1. Select **OK** and close the **Certificate Templates** console + +The certificate template is configured to supersede all the certificate templates provided in the *superseded templates* list.\ +However, the certificate template and the superseding of certificate templates isn't active until the template is published to one or more certificate authorities. + +> [!NOTE] +> The domain controller's certificate must chain to a root in the NTAuth store. By default, the Active Directory Certificate Authority's root certificate is added to the NTAuth store. If you are using a third-party CA, this may not be done by default. If the domain controller certificate does not chain to a root in the NTAuth store, user authentication will fail. +>To see all certificates in the NTAuth store, use the following command: +> +> `Certutil -viewstore -enterprise NTAuth` + diff --git a/windows/security/identity-protection/hello-for-business/includes/dc-certificate-template.md b/windows/security/identity-protection/hello-for-business/includes/dc-certificate-template.md new file mode 100644 index 0000000000..1fff52b89c --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/dc-certificate-template.md @@ -0,0 +1,51 @@ +--- +ms.date: 12/28/2022 +ms.topic: include +--- + +### Configure domain controller certificates + +Clients must trust the domain controllers, and the best way to enable the trust is to ensure that each domain controller has a *Kerberos Authentication* certificate. Installing a certificate on the domain controllers enables the Key Distribution Center (KDC) to prove its identity to other members of the domain. The certificates provide clients a root of trust external to the domain, namely the *enterprise certification authority*. + +Domain controllers automatically request a *domain controller certificate* (if published) when they discover an enterprise CA is added to Active Directory. The certificates based on the *Domain Controller* and *Domain Controller Authentication* certificate templates don't include the *KDC Authentication* object identifier (OID), which was later added to the Kerberos RFC. Therefore, domain controllers need to request a certificate based on the *Kerberos Authentication* certificate template. + +By default, the Active Directory CA provides and publishes the *Kerberos Authentication* certificate template. The cryptography configuration included in the template is based on older and less performant cryptography APIs. To ensure domain controllers request the proper certificate with the best available cryptography, use the *Kerberos Authentication* certificate template as a *baseline* to create an updated domain controller certificate template. + +> [!IMPORTANT] +> The certificates issued to the domain controllers must meet the following requirements: +> - The *Certificate Revocation List (CRL) distribution point* extension must point to a valid CRL, or an *Authority Information Access (AIA)* extension that points to an Online Certificate Status Protocol (OCSP) responder +> - Optionally, the certificate *Subject* section could contain the directory path of the server object (the distinguished name) +> - The certificate *Key Usage* section must contain *Digital Signature* and *Key Encipherment* +> - Optionally, the certificate *Basic Constraints* section should contain: `[Subject Type=End Entity, Path Length Constraint=None]` +> - The certificate *extended key usage* section must contain Client Authentication (`1.3.6.1.5.5.7.3.2`), Server Authentication (`1.3.6.1.5.5.7.3.1`), and KDC Authentication (`1.3.6.1.5.2.3.5`) +> - The certificate *Subject Alternative Name* section must contain the Domain Name System (DNS) name +> - The certificate template must have an extension that has the value `DomainController`, encoded as a [BMPstring](/windows/win32/seccertenroll/about-bmpstring). If you are using Windows Server Enterprise Certificate Authority, this extension is already included in the domain controller certificate template +> - The domain controller certificate must be installed in the local computer's certificate store + +Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials. + +1. Open the **Certification Authority** management console +1. Right-click **Certificate Templates > Manage** +1. In the **Certificate Template Console**, right-click the **Kerberos Authentication** template in the details pane and select **Duplicate Template** +1. On the **Compatibility** tab: + - Clear the **Show resulting changes** check box + - Select **Windows Server 2016** from the **Certification Authority** list + - Select **Windows 10 / Windows Server 2016** from the **Certificate Recipient** list +1. On the **General** tab + - Type *Domain Controller Authentication (Kerberos)* in Template display name + - Adjust the validity and renewal period to meet your enterprise's needs + > [!NOTE] + > If you use different template names, you'll need to remember and substitute these names in different portions of the lab. +1. On the **Subject Name** tab: + - Select the **Build from this Active Directory information** button if it isn't already selected + - Select **None** from the **Subject name format** list + - Select **DNS name** from the **Include this information in alternate subject** list + - Clear all other items +1. On the **Cryptography** tab: + - Select **Key Storage Provider** from the **Provider Category** list + - Select **RSA** from the **Algorithm name** list + - Type *2048* in the **Minimum key size** text box + - Select **SHA256** from the **Request hash** list +1. Select **OK** +1. Close the console + diff --git a/windows/security/identity-protection/hello-for-business/includes/dc-certificate-validate.md b/windows/security/identity-protection/hello-for-business/includes/dc-certificate-validate.md new file mode 100644 index 0000000000..5f8e4a5a88 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/dc-certificate-validate.md @@ -0,0 +1,39 @@ +--- +ms.date: 12/28/2022 +ms.topic: include +--- + +Windows Hello for Business is a distributed system, which on the surface appears complex and difficult. The key to a successful deployment is to validate phases of work prior to moving to the next phase. + +Confirm your domain controllers enroll the correct certificates and not any superseded certificate templates. Check that each domain controller completed the certificate autoenrollment. + +### Use the event logs + +Sign in to domain controller or management workstations with *Domain Administrator* equivalent credentials. + +1. Using the Event Viewer, navigate to the **Application and Services > Microsoft > Windows > CertificateServices-Lifecycles-System** event log +1. Look for an event indicating a new certificate enrollment (autoenrollment): + - The details of the event include the certificate template on which the certificate was issued + - The name of the certificate template used to issue the certificate should match the certificate template name included in the event + - The certificate thumbprint and EKUs for the certificate are also included in the event + - The EKU needed for proper Windows Hello for Business authentication is Kerberos Authentication, in addition to other EKUs provide by the certificate template + +Certificates superseded by your new domain controller certificate generate an archive event in the event log. The archive event contains the certificate template name and thumbprint of the certificate that was superseded by the new certificate. + +### Certificate Manager + +You can use the Certificate Manager console to validate the domain controller has the properly enrolled certificate based on the correct certificate template with the proper EKUs. Use **certlm.msc** to view certificate in the local computers certificate stores. Expand the **Personal** store and view the certificates enrolled for the computer. Archived certificates don't appear in Certificate Manager. + +### Certutil.exe + +You can use `certutil.exe` command to view enrolled certificates in the local computer. Certutil shows enrolled and archived certificates for the local computer. From an elevated command prompt, run `certutil.exe -q -store my` to view locally enrolled certificates. + +To view detailed information about each certificate in the store, use `certutil.exe -q -v -store my` to validate automatic certificate enrollment enrolled the proper certificates. + +### Troubleshooting + +Windows triggers automatic certificate enrollment for the computer during boot, and when Group Policy updates. You can refresh Group Policy from an elevated command prompt using `gpupdate.exe /force`. + +Alternatively, you can forcefully trigger automatic certificate enrollment using `certreq.exe -autoenroll -q` from an elevated command prompt. + +Use the event logs to monitor certificate enrollment and archive. Review the configuration, such as publishing certificate templates to issuing certification authority and the allow auto enrollment permissions. \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/includes/enrollment-agent-certificate-template.md b/windows/security/identity-protection/hello-for-business/includes/enrollment-agent-certificate-template.md new file mode 100644 index 0000000000..0304c108d2 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/enrollment-agent-certificate-template.md @@ -0,0 +1,79 @@ +--- +ms.date: 01/03/2022 +ms.topic: include +--- + +### Configure an enrollment agent certificate template + +A certificate registration authority (CRA) is a trusted authority that validates certificate request. Once it validates the request, it presents the request to the certification authority (CA) for issuance. The CA issues the certificate, returns it to the CRA, which returns the certificate to the requesting user. Windows Hello for Business certificate trust deployments use AD FS as the CRA. + +The CRA enrolls for an *enrollment agent certificate*. Once the CRA verifies the certificate request, it signs the certificate request using its enrollment agent certificate and sends it to the CA. The Windows Hello for Business Authentication certificate template is configured to only issue certificates to certificate requests that have been signed with an enrollment agent certificate. The CA only issues a certificate for that template if the registration authority signs the certificate request. + +> [!IMPORTANT] +> Follow the procedures below based on the AD FS service account used in your environment. + +#### Create an enrollment agent certificate for Group Managed Service Accounts (GMSA) + +Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials. + +1. Open the **Certification Authority** management console +1. Right-click **Certificate Templates** and select **Manage** +1. In the **Certificate Template Console**, right-click on the **Exchange Enrollment Agent (Offline request)** template details pane and select **Duplicate Template** +1. On the **Compatibility** tab: + - Clear the **Show resulting changes** check box + - Select **Windows Server 2016** from the **Certification Authority** list. + - Select **Windows 10 / Windows Server 2016** from the **Certificate Recipient** list +1. On the **General** tab: + - Type *WHFB Enrollment Agent* in **Template display name** + - Adjust the validity and renewal period to meet your enterprise's needs +1. On the **Subject** tab, select the **Supply in the request** button if it isn't already selected + + > [!NOTE] + > Group Managed Service Accounts (GMSA) do not support the *Build from this Active Directory information* option and will result in the AD FS server failing to enroll the enrollment agent certificate. You must configure the certificate template with *Supply in the request* to ensure that AD FS servers can perform the automatic enrollment and renewal of the enrollment agent certificate. + +1. On the **Cryptography** tab: + - Select **Key Storage Provider** from the **Provider Category** list + - Select **RSA** from the **Algorithm name** list + - Type *2048* in the **Minimum key size** text box + - Select **SHA256** from the **Request hash** list +1. On the **Security** tab, select **Add** +1. Select **Object Types** and select the **Service Accounts** check box. Select **OK** +1. Type *adfssvc* in the **Enter the object names to select** text box and select **OK** +1. Select the **adfssvc** from the **Group or users names** list. In the **Permissions for adfssvc** section: + - In the **Permissions for adfssvc** section, select the **Allow** check box for the **Enroll** permission + - Excluding the **adfssvc** user, clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other items in the **Group or users names** list + - Select **OK** +1. Close the console + +#### Create an enrollment agent certificate for a standard service account + +Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials. + +1. Open the **Certification Authority** management console +1. Right-click **Certificate Templates** and select **Manage** +1. In the **Certificate Template Console**, right-click on the **Exchange Enrollment Agent (Offline request)** template details pane and select **Duplicate Template** +1. On the **Compatibility** tab: + - Clear the **Show resulting changes** check box + - Select **Windows Server 2016** from the **Certification Authority** list. + - Select **Windows 10 / Windows Server 2016** from the **Certificate Recipient** list +1. On the **General** tab: + - Type *WHFB Enrollment Agent* in **Template display name** + - Adjust the validity and renewal period to meet your enterprise's needs +1. On the **Subject** tab: + - Select the **Build from this Active Directory information** button + - Select **Fully distinguished name** from the **Subject name format** + - Select the **User Principal Name (UPN)** check box under **Include this information in alternative subject name** +1. On the **Cryptography** tab: + - Select **Key Storage Provider** from the **Provider Category** list + - Select **RSA** from the **Algorithm name** list + - Type *2048* in the **Minimum key size** text box + - Select **SHA256** from the **Request hash** list +1. On the **Security** tab, select **Add** +1. Select **Object Types** and select the **Service Accounts** check box. Select **OK** +1. Type *adfssvc* in the **Enter the object names to select** text box and select **OK** +1. Select the **adfssvc** from the **Group or users names** list. In the **Permissions for adfssvc** section: + - In the **Permissions for adfssvc** section, select the **Allow** check box for the **Enroll** permission + - Excluding the **adfssvc** user, clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other items in the **Group or users names** list + - Select **OK** +1. Close the console + diff --git a/windows/security/includes/hello-cloud.md b/windows/security/identity-protection/hello-for-business/includes/hello-cloud.md similarity index 84% rename from windows/security/includes/hello-cloud.md rename to windows/security/identity-protection/hello-for-business/includes/hello-cloud.md index 1c41485f11..4724b9d6da 100644 --- a/windows/security/includes/hello-cloud.md +++ b/windows/security/identity-protection/hello-for-business/includes/hello-cloud.md @@ -1,6 +1,4 @@ --- -author: paolomatarazzo -ms.author: paoloma ms.date: 12/08/2022 ms.topic: include --- diff --git a/windows/security/identity-protection/hello-for-business/includes/hello-deployment-cloud.md b/windows/security/identity-protection/hello-for-business/includes/hello-deployment-cloud.md new file mode 100644 index 0000000000..a9b2685f07 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/hello-deployment-cloud.md @@ -0,0 +1,6 @@ +--- +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") \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/includes/hello-deployment-hybrid.md b/windows/security/identity-protection/hello-for-business/includes/hello-deployment-hybrid.md new file mode 100644 index 0000000000..b6ba025722 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/hello-deployment-hybrid.md @@ -0,0 +1,6 @@ +--- +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") \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/includes/hello-deployment-onpremises.md b/windows/security/identity-protection/hello-for-business/includes/hello-deployment-onpremises.md new file mode 100644 index 0000000000..5426da4561 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/hello-deployment-onpremises.md @@ -0,0 +1,6 @@ +--- +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") \ No newline at end of file diff --git a/windows/security/includes/hello-hybrid-cert-trust-aad.md b/windows/security/identity-protection/hello-for-business/includes/hello-hybrid-cert-trust-aad.md similarity index 87% rename from windows/security/includes/hello-hybrid-cert-trust-aad.md rename to windows/security/identity-protection/hello-for-business/includes/hello-hybrid-cert-trust-aad.md index 57c03e95a3..955f819fbf 100644 --- a/windows/security/includes/hello-hybrid-cert-trust-aad.md +++ b/windows/security/identity-protection/hello-for-business/includes/hello-hybrid-cert-trust-aad.md @@ -1,6 +1,4 @@ --- -author: paolomatarazzo -ms.author: paoloma ms.date: 12/08/2022 ms.topic: include --- diff --git a/windows/security/includes/hello-hybrid-cert-trust-ad.md b/windows/security/identity-protection/hello-for-business/includes/hello-hybrid-cert-trust-ad.md similarity index 88% rename from windows/security/includes/hello-hybrid-cert-trust-ad.md rename to windows/security/identity-protection/hello-for-business/includes/hello-hybrid-cert-trust-ad.md index 4691d86bc0..a5b340a3f8 100644 --- a/windows/security/includes/hello-hybrid-cert-trust-ad.md +++ b/windows/security/identity-protection/hello-for-business/includes/hello-hybrid-cert-trust-ad.md @@ -1,6 +1,4 @@ --- -author: paolomatarazzo -ms.author: paoloma ms.date: 12/08/2022 ms.topic: include --- diff --git a/windows/security/includes/hello-hybrid-cert-trust.md b/windows/security/identity-protection/hello-for-business/includes/hello-hybrid-cert-trust.md similarity index 89% rename from windows/security/includes/hello-hybrid-cert-trust.md rename to windows/security/identity-protection/hello-for-business/includes/hello-hybrid-cert-trust.md index d6ca6e8f5d..81e14489f5 100644 --- a/windows/security/includes/hello-hybrid-cert-trust.md +++ b/windows/security/identity-protection/hello-for-business/includes/hello-hybrid-cert-trust.md @@ -1,6 +1,4 @@ --- -author: paolomatarazzo -ms.author: paoloma ms.date: 12/08/2022 ms.topic: include --- diff --git a/windows/security/includes/hello-hybrid-cloudkerb-trust.md b/windows/security/identity-protection/hello-for-business/includes/hello-hybrid-cloudkerb-trust.md similarity index 89% rename from windows/security/includes/hello-hybrid-cloudkerb-trust.md rename to windows/security/identity-protection/hello-for-business/includes/hello-hybrid-cloudkerb-trust.md index 61346cd80e..302cbee601 100644 --- a/windows/security/includes/hello-hybrid-cloudkerb-trust.md +++ b/windows/security/identity-protection/hello-for-business/includes/hello-hybrid-cloudkerb-trust.md @@ -1,6 +1,4 @@ --- -author: paolomatarazzo -ms.author: paoloma ms.date: 12/08/2022 ms.topic: include --- diff --git a/windows/security/includes/hello-hybrid-key-trust-ad.md b/windows/security/identity-protection/hello-for-business/includes/hello-hybrid-key-trust-ad.md similarity index 87% rename from windows/security/includes/hello-hybrid-key-trust-ad.md rename to windows/security/identity-protection/hello-for-business/includes/hello-hybrid-key-trust-ad.md index a5074f5bd4..b637be9beb 100644 --- a/windows/security/includes/hello-hybrid-key-trust-ad.md +++ b/windows/security/identity-protection/hello-for-business/includes/hello-hybrid-key-trust-ad.md @@ -1,6 +1,4 @@ --- -author: paolomatarazzo -ms.author: paoloma ms.date: 12/08/2022 ms.topic: include --- diff --git a/windows/security/includes/hello-hybrid-key-trust.md b/windows/security/identity-protection/hello-for-business/includes/hello-hybrid-key-trust.md similarity index 88% rename from windows/security/includes/hello-hybrid-key-trust.md rename to windows/security/identity-protection/hello-for-business/includes/hello-hybrid-key-trust.md index d9feebc213..72a7d5634b 100644 --- a/windows/security/includes/hello-hybrid-key-trust.md +++ b/windows/security/identity-protection/hello-for-business/includes/hello-hybrid-key-trust.md @@ -1,6 +1,4 @@ --- -author: paolomatarazzo -ms.author: paoloma ms.date: 12/08/2022 ms.topic: include --- diff --git a/windows/security/includes/hello-hybrid-keycert-trust-aad.md b/windows/security/identity-protection/hello-for-business/includes/hello-hybrid-keycert-trust-aad.md similarity index 89% rename from windows/security/includes/hello-hybrid-keycert-trust-aad.md rename to windows/security/identity-protection/hello-for-business/includes/hello-hybrid-keycert-trust-aad.md index 4c073f0897..40496f1006 100644 --- a/windows/security/includes/hello-hybrid-keycert-trust-aad.md +++ b/windows/security/identity-protection/hello-for-business/includes/hello-hybrid-keycert-trust-aad.md @@ -1,6 +1,4 @@ --- -author: paolomatarazzo -ms.author: paoloma ms.date: 12/08/2022 ms.topic: include --- diff --git a/windows/security/includes/hello-intro.md b/windows/security/identity-protection/hello-for-business/includes/hello-intro.md similarity index 60% rename from windows/security/includes/hello-intro.md rename to windows/security/identity-protection/hello-for-business/includes/hello-intro.md index 46d97c93e6..b89d23afb8 100644 --- a/windows/security/includes/hello-intro.md +++ b/windows/security/identity-protection/hello-for-business/includes/hello-intro.md @@ -1,6 +1,4 @@ --- -author: paolomatarazzo -ms.author: paoloma ms.date: 12/08/2022 ms.topic: include --- diff --git a/windows/security/identity-protection/hello-for-business/includes/hello-join-aad.md b/windows/security/identity-protection/hello-for-business/includes/hello-join-aad.md new file mode 100644 index 0000000000..82f5f99a23 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/hello-join-aad.md @@ -0,0 +1,6 @@ +--- +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") \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/includes/hello-join-domain.md b/windows/security/identity-protection/hello-for-business/includes/hello-join-domain.md new file mode 100644 index 0000000000..d7cd002e30 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/hello-join-domain.md @@ -0,0 +1,6 @@ +--- +ms.date: 12/08/2022 +ms.topic: include +--- + +[domain join :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md "Devices that are domain joined do not have any dependencies on Azure AD. Only local users accounts and Active Directory users can sign in to these devices") \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/includes/hello-join-hybrid.md b/windows/security/identity-protection/hello-for-business/includes/hello-join-hybrid.md new file mode 100644 index 0000000000..ba8b5df65a --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/hello-join-hybrid.md @@ -0,0 +1,6 @@ +--- +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") \ No newline at end of file diff --git a/windows/security/includes/hello-on-premises-cert-trust.md b/windows/security/identity-protection/hello-for-business/includes/hello-on-premises-cert-trust.md similarity index 88% rename from windows/security/includes/hello-on-premises-cert-trust.md rename to windows/security/identity-protection/hello-for-business/includes/hello-on-premises-cert-trust.md index b106b5b8c8..06ab63397f 100644 --- a/windows/security/includes/hello-on-premises-cert-trust.md +++ b/windows/security/identity-protection/hello-for-business/includes/hello-on-premises-cert-trust.md @@ -1,6 +1,4 @@ --- -author: paolomatarazzo -ms.author: paoloma ms.date: 12/08/2022 ms.topic: include --- diff --git a/windows/security/includes/hello-on-premises-key-trust.md b/windows/security/identity-protection/hello-for-business/includes/hello-on-premises-key-trust.md similarity index 87% rename from windows/security/includes/hello-on-premises-key-trust.md rename to windows/security/identity-protection/hello-for-business/includes/hello-on-premises-key-trust.md index f290b0d975..ef66939cb2 100644 --- a/windows/security/includes/hello-on-premises-key-trust.md +++ b/windows/security/identity-protection/hello-for-business/includes/hello-on-premises-key-trust.md @@ -1,6 +1,4 @@ --- -author: paolomatarazzo -ms.author: paoloma ms.date: 12/08/2022 ms.topic: include --- diff --git a/windows/security/identity-protection/hello-for-business/includes/hello-trust-certificate.md b/windows/security/identity-protection/hello-for-business/includes/hello-trust-certificate.md new file mode 100644 index 0000000000..3b89d756cf --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/hello-trust-certificate.md @@ -0,0 +1,6 @@ +--- +ms.date: 12/08/2022 +ms.topic: include +--- + +[certificate trust :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#certificate-trust "This trust type uses a certificate to authenticate the users to Active Directory. It's required to issue certificates to the users and to the domain controllers") \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/includes/hello-trust-cloud-kerberos.md b/windows/security/identity-protection/hello-for-business/includes/hello-trust-cloud-kerberos.md new file mode 100644 index 0000000000..fa465e241c --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/hello-trust-cloud-kerberos.md @@ -0,0 +1,6 @@ +--- +ms.date: 12/08/2022 +ms.topic: include +--- + +[cloud Kerberos trust :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#cloud-kerberos-trust "This trust type uses security keys to authenticate the users to Active Directory. It's not required to issue any certificates, making it the recommended choice for environments that do not need certificate authentication") \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/includes/hello-trust-key.md b/windows/security/identity-protection/hello-for-business/includes/hello-trust-key.md new file mode 100644 index 0000000000..3e4bdecccc --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/hello-trust-key.md @@ -0,0 +1,6 @@ +--- +ms.date: 12/08/2022 +ms.topic: include +--- + +[key trust :::image type="icon" source="../../../images/icons/information.svg" border="false":::](../hello-how-it-works-technology.md#key-trust "This trust type uses a raw key to authenticate the users to Active Directory. It's not required to issue certificates to users, but it's required to deploy certificates to domain controllers") \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/includes/lab-based-pki-deploy.md b/windows/security/identity-protection/hello-for-business/includes/lab-based-pki-deploy.md new file mode 100644 index 0000000000..5cc0341b05 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/lab-based-pki-deploy.md @@ -0,0 +1,32 @@ +--- +ms.date: 01/03/2023 +ms.topic: include +--- + +## Deploy an enterprise certification authority + +This guide assumes most enterprises have an existing public key infrastructure. Windows Hello for Business depends on an enterprise PKI running the Windows Server *Active Directory Certificate Services* role.\ +If you don't have an existing PKI, review [Certification Authority Guidance][PREV-1] to properly design your infrastructure. Then, consult the [Test Lab Guide: Deploying an AD CS Two-Tier PKI Hierarchy][PREV-2] for instructions on how to configure your PKI using the information from your design session. + +### Lab-based PKI + +The following instructions may be used to deploy simple public key infrastructure that is suitable **for a lab environment**. + +Sign in using *Enterprise Administrator* equivalent credentials on a Windows Server where you want the certification authority (CA) installed. + +>[!NOTE] +>Never install a certification authority on a domain controller in a production environment. + +1. Open an elevated Windows PowerShell prompt +1. Use the following command to install the Active Directory Certificate Services role. + ```PowerShell + Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools + ``` +3. Use the following command to configure the CA using a basic certification authority configuration + ```PowerShell + Install-AdcsCertificationAuthority + ``` + + +[PREV-1]: /previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831574(v=ws.11) +[PREV-2]: /previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831348(v=ws.11) \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/includes/unpublish-superseded-templates.md b/windows/security/identity-protection/hello-for-business/includes/unpublish-superseded-templates.md new file mode 100644 index 0000000000..5d8b4c3d0a --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/unpublish-superseded-templates.md @@ -0,0 +1,18 @@ +--- +ms.date: 12/28/2022 +ms.topic: include +--- + +### Unpublish Superseded Certificate Templates + +The certification authority only issues certificates based on published certificate templates. For security, it's a good practice to unpublish certificate templates that the CA isn't configured to issue, including the pre-published templates from the role installation and any superseded templates. + +The newly created *domain controller authentication* certificate template supersedes previous domain controller certificate templates. Therefore, you need to unpublish these certificate templates from all issuing certificate authorities. + +Sign in to the CA or management workstation with *Enterprise Administrator* equivalent credentials. + +1. Open the **Certification Authority** management console +1. Expand the parent node from the navigation pane > **Certificate Templates** +1. Right-click the *Domain Controller* certificate template and select **Delete**. Select **Yes** on the **Disable certificate templates** window +1. Repeat step 3 for the *Domain Controller Authentication* and *Kerberos Authentication* certificate templates + diff --git a/windows/security/identity-protection/hello-for-business/includes/web-server-certificate-template.md b/windows/security/identity-protection/hello-for-business/includes/web-server-certificate-template.md new file mode 100644 index 0000000000..601e29153a --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/web-server-certificate-template.md @@ -0,0 +1,38 @@ +--- +ms.date: 01/23/2023 +ms.topic: include +--- + +### Configure an internal web server certificate template + +Windows clients communicate with AD FS via HTTPS. To meet this need, a *server authentication* certificate must be issued to all the nodes in the AD FS farm. On-premises deployments can use a *server authentication* certificate issued by the enterprise PKI. A *server authentication* certificate template must be configured, so the AD FS nodes can request a certificate. + +Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials. + +1. Open the **Certification Authority** management console +1. Right-click **Certificate Templates** and select **Manage** +1. In the **Certificate Template Console**, right-click the **Web Server** template in the details pane and select **Duplicate Template** +1. On the **Compatibility** tab: + - Clear the **Show resulting changes** check box + - Select **Windows Server 2016** from the **Certification Authority** list + - Select **Windows 10 / Windows Server 2016** from the **Certificate Recipient** list +1. On the **General** tab: + - Type *Internal Web Server* in **Template display name** + - Adjust the validity and renewal period to meet your enterprise's needs + > [!NOTE] + > If you use different template names, you'll need to remember and substitute these names in different portions of the lab. +1. On the **Request Handling** tab, select **Allow private key to be exported** +1. On the **Subject** tab, select the **Supply in the request** button if it isn't already selected +1. On the **Security** tab: + - Select **Add** + - Type **Domain Computers** in the **Enter the object names to select** box + - Select **OK** + - Select the **Allow** check box next to the **Enroll** permission +1. On the **Cryptography** tab: + - Select **Key Storage Provider** from the **Provider Category** list + - Select **RSA** from the **Algorithm name** list + - Type *2048* in the **Minimum key size** text box + - Select **SHA256** from the **Request hash** list + - Select **OK** +1. Close the console + diff --git a/windows/security/identity-protection/hello-for-business/toc.yml b/windows/security/identity-protection/hello-for-business/toc.yml index fb4c92826f..cb88c5d036 100644 --- a/windows/security/identity-protection/hello-for-business/toc.yml +++ b/windows/security/identity-protection/hello-for-business/toc.yml @@ -31,66 +31,26 @@ items: - name: Overview href: hello-hybrid-key-trust.md - - name: Prerequisites - href: hello-hybrid-key-trust-prereqs.md - - name: New installation baseline - href: hello-hybrid-key-new-install.md - - name: Configure directory synchronization - href: hello-hybrid-key-trust-dirsync.md - - name: Configure Azure AD device registration - href: hello-hybrid-key-trust-devreg.md - - name: Configure Windows Hello for Business settings - items: - - name: Overview - href: hello-hybrid-key-whfb-settings.md - - name: Configure Active Directory - href: hello-hybrid-key-whfb-settings-ad.md - - name: Configure Azure AD Connect Sync - href: hello-hybrid-key-whfb-settings-dir-sync.md - - name: Configure PKI - href: hello-hybrid-key-whfb-settings-pki.md - - name: Configure Group Policy settings - href: hello-hybrid-key-whfb-settings-policy.md - - name: Sign-in and provision Windows Hello for Business - href: hello-hybrid-key-whfb-provision.md - - name: On-premises SSO for Azure AD joined devices + - name: Configure and validate the PKI + href: hello-hybrid-key-trust-validate-pki.md + - name: Configure and provision Windows Hello for Business + href: hello-hybrid-key-trust-provision.md + - name: Configure SSO for Azure AD joined devices href: hello-hybrid-aadj-sso.md - - name: Configure Azure AD joined devices for on-premises SSO - href: hello-hybrid-aadj-sso-base.md - name: Certificate trust deployment items: - name: Overview href: hello-hybrid-cert-trust.md - - name: Prerequisites - href: hello-hybrid-cert-trust-prereqs.md - - name: New installation baseline - href: hello-hybrid-cert-new-install.md - - name: Configure Azure AD device registration - href: hello-hybrid-cert-trust-devreg.md - - name: Configure Windows Hello for Business settings - items: - - name: Overview - href: hello-hybrid-cert-whfb-settings.md - - name: Configure Active Directory - href: hello-hybrid-cert-whfb-settings-ad.md - - name: Configure Azure AD Connect Sync - href: hello-hybrid-cert-whfb-settings-dir-sync.md - - name: Configure PKI - href: hello-hybrid-cert-whfb-settings-pki.md - - name: Configure AD FS - href: hello-hybrid-cert-whfb-settings-adfs.md - - name: Configure Group Policy settings - href: hello-hybrid-cert-whfb-settings-policy.md - - name: Sign-in and provision Windows Hello for Business + - name: Configure and validate the PKI + href: hello-hybrid-cert-trust-validate-pki.md + - name: Configure AD FS + href: hello-hybrid-cert-whfb-settings-adfs.md + - name: Configure and provision Windows Hello for Business href: hello-hybrid-cert-whfb-provision.md - - name: On-premises SSO for Azure AD joined devices + - name: Configure SSO for Azure AD joined devices href: hello-hybrid-aadj-sso.md - - name: Configure Azure AD joined devices for on-premises SSO - href: hello-hybrid-aadj-sso-base.md - - name: Using certificates for on-premises SSO + - name: Deploy certificates to Azure AD joined devices href: hello-hybrid-aadj-sso-cert.md - - name: Planning for Domain Controller load - href: hello-adequate-domain-controllers.md - name: On-premises deployments items: - name: Key trust deployment @@ -99,7 +59,7 @@ href: hello-deployment-key-trust.md - name: Validate Active Directory prerequisites href: hello-key-trust-validate-ad-prereq.md - - name: Configure and validate Public Key Infrastructure (PKI) + - name: Configure and validate the PKI href: hello-key-trust-validate-pki.md - name: Prepare and deploy Active Directory Federation Services (AD FS) href: hello-key-trust-adfs.md @@ -121,8 +81,8 @@ href: hello-cert-trust-validate-deploy-mfa.md - name: Configure Windows Hello for Business policy settings href: hello-cert-trust-policy-settings.md - - name: Planning for Domain Controller load - href: hello-adequate-domain-controllers.md + - name: Planning for Domain Controller load + href: hello-adequate-domain-controllers.md - name: Deploy certificates for remote desktop (RDP) sign-in href: hello-deployment-rdp-certs.md - name: How-to Guides diff --git a/windows/security/identity-protection/smart-cards/smart-card-certificate-requirements-and-enumeration.md b/windows/security/identity-protection/smart-cards/smart-card-certificate-requirements-and-enumeration.md index dfcc5f5c94..4d2926242d 100644 --- a/windows/security/identity-protection/smart-cards/smart-card-certificate-requirements-and-enumeration.md +++ b/windows/security/identity-protection/smart-cards/smart-card-certificate-requirements-and-enumeration.md @@ -66,7 +66,7 @@ When a smart card is inserted, the following steps are performed. Although versions of Windows earlier than Windows Vista include support for smart cards, the types of certificates that smart cards can contain are limited. The limitations are: -- Each certificate must have a user principal name (UPN) and the smart card sign-in object identifier (also known as OID) in the enhanced key usage (EKU) attribute field. There is a Group Policy setting, Allow ECC certificates to be used for logon and authentication, to make the EKU optional. +- Each certificate must have a user principal name (UPN) and the smart card sign-in object identifier (also known as OID) in the extended key usage (EKU) attribute field. There is a Group Policy setting, Allow ECC certificates to be used for logon and authentication, to make the EKU optional. - Each certificate must be stored in the AT\_KEYEXCHANGE portion of the default CryptoAPI container, and non-default CryptoAPI containers are not supported. @@ -190,7 +190,7 @@ The smart card certificate has specific format requirements when it is used with | CRL distribution point location | Not required | The location must be specified, online, and available, for example:
\[1\]CRL Distribution Point
Distribution Point Name:
Full Name:
URL=`` | | Key usage | Digital signature | Digital signature | | Basic constraints | Not required | \[Subject Type=End Entity, Path Length Constraint=None\] (Optional) | -| Enhanced key usage (EKU) | The smart card sign-in object identifier is not required.

**Note**  If an EKU is present, it must contain the smart card sign-in EKU. Certificates with no EKU can be used for sign-in. | - Client Authentication (1.3.6.1.5.5.7.3.2)
The client authentication object identifier is required only if a certificate is used for SSL authentication.

- Smart Card Sign-in (1.3.6.1.4.1.311.20.2.2) | +| extended key usage (EKU) | The smart card sign-in object identifier is not required.

**Note**  If an EKU is present, it must contain the smart card sign-in EKU. Certificates with no EKU can be used for sign-in. | - Client Authentication (1.3.6.1.5.5.7.3.2)
The client authentication object identifier is required only if a certificate is used for SSL authentication.

- Smart Card Sign-in (1.3.6.1.4.1.311.20.2.2) | | Subject alternative name | E-mail ID is not required for smart card sign-in. | Other Name: Principal Name=(UPN), for example:
UPN=user1@contoso.com
The UPN OtherName object identifier is 1.3.6.1.4.1.311.20.2.3.
The UPN OtherName value must be an ASN1-encoded UTF8 string. | | Subject | Not required | Distinguished name of user. This field is a mandatory extension, but the population of this field is optional. | | Key exchange (AT\_KEYEXCHANGE field) | Not required for smart card sign-in certificates if a Group Policy setting is enabled. (By default, Group Policy settings are not enabled.) | Not required | diff --git a/windows/security/identity-protection/smart-cards/smart-card-group-policy-and-registry-settings.md b/windows/security/identity-protection/smart-cards/smart-card-group-policy-and-registry-settings.md index a14fa3345b..26f06f48c2 100644 --- a/windows/security/identity-protection/smart-cards/smart-card-group-policy-and-registry-settings.md +++ b/windows/security/identity-protection/smart-cards/smart-card-group-policy-and-registry-settings.md @@ -93,10 +93,10 @@ The following table lists the default values for these GPO settings. Variations ### Allow certificates with no extended key usage certificate attribute -You can use this policy setting to allow certificates without an enhanced key usage (EKU) set to be used for sign-in. +You can use this policy setting to allow certificates without an extended key usage (EKU) set to be used for sign-in. > [!NOTE] -> Enhanced key usage certificate attribute is also known as extended key usage. +> extended key usage certificate attribute is also known as extended key usage. > > In versions of Windows before Windows Vista, smart card certificates that are used to sign in require an EKU extension with a smart card logon object identifier. This policy setting can be used to modify that restriction. diff --git a/windows/security/identity-protection/vpn/vpn-authentication.md b/windows/security/identity-protection/vpn/vpn-authentication.md index a44aa1b079..f14e959f6b 100644 --- a/windows/security/identity-protection/vpn/vpn-authentication.md +++ b/windows/security/identity-protection/vpn/vpn-authentication.md @@ -34,7 +34,7 @@ Windows supports a number of EAP authentication methods. - Certificate filtering: - Certificate filtering can be enabled to search for a particular certificate to use to authenticate with - - Filtering can be Issuer-based or Enhanced Key Usage (EKU)-based + - Filtering can be Issuer-based or extended key usage (EKU)-based - Server validation - with TLS, server validation can be toggled on or off: - Server name - specify the server to validate @@ -88,7 +88,7 @@ See [EAP configuration](/windows/client-management/mdm/eap-configuration) for EA The following image shows the field for EAP XML in a Microsoft Intune VPN profile. The EAP XML field only appears when you select a built-in connection type (automatic, IKEv2, L2TP, PPTP). -![EAP XML configuration in Intune profile.](images/vpn-eap-xml.png) +:::image type="content" source="images/vpn-eap-xml.png" alt-text="EAP XML configuration in Intune profile."::: ## Related topics diff --git a/windows/security/identity-protection/vpn/vpn-conditional-access.md b/windows/security/identity-protection/vpn/vpn-conditional-access.md index 5da2a635a4..e9af1d83a5 100644 --- a/windows/security/identity-protection/vpn/vpn-conditional-access.md +++ b/windows/security/identity-protection/vpn/vpn-conditional-access.md @@ -68,7 +68,7 @@ Two client-side configuration service providers are leveraged for VPN device com - **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. - - **Sso/Eku**: comma-separated list of Enhanced Key Usage (EKU) extensions for the VPN client to look for the correct certificate for Kerberos authentication. + - **Sso/Eku**: comma-separated list of extended key usage (EKU) extensions for the VPN client to look for the correct certificate for Kerberos authentication. - HealthAttestation CSP (not a requirement) - functions performed by the HealthAttestation CSP include: diff --git a/windows/security/includes/hello-deployment-cloud.md b/windows/security/includes/hello-deployment-cloud.md deleted file mode 100644 index 8152da9722..0000000000 --- a/windows/security/includes/hello-deployment-cloud.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -author: paolomatarazzo -ms.author: paoloma -ms.date: 12/08/2022 -ms.topic: include ---- - -[cloud :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#cloud-deployment "For organizations using Azure AD-only identities. Device management is usually done via Intune/MDM") \ No newline at end of file diff --git a/windows/security/includes/hello-deployment-hybrid.md b/windows/security/includes/hello-deployment-hybrid.md deleted file mode 100644 index b35d4b548e..0000000000 --- a/windows/security/includes/hello-deployment-hybrid.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -author: paolomatarazzo -ms.author: paoloma -ms.date: 12/08/2022 -ms.topic: include ---- - -[hybrid :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/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") \ No newline at end of file diff --git a/windows/security/includes/hello-deployment-onpremises.md b/windows/security/includes/hello-deployment-onpremises.md deleted file mode 100644 index 8746a5e9c7..0000000000 --- a/windows/security/includes/hello-deployment-onpremises.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -author: paolomatarazzo -ms.author: paoloma -ms.date: 12/08/2022 -ms.topic: include ---- - -[on-premises :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/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") \ No newline at end of file diff --git a/windows/security/includes/hello-join-aad.md b/windows/security/includes/hello-join-aad.md deleted file mode 100644 index 5709970576..0000000000 --- a/windows/security/includes/hello-join-aad.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -author: paolomatarazzo -ms.author: paoloma -ms.date: 12/08/2022 -ms.topic: include ---- - -[Azure AD join :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/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") \ No newline at end of file diff --git a/windows/security/includes/hello-join-domain.md b/windows/security/includes/hello-join-domain.md deleted file mode 100644 index 0385e2089a..0000000000 --- a/windows/security/includes/hello-join-domain.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -author: paolomatarazzo -ms.author: paoloma -ms.date: 12/08/2022 -ms.topic: include ---- - -[domain join :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md "Devices that are domain joined do not have any dependencies on Azure AD. Only local users accounts and Active Directory users can sign in to these devices") \ No newline at end of file diff --git a/windows/security/includes/hello-join-hybrid.md b/windows/security/includes/hello-join-hybrid.md deleted file mode 100644 index 3d3e75c6b6..0000000000 --- a/windows/security/includes/hello-join-hybrid.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -author: paolomatarazzo -ms.author: paoloma -ms.date: 12/08/2022 -ms.topic: include ---- - -[hybrid Azure AD join :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/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") \ No newline at end of file diff --git a/windows/security/includes/hello-trust-certificate.md b/windows/security/includes/hello-trust-certificate.md deleted file mode 100644 index ffc705fde0..0000000000 --- a/windows/security/includes/hello-trust-certificate.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -author: paolomatarazzo -ms.author: paoloma -ms.date: 12/08/2022 -ms.topic: include ---- - -[certificate trust :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#certificate-trust "This trust type uses a certificate to authenticate the users to Active Directory. It's required to issue certificates to the users and to the domain controllers") \ No newline at end of file diff --git a/windows/security/includes/hello-trust-cloud-kerberos.md b/windows/security/includes/hello-trust-cloud-kerberos.md deleted file mode 100644 index 5ddac53ba9..0000000000 --- a/windows/security/includes/hello-trust-cloud-kerberos.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -author: paolomatarazzo -ms.author: paoloma -ms.date: 12/08/2022 -ms.topic: include ---- - -[cloud Kerberos trust :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#cloud-kerberos-trust "This trust type uses security keys to authenticate the users to Active Directory. It's not required to issue any certificates, making it the recommended choice for environments that do not need certificate authentication") \ No newline at end of file diff --git a/windows/security/includes/hello-trust-key.md b/windows/security/includes/hello-trust-key.md deleted file mode 100644 index 133f7f5204..0000000000 --- a/windows/security/includes/hello-trust-key.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -author: paolomatarazzo -ms.author: paoloma -ms.date: 12/08/2022 -ms.topic: include ---- - -[key trust :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#key-trust "This trust type uses a raw key to authenticate the users to Active Directory. It's not required to issue certificates to users, but it's required to deploy certificates to domain controllers") \ No newline at end of file diff --git a/windows/security/includes/intune-custom-settings-info.md b/windows/security/includes/intune-custom-settings-info.md new file mode 100644 index 0000000000..9509d5b13d --- /dev/null +++ b/windows/security/includes/intune-custom-settings-info.md @@ -0,0 +1,8 @@ +--- +author: paolomatarazzo +ms.author: paoloma +ms.date: 01/03/2022 +ms.topic: include +--- + +For more information about how to create custom settings using Intune, see [Use custom settings for Windows devices in Intune](/mem/intune/configuration/custom-settings-windows-10). \ No newline at end of file diff --git a/windows/security/includes/intune-settings-catalog-1.md b/windows/security/includes/intune-settings-catalog-1.md new file mode 100644 index 0000000000..2ddfc8d6b6 --- /dev/null +++ b/windows/security/includes/intune-settings-catalog-1.md @@ -0,0 +1,18 @@ +--- +author: paolomatarazzo +ms.author: paoloma +ms.date: 01/03/2022 +ms.topic: include +--- + +To configure devices with Microsoft Intune, use the settings catalog: + + > [!TIP] + > If you're browsing with an account that can create Intune policies, you can skip to step 5 by using this direct link to create a Settings catalog policy (opens in a new tab). + +1. Go to the Microsoft Endpoint Manager admin center +2. Select **Devices > Configuration profiles > Create profile** +3. Select **Platform > Windows 10 and later** and **Profile type > Settings catalog** +4. Select **Create** +5. Specify a **Name** and, optionally, a **Description** > **Next** +6. In the settings picker, add the following settings: \ No newline at end of file diff --git a/windows/security/includes/intune-settings-catalog-2.md b/windows/security/includes/intune-settings-catalog-2.md new file mode 100644 index 0000000000..9558ed41a7 --- /dev/null +++ b/windows/security/includes/intune-settings-catalog-2.md @@ -0,0 +1,11 @@ +--- +author: paolomatarazzo +ms.author: paoloma +ms.date: 01/03/2022 +ms.topic: include +--- + +7. Select **Next** +8. Optionally, add *scope tags* > **Next** +9. Assign the policy to a security group that contains as members the devices or users that you want to configure > **Next** +10. Review the policy configuration and select **Create** \ No newline at end of file diff --git a/windows/security/includes/intune-settings-catalog-info.md b/windows/security/includes/intune-settings-catalog-info.md new file mode 100644 index 0000000000..8387d702ff --- /dev/null +++ b/windows/security/includes/intune-settings-catalog-info.md @@ -0,0 +1,8 @@ +--- +author: paolomatarazzo +ms.author: paoloma +ms.date: 01/03/2022 +ms.topic: include +--- + +For more information about how to create policies with the Intune settings catalog, see [Use the settings catalog to configure settings](/mem/intune/configuration/settings-catalog). \ No newline at end of file diff --git a/windows/security/information-protection/bitlocker/bitlocker-group-policy-settings.md b/windows/security/information-protection/bitlocker/bitlocker-group-policy-settings.md index 948d296fa0..38d6bcb2f9 100644 --- a/windows/security/information-protection/bitlocker/bitlocker-group-policy-settings.md +++ b/windows/security/information-protection/bitlocker/bitlocker-group-policy-settings.md @@ -471,7 +471,7 @@ This policy setting is used to determine what certificate to use with BitLocker. This policy setting is applied when BitLocker is turned on. -The object identifier is specified in the enhanced key usage (EKU) of a certificate. BitLocker can identify which certificates can be used to authenticate a user certificate to a BitLocker-protected drive by matching the object identifier in the certificate with the object identifier that is defined by this policy setting. +The object identifier is specified in the extended key usage (EKU) of a certificate. BitLocker can identify which certificates can be used to authenticate a user certificate to a BitLocker-protected drive by matching the object identifier in the certificate with the object identifier that is defined by this policy setting. The default object identifier is 1.3.6.1.4.1.311.67.1.1. diff --git a/windows/security/threat-protection/auditing/audit-audit-policy-change.md b/windows/security/threat-protection/auditing/audit-audit-policy-change.md index c5cdf8c616..74134a5bd9 100644 --- a/windows/security/threat-protection/auditing/audit-audit-policy-change.md +++ b/windows/security/threat-protection/auditing/audit-audit-policy-change.md @@ -49,13 +49,13 @@ Changes to audit policy that are audited include: The following events will be enabled with Success auditing in this subcategory: -- 4902(S): The Per-user audit policy table was created. +- [4902](event-4902.md)(S): The Per-user audit policy table was created. -- 4907(S): Auditing settings on object were changed. +- [4907](event-4907.md)(S): Auditing settings on object were changed. -- 4904(S): An attempt was made to register a security event source. +- [4904](event-4904.md)(S): An attempt was made to register a security event source. -- 4905(S): An attempt was made to unregister a security event source. +- [4905](event-4905.md)(S): An attempt was made to unregister a security event source. All other events in this subcategory will be logged regardless of the "Audit Policy Change" setting. @@ -79,4 +79,4 @@ All other events in this subcategory will be logged regardless of the "Audit Pol - [4904](event-4904.md)(S): An attempt was made to register a security event source. -- [4905](event-4905.md)(S): An attempt was made to unregister a security event source. \ No newline at end of file +- [4905](event-4905.md)(S): An attempt was made to unregister a security event source. diff --git a/windows/security/threat-protection/auditing/audit-authorization-policy-change.md b/windows/security/threat-protection/auditing/audit-authorization-policy-change.md index b7fd89b268..caa5d33848 100644 --- a/windows/security/threat-protection/auditing/audit-authorization-policy-change.md +++ b/windows/security/threat-protection/auditing/audit-authorization-policy-change.md @@ -20,6 +20,8 @@ ms.topic: reference Audit Authorization Policy Change allows you to audit assignment and removal of user rights in user right policies, changes in security token object permission, resource attributes changes and Central Access Policy changes for file system objects. +**Event volume**: Medium to High. + | Computer Type | General Success | General Failure | Stronger Success | Stronger Failure | Comments | |-------------------|-----------------|-----------------|------------------|------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Domain Controller | IF | No | IF | No | IF – With Success auditing for this subcategory, you can get information related to changes in user rights policies, or changes of resource attributes or Central Access Policy applied to file system objects.
However, if you are using an application or system service that makes changes to system privileges through the AdjustPrivilegesToken API, we do not recommend Success auditing because of the high volume of event “[4703](event-4703.md)(S): A user right was adjusted” that may be generated. As of Windows 10, event 4703 is generated by applications or services that dynamically adjust token privileges. An example of such an application is Microsoft Configuration Manager, which makes WMI queries at recurring intervals and quickly generates a large number of 4703 events (with the WMI activity listed as coming from **svchost.exe**).
If one of your applications or services is generating a large number of 4703 events, you might find that your event-management software has filtering logic that can automatically discard the recurring events, which would make it easier to work with Success auditing for this category.
This subcategory doesn’t have Failure events, so there is no recommendation to enable Failure auditing for this subcategory. | @@ -40,5 +42,3 @@ Audit Authorization Policy Change allows you to audit assignment and removal of - [4913](event-4913.md)(S): Central Access Policy on the object was changed. -**Event volume**: Medium to High. - diff --git a/windows/security/threat-protection/auditing/event-4670.md b/windows/security/threat-protection/auditing/event-4670.md index 9509f490e5..f20653ded7 100644 --- a/windows/security/threat-protection/auditing/event-4670.md +++ b/windows/security/threat-protection/auditing/event-4670.md @@ -235,14 +235,14 @@ Example: D:(A;;FA;;;WD) | "GR" | GENERIC READ | "SD" | Delete | | "GW" | GENERIC WRITE | "WD" | Modify Permissions | | "GX" | GENERIC EXECUTE | "WO" | Modify Owner | -| File access rights | "RP" | Read All Properties | +| File access rights | | "RP" | Read All Properties | | "FA" | FILE ALL ACCESS | "WP" | Write All Properties | | "FR" | FILE GENERIC READ | "CC" | Create All Child Objects | | "FW" | FILE GENERIC WRITE | "DC" | Delete All Child Objects | | "FX" | FILE GENERIC EXECUTE | "LC" | List Contents | -| Registry key access rights | "SW" | All Validated Writes | -| "KA" | "LO" | "LO" | List Object | -| "K" | KEY READ | "DT" | Delete Subtree | +| Registry key access rights | | "SW" | Self Write | +| "KA" | KEY ALL ACCESS | "LO" | List Object | +| "KR" | KEY READ | "DT" | Delete Subtree | | "KW" | KEY WRITE | "CR" | All Extended Rights | | "KX" | KEY EXECUTE | | | @@ -272,4 +272,4 @@ For file system and registry objects, the following recommendations apply. - If you have critical registry objects for which you need to monitor all modifications (especially permissions changes and owner changes), monitor for the specific **Object\\Object Name.** -- If you have high-value computers for which you need to monitor all changes for all or specific objects (for example, file system or registry objects), monitor for all [4670](event-4670.md) events on these computers. For example, you could monitor the **ntds.dit** file on domain controllers. \ No newline at end of file +- If you have high-value computers for which you need to monitor all changes for all or specific objects (for example, file system or registry objects), monitor for all [4670](event-4670.md) events on these computers. For example, you could monitor the **ntds.dit** file on domain controllers. diff --git a/windows/security/threat-protection/security-policy-settings/TOC.yml b/windows/security/threat-protection/security-policy-settings/TOC.yml index 1ddc477ef1..1e4b1fa586 100644 --- a/windows/security/threat-protection/security-policy-settings/TOC.yml +++ b/windows/security/threat-protection/security-policy-settings/TOC.yml @@ -136,10 +136,6 @@ href: interactive-logon-smart-card-removal-behavior.md - name: "Microsoft network client: Digitally sign communications (always)" href: microsoft-network-client-digitally-sign-communications-always.md - - name: "SMBv1 Microsoft network client: Digitally sign communications (always)" - href: smbv1-microsoft-network-client-digitally-sign-communications-always.md - - name: "SMBv1 Microsoft network client: Digitally sign communications (if server agrees)" - href: smbv1-microsoft-network-client-digitally-sign-communications-if-server-agrees.md - name: "Microsoft network client: Send unencrypted password to third-party SMB servers" href: microsoft-network-client-send-unencrypted-password-to-third-party-smb-servers.md - name: "Microsoft network server: Amount of idle time required before suspending session" @@ -148,10 +144,6 @@ href: microsoft-network-server-attempt-s4u2self-to-obtain-claim-information.md - name: "Microsoft network server: Digitally sign communications (always)" href: microsoft-network-server-digitally-sign-communications-always.md - - name: "SMBv1 Microsoft network server: Digitally sign communications (always)" - href: smbv1-microsoft-network-server-digitally-sign-communications-always.md - - name: "SMBv1 Microsoft network server: Digitally sign communications (if client agrees)" - href: smbv1-microsoft-network-server-digitally-sign-communications-if-client-agrees.md - name: "Microsoft network server: Disconnect clients when logon hours expire" href: microsoft-network-server-disconnect-clients-when-logon-hours-expire.md - name: "Microsoft network server: Server SPN target name validation level" diff --git a/windows/security/threat-protection/security-policy-settings/access-credential-manager-as-a-trusted-caller.md b/windows/security/threat-protection/security-policy-settings/access-credential-manager-as-a-trusted-caller.md index 1c67b647de..5ac230e0ed 100644 --- a/windows/security/threat-protection/security-policy-settings/access-credential-manager-as-a-trusted-caller.md +++ b/windows/security/threat-protection/security-policy-settings/access-credential-manager-as-a-trusted-caller.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Access Credential Manager as a trusted caller **Applies to** +- Windows 11 - Windows 10 This article describes the recommended practices, location, values, policy management, and security considerations for the **Access Credential Manager as a trusted caller** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/access-this-computer-from-the-network.md b/windows/security/threat-protection/security-policy-settings/access-this-computer-from-the-network.md index ea4406b6f7..7f643514fc 100644 --- a/windows/security/threat-protection/security-policy-settings/access-this-computer-from-the-network.md +++ b/windows/security/threat-protection/security-policy-settings/access-this-computer-from-the-network.md @@ -20,7 +20,12 @@ ms.technology: itpro-security # Access this computer from the network - security policy setting **Applies to** -- Windows 10, Azure Stack HCI, Windows Server 2022, Windows Server 2019, Windows Server 2016 +- Windows 11 +- Windows 10 +- Windows Server 2022 +- Windows Server 2019 +- Windows Server 2016 +- Azure Stack HCI Describes the best practices, location, values, policy management, and security considerations for the **Access this computer from the network** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/act-as-part-of-the-operating-system.md b/windows/security/threat-protection/security-policy-settings/act-as-part-of-the-operating-system.md index c36f75e923..5c6402aa17 100644 --- a/windows/security/threat-protection/security-policy-settings/act-as-part-of-the-operating-system.md +++ b/windows/security/threat-protection/security-policy-settings/act-as-part-of-the-operating-system.md @@ -20,7 +20,8 @@ ms.technology: itpro-security # Act as part of the operating system **Applies to** -- Windows 10 +- Windows 11 +- Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Act as part of the operating system** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/add-workstations-to-domain.md b/windows/security/threat-protection/security-policy-settings/add-workstations-to-domain.md index 6c558c83f7..139d15f4ec 100644 --- a/windows/security/threat-protection/security-policy-settings/add-workstations-to-domain.md +++ b/windows/security/threat-protection/security-policy-settings/add-workstations-to-domain.md @@ -1,17 +1,12 @@ --- -title: Add workstations to domain (Windows 10) +title: Add workstations to domain description: Describes the best practices, location, values, policy management and security considerations for the Add workstations to domain security policy setting. -ms.assetid: b0c21af4-c928-4344-b1f1-58ef162ad0b3 ms.reviewer: ms.author: vinpa ms.prod: windows-client -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security ms.localizationpriority: medium author: vinaypamnani-msft manager: aaroncz -audience: ITPro ms.topic: conceptual ms.date: 04/19/2017 ms.technology: itpro-security @@ -20,7 +15,7 @@ ms.technology: itpro-security # Add workstations to domain **Applies to** -- Windows 10 +- Windows Server Describes the best practices, location, values, policy management and security considerations for the **Add workstations to domain** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/adjust-memory-quotas-for-a-process.md b/windows/security/threat-protection/security-policy-settings/adjust-memory-quotas-for-a-process.md index 622ad26f5c..af89003808 100644 --- a/windows/security/threat-protection/security-policy-settings/adjust-memory-quotas-for-a-process.md +++ b/windows/security/threat-protection/security-policy-settings/adjust-memory-quotas-for-a-process.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Adjust memory quotas for a process **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Adjust memory quotas for a process** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/allow-log-on-locally.md b/windows/security/threat-protection/security-policy-settings/allow-log-on-locally.md index 6e252f1e14..475bd01f46 100644 --- a/windows/security/threat-protection/security-policy-settings/allow-log-on-locally.md +++ b/windows/security/threat-protection/security-policy-settings/allow-log-on-locally.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Allow log on locally - security policy setting **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Allow log on locally** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/allow-log-on-through-remote-desktop-services.md b/windows/security/threat-protection/security-policy-settings/allow-log-on-through-remote-desktop-services.md index 6b074f6cb3..fd5a84fe03 100644 --- a/windows/security/threat-protection/security-policy-settings/allow-log-on-through-remote-desktop-services.md +++ b/windows/security/threat-protection/security-policy-settings/allow-log-on-through-remote-desktop-services.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Allow log on through Remote Desktop Services **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Allow log on through Remote Desktop Services** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/back-up-files-and-directories.md b/windows/security/threat-protection/security-policy-settings/back-up-files-and-directories.md index 40d62fb154..99590d638b 100644 --- a/windows/security/threat-protection/security-policy-settings/back-up-files-and-directories.md +++ b/windows/security/threat-protection/security-policy-settings/back-up-files-and-directories.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Back up files and directories - security policy setting **Applies to** +- Windows 11 - Windows 10 This article describes the recommended practices, location, values, policy management, and security considerations for the **Back up files and directories** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/bypass-traverse-checking.md b/windows/security/threat-protection/security-policy-settings/bypass-traverse-checking.md index bd274babde..ccdce7a3f5 100644 --- a/windows/security/threat-protection/security-policy-settings/bypass-traverse-checking.md +++ b/windows/security/threat-protection/security-policy-settings/bypass-traverse-checking.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Bypass traverse checking **Applies to** +- Windows 11 - Windows 10 >Learn more about what features and functionality are supported in each Windows edition at [Compare Windows 10 Editions](https://www.microsoft.com/WindowsForBusiness/Compare). diff --git a/windows/security/threat-protection/security-policy-settings/change-the-system-time.md b/windows/security/threat-protection/security-policy-settings/change-the-system-time.md index 3958ae9bed..02cbb94d06 100644 --- a/windows/security/threat-protection/security-policy-settings/change-the-system-time.md +++ b/windows/security/threat-protection/security-policy-settings/change-the-system-time.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Change the system time - security policy setting **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Change the system time** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/change-the-time-zone.md b/windows/security/threat-protection/security-policy-settings/change-the-time-zone.md index 0f18fbe6a0..d8dfd97662 100644 --- a/windows/security/threat-protection/security-policy-settings/change-the-time-zone.md +++ b/windows/security/threat-protection/security-policy-settings/change-the-time-zone.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Change the time zone - security policy setting **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Change the time zone** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/create-a-pagefile.md b/windows/security/threat-protection/security-policy-settings/create-a-pagefile.md index 68753e633a..a5438297fd 100644 --- a/windows/security/threat-protection/security-policy-settings/create-a-pagefile.md +++ b/windows/security/threat-protection/security-policy-settings/create-a-pagefile.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Create a pagefile - security policy setting **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Create a pagefile** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/create-a-token-object.md b/windows/security/threat-protection/security-policy-settings/create-a-token-object.md index 397456fc85..727912a7ca 100644 --- a/windows/security/threat-protection/security-policy-settings/create-a-token-object.md +++ b/windows/security/threat-protection/security-policy-settings/create-a-token-object.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Create a token object **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Create a token object** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/create-global-objects.md b/windows/security/threat-protection/security-policy-settings/create-global-objects.md index bd8b943798..f6be4d3ed7 100644 --- a/windows/security/threat-protection/security-policy-settings/create-global-objects.md +++ b/windows/security/threat-protection/security-policy-settings/create-global-objects.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Create global objects **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Create global objects** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/create-permanent-shared-objects.md b/windows/security/threat-protection/security-policy-settings/create-permanent-shared-objects.md index dd58539e88..38fb6346f9 100644 --- a/windows/security/threat-protection/security-policy-settings/create-permanent-shared-objects.md +++ b/windows/security/threat-protection/security-policy-settings/create-permanent-shared-objects.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Create permanent shared objects **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Create permanent shared objects** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/create-symbolic-links.md b/windows/security/threat-protection/security-policy-settings/create-symbolic-links.md index 5ea5c36a0c..82c3f5ffc9 100644 --- a/windows/security/threat-protection/security-policy-settings/create-symbolic-links.md +++ b/windows/security/threat-protection/security-policy-settings/create-symbolic-links.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Create symbolic links **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Create symbolic links** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/debug-programs.md b/windows/security/threat-protection/security-policy-settings/debug-programs.md index c97a34004a..7b72217ab7 100644 --- a/windows/security/threat-protection/security-policy-settings/debug-programs.md +++ b/windows/security/threat-protection/security-policy-settings/debug-programs.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Debug programs **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Debug programs** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/deny-access-to-this-computer-from-the-network.md b/windows/security/threat-protection/security-policy-settings/deny-access-to-this-computer-from-the-network.md index 9d51332226..9dc9bb9d38 100644 --- a/windows/security/threat-protection/security-policy-settings/deny-access-to-this-computer-from-the-network.md +++ b/windows/security/threat-protection/security-policy-settings/deny-access-to-this-computer-from-the-network.md @@ -20,7 +20,8 @@ ms.technology: itpro-security # Deny access to this computer from the network **Applies to** -- Windows 10 +- Windows 11 +- Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Deny access to this computer from the network** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/deny-log-on-as-a-batch-job.md b/windows/security/threat-protection/security-policy-settings/deny-log-on-as-a-batch-job.md index 26257d7869..d832f6a8ba 100644 --- a/windows/security/threat-protection/security-policy-settings/deny-log-on-as-a-batch-job.md +++ b/windows/security/threat-protection/security-policy-settings/deny-log-on-as-a-batch-job.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Deny log on as a batch job **Applies to** +- Windows 11 - Windows 10 This article describes the recommended practices, location, values, policy management, and security considerations for the **Deny log on as a batch job** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/deny-log-on-as-a-service.md b/windows/security/threat-protection/security-policy-settings/deny-log-on-as-a-service.md index 943ab1c47e..22b448bed6 100644 --- a/windows/security/threat-protection/security-policy-settings/deny-log-on-as-a-service.md +++ b/windows/security/threat-protection/security-policy-settings/deny-log-on-as-a-service.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Deny log on as a service **Applies to** +- Windows 11 - Windows 10 This article describes the recommended practices, location, values, policy management, and security considerations for the **Deny log on as a service** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/deny-log-on-locally.md b/windows/security/threat-protection/security-policy-settings/deny-log-on-locally.md index 66c2308100..1ef7bc4a08 100644 --- a/windows/security/threat-protection/security-policy-settings/deny-log-on-locally.md +++ b/windows/security/threat-protection/security-policy-settings/deny-log-on-locally.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Deny log on locally **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Deny log on locally** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/deny-log-on-through-remote-desktop-services.md b/windows/security/threat-protection/security-policy-settings/deny-log-on-through-remote-desktop-services.md index ad977d3239..2bc5898d13 100644 --- a/windows/security/threat-protection/security-policy-settings/deny-log-on-through-remote-desktop-services.md +++ b/windows/security/threat-protection/security-policy-settings/deny-log-on-through-remote-desktop-services.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Deny log on through Remote Desktop Services **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Deny log on through Remote Desktop Services** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/domain-controller-allow-server-operators-to-schedule-tasks.md b/windows/security/threat-protection/security-policy-settings/domain-controller-allow-server-operators-to-schedule-tasks.md index 67c1a1fd26..28361156ef 100644 --- a/windows/security/threat-protection/security-policy-settings/domain-controller-allow-server-operators-to-schedule-tasks.md +++ b/windows/security/threat-protection/security-policy-settings/domain-controller-allow-server-operators-to-schedule-tasks.md @@ -1,17 +1,12 @@ --- -title: Domain controller Allow server operators to schedule tasks (Windows 10) +title: Domain controller Allow server operators to schedule tasks description: Describes the best practices, location, values, and security considerations for the Domain controller Allow server operators to schedule tasks security policy setting. -ms.assetid: 198b12a4-8a5d-48e8-a752-2073b8a2cb0d ms.reviewer: ms.author: vinpa ms.prod: windows-client -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security ms.localizationpriority: medium author: vinaypamnani-msft manager: aaroncz -audience: ITPro ms.topic: conceptual ms.date: 04/19/2017 ms.technology: itpro-security @@ -20,7 +15,7 @@ ms.technology: itpro-security # Domain controller: Allow server operators to schedule tasks **Applies to** -- Windows 10 +- Windows Server Describes the best practices, location, values, and security considerations for the **Domain controller: Allow server operators to schedule tasks** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/domain-controller-ldap-server-signing-requirements.md b/windows/security/threat-protection/security-policy-settings/domain-controller-ldap-server-signing-requirements.md index cc42ccd096..39803ce695 100644 --- a/windows/security/threat-protection/security-policy-settings/domain-controller-ldap-server-signing-requirements.md +++ b/windows/security/threat-protection/security-policy-settings/domain-controller-ldap-server-signing-requirements.md @@ -1,17 +1,12 @@ --- -title: Domain controller LDAP server signing requirements (Windows 10) +title: Domain controller LDAP server signing requirements description: Describes the best practices, location, values, and security considerations for the Domain controller LDAP server signing requirements security policy setting. -ms.assetid: fe122179-7571-465b-98d0-b8ce0f224390 ms.reviewer: ms.author: vinpa ms.prod: windows-client -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security ms.localizationpriority: medium author: vinaypamnani-msft manager: aaroncz -audience: ITPro ms.topic: conceptual ms.date: 04/19/2017 ms.technology: itpro-security @@ -20,7 +15,7 @@ ms.technology: itpro-security # Domain controller: LDAP server signing requirements **Applies to** -- Windows 10 +- Windows Server This article describes the best practices, location, values, and security considerations for the **Domain controller: LDAP server signing requirements** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/domain-controller-refuse-machine-account-password-changes.md b/windows/security/threat-protection/security-policy-settings/domain-controller-refuse-machine-account-password-changes.md index df6db377b5..63d863c555 100644 --- a/windows/security/threat-protection/security-policy-settings/domain-controller-refuse-machine-account-password-changes.md +++ b/windows/security/threat-protection/security-policy-settings/domain-controller-refuse-machine-account-password-changes.md @@ -1,17 +1,12 @@ --- -title: Refuse machine account password changes policy (Windows 10) +title: Refuse machine account password changes policy description: Describes the best practices, location, values, and security considerations for the Domain controller Refuse machine account password changes security policy setting. -ms.assetid: 5a7fa2e2-e1a8-4833-90f7-aa83e3b456a9 ms.reviewer: ms.author: vinpa ms.prod: windows-client -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security ms.localizationpriority: medium author: vinaypamnani-msft manager: aaroncz -audience: ITPro ms.topic: conceptual ms.technology: itpro-security ms.date: 12/31/2017 @@ -20,7 +15,7 @@ ms.date: 12/31/2017 # Domain controller: Refuse machine account password changes **Applies to** -- Windows 10 +- Windows Server Describes the best practices, location, values, and security considerations for the **Domain controller: Refuse machine account password changes** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/enable-computer-and-user-accounts-to-be-trusted-for-delegation.md b/windows/security/threat-protection/security-policy-settings/enable-computer-and-user-accounts-to-be-trusted-for-delegation.md index e1bc8ef4b9..6c8e9a5f36 100644 --- a/windows/security/threat-protection/security-policy-settings/enable-computer-and-user-accounts-to-be-trusted-for-delegation.md +++ b/windows/security/threat-protection/security-policy-settings/enable-computer-and-user-accounts-to-be-trusted-for-delegation.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Enable computer and user accounts to be trusted for delegation **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Enable computer and user accounts to be trusted for delegation** security policy setting. @@ -108,4 +109,4 @@ None. Not defined is the default configuration. ## Related topics -- [User Rights Assignment](user-rights-assignment.md) \ No newline at end of file +- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/force-shutdown-from-a-remote-system.md b/windows/security/threat-protection/security-policy-settings/force-shutdown-from-a-remote-system.md index 47d87b0cef..8b13dfac68 100644 --- a/windows/security/threat-protection/security-policy-settings/force-shutdown-from-a-remote-system.md +++ b/windows/security/threat-protection/security-policy-settings/force-shutdown-from-a-remote-system.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Force shutdown from a remote system **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Force shutdown from a remote system** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/generate-security-audits.md b/windows/security/threat-protection/security-policy-settings/generate-security-audits.md index be5d5caebf..ed57ea1a97 100644 --- a/windows/security/threat-protection/security-policy-settings/generate-security-audits.md +++ b/windows/security/threat-protection/security-policy-settings/generate-security-audits.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Generate security audits **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Generate security audits** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/impersonate-a-client-after-authentication.md b/windows/security/threat-protection/security-policy-settings/impersonate-a-client-after-authentication.md index c4a613a542..e2a1861c80 100644 --- a/windows/security/threat-protection/security-policy-settings/impersonate-a-client-after-authentication.md +++ b/windows/security/threat-protection/security-policy-settings/impersonate-a-client-after-authentication.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Impersonate a client after authentication **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Impersonate a client after authentication** security policy setting. @@ -109,4 +110,4 @@ In IIS 7.0 and later, a built-in account (IUSR) replaces the IUSR_MachineName ac ## Related topics -- [User Rights Assignment](user-rights-assignment.md) \ No newline at end of file +- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/increase-a-process-working-set.md b/windows/security/threat-protection/security-policy-settings/increase-a-process-working-set.md index 3c54eb33ec..0f79c38991 100644 --- a/windows/security/threat-protection/security-policy-settings/increase-a-process-working-set.md +++ b/windows/security/threat-protection/security-policy-settings/increase-a-process-working-set.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Increase a process working set **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Increase a process working set** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/increase-scheduling-priority.md b/windows/security/threat-protection/security-policy-settings/increase-scheduling-priority.md index 2c2e0bb890..5446601279 100644 --- a/windows/security/threat-protection/security-policy-settings/increase-scheduling-priority.md +++ b/windows/security/threat-protection/security-policy-settings/increase-scheduling-priority.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Increase scheduling priority **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Increase scheduling priority** security policy setting. @@ -89,4 +90,4 @@ None. Restricting the **Increase scheduling priority** user right to members of ## Related topics - [User Rights Assignment](user-rights-assignment.md) -- [Increase scheduling priority for Windows Server 2012 and earlier](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn221960(v%3dws.11)) \ No newline at end of file +- [Increase scheduling priority for Windows Server 2012 and earlier](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn221960(v%3dws.11)) diff --git a/windows/security/threat-protection/security-policy-settings/interactive-logon-require-smart-card.md b/windows/security/threat-protection/security-policy-settings/interactive-logon-require-smart-card.md index 32b2a60b44..c4c432757d 100644 --- a/windows/security/threat-protection/security-policy-settings/interactive-logon-require-smart-card.md +++ b/windows/security/threat-protection/security-policy-settings/interactive-logon-require-smart-card.md @@ -1,47 +1,44 @@ --- -title: Interactive logon Require smart card - security policy setting (Windows 10) -description: Describes the best practices, location, values, policy management, and security considerations for the Interactive logon Require smart card security policy setting. -ms.assetid: c6a8c040-cbc7-472d-8bc5-579ddf3cbd6c -ms.reviewer: -ms.author: vinpa -ms.prod: windows-client -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium +title: "Interactive logon: Require Windows Hello for Business or smart card" +description: "Describes the best practices, location, values, policy management, and security considerations for the 'Interactive logon: Require Windows Hello for Business or smart card' security policy setting." author: vinaypamnani-msft +ms.author: vinpa manager: aaroncz -audience: ITPro -ms.topic: conceptual -ms.date: 04/19/2017 +ms.reviewer: +ms.prod: windows-client ms.technology: itpro-security +ms.localizationpriority: medium +ms.topic: conceptual +ms.date: 01/13/2023 --- -# Interactive logon: Require smart card - security policy setting +# Interactive logon: Require Windows Hello for Business or smart card **Applies to** -- Windows 10 -Describes the best practices, location, values, policy management, and security considerations for the **Interactive logon: Require smart card** security policy setting. +- Windows 11 +- Windows 10, version 1703 or later + +Describes the best practices, location, values, policy management, and security considerations for the **Interactive logon: Require Windows Hello for Business or smart card** security policy setting. > [!NOTE] -> You may need to download the ADMX template for your version of Windows to enable this policy to be applied. +> You may need to download the ADMX template for your version of Windows to apply this policy. ## Reference -The **Interactive logon: Require smart card** policy setting requires users to log on to a device by using a smart card. +The **Interactive logon: Require Windows Hello for Business or smart card** policy setting requires users to sign in to a device by using a smart card or Windows Hello for Business method. -Requiring users to use long, complex passwords for authentication enhances network security, especially if the users must change their passwords regularly. This requirement reduces the chance that a malicious user will be able to guess a user's password through a brute-force attack. Using smart cards rather than passwords for authentication dramatically increases security because, with today's technology, it is nearly impossible for a malicious user to impersonate another user. Smart cards that require personal identification numbers (PINs) provide two-factor authentication: the user who attempts to log on must possess the smart card and know its PIN. A malicious user who captures the authentication traffic between the user's device and the domain controller will find it difficult to decrypt the traffic: even if they do, the next time the user logs on to the network, a new session key will be generated for encrypting traffic between the user and the domain controller. +Requiring users to use long, complex passwords for authentication enhances network security, especially if the users must change their passwords regularly. This requirement reduces the chance that a malicious user will be able to guess a user's password through a brute-force attack. Using smart cards rather than passwords for authentication dramatically increases security because, with today's technology, it's nearly impossible for a malicious user to impersonate another user. Smart cards that require personal identification numbers (PINs) provide two-factor authentication: the user who attempts to sign in must possess the smart card and know its PIN. A malicious user who captures the authentication traffic between the user's device and the domain controller will find it difficult to decrypt the traffic: even if they do, the next time the user signs in to the network, a new session key will be generated for encrypting traffic between the user and the domain controller. ### Possible values -- Enabled -- Disabled -- Not defined +- Enabled +- Disabled +- Not defined ### Best practices -- Set **Interactive logon: Require smart card** to Enabled. All users will have to use smart cards to log on to the network. This requirement means that the organization must have a reliable public key infrastructure (PKI) in place, and provide smart cards and smart card readers for all users. +- Set **Interactive logon: Require Windows Hello for Business or smart card** to Enabled. All users will have to use smart cards to sign in to the network, or a Windows Hello for Business method. This requirement means that the organization must have a reliable public key infrastructure (PKI) in place, and provide smart cards and smart card readers for all users. For more information about password-less authentication, see [Windows Hello for Business overview](../../identity-protection/hello-for-business/hello-overview.md). ### Location @@ -49,32 +46,32 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Sec ### Default values -The following table lists the actual and effective default values for this policy, by server type or Group Policy Object (GPO). Default values are also listed on the policy's property page. +The following table lists the actual and effective default values for this policy, by server type or group policy object (GPO). Default values are also listed on the policy's property page. | Server type or GPO | Default value | | - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Disabled| -| DC Effective Default Settings | Disabled| -| Member Server Effective Default Settings | Disabled| -| Client Computer Effective Default Settings | Disabled| - +| Default Domain Policy| Not defined| +| Default Domain Controller Policy | Not defined| +| Stand-Alone Server Default Settings | Disabled| +| DC Effective Default Settings | Disabled| +| Member Server Effective Default Settings | Disabled| +| Client Computer Effective Default Settings | Disabled| + ## Policy management This section describes features and tools that are available to help you manage this policy. ### Restart requirement -None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy. +None. Changes to this policy become effective without a device restart when they're saved locally or distributed through group policy. ### Policy conflict considerations None. -### Group Policy +### Group policy -This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through GPOs. If this policy is not contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in. +This policy setting can be configured by using the group policy management console (GPMC) to be distributed through GPOs. If this policy isn't contained in a distributed GPO, this policy can be configured on the local computer by using the local security policy snap-in. ## Security considerations @@ -86,13 +83,13 @@ It can be difficult to make users choose strong passwords, and even strong passw ### Countermeasure -For users with access to computers that contain sensitive data, issue smart cards to users and configure the **Interactive logon: Require smart card** setting to Enabled. +For users with access to computers that contain sensitive data, issue smart cards to users or configure Windows Hello for Business. Then configure the **Interactive logon: Require Windows Hello for Business or smart card** setting to Enabled. -### Potential impact +### Potential effect -All users of a device with this setting enabled must use smart cards to log on locally. So the organization must have a reliable public key infrastructure (PKI) as well as smart cards and smart card readers for these users. These requirements are significant challenges because -expertise and resources are required to plan for and deploy these technologies. Active Directory Certificate Services (AD CS) can be used to implement and manage certificates. You can use automatic user and device enrollment and renewal on the client. +All users of a device with this setting enabled must use smart cards or a Windows Hello for Business method to sign in locally. The organization must have a reliable public key infrastructure (PKI), smart cards, and smart card readers for these users, or have enabled Windows Hello for Business. These requirements are significant challenges because expertise and resources are required to plan for and deploy these technologies. Active Directory Certificate Services can be used to implement and manage certificates. You can use automatic user and device enrollment and renewal on the client. -## Related topics +## Related articles - [Security Options](security-options.md) +- [Windows Hello for Business overview](../../identity-protection/hello-for-business/hello-overview.md) diff --git a/windows/security/threat-protection/security-policy-settings/load-and-unload-device-drivers.md b/windows/security/threat-protection/security-policy-settings/load-and-unload-device-drivers.md index 10425d576a..f0f4e5f932 100644 --- a/windows/security/threat-protection/security-policy-settings/load-and-unload-device-drivers.md +++ b/windows/security/threat-protection/security-policy-settings/load-and-unload-device-drivers.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Load and unload device drivers **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Load and unload device drivers** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/lock-pages-in-memory.md b/windows/security/threat-protection/security-policy-settings/lock-pages-in-memory.md index ab91674f23..d7510658e7 100644 --- a/windows/security/threat-protection/security-policy-settings/lock-pages-in-memory.md +++ b/windows/security/threat-protection/security-policy-settings/lock-pages-in-memory.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Lock pages in memory **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Lock pages in memory** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/log-on-as-a-batch-job.md b/windows/security/threat-protection/security-policy-settings/log-on-as-a-batch-job.md index c982a7ca78..bcdeda1852 100644 --- a/windows/security/threat-protection/security-policy-settings/log-on-as-a-batch-job.md +++ b/windows/security/threat-protection/security-policy-settings/log-on-as-a-batch-job.md @@ -22,6 +22,7 @@ ms.technology: itpro-security # Log on as a batch job **Applies to** +- Windows 11 - Windows 10 This article describes the recommended practices, location, values, policy management, and security considerations for the **Log on as a batch job** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/log-on-as-a-service.md b/windows/security/threat-protection/security-policy-settings/log-on-as-a-service.md index 833a0d2eea..667a0885f7 100644 --- a/windows/security/threat-protection/security-policy-settings/log-on-as-a-service.md +++ b/windows/security/threat-protection/security-policy-settings/log-on-as-a-service.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Log on as a service **Applies to** +- Windows 11 - Windows 10 This article describes the recommended practices, location, values, policy management, and security considerations for the **Log on as a service** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/manage-auditing-and-security-log.md b/windows/security/threat-protection/security-policy-settings/manage-auditing-and-security-log.md index f19e322da5..0b62095cd7 100644 --- a/windows/security/threat-protection/security-policy-settings/manage-auditing-and-security-log.md +++ b/windows/security/threat-protection/security-policy-settings/manage-auditing-and-security-log.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Manage auditing and security log **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Manage auditing and security log** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/microsoft-network-client-digitally-sign-communications-always.md b/windows/security/threat-protection/security-policy-settings/microsoft-network-client-digitally-sign-communications-always.md index e446db45a1..e4f7c05351 100644 --- a/windows/security/threat-protection/security-policy-settings/microsoft-network-client-digitally-sign-communications-always.md +++ b/windows/security/threat-protection/security-policy-settings/microsoft-network-client-digitally-sign-communications-always.md @@ -1,17 +1,13 @@ --- -title: Microsoft network client Digitally sign communications (always) (Windows 10) +title: Microsoft network client Digitally sign communications (always) description: Best practices and security considerations for the Microsoft network client Digitally sign communications (always) security policy setting. -ms.assetid: 4b7b0298-b130-40f8-960d-60418ba85f76 ms.reviewer: manager: aaroncz ms.author: vinpa ms.prod: windows-client -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security ms.localizationpriority: medium author: vinaypamnani-msft -ms.date: 06/28/2018 +ms.date: 01/13/2023 ms.technology: itpro-security ms.topic: conceptual --- @@ -19,12 +15,26 @@ ms.topic: conceptual # Microsoft network client: Digitally sign communications (always) **Applies to** -- Windows 11 -- Windows 10 -- Windows Server + +- Windows 11 +- Windows 10 +- Windows Server This article describes the best practices, location, values, policy management, and security considerations for the **Microsoft network client: Digitally sign communications (always)** security policy setting for SMBv3 and SMBv2. +> [!NOTE] +> This article is about the server message block (SMB) v2 and v3 protocols. SMBv1 isn't secure and has been deprecated in Windows. Starting with Windows 10, version 1709, and Windows Server, version 1709, [SMBv1 isn't installed by default](/windows-server/storage/file-server/troubleshoot/smbv1-not-installed-by-default-in-windows). + +> [!IMPORTANT] +> Microsoft doesn't recommend using the following group policy settings: +> +> - **Microsoft network server: Digitally sign communications (if client agrees)** +> - **Microsoft network client: Digitally sign communications (if server agrees)** +> +> Also don't use the **EnableSecuritySignature** registry settings. +> +> These options only affect the SMBv1 behavior. They can be effectively replaced by the **Digitally sign communications (always)** group policy setting or the **RequireSecuritySignature** registry setting. + ## Reference The Server Message Block (SMB) protocol provides the basis for file and print sharing and many other networking operations, such as remote Windows administration. To prevent "man-in-the-middle" attacks that modify SMB packets in transit, the SMB protocol supports digital signing of SMB packets. @@ -35,22 +45,21 @@ Beginning with SMBv2 clients and servers, signing can be either *required* or *n Negotiation occurs between the SMB client and the SMB server to decide whether signing will be used. The following table shows the effective behavior for SMBv3 and SMBv2. - -| | Server – required | Server – not required | +| Client | Server - required | Server - not required | |---------------------------|---------------------|------------------------| -| **Client – required** | Signed | Signed | -| **Client – not required** | Signed 1 | Not signed2 | +| **Client - required** | Signed | Signed | +| **Client - not required** | Signed 1 | Not signed2 |
1 Default for domain controller SMB traffic
2 Default for all other SMB traffic -Performance of SMB signing is improved in SMBv2. For more information, see [Potential impact](#potential-impact). +Performance of SMB signing is improved in SMBv2. For more information, see [Potential effect](#potential-effect). ### Possible values -- Enabled -- Disabled +- Enabled +- Disabled ### Best practice @@ -62,16 +71,16 @@ Enable **Microsoft network client: Digitally sign communications (always)**. ### Default values -The following table lists the default values for this policy. Default values are also listed on the policy’s property page. +The following table lists the default values for this policy. Default values are also listed on the policy's property page. | Server type or GPO | Default value | | - | - | -| Default Domain Policy| Disabled| -| Default Domain Controller Policy | Disabled| -| Stand-Alone Server Default Settings | Disabled| -| DC Effective Default Settings | Disabled| -| Member Server Effective Default Settings | Disabled| -| Client Computer Effective Default Settings | Disabled| +| Default Domain Policy| Disabled| +| Default Domain Controller Policy | Disabled| +| Stand-Alone Server Default Settings | Disabled| +| DC Effective Default Settings | Disabled| +| Member Server Effective Default Settings | Disabled| +| Client Computer Effective Default Settings | Disabled| ## Policy management @@ -98,10 +107,11 @@ Enable **Microsoft network client: Digitally sign communications (always)**. > [!NOTE] > An alternative countermeasure that could protect all network traffic is to implement digital signatures through IPsec. There are hardware-based accelerators for IPsec encryption and signing that can be used to minimize the performance impact on servers. No such accelerators are available for SMB signing. -### Potential impact +### Potential effect Storage speeds affect performance. A faster drive on the source and destination allows more throughput, which causes more CPU usage for signing. If you're using a 1-Gb Ethernet network or slower storage speed with a modern CPU, there's limited degradation in performance. If you're using a faster network (such as 10 Gb), the performance impact of signing may be greater. -## Related topics +## Related articles - [Security options](security-options.md) +- [Microsoft network server: Digitally sign communications (always)](microsoft-network-server-digitally-sign-communications-always.md) diff --git a/windows/security/threat-protection/security-policy-settings/microsoft-network-client-send-unencrypted-password-to-third-party-smb-servers.md b/windows/security/threat-protection/security-policy-settings/microsoft-network-client-send-unencrypted-password-to-third-party-smb-servers.md index 1162197765..131ca7ef0e 100644 --- a/windows/security/threat-protection/security-policy-settings/microsoft-network-client-send-unencrypted-password-to-third-party-smb-servers.md +++ b/windows/security/threat-protection/security-policy-settings/microsoft-network-client-send-unencrypted-password-to-third-party-smb-servers.md @@ -21,6 +21,7 @@ ms.technology: itpro-security # Microsoft network client: Send unencrypted password to third-party SMB servers **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management and security considerations for the **Microsoft network client: Send unencrypted password to third-party SMB servers** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/microsoft-network-server-amount-of-idle-time-required-before-suspending-session.md b/windows/security/threat-protection/security-policy-settings/microsoft-network-server-amount-of-idle-time-required-before-suspending-session.md index b5f65848a6..9b4f9c1021 100644 --- a/windows/security/threat-protection/security-policy-settings/microsoft-network-server-amount-of-idle-time-required-before-suspending-session.md +++ b/windows/security/threat-protection/security-policy-settings/microsoft-network-server-amount-of-idle-time-required-before-suspending-session.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Microsoft network server: Amount of idle time required before suspending session **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, and security considerations for the **Microsoft network server: Amount of idle time required before suspending session** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/microsoft-network-server-attempt-s4u2self-to-obtain-claim-information.md b/windows/security/threat-protection/security-policy-settings/microsoft-network-server-attempt-s4u2self-to-obtain-claim-information.md index 12c009ce89..18eb849aa7 100644 --- a/windows/security/threat-protection/security-policy-settings/microsoft-network-server-attempt-s4u2self-to-obtain-claim-information.md +++ b/windows/security/threat-protection/security-policy-settings/microsoft-network-server-attempt-s4u2self-to-obtain-claim-information.md @@ -20,7 +20,8 @@ ms.technology: itpro-security # Microsoft network server: Attempt S4U2Self to obtain claim information **Applies to** -- Windows 10 +- Windows 11 +- Windows 10 Describes the best practices, location, values, management, and security considerations for the **Microsoft network server: Attempt S4U2Self to obtain claim information** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/microsoft-network-server-digitally-sign-communications-always.md b/windows/security/threat-protection/security-policy-settings/microsoft-network-server-digitally-sign-communications-always.md index 3ef631a76e..4685a285de 100644 --- a/windows/security/threat-protection/security-policy-settings/microsoft-network-server-digitally-sign-communications-always.md +++ b/windows/security/threat-protection/security-policy-settings/microsoft-network-server-digitally-sign-communications-always.md @@ -1,33 +1,43 @@ --- -title: Microsoft network server Digitally sign communications (always) (Windows 10) +title: Microsoft network server Digitally sign communications (always) description: Best practices, security considerations, and more for the security policy setting, Microsoft network server Digitally sign communications (always). -ms.assetid: 2007b622-7bc2-44e8-9cf1-d34b62117ea8 -ms.reviewer: -ms.author: vinpa -ms.prod: windows-client -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium author: vinaypamnani-msft +ms.author: vinpa +ms.reviewer: manager: aaroncz -audience: ITPro -ms.topic: conceptual -ms.date: 06/21/2018 +ms.prod: windows-client ms.technology: itpro-security +ms.localizationpriority: medium +ms.topic: conceptual +ms.date: 01/13/2023 --- # Microsoft network server: Digitally sign communications (always) **Applies to** -- Windows 10 -- Windows Server + +- Windows 11 +- Windows 10 +- Windows Server Describes the best practices, location, values, policy management and security considerations for the **Microsoft network server: Digitally sign communications (always)** security policy setting for SMBv3 and SMBv2. +> [!NOTE] +> This article is about the server message block (SMB) v2 and v3 protocols. SMBv1 isn't secure and has been deprecated in Windows. Starting with Windows 10, version 1709, and Windows Server, version 1709, [SMBv1 isn't installed by default](/windows-server/storage/file-server/troubleshoot/smbv1-not-installed-by-default-in-windows). + +> [!IMPORTANT] +> Microsoft doesn't recommend using the following group policy settings: +> +> - **Microsoft network server: Digitally sign communications (if client agrees)** +> - **Microsoft network client: Digitally sign communications (if server agrees)** +> +> Also don't use the **EnableSecuritySignature** registry settings. +> +> These options only affect the SMBv1 behavior. They can be effectively replaced by the **Digitally sign communications (always)** group policy setting or the **RequireSecuritySignature** registry setting. + ## Reference -The Server Message Block (SMB) protocol provides the basis for file and print sharing and many other networking operations, such as remote Windows administration. To prevent man-in-the-middle attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets. +The Server Message Block (SMB) protocol provides the basis for file and print sharing and many other networking operations, such as remote Windows administration. To prevent man-in-the-middle attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets. Implementation of digital signatures in high-security networks helps prevent the impersonation of client computers and servers, which is known as "session hijacking." But misuse of these policy settings can cause data access failure. @@ -35,22 +45,21 @@ Beginning with SMBv2 clients and servers, signing can be either required or not There's a negotiation done between the SMB client and the SMB server to decide whether signing will effectively be used. The following table has the effective behavior for SMBv3 and SMBv2. - -| | Server – Required | Server – Not Required | +| Client | Server - Required | Server - Not Required | |---------------------------|---------------------|------------------------| -| **Client – Required** | Signed | Signed | -| **Client – Not Required** | Signed 1 | Not Signed2 | +| **Client - Required** | Signed | Signed | +| **Client - Not Required** | Signed 1 | Not Signed2 |
1 Default for domain controller SMB traffic
2 Default for all other SMB traffic -Performance of SMB signing is improved in SMBv2. For more information, see [Potential impact](#potential-impact). +Performance of SMB signing is improved in SMBv2. For more information, see [Potential effect](#potential-effect). ### Possible values -- Enabled -- Disabled +- Enabled +- Disabled ### Best practices @@ -58,20 +67,20 @@ Enable **Microsoft network server: Digitally sign communications (always)**. ### Location -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options +*Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options* ### Default values -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. +The following table lists the actual and effective default values for this policy. Default values are also listed on the policy's property page. | Server type or GPO | Default value | | - | - | | Default Domain Policy| Disabled| -| Default Domain Controller Policy | Enabled| -| Stand-Alone Server Default Settings | Disabled| -| DC Effective Default Settings | Enabled| -| Member Server Effective Default Settings| Disabled| -| Client Computer Effective Default Settings | Disabled| +| Default Domain Controller Policy | Enabled| +| Stand-Alone Server Default Settings | Disabled| +| DC Effective Default Settings | Enabled| +| Member Server Effective Default Settings| Disabled| +| Client Computer Effective Default Settings | Disabled| ## Policy management @@ -95,13 +104,14 @@ SMB is the resource-sharing protocol that is supported by many Windows operating Enable **Microsoft network server: Digitally sign communications (always)**. ->[!NOTE] ->An alternative countermeasure that could protect all network traffic is to implement digital signatures with IPsec. There are hardware-based accelerators for IPsec encryption and signing that could be used to minimize the performance impact on the servers' CPUs. No such accelerators are available for SMB signing. +> [!NOTE] +> An alternative countermeasure that could protect all network traffic is to implement digital signatures with IPsec. There are hardware-based accelerators for IPsec encryption and signing that could be used to minimize the performance impact on the servers' CPUs. No such accelerators are available for SMB signing. -### Potential impact +### Potential effect Storage speeds impact performance. A faster drive on the source and destination allows more throughput, which causes more CPU usage of signing. If you're using a 1-GB Ethernet network or slower storage speed with a modern CPU, there's limited degradation in performance. If you're using a faster network (such as 10 Gb), the performance impact of signing may be greater. -## Related topics +## Related articles - [Security Options](security-options.md) +- [Microsoft network client: Digitally sign communications (always)](microsoft-network-client-digitally-sign-communications-always.md) diff --git a/windows/security/threat-protection/security-policy-settings/microsoft-network-server-disconnect-clients-when-logon-hours-expire.md b/windows/security/threat-protection/security-policy-settings/microsoft-network-server-disconnect-clients-when-logon-hours-expire.md index 9af04189fa..02f163e1c5 100644 --- a/windows/security/threat-protection/security-policy-settings/microsoft-network-server-disconnect-clients-when-logon-hours-expire.md +++ b/windows/security/threat-protection/security-policy-settings/microsoft-network-server-disconnect-clients-when-logon-hours-expire.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Microsoft network server: Disconnect clients when sign-in hours expire **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, and security considerations for the **Microsoft network server: Disconnect clients when logon hours expire** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/microsoft-network-server-server-spn-target-name-validation-level.md b/windows/security/threat-protection/security-policy-settings/microsoft-network-server-server-spn-target-name-validation-level.md index e157b27f1e..21c41369f9 100644 --- a/windows/security/threat-protection/security-policy-settings/microsoft-network-server-server-spn-target-name-validation-level.md +++ b/windows/security/threat-protection/security-policy-settings/microsoft-network-server-server-spn-target-name-validation-level.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Microsoft network server: Server SPN target name validation level **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, and values, policy management and security considerations for the **Microsoft network server: Server SPN target name validation level** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/modify-an-object-label.md b/windows/security/threat-protection/security-policy-settings/modify-an-object-label.md index 784db5fe09..f3d460e68c 100644 --- a/windows/security/threat-protection/security-policy-settings/modify-an-object-label.md +++ b/windows/security/threat-protection/security-policy-settings/modify-an-object-label.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Modify an object label **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Modify an object label** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/modify-firmware-environment-values.md b/windows/security/threat-protection/security-policy-settings/modify-firmware-environment-values.md index 3f104ff095..ae4fa3457e 100644 --- a/windows/security/threat-protection/security-policy-settings/modify-firmware-environment-values.md +++ b/windows/security/threat-protection/security-policy-settings/modify-firmware-environment-values.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Modify firmware environment values **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Modify firmware environment values** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/network-access-allow-anonymous-sidname-translation.md b/windows/security/threat-protection/security-policy-settings/network-access-allow-anonymous-sidname-translation.md index c3103f7be5..af493fdd5f 100644 --- a/windows/security/threat-protection/security-policy-settings/network-access-allow-anonymous-sidname-translation.md +++ b/windows/security/threat-protection/security-policy-settings/network-access-allow-anonymous-sidname-translation.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Network access: Allow anonymous SID/Name translation **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management and security considerations for the **Network access: Allow anonymous SID/Name translation** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-anonymous-enumeration-of-sam-accounts.md b/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-anonymous-enumeration-of-sam-accounts.md index 36749adf40..5b7e0c66e6 100644 --- a/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-anonymous-enumeration-of-sam-accounts.md +++ b/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-anonymous-enumeration-of-sam-accounts.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Network access: Do not allow anonymous enumeration of SAM accounts **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, and security considerations for the **Network access: Do not allow anonymous enumeration of SAM accounts** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-storage-of-passwords-and-credentials-for-network-authentication.md b/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-storage-of-passwords-and-credentials-for-network-authentication.md index cd953a6928..a8ded6ea27 100644 --- a/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-storage-of-passwords-and-credentials-for-network-authentication.md +++ b/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-storage-of-passwords-and-credentials-for-network-authentication.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Network access: Do not allow storage of passwords and credentials for network authentication **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management and security considerations for the **Network access: Do not allow storage of passwords and credentials for network authentication** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/network-access-let-everyone-permissions-apply-to-anonymous-users.md b/windows/security/threat-protection/security-policy-settings/network-access-let-everyone-permissions-apply-to-anonymous-users.md index d4297e81d7..3ae0bff29a 100644 --- a/windows/security/threat-protection/security-policy-settings/network-access-let-everyone-permissions-apply-to-anonymous-users.md +++ b/windows/security/threat-protection/security-policy-settings/network-access-let-everyone-permissions-apply-to-anonymous-users.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Network access: Let Everyone permissions apply to anonymous users **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management and security considerations for the **Network access: Let Everyone permissions apply to anonymous users** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/network-access-named-pipes-that-can-be-accessed-anonymously.md b/windows/security/threat-protection/security-policy-settings/network-access-named-pipes-that-can-be-accessed-anonymously.md index beb39359bb..e570e96543 100644 --- a/windows/security/threat-protection/security-policy-settings/network-access-named-pipes-that-can-be-accessed-anonymously.md +++ b/windows/security/threat-protection/security-policy-settings/network-access-named-pipes-that-can-be-accessed-anonymously.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Network access: Named Pipes that can be accessed anonymously **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management and security considerations for the **Network access: Named Pipes that can be accessed anonymously** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/network-access-remotely-accessible-registry-paths-and-subpaths.md b/windows/security/threat-protection/security-policy-settings/network-access-remotely-accessible-registry-paths-and-subpaths.md index cf9c3cea63..6bebdb7c99 100644 --- a/windows/security/threat-protection/security-policy-settings/network-access-remotely-accessible-registry-paths-and-subpaths.md +++ b/windows/security/threat-protection/security-policy-settings/network-access-remotely-accessible-registry-paths-and-subpaths.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Network access: Remotely accessible registry paths and subpaths **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, and security considerations for the **Network access: Remotely accessible registry paths and subpaths** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/network-access-remotely-accessible-registry-paths.md b/windows/security/threat-protection/security-policy-settings/network-access-remotely-accessible-registry-paths.md index cf59a0d22f..1ca60361c7 100644 --- a/windows/security/threat-protection/security-policy-settings/network-access-remotely-accessible-registry-paths.md +++ b/windows/security/threat-protection/security-policy-settings/network-access-remotely-accessible-registry-paths.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Network access: Remotely accessible registry paths **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management and security considerations for the **Network access: Remotely accessible registry paths** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/network-access-shares-that-can-be-accessed-anonymously.md b/windows/security/threat-protection/security-policy-settings/network-access-shares-that-can-be-accessed-anonymously.md index 6f1e91f1b2..b9d02af2c4 100644 --- a/windows/security/threat-protection/security-policy-settings/network-access-shares-that-can-be-accessed-anonymously.md +++ b/windows/security/threat-protection/security-policy-settings/network-access-shares-that-can-be-accessed-anonymously.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Network access: Shares that can be accessed anonymously **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management and security considerations for the **Network access: Shares that can be accessed anonymously** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/network-access-sharing-and-security-model-for-local-accounts.md b/windows/security/threat-protection/security-policy-settings/network-access-sharing-and-security-model-for-local-accounts.md index 3feed8fa4d..01d1e937b2 100644 --- a/windows/security/threat-protection/security-policy-settings/network-access-sharing-and-security-model-for-local-accounts.md +++ b/windows/security/threat-protection/security-policy-settings/network-access-sharing-and-security-model-for-local-accounts.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Network access: Sharing and security model for local accounts **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management and security considerations for the **Network access: Sharing and security model for local accounts** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/network-security-allow-local-system-to-use-computer-identity-for-ntlm.md b/windows/security/threat-protection/security-policy-settings/network-security-allow-local-system-to-use-computer-identity-for-ntlm.md index 531f18f014..bdd1418a71 100644 --- a/windows/security/threat-protection/security-policy-settings/network-security-allow-local-system-to-use-computer-identity-for-ntlm.md +++ b/windows/security/threat-protection/security-policy-settings/network-security-allow-local-system-to-use-computer-identity-for-ntlm.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Network security: Allow Local System to use computer identity for NTLM **Applies to** +- Windows 11 - Windows 10 Describes the location, values, policy management, and security considerations for the **Network security: Allow Local System to use computer identity for NTLM** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/network-security-allow-localsystem-null-session-fallback.md b/windows/security/threat-protection/security-policy-settings/network-security-allow-localsystem-null-session-fallback.md index 4d47667005..2bd7b413bb 100644 --- a/windows/security/threat-protection/security-policy-settings/network-security-allow-localsystem-null-session-fallback.md +++ b/windows/security/threat-protection/security-policy-settings/network-security-allow-localsystem-null-session-fallback.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Network security: Allow LocalSystem NULL session fallback **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, and security considerations for the **Network security: Allow LocalSystem NULL session fallback** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/network-security-allow-pku2u-authentication-requests-to-this-computer-to-use-online-identities.md b/windows/security/threat-protection/security-policy-settings/network-security-allow-pku2u-authentication-requests-to-this-computer-to-use-online-identities.md index 08db95e10e..c317d27ae4 100644 --- a/windows/security/threat-protection/security-policy-settings/network-security-allow-pku2u-authentication-requests-to-this-computer-to-use-online-identities.md +++ b/windows/security/threat-protection/security-policy-settings/network-security-allow-pku2u-authentication-requests-to-this-computer-to-use-online-identities.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Network security: Allow PKU2U authentication requests to this computer to use online identities **Applies to** +- Windows 11 - Windows 10 This article describes the best practices, location, and values for the **Network Security: Allow PKU2U authentication requests to this computer to use online identities** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/network-security-configure-encryption-types-allowed-for-kerberos.md b/windows/security/threat-protection/security-policy-settings/network-security-configure-encryption-types-allowed-for-kerberos.md index b0da8cc808..a9b0b1ae89 100644 --- a/windows/security/threat-protection/security-policy-settings/network-security-configure-encryption-types-allowed-for-kerberos.md +++ b/windows/security/threat-protection/security-policy-settings/network-security-configure-encryption-types-allowed-for-kerberos.md @@ -1,17 +1,12 @@ --- title: Network security Configure encryption types allowed for Kerberos description: Best practices, location, values and security considerations for the policy setting, Network security Configure encryption types allowed for Kerberos Win7 only. -ms.assetid: 303d32cc-415b-44ba-96c0-133934046ece ms.reviewer: ms.author: vinpa ms.prod: windows-client -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security ms.localizationpriority: medium author: vinaypamnani-msft manager: aaroncz -audience: ITPro ms.collection: - highpri ms.topic: conceptual @@ -22,7 +17,9 @@ ms.technology: itpro-security # Network security: Configure encryption types allowed for Kerberos **Applies to** -- Windows 2000 Server, Windows XP, Windows Server 2003, Windows Vista, Windows 7, Windows 8, Windows 8.1, Windows 10, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 +- Windows 11 +- Windows 10 +- Windows Server Describes the best practices, location, values, and security considerations for the **Network security: Configure encryption types allowed for Kerberos** security policy setting. @@ -30,18 +27,18 @@ Describes the best practices, location, values, and security considerations for This policy setting allows you to set the encryption types that the Kerberos protocol is allowed to use. If it isn't selected, the encryption type won't be allowed. This setting might affect compatibility with client computers or services and applications. Multiple selections are permitted. -For more information, see [article 977321](/troubleshoot/windows-server/windows-security/kdc-event-16-27-des-encryption-disabled) in the Microsoft Knowledge Base. +For more information, see [KDC event ID 16 or 27 is logged if DES for Kerberos is disabled](/troubleshoot/windows-server/windows-security/kdc-event-16-27-des-encryption-disabled). The following table lists and explains the allowed encryption types. | Encryption type | Description and version support | | - | - | -| DES_CBC_CRC | Data Encryption Standard with Cipher Block Chaining using the Cyclic Redundancy Check function
Supported in Windows 2000 Server, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008. The Windows 7, Windows 10, Windows Server 2008 R2, and later operating systems don't support DES by default. | -| DES_CBC_MD5| Data Encryption Standard with Cipher Block Chaining using the Message-Digest algorithm 5 checksum function
Supported in Windows 2000 Server, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008. The Windows 7, Windows 10, Windows Server 2008 R2, and later operating systems don't support DES by default. | -| RC4_HMAC_MD5| Rivest Cipher 4 with Hashed Message Authentication Code using the Message-Digest algorithm 5 checksum function
Supported in Windows 2000 Server, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows 10, Windows Server 2008 R2, Windows Server 2012 and Windows Server 2012 R2.| -| AES128_HMAC_SHA1| Advanced Encryption Standard in 128-bit cipher block with Hashed Message Authentication Code using the Secure Hash Algorithm (1).
Not supported in Windows 2000 Server, Windows XP, or Windows Server 2003.
Supported in Windows Vista, Windows Server 2008, Windows 7, Windows 10, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2. | -| AES256_HMAC_SHA1| Advanced Encryption Standard in 256-bit cipher block with Hashed Message Authentication Code using the Secure Hash Algorithm (1).
Not supported in Windows 2000 Server, Windows XP, or Windows Server 2003.
Supported in Windows Vista, Windows Server 2008, Windows 7, Windows 10, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2. | +| DES_CBC_CRC | Data Encryption Standard with Cipher Block Chaining using the Cyclic Redundancy Check function
Supported in Windows 2000 Server, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008. The Windows 7, Windows 10, Windows 11, Windows Server 2008 R2, and later operating systems don't support DES by default. | +| DES_CBC_MD5| Data Encryption Standard with Cipher Block Chaining using the Message-Digest algorithm 5 checksum function
Supported in Windows 2000 Server, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008. The Windows 7, Windows 10, Windows 11, Windows Server 2008 R2, and later operating systems don't support DES by default. | +| RC4_HMAC_MD5| Rivest Cipher 4 with Hashed Message Authentication Code using the Message-Digest algorithm 5 checksum function
Supported in Windows 2000 Server, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows 10, Windows 11, Windows Server 2008 R2, Windows Server 2012 and Windows Server 2012 R2.| +| AES128_HMAC_SHA1| Advanced Encryption Standard in 128-bit cipher block with Hashed Message Authentication Code using the Secure Hash Algorithm (1).
Not supported in Windows 2000 Server, Windows XP, or Windows Server 2003.
Supported in Windows Vista, Windows Server 2008, Windows 7, Windows 10, Windows 11, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2. | +| AES256_HMAC_SHA1| Advanced Encryption Standard in 256-bit cipher block with Hashed Message Authentication Code using the Secure Hash Algorithm (1).
Not supported in Windows 2000 Server, Windows XP, or Windows Server 2003.
Supported in Windows Vista, Windows Server 2008, Windows 7, Windows 10, Windows 11, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2. | | Future encryption types| Reserved by Microsoft for other encryption types that might be implemented.| ### Possible values diff --git a/windows/security/threat-protection/security-policy-settings/network-security-do-not-store-lan-manager-hash-value-on-next-password-change.md b/windows/security/threat-protection/security-policy-settings/network-security-do-not-store-lan-manager-hash-value-on-next-password-change.md index 463b054ea4..2f5d913958 100644 --- a/windows/security/threat-protection/security-policy-settings/network-security-do-not-store-lan-manager-hash-value-on-next-password-change.md +++ b/windows/security/threat-protection/security-policy-settings/network-security-do-not-store-lan-manager-hash-value-on-next-password-change.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Network security: Do not store LAN Manager hash value on next password change **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management and security considerations for the **Network security: Do not store LAN Manager hash value on next password change** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/network-security-force-logoff-when-logon-hours-expire.md b/windows/security/threat-protection/security-policy-settings/network-security-force-logoff-when-logon-hours-expire.md index 3e5f9a03b9..1999afcfbb 100644 --- a/windows/security/threat-protection/security-policy-settings/network-security-force-logoff-when-logon-hours-expire.md +++ b/windows/security/threat-protection/security-policy-settings/network-security-force-logoff-when-logon-hours-expire.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Network security: Force logoff when logon hours expire **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Network security: Force logoff when logon hours expire** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/network-security-lan-manager-authentication-level.md b/windows/security/threat-protection/security-policy-settings/network-security-lan-manager-authentication-level.md index aba0587774..e1585d602e 100644 --- a/windows/security/threat-protection/security-policy-settings/network-security-lan-manager-authentication-level.md +++ b/windows/security/threat-protection/security-policy-settings/network-security-lan-manager-authentication-level.md @@ -22,6 +22,7 @@ ms.technology: itpro-security # Network security: LAN Manager authentication level **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management and security considerations for the **Network security: LAN Manager authentication level** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/network-security-ldap-client-signing-requirements.md b/windows/security/threat-protection/security-policy-settings/network-security-ldap-client-signing-requirements.md index 3c0032faf1..3fb085d04d 100644 --- a/windows/security/threat-protection/security-policy-settings/network-security-ldap-client-signing-requirements.md +++ b/windows/security/threat-protection/security-policy-settings/network-security-ldap-client-signing-requirements.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Network security: LDAP client signing requirements **Applies to** +- Windows 11 - Windows 10 This security policy reference topic for the IT professional describes the best practices, location, values, policy management and security considerations for this policy setting. This information applies to computers running at least the Windows Server 2008 operating system. diff --git a/windows/security/threat-protection/security-policy-settings/network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-clients.md b/windows/security/threat-protection/security-policy-settings/network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-clients.md index d0a7524fb4..aa708a1c42 100644 --- a/windows/security/threat-protection/security-policy-settings/network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-clients.md +++ b/windows/security/threat-protection/security-policy-settings/network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-clients.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Network security: Minimum session security for NTLM SSP based (including secure RPC) clients **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management and security considerations for the **Network security: Minimum session security for NTLM SSP based (including secure RPC) clients** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-servers.md b/windows/security/threat-protection/security-policy-settings/network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-servers.md index 022d167542..c53712c5e9 100644 --- a/windows/security/threat-protection/security-policy-settings/network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-servers.md +++ b/windows/security/threat-protection/security-policy-settings/network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-servers.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Network security: Minimum session security for NTLM SSP based (including secure RPC) servers **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management and security considerations for the **Network security: Minimum session security for NTLM SSP based (including secure RPC) servers** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-add-remote-server-exceptions-for-ntlm-authentication.md b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-add-remote-server-exceptions-for-ntlm-authentication.md index 09f6ccc2c7..c42e1f65c5 100644 --- a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-add-remote-server-exceptions-for-ntlm-authentication.md +++ b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-add-remote-server-exceptions-for-ntlm-authentication.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, management aspects, and security considerations for the **Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-add-server-exceptions-in-this-domain.md b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-add-server-exceptions-in-this-domain.md index 99e8c7a39f..86b0883198 100644 --- a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-add-server-exceptions-in-this-domain.md +++ b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-add-server-exceptions-in-this-domain.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Network security: Restrict NTLM: Add server exceptions in this domain **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, management aspects, and security considerations for the **Network security: Restrict NTLM: Add server exceptions in this domain** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-audit-incoming-ntlm-traffic.md b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-audit-incoming-ntlm-traffic.md index 4c15706058..8d99ff27a8 100644 --- a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-audit-incoming-ntlm-traffic.md +++ b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-audit-incoming-ntlm-traffic.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Network security: Restrict NTLM: Audit incoming NTLM traffic **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, management aspects, and security considerations for the **Network Security: Restrict NTLM: Audit incoming NTLM traffic** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-audit-ntlm-authentication-in-this-domain.md b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-audit-ntlm-authentication-in-this-domain.md index 7bf8d5f15b..f0c1ef0a6c 100644 --- a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-audit-ntlm-authentication-in-this-domain.md +++ b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-audit-ntlm-authentication-in-this-domain.md @@ -1,17 +1,12 @@ --- -title: Network security Restrict NTLM Audit NTLM authentication in this domain (Windows 10) +title: Network security Restrict NTLM Audit NTLM authentication in this domain description: Best practices, security considerations, and more for the security policy setting, Network Security Restrict NTLM Audit NTLM authentication in this domain. -ms.assetid: 33183ef9-53b5-4258-8605-73dc46335e6e ms.reviewer: ms.author: vinpa ms.prod: windows-client -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security ms.localizationpriority: medium author: vinaypamnani-msft manager: aaroncz -audience: ITPro ms.topic: conceptual ms.date: 04/19/2017 ms.technology: itpro-security @@ -20,7 +15,7 @@ ms.technology: itpro-security # Network security: Restrict NTLM: Audit NTLM authentication in this domain **Applies to** -- Windows 10 +- Windows Server Describes the best practices, location, values, management aspects, and security considerations for the **Network Security: Restrict NTLM: Audit NTLM authentication in this domain** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-incoming-ntlm-traffic.md b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-incoming-ntlm-traffic.md index 2f02467243..968acbe1da 100644 --- a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-incoming-ntlm-traffic.md +++ b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-incoming-ntlm-traffic.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Network security: Restrict NTLM: Incoming NTLM traffic **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, management aspects, and security considerations for the **Network Security: Restrict NTLM: Incoming NTLM traffic** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-ntlm-authentication-in-this-domain.md b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-ntlm-authentication-in-this-domain.md index 33ff80fb70..61092a99fc 100644 --- a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-ntlm-authentication-in-this-domain.md +++ b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-ntlm-authentication-in-this-domain.md @@ -1,17 +1,12 @@ --- -title: Network security Restrict NTLM in this domain (Windows 10) +title: Network security Restrict NTLM in this domain description: Learn about best practices, security considerations and more for the security policy setting, Network Security Restrict NTLM NTLM authentication in this domain. -ms.assetid: 4c7884e9-cc11-4402-96b6-89c77dc908f8 ms.reviewer: ms.author: vinpa ms.prod: windows-client -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security ms.localizationpriority: medium author: vinaypamnani-msft manager: aaroncz -audience: ITPro ms.topic: conceptual ms.technology: itpro-security ms.date: 12/31/2017 @@ -20,7 +15,7 @@ ms.date: 12/31/2017 # Network security: Restrict NTLM: NTLM authentication in this domain **Applies to** -- Windows 10 +- Windows Server Describes the best practices, location, values, management aspects, and security considerations for the **Network Security: Restrict NTLM: NTLM authentication in this domain** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md index 9037b9728c..375f27c55c 100644 --- a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md +++ b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, management aspects, and security considerations for the **Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/perform-volume-maintenance-tasks.md b/windows/security/threat-protection/security-policy-settings/perform-volume-maintenance-tasks.md index 7b30d8f59c..60aa01ecc1 100644 --- a/windows/security/threat-protection/security-policy-settings/perform-volume-maintenance-tasks.md +++ b/windows/security/threat-protection/security-policy-settings/perform-volume-maintenance-tasks.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Perform volume maintenance tasks **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Perform volume maintenance tasks** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/profile-single-process.md b/windows/security/threat-protection/security-policy-settings/profile-single-process.md index cde1362185..d0654f81aa 100644 --- a/windows/security/threat-protection/security-policy-settings/profile-single-process.md +++ b/windows/security/threat-protection/security-policy-settings/profile-single-process.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Profile single process **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Profile single process** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/profile-system-performance.md b/windows/security/threat-protection/security-policy-settings/profile-system-performance.md index ecb01bb455..53ea9e3b07 100644 --- a/windows/security/threat-protection/security-policy-settings/profile-system-performance.md +++ b/windows/security/threat-protection/security-policy-settings/profile-system-performance.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Profile system performance **Applies to** +- Windows 11 - Windows 10 This security policy reference topic for the IT professional describes the best practices, location, values, policy management, and security considerations for the **Profile system performance** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/recovery-console-allow-automatic-administrative-logon.md b/windows/security/threat-protection/security-policy-settings/recovery-console-allow-automatic-administrative-logon.md index 0980bf4469..c6dba7f1f4 100644 --- a/windows/security/threat-protection/security-policy-settings/recovery-console-allow-automatic-administrative-logon.md +++ b/windows/security/threat-protection/security-policy-settings/recovery-console-allow-automatic-administrative-logon.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Recovery console: Allow automatic administrative logon **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Recovery console: Allow automatic administrative logon** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/recovery-console-allow-floppy-copy-and-access-to-all-drives-and-folders.md b/windows/security/threat-protection/security-policy-settings/recovery-console-allow-floppy-copy-and-access-to-all-drives-and-folders.md index d7906353f2..e530ce19b8 100644 --- a/windows/security/threat-protection/security-policy-settings/recovery-console-allow-floppy-copy-and-access-to-all-drives-and-folders.md +++ b/windows/security/threat-protection/security-policy-settings/recovery-console-allow-floppy-copy-and-access-to-all-drives-and-folders.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Recovery console: Allow floppy copy and access to all drives and folders **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management and security considerations for the **Recovery console: Allow floppy copy and access to all drives and folders** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/remove-computer-from-docking-station.md b/windows/security/threat-protection/security-policy-settings/remove-computer-from-docking-station.md index 57181925d6..0f15781757 100644 --- a/windows/security/threat-protection/security-policy-settings/remove-computer-from-docking-station.md +++ b/windows/security/threat-protection/security-policy-settings/remove-computer-from-docking-station.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Remove computer from docking station - security policy setting **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Remove computer from docking station** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/replace-a-process-level-token.md b/windows/security/threat-protection/security-policy-settings/replace-a-process-level-token.md index 5e9ee1c0f3..af5c5cc7df 100644 --- a/windows/security/threat-protection/security-policy-settings/replace-a-process-level-token.md +++ b/windows/security/threat-protection/security-policy-settings/replace-a-process-level-token.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Replace a process level token **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Replace a process level token** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/restore-files-and-directories.md b/windows/security/threat-protection/security-policy-settings/restore-files-and-directories.md index d534fcedaa..a80d0249a1 100644 --- a/windows/security/threat-protection/security-policy-settings/restore-files-and-directories.md +++ b/windows/security/threat-protection/security-policy-settings/restore-files-and-directories.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Restore files and directories - security policy setting **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Restore files and directories** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/security-options.md b/windows/security/threat-protection/security-policy-settings/security-options.md index b7b56bf6a8..a53ae544d8 100644 --- a/windows/security/threat-protection/security-policy-settings/security-options.md +++ b/windows/security/threat-protection/security-policy-settings/security-options.md @@ -1,17 +1,13 @@ --- -title: Security Options (Windows 10) +title: Security options description: Introduction to the Security Options settings of the local security policies plus links to more information. -ms.assetid: 405ea253-8116-4e57-b08e-14a8dcdca92b ms.reviewer: manager: aaroncz ms.author: vinpa ms.prod: windows-client -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security ms.localizationpriority: medium author: vinaypamnani-msft -ms.date: 06/28/2018 +ms.date: 01/13/2023 ms.technology: itpro-security ms.topic: conceptual --- @@ -19,8 +15,9 @@ ms.topic: conceptual # Security Options **Applies to** -- Windows 11 -- Windows 10 + +- Windows 11 +- Windows 10 Provides an introduction to the **Security Options** settings for local security policies and links to more information. @@ -34,75 +31,71 @@ For info about setting security policies, see [Configure security policy setting | Article | Description | | - | - | -| [Accounts: Administrator account status](accounts-administrator-account-status.md) | Describes the best practices, location, values, and security considerations for the **Accounts: Administrator account status** security policy setting.| -| [Accounts: Block Microsoft accounts](accounts-block-microsoft-accounts.md) | Describes the best practices, location, values, management, and security considerations for the **Accounts: Block Microsoft accounts** security policy setting.| -| [Accounts: Guest account status](accounts-guest-account-status.md) | Describes the best practices, location, values, and security considerations for the **Accounts: Guest account status** security policy setting.| +| [Accounts: Administrator account status](accounts-administrator-account-status.md) | Describes the best practices, location, values, and security considerations for the **Accounts: Administrator account status** security policy setting.| +| [Accounts: Block Microsoft accounts](accounts-block-microsoft-accounts.md) | Describes the best practices, location, values, management, and security considerations for the **Accounts: Block Microsoft accounts** security policy setting.| +| [Accounts: Guest account status](accounts-guest-account-status.md) | Describes the best practices, location, values, and security considerations for the **Accounts: Guest account status** security policy setting.| | [Accounts: Limit local account use of blank passwords to console logon only](accounts-limit-local-account-use-of-blank-passwords-to-console-logon-only.md) | Describes the best practices, location, values, and security considerations for the **Accounts: Limit local account use of blank passwords to console logon only** security policy setting. | -| [Accounts: Rename administrator account](accounts-rename-administrator-account.md)| This security policy article for the IT professional describes the best practices, location, values, and security considerations for this policy setting.| -| [Accounts: Rename guest account](accounts-rename-guest-account.md) | Describes the best practices, location, values, and security considerations for the **Accounts: Rename guest account** security policy setting.| -| [Audit: Audit the access of global system objects](audit-audit-the-access-of-global-system-objects.md) | Describes the best practices, location, values, and security considerations for the **Audit: Audit the access of global system objects** security policy setting.| -| [Audit: Audit the use of Backup and Restore privilege](audit-audit-the-use-of-backup-and-restore-privilege.md) | Describes the best practices, location, values, and security considerations for the **Audit: Audit the use of Backup and Restore privilege** security policy setting.| +| [Accounts: Rename administrator account](accounts-rename-administrator-account.md)| This security policy article for the IT professional describes the best practices, location, values, and security considerations for this policy setting.| +| [Accounts: Rename guest account](accounts-rename-guest-account.md) | Describes the best practices, location, values, and security considerations for the **Accounts: Rename guest account** security policy setting.| +| [Audit: Audit the access of global system objects](audit-audit-the-access-of-global-system-objects.md) | Describes the best practices, location, values, and security considerations for the **Audit: Audit the access of global system objects** security policy setting.| +| [Audit: Audit the use of Backup and Restore privilege](audit-audit-the-use-of-backup-and-restore-privilege.md) | Describes the best practices, location, values, and security considerations for the **Audit: Audit the use of Backup and Restore privilege** security policy setting.| | [Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings](audit-force-audit-policy-subcategory-settings-to-override.md) | Describes the best practices, location, values, and security considerations for the **Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings** security policy setting. | | [Audit: Shut down system immediately if unable to log security audits](audit-shut-down-system-immediately-if-unable-to-log-security-audits.md)| Describes the best practices, location, values, management practices, and security considerations for the **Audit: Shut down system immediately if unable to log security audits** security policy setting. | | [DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax](dcom-machine-access-restrictions-in-security-descriptor-definition-language-sddl-syntax.md)| Describes the best practices, location, values, and security considerations for the **DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax** policy setting. | | [DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax](dcom-machine-launch-restrictions-in-security-descriptor-definition-language-sddl-syntax.md)| Describes the best practices, location, values, and security considerations for the **DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax** security policy setting. | -| [Devices: Allow undock without having to log on](devices-allow-undock-without-having-to-log-on.md)| Describes the best practices, location, values, and security considerations for the **Devices: Allow undock without having to log on** security policy setting.| -| [Devices: Allowed to format and eject removable media](devices-allowed-to-format-and-eject-removable-media.md) | Describes the best practices, location, values, and security considerations for the **Devices: Allowed to format and eject removable media** security policy setting.| -| [Devices: Prevent users from installing printer drivers](devices-prevent-users-from-installing-printer-drivers.md) | Describes the best practices, location, values, and security considerations for the **Devices: Prevent users from installing printer drivers** security policy setting.| +| [Devices: Allow undock without having to log on](devices-allow-undock-without-having-to-log-on.md)| Describes the best practices, location, values, and security considerations for the **Devices: Allow undock without having to log on** security policy setting.| +| [Devices: Allowed to format and eject removable media](devices-allowed-to-format-and-eject-removable-media.md) | Describes the best practices, location, values, and security considerations for the **Devices: Allowed to format and eject removable media** security policy setting.| +| [Devices: Prevent users from installing printer drivers](devices-prevent-users-from-installing-printer-drivers.md) | Describes the best practices, location, values, and security considerations for the **Devices: Prevent users from installing printer drivers** security policy setting.| | [Devices: Restrict CD-ROM access to locally logged-on user only](devices-restrict-cd-rom-access-to-locally-logged-on-user-only.md) | Describes the best practices, location, values, and security considerations for the **Devices: Restrict CD-ROM access to locally logged-on user only** security policy setting. | | [Devices: Restrict floppy access to locally logged-on user only](devices-restrict-floppy-access-to-locally-logged-on-user-only.md)| Describes the best practices, location, values, and security considerations for the **Devices: Restrict floppy access to locally logged-on user only** security policy setting. | | [Domain controller: Allow server operators to schedule tasks](domain-controller-allow-server-operators-to-schedule-tasks.md)| Describes the best practices, location, values, and security considerations for the **Domain controller: Allow server operators to schedule tasks** security policy setting. | | [Domain controller: LDAP server signing requirements](domain-controller-ldap-server-signing-requirements.md)| Describes the best practices, location, values, and security considerations for the **Domain controller: LDAP server signing requirements** security policy setting. | -| [Domain controller: Refuse machine account password changes](domain-controller-refuse-machine-account-password-changes.md) | Describes the best practices, location, values, and security considerations for the **Domain controller: Refuse machine account password changes** security policy setting.| +| [Domain controller: Refuse machine account password changes](domain-controller-refuse-machine-account-password-changes.md) | Describes the best practices, location, values, and security considerations for the **Domain controller: Refuse machine account password changes** security policy setting.| | [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md) | Describes the best practices, location, values, and security considerations for the **Domain member: Digitally encrypt or sign secure channel data (always)** security policy setting. | | [Domain member: Digitally encrypt secure channel data (when possible)](domain-member-digitally-encrypt-secure-channel-data-when-possible.md)| Describes the best practices, location, values, and security considerations for the **Domain member: Digitally encrypt secure channel data (when possible)** security policy setting. | -| [Domain member: Digitally sign secure channel data (when possible)](domain-member-digitally-sign-secure-channel-data-when-possible.md)| Describes the best practices, location, values, and security considerations for the **Domain member: Digitally sign secure channel data (when possible)** security policy setting.| -| [Domain member: Disable machine account password changes](domain-member-disable-machine-account-password-changes.md)| Describes the best practices, location, values, and security considerations for the **Domain member: Disable machine account password changes** security policy setting. +| [Domain member: Digitally sign secure channel data (when possible)](domain-member-digitally-sign-secure-channel-data-when-possible.md)| Describes the best practices, location, values, and security considerations for the **Domain member: Digitally sign secure channel data (when possible)** security policy setting.| +| [Domain member: Disable machine account password changes](domain-member-disable-machine-account-password-changes.md)| Describes the best practices, location, values, and security considerations for the **Domain member: Disable machine account password changes** security policy setting.| | [Domain member: Maximum machine account password age](domain-member-maximum-machine-account-password-age.md) |Describes the best practices, location, values, and security considerations for the **Domain member: Maximum machine account password age** security policy setting.| |[Domain member: Require strong (Windows 2000 or later) session key](domain-member-require-strong-windows-2000-or-later-session-key.md)| Describes the best practices, location, values, and security considerations for the **Domain member: Require strong (Windows 2000 or later) session key** security policy setting. | | [Interactive logon: Display user information when the session is locked](interactive-logon-display-user-information-when-the-session-is-locked.md)| Describes the best practices, location, values, and security considerations for the **Interactive logon: Display user information when the session is locked** security policy setting. | -| [Interactive logon: Don't display last signed-in](interactive-logon-do-not-display-last-user-name.md)| Describes the best practices, location, values, and security considerations for the **Interactive logon: Don't display last signed-in** security policy setting.| -| [Interactive logon: Don't display username at sign-in](interactive-logon-dont-display-username-at-sign-in.md)| Describes the best practices, location, values, and security considerations for the **Interactive logon: Do not display username at sign-in** security policy setting.| -| [Interactive logon: Do not require CTRL+ALT+DEL](interactive-logon-do-not-require-ctrl-alt-del.md)| Describes the best practices, location, values, and security considerations for the **Interactive logon: Do not require CTRL+ALT+DEL** security policy setting.| -| [Interactive logon: Machine account lockout threshold](interactive-logon-machine-account-lockout-threshold.md) | Describes the best practices, location, values, management, and security considerations for the **Interactive logon: Machine account lockout threshold** security policy setting.| -| [Interactive logon: Machine inactivity limit](interactive-logon-machine-inactivity-limit.md)| Describes the best practices, location, values, management, and security considerations for the **Interactive logon: Machine inactivity limit** security policy setting.| +| [Interactive logon: Don't display last signed-in](interactive-logon-do-not-display-last-user-name.md)| Describes the best practices, location, values, and security considerations for the **Interactive logon: Don't display last signed-in** security policy setting.| +| [Interactive logon: Don't display username at sign-in](interactive-logon-dont-display-username-at-sign-in.md)| Describes the best practices, location, values, and security considerations for the **Interactive logon: Do not display username at sign-in** security policy setting.| +| [Interactive logon: Do not require CTRL+ALT+DEL](interactive-logon-do-not-require-ctrl-alt-del.md)| Describes the best practices, location, values, and security considerations for the **Interactive logon: Do not require CTRL+ALT+DEL** security policy setting.| +| [Interactive logon: Machine account lockout threshold](interactive-logon-machine-account-lockout-threshold.md) | Describes the best practices, location, values, management, and security considerations for the **Interactive logon: Machine account lockout threshold** security policy setting.| +| [Interactive logon: Machine inactivity limit](interactive-logon-machine-inactivity-limit.md)| Describes the best practices, location, values, management, and security considerations for the **Interactive logon: Machine inactivity limit** security policy setting.| | [Interactive logon: Message text for users attempting to log on](interactive-logon-message-text-for-users-attempting-to-log-on.md) | Describes the best practices, location, values, management, and security considerations for the **Interactive logon: Message text for users attempting to log on** security policy setting. | | [Interactive logon: Message title for users attempting to log on](interactive-logon-message-title-for-users-attempting-to-log-on.md)| Describes the best practices, location, values, policy management, and security considerations for the **Interactive logon: Message title for users attempting to log on** security policy setting. | | [Interactive logon: Number of previous logons to cache (in case domain controller is not available)](interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md)| Describes the best practices, location, values, policy management, and security considerations for the **Interactive logon: Number of previous logons to cache (in case domain controller is not available)** security policy setting. | | [Interactive logon: Prompt user to change password before expiration](interactive-logon-prompt-user-to-change-password-before-expiration.md)| Describes the best practices, location, values, policy management, and security considerations for the **Interactive logon: Prompt user to change password before expiration** security policy setting. | | [Interactive logon: Require Domain Controller authentication to unlock workstation](interactive-logon-require-domain-controller-authentication-to-unlock-workstation.md)| Describes the best practices, location, values, policy management, and security considerations for the **Interactive logon: Require Domain Controller authentication to unlock workstation** security policy setting. | -| [Interactive logon: Require smart card](interactive-logon-require-smart-card.md) | Describes the best practices, location, values, policy management, and security considerations for the **Interactive logon: Require smart card** security policy setting.| -| [Interactive logon: Smart card removal behavior](interactive-logon-smart-card-removal-behavior.md) | Describes the best practices, location, values, policy management, and security considerations for the **Interactive logon: Smart card removal behavior** security policy setting.| +| [Interactive logon: Require Windows Hello for Business or smart card](interactive-logon-require-smart-card.md) | Describes the best practices, location, values, policy management, and security considerations for the **Interactive logon: Require Windows Hello for Business or smart card** security policy setting.| +| [Interactive logon: Smart card removal behavior](interactive-logon-smart-card-removal-behavior.md) | Describes the best practices, location, values, policy management, and security considerations for the **Interactive logon: Smart card removal behavior** security policy setting.| | [Microsoft network client: Digitally sign communications (always)](microsoft-network-client-digitally-sign-communications-always.md) | Describes the best practices, location, values, policy management, and security considerations for the **Microsoft network client: Digitally sign communications (always)** security policy setting for SMBv3 and SMBv2. | -| [SMBv1 Microsoft network client: Digitally sign communications (always)](smbv1-microsoft-network-client-digitally-sign-communications-always.md) | Describes the best practices, location, values, policy management, and security considerations for the **Microsoft network client: Digitally sign communications (always)** security policy setting for SMBv1 only. | -| [SMBv1 Microsoft network client: Digitally sign communications (if server agrees)](smbv1-microsoft-network-client-digitally-sign-communications-if-server-agrees.md)| Describes the best practices, location, values, and security considerations for the **Microsoft network client: Digitally sign communications (if server agrees)** security policy setting for SMBv1 only. | | [Microsoft network client: Send unencrypted password to third-party SMB servers](microsoft-network-client-send-unencrypted-password-to-third-party-smb-servers.md)| Describes the best practices, location, values, policy management, and security considerations for the **Microsoft network client: Send unencrypted password to third-party SMB servers** security policy setting. | | [Microsoft network server: Amount of idle time required before suspending session](microsoft-network-server-amount-of-idle-time-required-before-suspending-session.md)| Describes the best practices, location, values, and security considerations for the **Microsoft network server: Amount of idle time required before suspending session** security policy setting. | | [Microsoft network server: Attempt S4U2Self to obtain claim information](microsoft-network-server-attempt-s4u2self-to-obtain-claim-information.md)| Describes the best practices, location, values, management, and security considerations for the **Microsoft network server: Attempt S4U2Self to obtain claim information** security policy setting. | -| [Microsoft network server: Digitally sign communications (always)](microsoft-network-server-digitally-sign-communications-always.md)| Describes the best practices, location, values, policy management, and security considerations for the **Microsoft network server: Digitally sign communications (always)** security policy setting for SMBv3 and SMBv2.| -| [SMBv1 Microsoft network server: Digitally sign communications (always)](smbv1-microsoft-network-server-digitally-sign-communications-always.md)| Describes the best practices, location, values, policy management, and security considerations for the **Microsoft network server: Digitally sign communications (always)** security policy setting for SMBv1 only.| -| [SMBv1 Microsoft network server: Digitally sign communications (if client agrees)](smbv1-microsoft-network-server-digitally-sign-communications-if-client-agrees.md)| Describes the best practices, location, values, policy management, and security considerations for the **Microsoft network server: Digitally sign communications (if client agrees)** security policy setting for SMBv1 only. | +| [Microsoft network server: Digitally sign communications (always)](microsoft-network-server-digitally-sign-communications-always.md)| Describes the best practices, location, values, policy management, and security considerations for the **Microsoft network server: Digitally sign communications (always)** security policy setting for SMBv3 and SMBv2.| | [Microsoft network server: Disconnect clients when logon hours expire](microsoft-network-server-disconnect-clients-when-logon-hours-expire.md)| Describes the best practices, location, values, and security considerations for the **Microsoft network server: Disconnect clients when logon hours expire** security policy setting. | | [Microsoft network server: Server SPN target name validation level](microsoft-network-server-server-spn-target-name-validation-level.md)| Describes the best practices, location, and values, policy management, and security considerations for the **Microsoft network server: Server SPN target name validation level** security policy setting. | -| [Network access: Allow anonymous SID/Name translation](network-access-allow-anonymous-sidname-translation.md)| Describes the best practices, location, values, policy management, and security considerations for the **Network access: Allow anonymous SID/Name translation** security policy setting.| +| [Network access: Allow anonymous SID/Name translation](network-access-allow-anonymous-sidname-translation.md)| Describes the best practices, location, values, policy management, and security considerations for the **Network access: Allow anonymous SID/Name translation** security policy setting.| | [Network access: Do not allow anonymous enumeration of SAM accounts](network-access-do-not-allow-anonymous-enumeration-of-sam-accounts.md)| Describes the best practices, location, values, and security considerations for the **Network access: Do not allow anonymous enumeration of SAM accounts** security policy setting. | | [Network access: Do not allow anonymous enumeration of SAM accounts and shares](network-access-do-not-allow-anonymous-enumeration-of-sam-accounts-and-shares.md)| Describes the best practices, location, values, and security considerations for the **Network access: Do not allow anonymous enumeration of SAM accounts and shares** security policy setting. | | [Network access: Do not allow storage of passwords and credentials for network authentication](network-access-do-not-allow-storage-of-passwords-and-credentials-for-network-authentication.md)| Describes the best practices, location, values, policy management, and security considerations for the **Network access: Do not allow storage of passwords and credentials for network authentication** security policy setting. | | [Network access: Let Everyone permissions apply to anonymous users](network-access-let-everyone-permissions-apply-to-anonymous-users.md)| Describes the best practices, location, values, policy management, and security considerations for the **Network access: Let Everyone permissions apply to anonymous users** security policy setting. | | [Network access: Named Pipes that can be accessed anonymously](network-access-named-pipes-that-can-be-accessed-anonymously.md)| Describes the best practices, location, values, policy management, and security considerations for the **Network access: Named Pipes that can be accessed anonymously** security policy setting. | -| [Network access: Remotely accessible registry paths](network-access-remotely-accessible-registry-paths.md)| Describes the best practices, location, values, policy management, and security considerations for the **Network access: Remotely accessible registry paths** security policy setting.| +| [Network access: Remotely accessible registry paths](network-access-remotely-accessible-registry-paths.md)| Describes the best practices, location, values, policy management, and security considerations for the **Network access: Remotely accessible registry paths** security policy setting.| | [Network access: Remotely accessible registry paths and subpaths](network-access-remotely-accessible-registry-paths-and-subpaths.md)| Describes the best practices, location, values, and security considerations for the **Network access: Remotely accessible registry paths and subpaths** security policy setting. | | [Network access: Restrict anonymous access to Named Pipes and Shares](network-access-restrict-anonymous-access-to-named-pipes-and-shares.md)| Describes the best practices, location, values, policy management, and security considerations for the **Network access: Restrict anonymous access to Named Pipes and Shares** security policy setting. | | [Network access: Restrict clients allowed to make remote calls to SAM](network-access-restrict-clients-allowed-to-make-remote-sam-calls.md)| Describes the best practices, location, values, policy management, and security considerations for the **Network access: Restrict clients allowed to make remote calls to SAM** security policy setting. | | [Network access: Shares that can be accessed anonymously](network-access-shares-that-can-be-accessed-anonymously.md)| Describes the best practices, location, values, policy management, and security considerations for the **Network access: Shares that can be accessed anonymously** security policy setting. | | [Network access: Sharing and security model for local accounts](network-access-sharing-and-security-model-for-local-accounts.md)| Describes the best practices, location, values, policy management, and security considerations for the **Network access: Sharing and security model for local accounts** security policy setting. | | [Network security: Allow Local System to use computer identity for NTLM](network-security-allow-local-system-to-use-computer-identity-for-ntlm.md)| Describes the location, values, policy management, and security considerations for the **Network security: Allow Local System to use computer identity for NTLM** security policy setting. | -| [Network security: Allow LocalSystem NULL session fallback](network-security-allow-localsystem-null-session-fallback.md)| Describes the best practices, location, values, and security considerations for the **Network security: Allow LocalSystem NULL session fallback** security policy setting.| +| [Network security: Allow LocalSystem NULL session fallback](network-security-allow-localsystem-null-session-fallback.md)| Describes the best practices, location, values, and security considerations for the **Network security: Allow LocalSystem NULL session fallback** security policy setting.| | [Network security: Allow PKU2U authentication requests to this computer to use online identities](network-security-allow-pku2u-authentication-requests-to-this-computer-to-use-online-identities.md)| Describes the best practices, location, and values for the **Network Security: Allow PKU2U authentication requests to this computer to use online identities** security policy setting. | | [Network security: Configure encryption types allowed for Kerberos Win7 only](network-security-configure-encryption-types-allowed-for-kerberos.md)| Describes the best practices, location, values, and security considerations for the **Network security: Configure encryption types allowed for Kerberos Win7 only** security policy setting. | | [Network security: Do not store LAN Manager hash value on next password change](network-security-do-not-store-lan-manager-hash-value-on-next-password-change.md)| Describes the best practices, location, values, policy management, and security considerations for the **Network security: Do not store LAN Manager hash value on next password change** security policy setting. | | [Network security: Force logoff when logon hours expire](network-security-force-logoff-when-logon-hours-expire.md)| Describes the best practices, location, values, policy management, and security considerations for the **Network security: Force logoff when logon hours expire** security policy setting. | -| [Network security: LAN Manager authentication level](network-security-lan-manager-authentication-level.md)| Describes the best practices, location, values, policy management, and security considerations for the **Network security: LAN Manager authentication level** security policy setting.| +| [Network security: LAN Manager authentication level](network-security-lan-manager-authentication-level.md)| Describes the best practices, location, values, policy management, and security considerations for the **Network security: LAN Manager authentication level** security policy setting.| | [Network security: LDAP client signing requirements](network-security-ldap-client-signing-requirements.md) | This security policy reference topic for the IT professional describes the best practices, location, values, policy management, and security considerations for this policy setting. This information applies to computers running at least the Windows Server 2008 operating system. | | [Network security: Minimum session security for NTLM SSP based (including secure RPC) clients](network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-clients.md)| Describes the best practices, location, values, policy management, and security considerations for the **Network security: Minimum session security for NTLM SSP based (including secure RPC) clients** security policy setting. | | [Network security: Minimum session security for NTLM SSP based (including secure RPC) servers](network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-servers.md)| Describes the best practices, location, values, policy management, and security considerations for the **Network security: Minimum session security for NTLM SSP based (including secure RPC) servers** security policy setting. | @@ -116,12 +109,12 @@ For info about setting security policies, see [Configure security policy setting | [Recovery console: Allow automatic administrative logon](recovery-console-allow-automatic-administrative-logon.md)| Describes the best practices, location, values, policy management, and security considerations for the **Recovery console: Allow automatic administrative logon** security policy setting. | | [Recovery console: Allow floppy copy and access to all drives and folders](recovery-console-allow-floppy-copy-and-access-to-all-drives-and-folders.md)| Describes the best practices, location, values, policy management, and security considerations for the **Recovery console: Allow floppy copy and access to all drives and folders** security policy setting. | | [Shutdown: Allow system to be shut down without having to lg on](shutdown-allow-system-to-be-shut-down-without-having-to-log-on.md)| Describes the best practices, location, values, policy management, and security considerations for the **Shutdown: Allow system to be shut down without having to log on** security policy setting. | -| [Shutdown: Clear virtual memory pagefile](shutdown-clear-virtual-memory-pagefile.md)| Describes the best practices, location, values, policy management, and security considerations for the **Shutdown: Clear virtual memory pagefile** security policy setting.| +| [Shutdown: Clear virtual memory pagefile](shutdown-clear-virtual-memory-pagefile.md)| Describes the best practices, location, values, policy management, and security considerations for the **Shutdown: Clear virtual memory pagefile** security policy setting.| | [System cryptography: Force strong key protection for user keys stored on the computer](system-cryptography-force-strong-key-protection-for-user-keys-stored-on-the-computer.md)| Describes the best practices, location, values, policy management, and security considerations for the **System cryptography: Force strong key protection for user keys stored on the computer** security policy setting. | | [System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing](system-cryptography-use-fips-compliant-algorithms-for-encryption-hashing-and-signing.md)| This security policy reference topic for the IT professional describes the best practices, location, values, policy management, and security considerations for this policy setting. | | [System objects: Require case insensitivity for non-Windows subsystems](system-objects-require-case-insensitivity-for-non-windows-subsystems.md)| Describes the best practices, location, values, policy management, and security considerations for the **System objects: Require case insensitivity for non-Windows subsystems** security policy setting. | | [System objects: Strengthen default permissions of internal system objects (e.g. Symbolic Links)](system-objects-strengthen-default-permissions-of-internal-system-objects.md)| Describes the best practices, location, values, policy management, and security considerations for the **System objects: Strengthen default permissions of internal system objects (for example, Symbolic Links)** security policy setting. | -| [System settings: Optional subsystems](system-settings-optional-subsystems.md) | Describes the best practices, location, values, policy management, and security considerations for the **System settings: Optional subsystems** security policy setting.| +| [System settings: Optional subsystems](system-settings-optional-subsystems.md) | Describes the best practices, location, values, policy management, and security considerations for the **System settings: Optional subsystems** security policy setting.| | [System settings: Use certificate rules on Windows executables for Software Restriction Policies](system-settings-use-certificate-rules-on-windows-executables-for-software-restriction-policies.md)| Describes the best practices, location, values, policy management, and security considerations for the **System settings: Use certificate rules on Windows executables for Software Restriction Policies** security policy setting. | | [User Account Control: Admin Approval Mode for the Built-in Administrator account](user-account-control-admin-approval-mode-for-the-built-in-administrator-account.md)| Describes the best practices, location, values, policy management, and security considerations for the **User Account Control: Admin Approval Mode for the Built-in Administrator account** security policy setting. | | [User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop](user-account-control-allow-uiaccess-applications-to-prompt-for-elevation-without-using-the-secure-desktop.md)| Describes the best practices, location, values, and security considerations for the **User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop** security policy setting. | @@ -133,7 +126,7 @@ For info about setting security policies, see [Configure security policy setting | [User Account Control: Run all administrators in Admin Approval Mode](user-account-control-run-all-administrators-in-admin-approval-mode.md)| Describes the best practices, location, values, policy management, and security considerations for the **User Account Control: Run all administrators in Admin Approval Mode** security policy setting. | | [User Account Control: Switch to the secure desktop when prompting for elevation](user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md)| Describes the best practices, location, values, policy management, and security considerations for the **User Account Control: Switch to the secure desktop when prompting for elevation** security policy setting. | | [User Account Control: Virtualize file and registry write failures to per-user locations](user-account-control-virtualize-file-and-registry-write-failures-to-per-user-locations.md)| Describes the best practices, location, values, policy management, and security considerations for the **User Account Control: Virtualize file and registry write failures to per-user locations** security policy setting. | - + ## Related articles - [Security policy settings reference](security-policy-settings-reference.md) diff --git a/windows/security/threat-protection/security-policy-settings/shut-down-the-system.md b/windows/security/threat-protection/security-policy-settings/shut-down-the-system.md index b2bd961eea..e238e91c99 100644 --- a/windows/security/threat-protection/security-policy-settings/shut-down-the-system.md +++ b/windows/security/threat-protection/security-policy-settings/shut-down-the-system.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Shut down the system - security policy setting **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Shut down the system** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/shutdown-allow-system-to-be-shut-down-without-having-to-log-on.md b/windows/security/threat-protection/security-policy-settings/shutdown-allow-system-to-be-shut-down-without-having-to-log-on.md index 6fe3056930..e0fa746d50 100644 --- a/windows/security/threat-protection/security-policy-settings/shutdown-allow-system-to-be-shut-down-without-having-to-log-on.md +++ b/windows/security/threat-protection/security-policy-settings/shutdown-allow-system-to-be-shut-down-without-having-to-log-on.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Shutdown: Allow system to be shut down without having to log on **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Shutdown: Allow system to be shut down without having to log on** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/shutdown-clear-virtual-memory-pagefile.md b/windows/security/threat-protection/security-policy-settings/shutdown-clear-virtual-memory-pagefile.md index 4b773d0043..24a66f59c2 100644 --- a/windows/security/threat-protection/security-policy-settings/shutdown-clear-virtual-memory-pagefile.md +++ b/windows/security/threat-protection/security-policy-settings/shutdown-clear-virtual-memory-pagefile.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Shutdown: Clear virtual memory pagefile **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management and security considerations for the **Shutdown: Clear virtual memory pagefile** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-client-digitally-sign-communications-always.md b/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-client-digitally-sign-communications-always.md deleted file mode 100644 index 99e2eca53e..0000000000 --- a/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-client-digitally-sign-communications-always.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -title: Always sign SMBv1 network client communications (Windows 10) -description: Learn about best practices, security considerations and more for the security policy setting, Microsoft network client Digitally sign communications (always). -ms.assetid: 4b7b0298-b130-40f8-960d-60418ba85f76 -ms.reviewer: -ms.author: vinpa -ms.prod: windows-client -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: conceptual -ms.date: 01/04/2019 -ms.technology: itpro-security ---- - -# SMBv1 Microsoft network client: Digitally sign communications (always) - -**Applies to** -- Windows 10 - -This topic is about the Server Message Block (SMB) v1 protocol. SMBv1 isn't secure and has been deprecated in Windows. Beginning with Windows 10 Fall Creators Update and Windows Server, version 1709, [SMBv1 isn't installed by default](/windows-server/storage/file-server/troubleshoot/smbv1-not-installed-by-default-in-windows). - -The rest of this topic describes the best practices, location, values, policy management and security considerations for the **Microsoft network client: Digitally sign communications (always)** security policy setting only for SMBv1. The same policy setting can be applied to computers that run SMBv2. For more information, see [Microsoft network client: Digitally sign communications (always)](microsoft-network-client-digitally-sign-communications-always.md). - -## Reference - -The Server Message Block (SMB) protocol provides the basis for file and print sharing and many other networking operations, such as remote Windows administration. To prevent man-in-the-middle attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets. -This policy setting determines whether SMB packet signing must be negotiated before further communication with the Server service is permitted. - -Implementation of digital signatures in high-security networks helps prevent the impersonation of client computers and servers, which is known as "session hijacking." But misuse of these policy settings is a common error that can cause data loss or problems with data access or security. - -If server-side SMB signing is required, a client device won't be able to establish a session with that server, unless it has client-side SMB signing enabled. By default, client-side SMB signing is enabled on workstations, servers, and domain controllers. Similarly, if client-side SMB signing is required, that client device won't be able to establish a session with servers that don't have packet signing enabled. By default, server-side SMB signing is enabled only on domain controllers. - -If server-side SMB signing is enabled, SMB packet signing will be negotiated with client computers that have SMB signing enabled. - -[!INCLUDE [smb1-perf-note](includes/smb1-perf-note.md)] - -There are three other policy settings that relate to packet-signing requirements for Server Message Block (SMB) communications: -- [Microsoft network server: Digitally sign communications (always)](smbv1-microsoft-network-server-digitally-sign-communications-always.md) -- [Microsoft network client: Digitally sign communications (if server agrees)](smbv1-microsoft-network-client-digitally-sign-communications-if-server-agrees.md) -- [Microsoft network server: Digitally sign communications (if client agrees)](smbv1-microsoft-network-server-digitally-sign-communications-if-client-agrees.md) - -### Possible values - -- Enabled -- Disabled -- Not defined - -### Best practices - -1. Configure the following security policy settings as follows: - - - Disable **Microsoft network client: Digitally sign communications (always)**. - - Disable [Microsoft network server: Digitally sign communications (always)](smbv1-microsoft-network-server-digitally-sign-communications-always.md). - - Enable [Microsoft network client: Digitally sign communications (if server agrees)](smbv1-microsoft-network-client-digitally-sign-communications-if-server-agrees.md). - - Enable [Microsoft network server: Digitally sign communications (if client agrees)](smbv1-microsoft-network-server-digitally-sign-communications-if-client-agrees.md). - -2. Alternately, you can set all of these policy settings to Enabled, but enabling them can cause slower performance on client devices and prevent them from communicating with legacy SMB applications and operating systems. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Disabled| -| DC Effective Default Settings | Disabled| -| Member Server Effective Default Settings | Disabled| -| Client Computer Effective Default Settings | Disabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Session hijacking uses tools that allow attackers who have access to the same network as the client device or server to interrupt, end, or steal a session in progress. Attackers can potentially intercept and modify unsigned Server Message Block (SMB) packets and then modify the traffic and forward it so that the server might perform objectionable actions. Alternatively, the attacker could pose as the server or client computer after legitimate authentication, and gain unauthorized access to data. - -SMB is the resource-sharing protocol that is supported by many Windows operating systems. It's the basis of NetBIOS and many other protocols. SMB signatures authenticate users and the servers that host the data. If either side fails the authentication process, data transmission doesn't take place. - -### Countermeasure - -Configure the settings as follows: - -- Disable **Microsoft network client: Digitally sign communications (always)**. -- Disable [Microsoft network server: Digitally sign communications (always)](smbv1-microsoft-network-server-digitally-sign-communications-always.md). -- Enable [Microsoft network client: Digitally sign communications (if server agrees)](smbv1-microsoft-network-client-digitally-sign-communications-if-server-agrees.md). -- Enable [Microsoft network server: Digitally sign communications (if client agrees)](smbv1-microsoft-network-server-digitally-sign-communications-if-client-agrees.md). - -In highly secure environments, we recommend that you configure all of these settings to Enabled. However, that configuration may cause slower performance on client devices and prevent communications with earlier SMB applications and operating systems. - ->**Note:**  An alternative countermeasure that could protect all network traffic is to implement digital signatures with IPsec. There are hardware-based accelerators for IPsec encryption and signing that could be used to minimize the performance impact on the servers' CPUs. No such accelerators are available for SMB signing. - -### Potential impact - -Implementations of the SMB file and print-sharing protocol support mutual authentication. This mutual authentication prevents session hijacking attacks and supports message authentication to prevent man-in-the-middle attacks. SMB signing provides this authentication by placing a digital signature into each SMB, which is then verified by the client and the server. - -Implementation of SMB signing may negatively affect performance because each packet must be signed and verified. If these settings are enabled on a server that is performing multiple roles, such as a small business server that is serving as a domain controller, file server, print server, and application server, performance may be substantially slowed. Additionally, if you configure devices to ignore all unsigned SMB communications, older applications and operating systems can't connect. However, if you completely disable all SMB signing, computers are vulnerable to session-hijacking attacks. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-client-digitally-sign-communications-if-server-agrees.md b/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-client-digitally-sign-communications-if-server-agrees.md deleted file mode 100644 index b4ac13d05a..0000000000 --- a/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-client-digitally-sign-communications-if-server-agrees.md +++ /dev/null @@ -1,122 +0,0 @@ ---- -title: SMBv1 Microsoft network client Digitally sign communications (if server agrees) (Windows 10) -description: Best practices, location, values, and security considerations for the policy setting, Microsoft network client Digitally sign communications (if server agrees). -ms.assetid: e553f700-aae5-425c-8650-f251c90ba5dd -ms.reviewer: -ms.author: vinpa -ms.prod: windows-client -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: conceptual -ms.date: 01/04/2019 -ms.technology: itpro-security ---- -# SMBv1 Microsoft network client: Digitally sign communications (if server agrees) - -**Applies to** -- Windows 10 - -This topic is about the Server Message Block (SMB) v1 protocol. SMBv1 isn't secure and has been deprecated in Windows. Beginning with Windows 10 Fall Creators Update and Windows Server, version 1709, [SMBv1 isn't installed by default](/windows-server/storage/file-server/troubleshoot/smbv1-not-installed-by-default-in-windows). - -The rest of this topic describes the best practices, location, values, and security considerations for the **Microsoft network client: Digitally sign communications (if server agrees)** security policy setting only for SMBv1. The same policy setting can be applied to computers that run SMBv2. For more information, see [Microsoft network client: Digitally sign communications (if server agrees)](microsoft-network-client-digitally-sign-communications-always.md). - -## Reference - -The Server Message Block (SMB) protocol provides the basis for Microsoft file and print sharing and many other networking operations, such as remote Windows administration. To prevent man-in-the-middle attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets. This policy setting determines whether SMB packet signing must be negotiated before further communication with the Server service is permitted. - -Implementation of digital signatures in high-security networks helps to prevent the impersonation of client computers and servers, which is known as "session hijacking." But misuse of these policy settings is a common error that can cause data loss or problems with data access or security. - -If server-side SMB signing is required, a client computer won't be able to establish a session with that server, unless it has client-side SMB signing enabled. By default, client-side SMB signing is enabled on workstations, servers, and domain controllers. Similarly, if client-side SMB signing is required, that client device won't be able to establish a session with servers that don't have packet signing enabled. By default, server-side SMB signing is enabled only on domain controllers. - -If server-side SMB signing is enabled, SMB packet signing will be negotiated with client computers that have SMB signing enabled. - -[!INCLUDE [smb1-perf-note](includes/smb1-perf-note.md)] - -There are three other policy settings that relate to packet-signing requirements for Server Message Block (SMB) communications: - -- [Microsoft network server: Digitally sign communications (always)](smbv1-microsoft-network-server-digitally-sign-communications-always.md) -- [Microsoft network client: Digitally sign communications (always)](smbv1-microsoft-network-client-digitally-sign-communications-always.md) -- [Microsoft network server: Digitally sign communications (if client agrees)](smbv1-microsoft-network-server-digitally-sign-communications-if-client-agrees.md) - -### Possible values - -- Enabled -- Disabled -- Not defined - -### Best practices - - - Configure the following security policy settings as follows: - - - Disable [Microsoft network client: Digitally sign communications (always)](smbv1-microsoft-network-client-digitally-sign-communications-always.md). - - Disable [Microsoft network server: Digitally sign communications (always)](smbv1-microsoft-network-server-digitally-sign-communications-always.md). - - Enable **Microsoft Network Client: Digitally Sign Communications (If Server Agrees)**. - - Enable [Microsoft network server: Digitally sign communications (if client agrees)](smbv1-microsoft-network-server-digitally-sign-communications-if-client-agrees.md). - - - Alternately, you can set all of these policy settings to Enabled, but enabling them can cause slower performance on client devices and prevent them from communicating with legacy SMB applications and operating systems. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Enabled| -| DC Effective Default Settings | Enabled| -| Member Server Effective Default Settings| Enabled| -| Client Computer Effective Default Settings | Enabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Session hijacking uses tools that allow attackers who have access to the same network as the client or server to interrupt, end, or steal a session in progress. Attackers can potentially intercept and modify unsigned Server Message Block (SMB) packets and then modify the traffic and forward it so -that the server might perform objectionable actions. Alternatively, the attacker could pose as the server or client device after legitimate authentication and gain unauthorized access to data. - -SMB is the resource-sharing protocol that is supported by many Windows operating systems. It's the basis of NetBIOS and many other protocols. SMB signatures authenticate users and the servers that host the data. If either side fails the authentication process, data transmission doesn't take place. - -### Countermeasure - -Configure the settings as follows: - -- Disable [Microsoft network client: Digitally sign communications (always)](smbv1-microsoft-network-client-digitally-sign-communications-always.md). -- Disable [Microsoft network server: Digitally sign communications (always)](smbv1-microsoft-network-server-digitally-sign-communications-always.md). -- Enable **Microsoft network client: Digitally sign communications (if server agrees)**. -- Enable [Microsoft network server: Digitally sign communications (if client agrees)](smbv1-microsoft-network-server-digitally-sign-communications-if-client-agrees.md). - -In highly secure environments, we recommend that you configure all of these settings to Enabled. However, that configuration may cause slower performance on client devices and prevent communications with earlier SMB applications and operating systems. - -> [!NOTE] -> An alternative countermeasure that could protect all network traffic is to implement digital signatures with IPsec. There are hardware-based accelerators for IPsec encryption and signing that could be used to minimize the performance impact on the servers' CPUs. No such accelerators are available for SMB signing. - -### Potential impact - -Implementations of the SMB file and print-sharing protocol support mutual authentication. This mutual authentication prevents session hijacking attacks and supports message authentication to prevent man-in-the-middle attacks. SMB signing provides this authentication by placing a digital signature into each SMB, which is then verified by the client and the server. - -Implementation of SMB signing may negatively affect performance because each packet must be signed and verified. If these settings are enabled on a server that is performing multiple roles, such as a small business server that is serving as a domain controller, file server, print server, and application server, performance may be substantially slowed. Additionally, if you configure devices to ignore all unsigned SMB communications, older applications and operating systems can't connect. However, if you completely disable all SMB signing, devices are vulnerable to session-hijacking -attacks. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-server-digitally-sign-communications-always.md b/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-server-digitally-sign-communications-always.md deleted file mode 100644 index 45b7731eb7..0000000000 --- a/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-server-digitally-sign-communications-always.md +++ /dev/null @@ -1,123 +0,0 @@ ---- -title: SMB v1 Microsoft network server Digitally sign communications (always) (Windows 10) -description: Best practices, security considerations, and more for the security policy setting, Microsoft network server Digitally sign communications (always). -ms.assetid: 2007b622-7bc2-44e8-9cf1-d34b62117ea8 -ms.reviewer: -ms.author: vinpa -ms.prod: windows-client -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: conceptual -ms.date: 01/04/2019 -ms.technology: itpro-security ---- - -# SMB v1 Microsoft network server: Digitally sign communications (always) - -**Applies to** -- Windows 10 - -This topic is about the Server Message Block (SMB) v1 protocol. SMBv1 isn't secure and has been deprecated in Windows. Beginning with Windows 10 Fall Creators Update and Windows Server, version 1709, [SMB v1 isn't installed by default](/windows-server/storage/file-server/troubleshoot/smbv1-not-installed-by-default-in-windows). - -The rest of this topic describes the best practices, location, values, policy management and security considerations for the **Microsoft network server: Digitally sign communications (always)** security policy setting only for SMBv1. The same policy setting can be applied to computers that run SMBv2. Fore more information, see [Microsoft network server: Digitally sign communications (always)](microsoft-network-server-digitally-sign-communications-always.md). - -## Reference - -The Server Message Block (SMB) protocol provides the basis for file and print sharing and many other networking operations, such as remote Windows administration. To prevent man-in-the-middle attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets. -This policy setting determines whether SMB packet signing must be negotiated before further communication with the Server service is permitted. - -Implementation of digital signatures in high-security networks helps to prevent the impersonation of client computers and servers, which is known as "session hijacking." But misuse of these policy settings is a common error that can cause data loss or problems with data access or security. - -For this policy to take effect on computers running Windows 2000, client-side packet signing must also be enabled. To enable client-side SMB packet signing, set [Microsoft network client: Digitally sign communications (if server agrees)](smbv1-microsoft-network-client-digitally-sign-communications-if-server-agrees.md). Devices that have this policy set won't be able to communicate with devices that don't have server-side packet signing enabled. By default, server-side packet signing is enabled only on domain controllers. Server-side packet signing can be enabled on devices by setting [Microsoft network server: Digitally sign communications (if client agrees)](smbv1-microsoft-network-server-digitally-sign-communications-if-client-agrees.md). - -If server-side SMB signing is required, a client device won't be able to establish a session with that server, unless it has client-side SMB signing enabled. By default, client-side SMB signing is enabled on workstations, servers, and domain controllers. Similarly, if client-side SMB signing is required, that client device won't be able to establish a session with servers that don't have packet signing enabled. By default, server-side SMB signing is enabled only on domain controllers. - -If server-side SMB signing is enabled, SMB packet signing will be negotiated with client devices that have SMB signing enabled. - -[!INCLUDE [smb1-perf-note](includes/smb1-perf-note.md)] - -There are three other policy settings that relate to packet-signing requirements for Server Message Block (SMB) communications: - -- [Microsoft network client: Digitally sign communications (always)](smbv1-microsoft-network-client-digitally-sign-communications-always.md) -- [Microsoft network client: Digitally sign communications (if server agrees)](smbv1-microsoft-network-client-digitally-sign-communications-if-server-agrees.md) -- [Microsoft network server: Digitally sign communications (if client agrees)](smbv1-microsoft-network-server-digitally-sign-communications-if-client-agrees.md) - -### Possible values - -- Enabled -- Disabled -- Not defined - -### Best practices - -1. Configure the following security policy settings as follows: - - - Disable [Microsoft network client: Digitally sign communications (always)](smbv1-microsoft-network-client-digitally-sign-communications-always.md). - - Disable **Microsoft network server: Digitally sign communications (always)**. - - Enable [Microsoft network client: Digitally sign communications (if server agrees)](smbv1-microsoft-network-client-digitally-sign-communications-if-server-agrees.md). - - Enable [Microsoft network server: Digitally sign communications (if client agrees)](smbv1-microsoft-network-server-digitally-sign-communications-if-client-agrees.md). - -2. Alternately, you can set all of these policy settings to Enabled, but enabling them can cause slower performance on client devices and prevent them from communicating with legacy SMB applications and operating systems. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Enabled| -| Stand-Alone Server Default Settings | Not defined| -| DC Effective Default Settings | Enabled| -| Member Server Effective Default Settings| Not defined| -| Client Computer Effective Default Settings | Disabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Session hijacking uses tools that allow attackers who have access to the same network as the client device or server to interrupt, end, or steal a session in progress. Attackers can potentially intercept and modify unsigned Server Message Block (SMB) packets and then modify the traffic and forward it so that the server might perform objectionable actions. Alternatively, the attacker could pose as the server or client device after legitimate authentication and gain unauthorized access to data. - -SMB is the resource-sharing protocol that is supported by many Windows operating systems. It's the basis of NetBIOS and many other protocols. SMB signatures authenticate users and the servers that host the data. If either side fails the authentication process, data transmission doesn't take place. - -### Countermeasure - -Configure the settings as follows: - -- Disable [Microsoft network client: Digitally sign communications (always)](smbv1-microsoft-network-client-digitally-sign-communications-always.md). -- Disable **Microsoft network server: Digitally sign communications (always)**. -- Enable [Microsoft network client: Digitally sign communications (if server agrees)](smbv1-microsoft-network-client-digitally-sign-communications-if-server-agrees.md). -- Enable [Microsoft network server: Digitally sign communications (if client agrees)](smbv1-microsoft-network-server-digitally-sign-communications-if-client-agrees.md). - -In highly secure environments, we recommend that you configure all of these settings to Enabled. However, that configuration may cause slower performance on client devices and prevent communications with earlier SMB applications and operating systems. - ->**Note:**  An alternative countermeasure that could protect all network traffic is to implement digital signatures with IPsec. There are hardware-based accelerators for IPsec encryption and signing that could be used to minimize the performance impact on the servers' CPUs. No such accelerators are available for SMB signing. - -### Potential impact - -Implementations of the SMB file and print-sharing protocol support mutual authentication. This mutual authentication prevents session hijacking attacks and supports message authentication to prevent man-in-the-middle attacks. SMB signing provides this authentication by placing a digital signature into each SMB, which is then verified by the client and the server. - -Implementation of SMB signing may negatively affect performance because each packet must be signed and verified. If these settings are enabled on a server that is performing multiple roles, such as a small business server that is serving as a domain controller, file server, print server, and application server, performance may be substantially slowed. Additionally, if you configure computers to ignore all unsigned SMB communications, older applications and operating systems can't connect. However, if you completely disable all SMB signing, devices are vulnerable to session-hijacking attacks. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-server-digitally-sign-communications-if-client-agrees.md b/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-server-digitally-sign-communications-if-client-agrees.md deleted file mode 100644 index cf2feb9753..0000000000 --- a/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-server-digitally-sign-communications-if-client-agrees.md +++ /dev/null @@ -1,122 +0,0 @@ ---- -title: SMBv1 Microsoft network server Digitally sign communications (if client agrees) (Windows 10) -description: Best practices, security considerations and more for the security policy setting, Microsoft network server Digitally sign communications (if client agrees). -ms.assetid: c92b2e3d-1dbf-4337-a145-b17a585f4fc1 -ms.reviewer: -ms.author: vinpa -ms.prod: windows-client -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: conceptual -ms.date: 01/04/2019 -ms.technology: itpro-security ---- - -# SMBv1 Microsoft network server: Digitally sign communications (if client agrees) - -**Applies to** -- Windows 10 - -This topic is about the Server Message Block (SMB) v1 protocol. SMBv1 isn't secure and has been deprecated in Windows. Beginning with Windows 10 Fall Creators Update and Windows Server, version 1709, [SMBv1 isn't installed by default](/windows-server/storage/file-server/troubleshoot/smbv1-not-installed-by-default-in-windows). - -The rest of this topic describes the best practices, location, values, policy management and security considerations for the **Microsoft network server: Digitally sign communications (if client agrees)** security policy setting only for SMBv1. The same policy setting can be applied to computers that run SMBv2. For more information, see [Microsoft network server: Digitally sign communications (if client agrees)](microsoft-network-server-digitally-sign-communications-always.md). - -## Reference - -The Server Message Block (SMB) protocol provides the basis for file and print sharing and many other networking operations, such as remote Windows administration. To prevent man-in-the-middle attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets. -This policy setting determines whether SMB packet signing must be negotiated before further communication with the Server service is permitted. - -Implementation of digital signatures in high-security networks helps to prevent the impersonation of client computers and servers, which is known as "session hijacking." But misuse of these policy settings is a common error that can cause data loss or problems with data access or security. - -If server-side SMB signing is required, a client device won't be able to establish a session with that server, unless it has client-side SMB signing enabled. By default, client-side SMB signing is enabled on workstations, servers, and domain controllers. Similarly, if client-side SMB signing is required, that client device won't be able to establish a session with servers that don't have packet signing enabled. By default, server-side SMB signing is enabled only on domain controllers. - -If server-side SMB signing is enabled, SMB packet signing will be negotiated with client computers that have SMB signing enabled. - -[!INCLUDE [smb1-perf-note](includes/smb1-perf-note.md)] - -There are three other policy settings that relate to packet-signing requirements for Server Message Block (SMB) communications: - -- [Microsoft network server: Digitally sign communications (always)](smbv1-microsoft-network-server-digitally-sign-communications-always.md) -- [Microsoft network client: Digitally sign communications (if server agrees)](smbv1-microsoft-network-client-digitally-sign-communications-if-server-agrees.md) -- [Microsoft network client: Digitally sign communications (always)](smbv1-microsoft-network-client-digitally-sign-communications-always.md) - -### Possible values - -- Enabled -- Disabled -- Not defined - -### Best practices - -1. Configure the following security policy settings as follows: - - - Disable [Microsoft network client: Digitally sign communications (always)](smbv1-microsoft-network-client-digitally-sign-communications-always.md). - - Disable [Microsoft network server: Digitally sign communications (always)](smbv1-microsoft-network-server-digitally-sign-communications-always.md). - - Enable [Microsoft Network Client: Digitally Sign Communications (If Server Agrees)](smbv1-microsoft-network-server-digitally-sign-communications-always.md). - - Enable **Microsoft Network Server: Digitally Sign Communications (If Client Agrees)**. - -2. Alternately, you can set all of these policy settings to Enabled, but enabling them can cause slower performance on client devices and prevent them from communicating with legacy SMB applications and operating systems. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - - -| Server type or GPO Default value | -|--------------------------------------------| -| Default Domain Policy | -| Default Domain Controller Policy | -| Stand-Alone Server Default Settings | -| DC Effective Default Settings | -| Member Server Effective Default Settings | -| Client Computer Effective Default Settings | - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a computer restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Session hijacking uses tools that allow attackers who have access to the same network as the client device or server to interrupt, end, or steal a session in progress. Attackers can potentially intercept and modify unsigned Server Message Block (SMB) packets and then modify the traffic and forward it so that the server might perform objectionable actions. Alternatively, the attacker could pose as the server or client computer after legitimate authentication and gain unauthorized access to data. - -SMB is the resource-sharing protocol that is supported by many Windows operating systems. It's the basis of NetBIOS and many other protocols. SMB signatures authenticate users and the servers that host the data. If either side fails the authentication process, data transmission doesn't take place. - -### Countermeasure - -Configure the settings as follows: - -- Disable [Microsoft network client: Digitally sign communications (always)](smbv1-microsoft-network-client-digitally-sign-communications-always.md). -- Disable [Microsoft network server: Digitally sign communications (always)](smbv1-microsoft-network-server-digitally-sign-communications-always.md). -- Enable [Microsoft network client: Digitally sign communications (if server agrees)](smbv1-microsoft-network-client-digitally-sign-communications-if-server-agrees.md). -- Enable **Microsoft network server: Digitally sign communications (if client agrees)**. - -In highly secure environments, we recommend that you configure all of these settings to Enabled. However, that configuration may cause slower performance on client devices and prevent communications with earlier SMB applications and operating systems. - ->**Note:** An alternative countermeasure that could protect all network traffic is to implement digital signatures with IPsec. There are hardware-based accelerators for IPsec encryption and signing that could be used to minimize the performance impact on the servers' CPUs. No such accelerators are available for SMB signing. - -### Potential impact - -SMB file and print-sharing protocol support mutual authentication. This mutual authentication prevents session hijacking attacks and supports message authentication to prevent man-in-the-middle attacks. SMB signing provides this authentication by placing a digital signature into each SMB, which is then verified by the client and the server. - -Implementation of SMB signing may negatively affect performance because each packet must be signed and verified. If these settings are enabled on a server that is performing multiple roles, such as a small business server that is serving as a domain controller, file server, print server, and application server, performance may be substantially slowed. Additionally, if you configure computers to ignore all unsigned SMB communications, older applications and operating systems can't connect. However, if you completely disable all SMB signing, computers are vulnerable to session-hijacking attacks. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/synchronize-directory-service-data.md b/windows/security/threat-protection/security-policy-settings/synchronize-directory-service-data.md index f165400681..bfd1681088 100644 --- a/windows/security/threat-protection/security-policy-settings/synchronize-directory-service-data.md +++ b/windows/security/threat-protection/security-policy-settings/synchronize-directory-service-data.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Synchronize directory service data **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Synchronize directory service data** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/system-cryptography-force-strong-key-protection-for-user-keys-stored-on-the-computer.md b/windows/security/threat-protection/security-policy-settings/system-cryptography-force-strong-key-protection-for-user-keys-stored-on-the-computer.md index 8e1ac04319..8c12b88790 100644 --- a/windows/security/threat-protection/security-policy-settings/system-cryptography-force-strong-key-protection-for-user-keys-stored-on-the-computer.md +++ b/windows/security/threat-protection/security-policy-settings/system-cryptography-force-strong-key-protection-for-user-keys-stored-on-the-computer.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # System cryptography: Force strong key protection for user keys stored on the computer **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management and security considerations for the **System cryptography: Force strong key protection for user keys stored on the computer** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/system-cryptography-use-fips-compliant-algorithms-for-encryption-hashing-and-signing.md b/windows/security/threat-protection/security-policy-settings/system-cryptography-use-fips-compliant-algorithms-for-encryption-hashing-and-signing.md index 86ed35f4ec..f8f1af1c61 100644 --- a/windows/security/threat-protection/security-policy-settings/system-cryptography-use-fips-compliant-algorithms-for-encryption-hashing-and-signing.md +++ b/windows/security/threat-protection/security-policy-settings/system-cryptography-use-fips-compliant-algorithms-for-encryption-hashing-and-signing.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing **Applies to** +- Windows 11 - Windows 10 This security policy reference topic for the IT professional describes the best practices, location, values, policy management and security considerations for this policy setting. @@ -121,4 +122,4 @@ uses the RDP protocol to communicate with servers that run Terminal Services and ## Related topics -- [Security Options](security-options.md) \ No newline at end of file +- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/system-objects-require-case-insensitivity-for-non-windows-subsystems.md b/windows/security/threat-protection/security-policy-settings/system-objects-require-case-insensitivity-for-non-windows-subsystems.md index fb283fcb9b..e40e3772a0 100644 --- a/windows/security/threat-protection/security-policy-settings/system-objects-require-case-insensitivity-for-non-windows-subsystems.md +++ b/windows/security/threat-protection/security-policy-settings/system-objects-require-case-insensitivity-for-non-windows-subsystems.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # System objects: Require case insensitivity for non-Windows subsystems **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **System objects: Require case insensitivity for non-Windows subsystems** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/system-objects-strengthen-default-permissions-of-internal-system-objects.md b/windows/security/threat-protection/security-policy-settings/system-objects-strengthen-default-permissions-of-internal-system-objects.md index c4cc3fd368..3f5107710b 100644 --- a/windows/security/threat-protection/security-policy-settings/system-objects-strengthen-default-permissions-of-internal-system-objects.md +++ b/windows/security/threat-protection/security-policy-settings/system-objects-strengthen-default-permissions-of-internal-system-objects.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # System objects: Strengthen default permissions of internal system objects (for example, Symbolic Links) **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management and security considerations for the **System objects: Strengthen default permissions of internal system objects (e.g. Symbolic Links)** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/system-settings-optional-subsystems.md b/windows/security/threat-protection/security-policy-settings/system-settings-optional-subsystems.md index d287cf1d46..1634b509b2 100644 --- a/windows/security/threat-protection/security-policy-settings/system-settings-optional-subsystems.md +++ b/windows/security/threat-protection/security-policy-settings/system-settings-optional-subsystems.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # System settings: Optional subsystems **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **System settings: Optional subsystems** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/system-settings-use-certificate-rules-on-windows-executables-for-software-restriction-policies.md b/windows/security/threat-protection/security-policy-settings/system-settings-use-certificate-rules-on-windows-executables-for-software-restriction-policies.md index 4d194b9586..cce46ae1bc 100644 --- a/windows/security/threat-protection/security-policy-settings/system-settings-use-certificate-rules-on-windows-executables-for-software-restriction-policies.md +++ b/windows/security/threat-protection/security-policy-settings/system-settings-use-certificate-rules-on-windows-executables-for-software-restriction-policies.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # System settings: Use certificate rules on Windows executables for Software Restriction Policies **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management and security considerations for the **System settings: Use certificate rules on Windows executables for Software Restriction Policies** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/take-ownership-of-files-or-other-objects.md b/windows/security/threat-protection/security-policy-settings/take-ownership-of-files-or-other-objects.md index 279eeced74..4010dae1ca 100644 --- a/windows/security/threat-protection/security-policy-settings/take-ownership-of-files-or-other-objects.md +++ b/windows/security/threat-protection/security-policy-settings/take-ownership-of-files-or-other-objects.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # Take ownership of files or other objects **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **Take ownership of files or other objects** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/user-account-control-admin-approval-mode-for-the-built-in-administrator-account.md b/windows/security/threat-protection/security-policy-settings/user-account-control-admin-approval-mode-for-the-built-in-administrator-account.md index 73b7ad213e..21d8236c79 100644 --- a/windows/security/threat-protection/security-policy-settings/user-account-control-admin-approval-mode-for-the-built-in-administrator-account.md +++ b/windows/security/threat-protection/security-policy-settings/user-account-control-admin-approval-mode-for-the-built-in-administrator-account.md @@ -19,9 +19,10 @@ ms.technology: itpro-security # User Account Control: Admin Approval Mode for the Built-in Administrator account **Applies to** +- Windows 11 - Windows 10 -Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Admin Approval Mode for the Built-in Administrator account** security policy setting. +Describes the best practices, location, values, policy management, and security considerations for the **User Account Control: Admin Approval Mode for the Built-in Administrator account** security policy setting. ## Reference @@ -92,4 +93,4 @@ Enable the **User Account Control: Admin Approval Mode for the Built-in Administ Users who sign in by using the local administrator account are prompted for consent whenever a program requests an elevation in privilege. ## Related topics -- [Security Options](/windows/device-security/security-policy-settings/security-options) \ No newline at end of file +- [Security Options](/windows/device-security/security-policy-settings/security-options) diff --git a/windows/security/threat-protection/security-policy-settings/user-account-control-allow-uiaccess-applications-to-prompt-for-elevation-without-using-the-secure-desktop.md b/windows/security/threat-protection/security-policy-settings/user-account-control-allow-uiaccess-applications-to-prompt-for-elevation-without-using-the-secure-desktop.md index 541ed662b6..f5fc92749b 100644 --- a/windows/security/threat-protection/security-policy-settings/user-account-control-allow-uiaccess-applications-to-prompt-for-elevation-without-using-the-secure-desktop.md +++ b/windows/security/threat-protection/security-policy-settings/user-account-control-allow-uiaccess-applications-to-prompt-for-elevation-without-using-the-secure-desktop.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, and security considerations for the **User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode.md b/windows/security/threat-protection/security-policy-settings/user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode.md index b573193466..ce19aa2735 100644 --- a/windows/security/threat-protection/security-policy-settings/user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode.md +++ b/windows/security/threat-protection/security-policy-settings/user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode** security policy setting. @@ -113,4 +114,4 @@ Administrators should be made aware that they'll be prompted for consent when al ## Related topics -- [Security Options](/windows/device-security/security-policy-settings/security-options) \ No newline at end of file +- [Security Options](/windows/device-security/security-policy-settings/security-options) diff --git a/windows/security/threat-protection/security-policy-settings/user-account-control-behavior-of-the-elevation-prompt-for-standard-users.md b/windows/security/threat-protection/security-policy-settings/user-account-control-behavior-of-the-elevation-prompt-for-standard-users.md index cc56752bf0..aa32f66540 100644 --- a/windows/security/threat-protection/security-policy-settings/user-account-control-behavior-of-the-elevation-prompt-for-standard-users.md +++ b/windows/security/threat-protection/security-policy-settings/user-account-control-behavior-of-the-elevation-prompt-for-standard-users.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # User Account Control: Behavior of the elevation prompt for standard users **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Behavior of the elevation prompt for standard users** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/user-account-control-detect-application-installations-and-prompt-for-elevation.md b/windows/security/threat-protection/security-policy-settings/user-account-control-detect-application-installations-and-prompt-for-elevation.md index 9a76eb60a7..57b797bc2c 100644 --- a/windows/security/threat-protection/security-policy-settings/user-account-control-detect-application-installations-and-prompt-for-elevation.md +++ b/windows/security/threat-protection/security-policy-settings/user-account-control-detect-application-installations-and-prompt-for-elevation.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # User Account Control: Detect application installations and prompt for elevation **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Detect application installations and prompt for elevation** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/user-account-control-only-elevate-executables-that-are-signed-and-validated.md b/windows/security/threat-protection/security-policy-settings/user-account-control-only-elevate-executables-that-are-signed-and-validated.md index 5b94f9db23..674025df05 100644 --- a/windows/security/threat-protection/security-policy-settings/user-account-control-only-elevate-executables-that-are-signed-and-validated.md +++ b/windows/security/threat-protection/security-policy-settings/user-account-control-only-elevate-executables-that-are-signed-and-validated.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # User Account Control: Only elevate executables that are signed and validated **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **User Account Control: Only elevate executables that are signed and validated** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations.md b/windows/security/threat-protection/security-policy-settings/user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations.md index c181b31d00..8814018506 100644 --- a/windows/security/threat-protection/security-policy-settings/user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations.md +++ b/windows/security/threat-protection/security-policy-settings/user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # User Account Control: Only elevate UIAccess applications that are installed in secure locations **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management, and security considerations for the **User Account Control: Only elevate UIAccess applications that are installed in secure locations** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/user-account-control-run-all-administrators-in-admin-approval-mode.md b/windows/security/threat-protection/security-policy-settings/user-account-control-run-all-administrators-in-admin-approval-mode.md index 28bcf3d293..a206b627a3 100644 --- a/windows/security/threat-protection/security-policy-settings/user-account-control-run-all-administrators-in-admin-approval-mode.md +++ b/windows/security/threat-protection/security-policy-settings/user-account-control-run-all-administrators-in-admin-approval-mode.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # User Account Control: Run all administrators in Admin Approval Mode **Applies to** +- Windows 11 - Windows 10 This article describes the best practices, location, values, policy management and security considerations for the **User Account Control: Run all administrators in Admin Approval Mode** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md b/windows/security/threat-protection/security-policy-settings/user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md index 3e92e84352..c0fb6ba1cc 100644 --- a/windows/security/threat-protection/security-policy-settings/user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md +++ b/windows/security/threat-protection/security-policy-settings/user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # User Account Control: Switch to the secure desktop when prompting for elevation **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Switch to the secure desktop when prompting for elevation** security policy setting. diff --git a/windows/security/threat-protection/security-policy-settings/user-account-control-virtualize-file-and-registry-write-failures-to-per-user-locations.md b/windows/security/threat-protection/security-policy-settings/user-account-control-virtualize-file-and-registry-write-failures-to-per-user-locations.md index fe36fcdd30..678f1180d6 100644 --- a/windows/security/threat-protection/security-policy-settings/user-account-control-virtualize-file-and-registry-write-failures-to-per-user-locations.md +++ b/windows/security/threat-protection/security-policy-settings/user-account-control-virtualize-file-and-registry-write-failures-to-per-user-locations.md @@ -20,6 +20,7 @@ ms.technology: itpro-security # User Account Control: Virtualize file and registry write failures to per-user locations **Applies to** +- Windows 11 - Windows 10 Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Virtualize file and registry write failures to per-user locations** security policy setting. diff --git a/windows/security/threat-protection/windows-defender-application-control/deployment/deploy-wdac-policies-with-script.md b/windows/security/threat-protection/windows-defender-application-control/deployment/deploy-wdac-policies-with-script.md index da03a2f08c..ca978a53c0 100644 --- a/windows/security/threat-protection/windows-defender-application-control/deployment/deploy-wdac-policies-with-script.md +++ b/windows/security/threat-protection/windows-defender-application-control/deployment/deploy-wdac-policies-with-script.md @@ -9,7 +9,7 @@ ms.reviewer: aaroncz ms.author: jogeurte ms.manager: jsuther manager: aaroncz -ms.date: 12/03/2022 +ms.date: 01/23/2023 ms.technology: itpro-security ms.topic: article ms.localizationpriority: medium @@ -26,13 +26,18 @@ ms.localizationpriority: medium >[!NOTE] >Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability). -This article describes how to deploy Windows Defender Application Control (WDAC) policies using script. The instructions below use PowerShell but can work with any scripting host. +This article describes how to deploy Windows Defender Application Control (WDAC) policies using script. The following instructions use PowerShell but can work with any scripting host. You should now have one or more WDAC policies converted into binary form. If not, follow the steps described in [Deploying Windows Defender Application Control (WDAC) policies](/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-deployment-guide). +> [!IMPORTANT] +> Due to a known issue, you should always activate new **signed** WDAC Base policies with a reboot on systems with [**memory integrity**](/windows/security/threat-protection/device-guard/enable-virtualization-based-protection-of-code-integrity) enabled. Skip all steps below that use citool.exe, RefreshPolicy.exe, or WMI to initiate a policy activation. Instead, copy the policy binary to the correct system32 and EFI locations and then activate the policy with a system restart. +> +> This issue does not affect updates to signed Base policies that are already active on the system, deployment of unsigned policies, or deployment of supplemental policies (signed or unsigned). It also does not affect deployments to systems that are not running memory integrity. + ## Deploying policies for Windows 11 22H2 and above -You can use [citool.exe](/windows/security/threat-protection/windows-defender-application-control/operations/citool-commands) to apply policies on Windows 11 22H2 with the following commands. Be sure to replace **<Path to policy binary file to deploy>** in the example below with the actual path to your WDAC policy binary file. +You can use [citool.exe](/windows/security/threat-protection/windows-defender-application-control/operations/citool-commands) to apply policies on Windows 11 22H2 with the following commands. Be sure to replace **<Path to policy binary file to deploy>** in the following example with the actual path to your WDAC policy binary file. ```powershell # Policy binary files should be named as {GUID}.cip for multiple policy format files (where {GUID} = from the Policy XML) @@ -92,9 +97,9 @@ Use WMI to apply policies on all other versions of Windows and Windows Server. ## Deploying signed policies -If you are using [signed WDAC policies](/windows/security/threat-protection/windows-defender-application-control/use-signed-policies-to-protect-windows-defender-application-control-against-tampering), the policies must be deployed into your device's EFI partition in addition to the steps outlined above. Unsigned WDAC policies do not need to be present in the EFI partition. Deploying your policy via [Microsoft Intune](/windows/security/threat-protection/windows-defender-application-control/deploy-windows-defender-application-control-policies-using-intune) or the Application Control CSP will handle this step automatically. +If you're using [signed WDAC policies](/windows/security/threat-protection/windows-defender-application-control/use-signed-policies-to-protect-windows-defender-application-control-against-tampering), the policies must be deployed into your device's EFI partition in addition to the locations outlined in the earlier sections. Unsigned WDAC policies don't need to be present in the EFI partition. -1. Mount the EFI volume and make the directory, if it doesn't exist, in an elevated PowerShell prompt: +1. Mount the EFI volume and make the directory, if it doesn't exist, in an elevated PowerShell prompt: ```powershell $MountPoint = 'C:\EFIMount' diff --git a/windows/security/threat-protection/windows-defender-application-control/deployment/deploy-windows-defender-application-control-policies-using-group-policy.md b/windows/security/threat-protection/windows-defender-application-control/deployment/deploy-windows-defender-application-control-policies-using-group-policy.md index f0c1ff7b47..6562b00f12 100644 --- a/windows/security/threat-protection/windows-defender-application-control/deployment/deploy-windows-defender-application-control-policies-using-group-policy.md +++ b/windows/security/threat-protection/windows-defender-application-control/deployment/deploy-windows-defender-application-control-policies-using-group-policy.md @@ -13,7 +13,7 @@ author: jsuther1974 ms.reviewer: jogeurte ms.author: vinpa manager: aaroncz -ms.date: 10/06/2022 +ms.date: 01/23/2023 ms.technology: itpro-security ms.topic: article --- @@ -28,10 +28,16 @@ ms.topic: article > [!NOTE] > Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md). -> -> Group Policy-based deployment of Windows Defender Application Control policies only supports single-policy format WDAC policies. To use WDAC on devices running Windows 10 1903 and greater, or Windows 11, we recommend using an alternative method for policy deployment. -Single-policy format Windows Defender Application Control policies (pre-1903 policy schema) can be easily deployed and managed with Group Policy. +> [!IMPORTANT] +> Due to a known issue, you should always activate new **signed** WDAC Base policies *with a reboot* on systems with [**memory integrity**](/windows/security/threat-protection/device-guard/enable-virtualization-based-protection-of-code-integrity) enabled. Instead of Group Policy, deploy new signed WDAC Base policies [via script](/windows/security/threat-protection/windows-defender-application-control/deployment/deploy-wdac-policies-with-script#deploying-signed-policies) and activate the policy with a system restart. +> +> This issue does not affect updates to signed Base policies that are already active on the system, deployment of unsigned policies, or deployment of supplemental policies (signed or unsigned). It also does not affect deployments to systems that are not running memory integrity. + +Single-policy format Windows Defender Application Control policies (pre-1903 policy schema) can be easily deployed and managed with Group Policy. + +> [!IMPORTANT] +> Group Policy-based deployment of Windows Defender Application Control policies only supports single-policy format WDAC policies. To use WDAC on devices running Windows 10 1903 and greater, or Windows 11, we recommend using an alternative method for policy deployment. You should now have a WDAC policy converted into binary form. If not, follow the steps described in [Deploying Windows Defender Application Control (WDAC) policies](/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-deployment-guide). diff --git a/windows/security/threat-protection/windows-defender-application-control/deployment/deploy-windows-defender-application-control-policies-using-intune.md b/windows/security/threat-protection/windows-defender-application-control/deployment/deploy-windows-defender-application-control-policies-using-intune.md index 14716db117..804ef93a26 100644 --- a/windows/security/threat-protection/windows-defender-application-control/deployment/deploy-windows-defender-application-control-policies-using-intune.md +++ b/windows/security/threat-protection/windows-defender-application-control/deployment/deploy-windows-defender-application-control-policies-using-intune.md @@ -8,7 +8,7 @@ author: jsuther1974 ms.reviewer: jogeurte ms.author: vinpa manager: aaroncz -ms.date: 10/06/2022 +ms.date: 01/23/2023 ms.topic: how-to --- @@ -25,6 +25,11 @@ ms.topic: how-to You can use a Mobile Device Management (MDM) solution, like Microsoft Intune, to configure Windows Defender Application Control (WDAC) on client machines. Intune includes native support for WDAC, which can be a helpful starting point, but customers may find the available circle-of-trust options too limiting. To deploy a custom policy through Intune and define your own circle of trust, you can configure a profile using Custom OMA-URI. If your organization uses another MDM solution, check with your solution provider for WDAC policy deployment steps. +> [!IMPORTANT] +> Due to a known issue, you should always activate new **signed** WDAC Base policies *with a reboot* on systems with [**memory integrity**](/windows/security/threat-protection/device-guard/enable-virtualization-based-protection-of-code-integrity) enabled. Instead of Mobile Device Management (MDM), deploy new signed WDAC Base policies [via script](deploy-wdac-policies-with-script.md) and activate the policy with a system restart. +> +> This issue does not affect updates to signed Base policies that are already active on the system, deployment of unsigned policies, or deployment of supplemental policies (signed or unsigned). It also does not affect deployments to systems that are not running memory integrity. + ## Use Intune's built-in policies Intune's built-in Windows Defender Application Control support allows you to configure Windows client computers to only run: diff --git a/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md b/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md index d14c84c13f..9672782041 100644 --- a/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md +++ b/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md @@ -13,7 +13,7 @@ author: jgeurten ms.reviewer: jsuther1974 ms.author: vinpa manager: aaroncz -ms.date: 08/29/2022 +ms.date: 01/23/2023 ms.technology: itpro-security ms.topic: article --- @@ -96,7 +96,7 @@ Each file rule level has its benefit and disadvantage. Use Table 2 to select the | **FilePublisher** | This level combines the "FileName" attribute of the signed file, plus "Publisher" (PCA certificate with CN of leaf), plus a minimum version number. This option trusts specific files from the specified publisher, with a version at or above the specified version number. | | **LeafCertificate** | Adds trusted signers at the individual signing certificate level. The benefit of using this level versus the individual hash level is that new versions of the product will have different hash values but typically the same signing certificate. When this level is used, no policy update would be needed to run the new version of the application. However, leaf certificates have much shorter validity periods than other certificate levels, so the Windows Defender Application Control policy must be updated whenever these certificates change. | | **PcaCertificate** | Adds the highest available certificate in the provided certificate chain to signers. This level is typically one certificate below the root certificate because the scan doesn't validate anything beyond the certificates included in the provided signature (it doesn't go online or check local root stores). | -| **RootCertificate** | Currently unsupported. | +| **RootCertificate** | This level may produce an overly permissive policy and isn't recommended for most use cases. | | **WHQL** | Trusts binaries if they've been validated and signed by WHQL. This level is primarily for kernel binaries. | | **WHQLPublisher** | This level combines the WHQL level and the CN on the leaf certificate, and is primarily for kernel binaries. | | **WHQLFilePublisher** | Specifies that the binaries are validated and signed by WHQL, with a specific publisher (WHQLPublisher), and that the binary is the specified version or newer. This level is primarily for kernel binaries. | diff --git a/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-deployment-guide.md b/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-deployment-guide.md index 938e4370ae..a961918d5c 100644 --- a/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-deployment-guide.md +++ b/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-deployment-guide.md @@ -8,7 +8,7 @@ author: jgeurten ms.reviewer: aaroncz ms.author: jogeurte manager: jsuther -ms.date: 10/06/2022 +ms.date: 01/23/2023 ms.topic: overview --- @@ -55,6 +55,11 @@ All Windows Defender Application Control policy changes should be deployed in au ## Choose how to deploy WDAC policies +> [!IMPORTANT] +> Due to a known issue, you should always activate new **signed** WDAC Base policies with a reboot on systems with [**memory integrity**](/windows/security/threat-protection/device-guard/enable-virtualization-based-protection-of-code-integrity) enabled. We recommend [deploying via script](deployment/deploy-wdac-policies-with-script.md) in this case. +> +> This issue does not affect updates to signed Base policies that are already active on the system, deployment of unsigned policies, or deployment of supplemental policies (signed or unsigned). It also does not affect deployments to systems that are not running memory integrity. + There are several options to deploy Windows Defender Application Control policies to managed endpoints, including: - [Deploy using a Mobile Device Management (MDM) solution](deployment/deploy-windows-defender-application-control-policies-using-intune.md), such as Microsoft Intune diff --git a/windows/security/threat-protection/windows-firewall/configure-authentication-methods.md b/windows/security/threat-protection/windows-firewall/configure-authentication-methods.md index 60e8551837..eb155239ab 100644 --- a/windows/security/threat-protection/windows-firewall/configure-authentication-methods.md +++ b/windows/security/threat-protection/windows-firewall/configure-authentication-methods.md @@ -52,7 +52,7 @@ To complete these procedures, you must be a member of the Domain Administrators 4. **User (using Kerberos V5)**. Selecting this option tells the computer to use and require authentication of the currently signed-in user by using their domain credentials. - 5. **Computer certificate from this certification authority**. Selecting this option and entering the identification of a certification authority (CA) tells the computer to use and require authentication by using a certificate that is issued by the selected CA. If you also select **Accept only health certificates**, then only certificates that include the system health authentication enhanced key usage (EKU) typically provided in a Network Access Protection (NAP) infrastructure can be used for this rule. + 5. **Computer certificate from this certification authority**. Selecting this option and entering the identification of a certification authority (CA) tells the computer to use and require authentication by using a certificate that is issued by the selected CA. If you also select **Accept only health certificates**, then only certificates that include the system health authentication extended key usage (EKU) typically provided in a Network Access Protection (NAP) infrastructure can be used for this rule. 6. **Advanced**. Click **Customize** to specify a custom combination of authentication methods required for your scenario. You can specify both a **First authentication method** and a **Second authentication method**. diff --git a/windows/security/threat-protection/windows-firewall/planning-certificate-based-authentication.md b/windows/security/threat-protection/windows-firewall/planning-certificate-based-authentication.md index b0b4bc000c..64238d1abd 100644 --- a/windows/security/threat-protection/windows-firewall/planning-certificate-based-authentication.md +++ b/windows/security/threat-protection/windows-firewall/planning-certificate-based-authentication.md @@ -55,6 +55,6 @@ If you're installing the certificates on an operating system other than Windows, When the clients and servers have the certificates available, you can configure the IPsec and connection security rules to include those certificates as a valid authentication method. The authentication method requires the subject name of the certificate, for example: **DC=com,DC=woodgrovebank,CN=CorporateCertServer**. Optionally, select **Enable certificate to account mapping** to support using these credentials for restricting access to users or devices that are members of authorized groups in a server isolation solution. -Starting in Windows Server 2012, you can configure certificate selection criteria so the desired certificate is selected and/or validated. Enhanced Key Usage (EKU) criteria can be configured, and name restrictions and certificate thumbprints. This EKU is configured using the **Advanced** button when choosing certificates for the authentication method in the user interface, or through Windows PowerShell. +Starting in Windows Server 2012, you can configure certificate selection criteria so the desired certificate is selected and/or validated. extended key usage (EKU) criteria can be configured, and name restrictions and certificate thumbprints. This EKU is configured using the **Advanced** button when choosing certificates for the authentication method in the user interface, or through Windows PowerShell. **Next:** [Documenting the Zones](documenting-the-zones.md)