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

updates

Browse Source
This commit is contained in:
Paolo Matarazzo 2023-01-03 09:08:37 -05:00
parent 7d61a18de6
commit a225fabf07
13 changed files with 84 additions and 1053 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
.openpublishing.redirection.json
View File

@ -20349,6 +20349,36 @@
"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
}
]
}

138
windows/security/identity-protection/hello-for-business/hello-hybrid-cert-new-install.md
View File

@ -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:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
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)
<br><br>
<hr>
## 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)

553
windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-devreg.md
View File

@ -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:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
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 **\<drive>:\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 "<your service account>"`
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) <br>
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 <AD DS domain name> -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,
".+@(?<domain>.+)",
"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://<verified-domain-name>/adfs/services/trust/"
);
```
In the claim above,
- `$<domain>` is the AD FS service URL
- `<verified-domain-name>` 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,
".+@(?<domain>.+)",
"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, ".+@(?<domain>.+)", "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=&lt;domain&gt;
- 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=&lt;domain&gt;
- Container Device Registration Service DKM under the above container
![Device Registration: Container](images/hybridct/device8.png)
- object of type serviceConnectionpoint at CN=&lt;guid&gt;, CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=&lt;domain&gt;
- 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=&lt;domain&gt;
- object of type msDS-DeviceRegistrationService in the above container
> [!div class="nextstepaction"]
> [Configure Windows Hello for Business settings](hello-hybrid-cert-whfb-settings.md)
<br>
<hr>
## 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)

157
windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-prereqs.md
View File

@ -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:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
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
<br>
## 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
<br>
## 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)
<br>
## 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)
<br>
## 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
<br>
## 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
<br>
### 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)
<br><br>
<hr>
## 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)

68
windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-ad.md
View File

@ -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:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
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)
<br><br>
<hr>
## 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)

77
windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-dir-sync.md
View File

@ -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:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
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)
<br><br>
<hr>
## 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)

39
windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings.md
View File

@ -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:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
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)
<br><br>
<hr>
## 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)

6
windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust.md
View File

@ -11,9 +11,9 @@ ms.topic: how-to
[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-key-trust.md)]
Windows Hello for Business replaces password sign-in with strong authentication, using an asymmetric key pair. This deployment guide describes how to 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.
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 and single sign-on to modern resources.
This deployment guide describes how to deploy Windows Hello for Business in a hybrid key trust scenario.
> [!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).
@ -41,7 +41,7 @@ The two directories must be synchronized with [Azure AD Connect Sync][AZ-1], whi
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.
> 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

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

@ -41,26 +41,14 @@
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: Configure and validate the 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
href: hello-hybrid-cert-whfb-provision.md
- name: Configure SSO for Azure AD joined devices

8
windows/security/includes/intune-custom-settings-info.md Normal file
View File

@ -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).

18
windows/security/includes/intune-settings-catalog-1.md Normal file
View File

@ -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 <a href="https://go.microsoft.com/fwlink/?linkid=2109431#view/Microsoft_Intune_Workflows/SettingsCatalogWizardBlade/mode/create/platform/Windows%2010%20and%20later/policyType/SettingsCatalogWindows10" target="_blank"><b>create a Settings catalog policy</b></a> (opens in a new tab).
1. Go to the <a href="https://go.microsoft.com/fwlink/?linkid=2109431" target="_blank"><b>Microsoft Endpoint Manager admin center</b></a>
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:

11
windows/security/includes/intune-settings-catalog-2.md Normal file
View File

@ -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**

8
windows/security/includes/intune-settings-catalog-info.md Normal file
View File

@ -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).