mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-19 12:23:37 +00:00
Incorp pics on provisioning page
corrected style and spacing on devreg page
This commit is contained in:
@ -30,13 +30,13 @@ Use this three phased approach for configuring device registration.
|
||||
1. [Configure devices to register in Azure](#configure-azure-for-device-registration)
|
||||
2. [Synchronize devices to on-premises Active Directory](#configure-active-directory-to-support-azure-device-syncrhonization)
|
||||
3. [Configure AD FS to use cloud devices](#configure-ad-fs-to-use-azure-registered-devices)
|
||||
>[!NOTE]
|
||||
> [!NOTE]
|
||||
> Before proceeding, you should familiarize yourself with device regisration concepts such as:
|
||||
>* Azure AD registered devices
|
||||
>* Azure AD joined devices
|
||||
>* Hybrid Azure AD joined devices
|
||||
> * 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.](https://docs.microsoft.com/en-us/azure/active-directory/device-management-introduction)
|
||||
> You can learn about this and more by reading [Introduction to Device Management in Azure Active Directory.](https://docs.microsoft.com/en-us/azure/active-directory/device-management-introduction)
|
||||
|
||||
## Configure Azure for Device Registration
|
||||
Begin configuring device registration to support Hybrid Windows Hello for Business by configuring device registration capabilities in Azure AD.
|
||||
@ -51,8 +51,8 @@ Azure Active Directory is now configured for device registration. Next, you need
|
||||
|
||||
To use Windows Hello for Business with Hybrid Azure AD joined devices, you must first upgrade your Active Directory schema to Windows Server 2016.
|
||||
|
||||
>![IMPORTANT]
|
||||
>If you already have a Windows Server 2016 domain controller in your forest, you can skip **Upgrading Active Directory to the Windows Server 2016 Schema** (this section).
|
||||
> [!IMPORTANT]
|
||||
> If you already have a Windows Server 2016 domain controller in your forest, you can skip **Upgrading Active Directory to the Windows Server 2016 Schema** (this section).
|
||||
|
||||
#### Identify the schema role domain controller
|
||||
|
||||
@ -113,11 +113,11 @@ If your AD FS farm is not already configured for Device Authentication (you can
|
||||
|
||||

|
||||
|
||||
2. On your AD FS primary server, ensure you are logged in as AD DS user with Enterprise Admin (EA ) privileges and open an elevated powershell prompt. Then, execute the following PowerShell commands:
|
||||
2. On your AD FS primary server, ensure you are logged in as AD DS user with Enterprise Admin (EA ) 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 hit Yes.
|
||||
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$"
|
||||
@ -190,7 +190,7 @@ Windows current devices authenticate using Integrated Windows Authentication to
|
||||
> [!NOTE]
|
||||
> When using AD FS, either **adfs/services/trust/13/windowstransport** or **adfs/services/trust/2005/windowstransport** must be enabled. If you are using the Web Authentication Proxy, also ensure that this endpoint is published through the proxy. You can see what end-points are enabled through the AD FS management console under **Service > Endpoints**.
|
||||
>
|
||||
>If you don<EFBFBD>t have AD FS as your on-premises federation service, follow the instructions of your vendor to make sure they support WS-Trust 1.3 or 2005 end-points and that these are published through the Metadata Exchange file (MEX).
|
||||
> If you don't have AD FS as your on-premises federation service, follow the instructions of your vendor to make sure they support WS-Trust 1.3 or 2005 end-points 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 which is then used by Azure AD Connect to associate the newly created device object with the computer account on-premises.
|
||||
|
||||
@ -214,7 +214,7 @@ In the following sections, you find information about:
|
||||
The definition helps you to verify whether the values are present or if you need to create them.
|
||||
|
||||
> [!NOTE]
|
||||
> If you don<EFBFBD>t use AD FS for your on-premises federation server, follow your vendor's instructions to create the appropriate configuration to issue these claims.
|
||||
> 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
|
||||
|
||||
@ -489,26 +489,16 @@ Using an elevated PowerShell command window, configure AD FS policy by executing
|
||||
#### 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</br></br>
|
||||
|
||||
- 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
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
- 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</br></br>
|
||||
|
||||
|
||||
- object of type msDS-DeviceRegistrationServiceContainer at CN=Device Registration Services,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
|
@ -21,19 +21,20 @@ localizationpriority: high
|
||||
## 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.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 AAD joined (AADJ or DJ++): Yes** appears. Additionally, you can validate this using the **dsregcmd /status** command from a console prompt where the value for **EnterpriseJoined** reads **Yes**.
|
||||
|
||||
<dsregcmd.png?
|
||||

|
||||
|
||||
|
||||
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**.
|
||||
|
||||
<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.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.
|
||||
|
||||
@ -47,10 +48,10 @@ The provisioning flow has all the information it needs to complete the Windows H
|
||||
|
||||
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. AAD Connect syncrhonizes the user's key to the on-prem Active Directory.
|
||||
|
||||
>[!IMPORTANT]
|
||||
>The minimum time needed to syncrhonize the user's public key from Azure Active Directory to the on-premises Active Directory is 30 minutes. This synchronization latency delays the certificate enrollment for the user. After the user's public key has syncrhonized to Active Directory, the user's certificate enrolls automatically as long as the user's session is active (actively working or locked, but still signed-in). Also, the Action Center notifies the user thier PIN is ready for use.
|
||||
> [!IMPORTANT]
|
||||
> The minimum time needed to syncrhonize the user's public key from Azure Active Directory to the on-premises Active Directory is 30 minutes. This synchronization latency delays the certificate enrollment for the user. After the user's public key has syncrhonized to Active Directory, the user's certificate enrolls automatically as long as the user's session is active (actively working or locked, but still signed-in). Also, the Action Center notifies the user thier PIN is ready for use.
|
||||
|
||||
>[!NOTE]
|
||||
> [!NOTE]
|
||||
> Microsoft is actively investigating in ways to reduce the syncrhonization latency and delays in certificate enrollment with the goal to make certificate enrollment occur real-time.
|
||||
|
||||
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.
|
||||
|
Binary file not shown.
After Width: | Height: | Size: 52 KiB |
BIN
windows/access-protection/hello-for-business/images/dsregcmd.png
Normal file
BIN
windows/access-protection/hello-for-business/images/dsregcmd.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 81 KiB |
BIN
windows/access-protection/hello-for-business/images/event358.png
Normal file
BIN
windows/access-protection/hello-for-business/images/event358.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 80 KiB |
BIN
windows/access-protection/hello-for-business/images/mfa.png
Normal file
BIN
windows/access-protection/hello-for-business/images/mfa.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 106 KiB |
Reference in New Issue
Block a user