mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-19 12:23:37 +00:00
Improper acronyms review update-05
The updates here are made for acronym :AAD, Azure AD-joined, AAD-joined as per the task 6027362. Thanks!
This commit is contained in:
Alekhya Jupudi
@ -91,9 +91,9 @@ If there's a conflicting Device policy and User policy, the User policy would ta
|
||||
|
||||
## Related reference documents for Azure AD join scenarios
|
||||
|
||||
- [Azure AD joined devices](/azure/active-directory/devices/concept-azure-ad-join)
|
||||
- [Azure AD-joined devices](/azure/active-directory/devices/concept-azure-ad-join)
|
||||
- [Plan your Azure Active Directory device deployment](/azure/active-directory/devices/plan-device-deployment)
|
||||
- [How to: Plan your Azure AD join implementation](/azure/active-directory/devices/azureadjoin-plan)
|
||||
- [How to manage the local administrators group on Azure AD joined devices](/azure/active-directory/devices/assign-local-admin)
|
||||
- [How to manage the local administrators group on Azure AD-joined devices](/azure/active-directory/devices/assign-local-admin)
|
||||
- [Manage device identities using the Azure portal](/azure/active-directory/devices/device-management-azure-portal)
|
||||
- [Azure AD Join Single Sign-on Deployment](hello-hybrid-aadj-sso.md)
|
||||
|
||||
@ -29,7 +29,7 @@ Applies to:
|
||||
- Windows 10, version 1803 and later
|
||||
- Windows 11
|
||||
|
||||
PIN reset on Azure AD joined devices uses a flow called web sign-in to authenticate the user above lock. Web sign in only allows navigation to specific domains. If it attempts to navigate to a domain that is not allowed it will show a page with the error message "We can't open that page right now".
|
||||
PIN reset on Azure AD-joined devices uses a flow called web sign-in to authenticate the user above lock. Web sign in only allows navigation to specific domains. If it attempts to navigate to a domain that is not allowed it will show a page with the error message "We can't open that page right now".
|
||||
|
||||
### Identifying Azure AD joined PIN Reset Allowed Domains Issue
|
||||
|
||||
@ -124,7 +124,7 @@ Domain controllers running early versions of Windows Server 2019 have an issue t
|
||||
|
||||
On the client, authentication with Windows Hello for Business will fail with the error message, *"That option is temporarily unavailable. For now, please use a different method to sign in."*
|
||||
|
||||
This error is usually presented on hybrid Azure AD joined devices in key trust deployments after Windows Hello for Business has been provisioned but before a user's key has synced from Azure AD to AD. If a user's key has been synced from Azure AD and the msDS-keycredentiallink attribute on the user object in AD has been populated for NGC, then it is possible that this error case is occurring.
|
||||
This error is usually presented on hybrid Azure AD-joined devices in key trust deployments after Windows Hello for Business has been provisioned but before a user's key has synced from Azure AD to AD. If a user's key has been synced from Azure AD and the msDS-keycredentiallink attribute on the user object in AD has been populated for NGC, then it is possible that this error case is occurring.
|
||||
|
||||
The other indicator of this failure case can be identified using network traces. If network traces are captured for a key trust sign-in event, the traces will show kerberos failing with the error KDC_ERR_CLIENT_NAME_MISMATCH.
|
||||
|
||||
@ -158,8 +158,8 @@ User: <User SID>
|
||||
Computer: <Computer name>
|
||||
Description:
|
||||
Windows Hello for Business provisioning will not be launched.
|
||||
Device is AAD joined ( AADJ or DJ++ ): Yes
|
||||
User has logged on with AAD credentials: Yes
|
||||
Device is Azure Active Directory-joined ( AADJ or DJ++ ): Yes
|
||||
User has logged on with Azure Active Directory credentials: Yes
|
||||
Windows Hello for Business policy is enabled: Yes
|
||||
Windows Hello for Business post-logon provisioning is enabled: Yes
|
||||
Local computer meets Windows hello for business hardware requirements: Yes
|
||||
|
||||
@ -34,7 +34,7 @@ Three approaches are documented here:
|
||||
|
||||
1. Deploying a certificate to hybrid joined devices using an on-premises Active Directory certificate enrollment policy.
|
||||
|
||||
1. Deploying a certificate to hybrid or Azure AD joined devices using Simple Certificate Enrollment Protocol (SCEP) and Intune.
|
||||
1. Deploying a certificate to hybrid or Azure AD-joined devices using Simple Certificate Enrollment Protocol (SCEP) and Intune.
|
||||
|
||||
1. Working with non-Microsoft enterprise certificate authorities.
|
||||
|
||||
@ -191,7 +191,7 @@ Once the configuration profile has been created, targeted clients will receive t
|
||||
1. In the right-hand pane of the MMC, check for the new certificate
|
||||
|
||||
> [!NOTE]
|
||||
> This infrastructure may also deploy the same certificates to co-managed or modern-managed Hybrid AAD-Joined devices using Intune Policies.
|
||||
> This infrastructure may also deploy the same certificates to co-managed or modern-managed Hybrid Azure Active Directory-Joined devices using Intune Policies.
|
||||
|
||||
## Using non-Microsoft Enterprise Certificate Authorities
|
||||
|
||||
@ -205,6 +205,6 @@ The Generate-CertificateRequest commandlet will generate an .inf file for a pre-
|
||||
|
||||
After adding the certificate using an approach from any of the previous sections, you should be able to RDP to any Windows device or server in the same Forest as the user’s on-premises Active Directory account, provided the PKI certificate chain for the issuing certificate authority is deployed to that target server.
|
||||
|
||||
1. Open the Remote Desktop Client (%windir%\system32\mstsc.exe) on the Hybrid AAD-Joined client where the authentication certificate has been deployed.
|
||||
1. Open the Remote Desktop Client (%windir%\system32\mstsc.exe) on the Hybrid Azure Active Directory-Joined client where the authentication certificate has been deployed.
|
||||
1. Attempt an RDP session to a target server.
|
||||
1. Use the certificate credential protected by your Windows Hello for Business gesture.
|
||||
|
||||
@ -72,7 +72,7 @@ If the error occurs again, check the error code against the following table to s
|
||||
| 0x801C03ED | Multi-factor authentication is required for a 'ProvisionKey' operation, but was not performed. <br><br> -or- <br><br> Token was not found in the Authorization header. <br><br> -or- <br><br> Failed to read one or more objects. <br><br> -or- <br><br> The request sent to the server was invalid. <br><br> -or- <br><br> User does not have permissions to join to Azure AD. | Sign out and then sign in again. If that doesn't resolve the issue, unjoin the device from Azure AD and rejoin. <br> Allow user(s) to join to Azure AD under Azure AD Device settings.
|
||||
| 0x801C03EE | Attestation failed. | Sign out and then sign in again. |
|
||||
| 0x801C03EF | The AIK certificate is no longer valid. | Sign out and then sign in again. |
|
||||
| 0x801C03F2 | Windows Hello key registration failed. | ERROR\_BAD\_DIRECTORY\_REQUEST. Another object with the same value for property proxyAddresses already exists. To resolve the issue, refer to [Duplicate Attributes Prevent Dirsync](/office365/troubleshoot/administration/duplicate-attributes-prevent-dirsync). Also, if no sync conflict exists, please verify that the "Mail/Email address" in AAD and the Primary SMTP address are the same in the proxy address.
|
||||
| 0x801C03F2 | Windows Hello key registration failed. | ERROR\_BAD\_DIRECTORY\_REQUEST. Another object with the same value for property proxyAddresses already exists. To resolve the issue, refer to [Duplicate Attributes Prevent Dirsync](/office365/troubleshoot/administration/duplicate-attributes-prevent-dirsync). Also, if no sync conflict exists, please verify that the "Mail/Email address" in Azure Active Directory and the Primary SMTP address are the same in the proxy address.
|
||||
| 0x801C044D | Authorization token does not contain device ID. | Unjoin the device from Azure AD and rejoin. |
|
||||
| | Unable to obtain user token. | Sign out and then sign in again. Check network and credentials. |
|
||||
| 0x801C044E | Failed to receive user credentials input. | Sign out and then sign in again. |
|
||||
@ -104,7 +104,7 @@ For errors listed in this table, contact Microsoft Support for assistance.
|
||||
| 0x801C03F0 | There is no key registered for the user. |
|
||||
| 0x801C03F1 | There is no UPN in the token. |
|
||||
| 0x801C044C | There is no core window for the current thread. |
|
||||
| 0x801c004D | DSREG_NO_DEFAULT_ACCOUNT: NGC provisioning is unable to find the default WAM account to use to request AAD token for provisioning. Unable to enroll a device to use a PIN for login. |
|
||||
| 0x801c004D | DSREG_NO_DEFAULT_ACCOUNT: NGC provisioning is unable to find the default WAM account to use to request Azure Active Directory token for provisioning. Unable to enroll a device to use a PIN for login. |
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
@ -29,7 +29,7 @@ sections:
|
||||
|
||||
- question: What is Windows Hello for Business cloud trust?
|
||||
answer: |
|
||||
Windows Hello for Business cloud trust is a new trust model that is currently in preview. This trust model will enable Windows Hello for Business deployment using the infrastructure introduced for supporting [security key sign-in on Hybrid Azure AD joined devices and on-premises resource access on Azure AD Joined devices](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). Cloud trust is the preferred deployment model if you do not need to support certificate authentication scenarios. For more information, see [Hybrid Cloud Trust Deployment (Preview)](/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-trust).
|
||||
Windows Hello for Business cloud trust is a new trust model that is currently in preview. This trust model will enable Windows Hello for Business deployment using the infrastructure introduced for supporting [security key sign-in on Hybrid Azure AD-joined devices and on-premises resource access on Azure AD Joined devices](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). Cloud trust is the preferred deployment model if you do not need to support certificate authentication scenarios. For more information, see [Hybrid Cloud Trust Deployment (Preview)](/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-trust).
|
||||
|
||||
- question: What about virtual smart cards?
|
||||
answer: |
|
||||
|
||||
@ -39,7 +39,7 @@ There are two forms of PIN reset called destructive and non-destructive. Destruc
|
||||
Destructive and non-destructive PIN reset use the same entry points for initiating a PIN reset. If a user has forgotten their PIN, but has an alternate logon method, they can navigate to Sign-in options in Settings and initiate a PIN reset from the PIN options. If they do not have an alternate way to sign into their device, PIN reset can also be initiated from above the lock screen in the PIN credential provider.
|
||||
|
||||
>[!IMPORTANT]
|
||||
>For hybrid Azure AD joined devices, users must have corporate network connectivity to domain controllers to complete destructive PIN reset. If AD FS is being used for certificate trust or for on-premises only deployments, users must also have corporate network connectivity to federation services to reset their PIN.
|
||||
>For hybrid Azure AD-joined devices, users must have corporate network connectivity to domain controllers to complete destructive PIN reset. If AD FS is being used for certificate trust or for on-premises only deployments, users must also have corporate network connectivity to federation services to reset their PIN.
|
||||
|
||||
### Reset PIN from Settings
|
||||
|
||||
@ -49,7 +49,7 @@ Destructive and non-destructive PIN reset use the same entry points for initiati
|
||||
|
||||
### Reset PIN above the Lock Screen
|
||||
|
||||
For Azure AD joined devices:
|
||||
For Azure AD-joined devices:
|
||||
|
||||
1. If the PIN credential provider is not selected, expand the **Sign-in options** link, and select the PIN pad icon.
|
||||
1. Click **I forgot my PIN** from the PIN credential provider.
|
||||
@ -57,7 +57,7 @@ For Azure AD joined devices:
|
||||
1. Follow the instructions provided by the provisioning process.
|
||||
1. When finished, unlock your desktop using your newly created PIN.
|
||||
|
||||
For Hybrid Azure AD joined devices:
|
||||
For Hybrid Azure AD-joined devices:
|
||||
|
||||
1. If the PIN credential provider is not selected, expand the **Sign-in options** link, and select the PIN pad icon.
|
||||
1. Click **I forgot my PIN** from the PIN credential provider.
|
||||
@ -66,7 +66,7 @@ For Hybrid Azure AD joined devices:
|
||||
1. When finished, unlock your desktop using your newly created PIN.
|
||||
|
||||
> [!NOTE]
|
||||
> Key trust on hybrid Azure AD joined devices does not support destructive PIN reset from above the Lock Screen. This is due to the sync delay between when a user provisions their Windows Hello for Business credential and being able to use it for sign-in. For this deployment model, you must deploy non-destructive PIN reset for above lock PIN reset to work.
|
||||
> Key trust on hybrid Azure AD-joined devices does not support destructive PIN reset from above the Lock Screen. This is due to the sync delay between when a user provisions their Windows Hello for Business credential and being able to use it for sign-in. For this deployment model, you must deploy non-destructive PIN reset for above lock PIN reset to work.
|
||||
|
||||
You may find that PIN reset from settings only works post login, and that the "lock screen" PIN reset function will not work if you have any matching limitation of SSPR password reset from the lock screen. For more information, see [Enable Azure Active Directory self-service password reset at the Windows sign-in screen - General ](/azure/active-directory/authentication/howto-sspr-windows#general-limitations).
|
||||
|
||||
@ -193,7 +193,7 @@ The PIN reset configuration for a user can be viewed by running [**dsregcmd /sta
|
||||
- Windows 11
|
||||
- Azure AD joined
|
||||
|
||||
The [ConfigureWebSignInAllowedUrls](/windows/client-management/mdm/policy-csp-authentication#authentication-configurewebsigninallowedurls) policy allows you to specify a list of domains that are allowed to be navigated to during PIN reset flows on Azure AD joined devices. If you have a federated environment and authentication is handled using AD FS or a third-party identity provider, this policy should be set to ensure that authentication pages from that identity provider can be used during Azure AD joined PIN reset.
|
||||
The [ConfigureWebSignInAllowedUrls](/windows/client-management/mdm/policy-csp-authentication#authentication-configurewebsigninallowedurls) policy allows you to specify a list of domains that are allowed to be navigated to during PIN reset flows on Azure AD-joined devices. If you have a federated environment and authentication is handled using AD FS or a third-party identity provider, this policy should be set to ensure that authentication pages from that identity provider can be used during Azure AD joined PIN reset.
|
||||
|
||||
### Configuring Policy Using Intune
|
||||
|
||||
|
||||
@ -24,7 +24,7 @@ ms.reviewer:
|
||||
|
||||
Windows Hello for Business authentication is passwordless, two-factor authentication. Authenticating with Windows Hello for Business provides a convenient sign-in experience that authenticates the user to both Azure Active Directory and Active Directory resources.
|
||||
|
||||
Azure Active Directory joined devices authenticate to Azure during sign-in and can optionally authenticate to Active Directory. Hybrid Azure Active Directory joined devices authenticate to Active Directory during sign-in, and authenticate to Azure Active Directory in the background.
|
||||
Azure Active Directory-joined devices authenticate to Azure during sign-in and can optionally authenticate to Active Directory. Hybrid Azure Active Directory-joined devices authenticate to Active Directory during sign-in, and authenticate to Azure Active Directory in the background.
|
||||
|
||||
- [Azure AD join authentication to Azure Active Directory](#azure-ad-join-authentication-to-azure-active-directory)
|
||||
- [Azure AD join authentication to Active Directory using Azure AD Kerberos (cloud trust preview)](#azure-ad-join-authentication-to-active-directory-using-azure-ad-kerberos-cloud-trust-preview)
|
||||
@ -39,7 +39,7 @@ Azure Active Directory joined devices authenticate to Azure during sign-in and c
|
||||
|
||||
|
||||
> [!NOTE]
|
||||
> All Azure AD joined devices authenticate with Windows Hello for Business to Azure AD the same way. The Windows Hello for Business trust type only impacts how the device authenticates to on-premises AD.
|
||||
> All Azure AD-joined devices authenticate with Windows Hello for Business to Azure AD the same way. The Windows Hello for Business trust type only impacts how the device authenticates to on-premises AD.
|
||||
|
||||
| Phase | Description |
|
||||
| :----: | :----------- |
|
||||
|
||||
@ -80,7 +80,7 @@ List of provisioning flows:
|
||||
| C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Azure Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Azure Active Directory returns a key ID to the application which signals the end of user provisioning and the application exits. |
|
||||
|
||||
> [!NOTE]
|
||||
> Windows Hello for Business Cloud Trust does not require users' keys to be synced from Azure AD to AD. Users can immediately authenticate to AAD and AD after provisioning their credential.
|
||||
> Windows Hello for Business Cloud Trust does not require users' keys to be synced from Azure AD to AD. Users can immediately authenticate to Azure Active Directory and AD after provisioning their credential.
|
||||
|
||||
[Return to top](#windows-hello-for-business-provisioning)
|
||||
|
||||
@ -94,7 +94,7 @@ List of provisioning flows:
|
||||
| A | The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Azure MFA service provides the second factor of authentication. If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.<br>Azure Active Directory validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
|
||||
| B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv). |
|
||||
| C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Azure Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Azure Active Directory returns a key ID to the application which signals the end of user provisioning and the application exits. |
|
||||
| D | Azure AD Connect requests updates on its next synchronization cycle. Azure Active Directory sends the user's public key that was securely registered through provisioning. AAD Connect receives the public key and writes it to user's msDS-KeyCredentialLink attribute in Active Directory. |
|
||||
| D | Azure AD Connect requests updates on its next synchronization cycle. Azure Active Directory sends the user's public key that was securely registered through provisioning. Azure Active Directory Connect receives the public key and writes it to user's msDS-KeyCredentialLink attribute in Active Directory. |
|
||||
|
||||
> [!IMPORTANT]
|
||||
> The newly provisioned user will not be able to sign in using Windows Hello for Business until Azure AD Connect successfully synchronizes the public key to the on-premises Active Directory.
|
||||
|
||||
@ -166,7 +166,7 @@ For more than a decade, many organizations have used the domain join to their on
|
||||
- Users to sign in to their devices with their Active Directory work or school accounts.
|
||||
Typically, organizations with an on-premises footprint rely on imaging methods to provision devices, and they often use or group policy (GP) to manage them.
|
||||
|
||||
If your environment has an on-premises AD footprint and you also want benefit from the capabilities provided by Azure Active Directory, you can implement hybrid Azure AD joined devices. These are devices that are both, joined to your on-premises Active Directory and your Azure Active Directory.
|
||||
If your environment has an on-premises AD footprint and you also want benefit from the capabilities provided by Azure Active Directory, you can implement hybrid Azure AD-joined devices. These are devices that are both, joined to your on-premises Active Directory and your Azure Active Directory.
|
||||
|
||||
### Related topics
|
||||
[Azure AD Joined](#azure-ad-joined), [Azure AD Registered](#azure-ad-registered), [Hybrid Deployment](#hybrid-deployment)
|
||||
@ -252,7 +252,7 @@ The simplest way to enable authentication for on-premises directory objects in A
|
||||
## Primary Refresh Token
|
||||
SSO relies on special tokens obtained for each of the types of applications above. These are in turn used to obtain access tokens to specific applications. In the traditional Windows Integrated authentication case using Kerberos, this token is a Kerberos TGT (ticket-granting ticket). For Azure AD and AD FS applications we call this a Primary Refresh Token (PRT). This is a [JSON Web Token](http://openid.net/specs/draft-jones-json-web-token-07.html) containing claims about both the user and the device.
|
||||
|
||||
The PRT is initially obtained during Windows Logon (user sign-in/unlock) in a similar way the Kerberos TGT is obtained. This is true for both Azure AD joined and hybrid Azure AD joined devices. In personal devices registered with Azure AD, the PRT is initially obtained upon Add Work or School Account (in a personal device the account to unlock the device is not the work account but a consumer account e.g. hotmail.com, live.com, outlook.com, etc.).
|
||||
The PRT is initially obtained during Windows Logon (user sign-in/unlock) in a similar way the Kerberos TGT is obtained. This is true for both Azure AD joined and hybrid Azure AD-joined devices. In personal devices registered with Azure AD, the PRT is initially obtained upon Add Work or School Account (in a personal device the account to unlock the device is not the work account but a consumer account e.g. hotmail.com, live.com, outlook.com, etc.).
|
||||
|
||||
The PRT is needed for SSO. Without it, the user will be prompted for credentials when accessing applications every time. Please also note that the PRT contains information about the device. This means that if you have any [device-based conditional access](/azure/active-directory/active-directory-conditional-access-policy-connected-applications) policy set on an application, without the PRT, access will be denied.
|
||||
|
||||
|
||||
@ -22,7 +22,7 @@ ms.reviewer:
|
||||
- Windows 10
|
||||
- Windows 11
|
||||
|
||||
Windows Hello for Business is a modern, two-factor credential that is the more secure alternative to passwords. Whether you are cloud or on-premises, Windows Hello for Business has a deployment option for you. For cloud deployments, you can use Windows Hello for Business with Azure Active Directory joined, Hybrid Azure Active Directory joined, or Azure Active Directory registered devices. Windows Hello for Business also works for domain joined devices.
|
||||
Windows Hello for Business is a modern, two-factor credential that is the more secure alternative to passwords. Whether you are cloud or on-premises, Windows Hello for Business has a deployment option for you. For cloud deployments, you can use Windows Hello for Business with Azure Active Directory-joined, Hybrid Azure Active Directory-joined, or Azure AD registered devices. Windows Hello for Business also works for domain joined devices.
|
||||
|
||||
Watch this quick video where Pieter Wigleven gives a simple explanation of how Windows Hello for Business works and some of its supporting features.
|
||||
> [!VIDEO https://www.youtube.com/embed/G-GJuDWbBE8]
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Configure Azure AD joined devices for On-premises Single-Sign On using Windows Hello for Business
|
||||
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.
|
||||
keywords: identity, PIN, biometric, Hello, passport, AADJ, SSO,
|
||||
ms.prod: m365-security
|
||||
@ -17,19 +17,19 @@ ms.topic: article
|
||||
localizationpriority: medium
|
||||
ms.date: 01/14/2021
|
||||
---
|
||||
# Configure Azure AD joined devices for On-premises Single-Sign On using Windows Hello for Business
|
||||
# Configure Azure AD-joined devices for On-premises Single-Sign On using Windows Hello for Business
|
||||
|
||||
**Applies to**
|
||||
|
||||
- Windows 10
|
||||
- Windows 11
|
||||
- Azure Active Directory joined
|
||||
- Azure Active Directory-joined
|
||||
- Hybrid Deployment
|
||||
- Key trust model
|
||||
|
||||
## 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 do not 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.
|
||||
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 do not 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
|
||||
@ -56,9 +56,9 @@ Certificates issued by a certificate authority can be revoked. When a certifica
|
||||
|
||||
|
||||
|
||||
The preceding domain controller certificate shows a CRL distribution path (CDP) using Active Directory. You can determine this because 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 cannot read data from Active Directory, and certificate validation does not provide an opportunity to authenticate prior to reading the certificate revocation list. This becomes a circular problem as the user is attempting to authenticate, but must read Active Directory to complete the authentication, but the user cannot read Active Directory because they have not authenticated.
|
||||
The preceding domain controller certificate shows a CRL distribution path (CDP) using Active Directory. You can determine this because 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 cannot read data from Active Directory, and certificate validation does not provide an opportunity to authenticate prior to reading the certificate revocation list. This becomes a circular problem as the user is attempting to authenticate, but must read Active Directory to complete the authentication, but the user cannot read Active Directory because they have not authenticated.
|
||||
|
||||
To resolve this issue, the CRL distribution point must be a location that is accessible by Azure Active Directory joined devices that does not require authentication. The easiest solution is to publish the CRL distribution point on a web server that uses HTTP (not HTTPS).
|
||||
To resolve this issue, the CRL distribution point must be a location that is accessible by Azure Active Directory-joined devices that does not 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 does not 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.
|
||||
|
||||
@ -73,7 +73,7 @@ If you are interested in configuring your environment to use the Windows Hello f
|
||||
|
||||
### Domain Controller Certificates
|
||||
|
||||
Certificate authorities write CRL distribution points in certificates as they are 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
|
||||
Certificate authorities write CRL distribution points in certificates as they are 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?
|
||||
|
||||
@ -87,7 +87,7 @@ Windows Hello for Business enforces the strict KDC validation security feature w
|
||||
- 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 does not enforce that the domain controller certificate includes the **KDC Authentication** EKU. If you are 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)
|
||||
Authenticating from a Hybrid Azure AD joined device to a domain using Windows Hello for Business does not enforce that the domain controller certificate includes the **KDC Authentication** EKU. If you are 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.
|
||||
@ -107,7 +107,7 @@ Steps you will perform include:
|
||||
|
||||
### 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 is just one and may be useful for those unfamiliar with adding a new 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 is just one and may be useful for those 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.
|
||||
@ -265,7 +265,7 @@ With the CA properly configured with a valid HTTP-based CRL distribution point,
|
||||
|
||||
## Configure and Assign a Trusted Certificate Device Configuration Profile
|
||||
|
||||
Your domain controllers have new certificate that include the new CRL distribution point. Next, you need your enterprise root certificate so you can deploy it to Azure AD joined devices. Deploying the enterprise root certificates to the device, ensures the device trusts any certificates issued by the certificate authority. Without the certificate, Azure AD joined devices do not trust domain controller certificates and authentication fails.
|
||||
Your domain controllers have new certificate that include the new CRL distribution point. Next, you need your enterprise root certificate so you can deploy it to Azure AD-joined devices. Deploying the enterprise root certificates to the device, ensures the device trusts any certificates issued by the certificate authority. Without the certificate, Azure AD-joined devices do not trust domain controller certificates and authentication fails.
|
||||
|
||||
Steps you will perform include:
|
||||
- [Export Enterprise Root certificate](#export-enterprise-root-certificate)
|
||||
@ -288,7 +288,7 @@ Steps you will perform include:
|
||||
|
||||
### 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.
|
||||
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. Click **Device configuration**. In the **Device Configuration** blade, click **Create profile**.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Using Certificates for AADJ On-premises Single-sign On single sign-on
|
||||
description: If you want to use certificates for on-premises single-sign on for Azure Active Directory joined devices, then follow these additional steps.
|
||||
description: If you want to use certificates for on-premises single-sign on for Azure Active Directory-joined devices, then follow these additional steps.
|
||||
keywords: identity, PIN, biometric, Hello, passport, AADJ, SSO,
|
||||
ms.prod: m365-security
|
||||
ms.mktglfcycl: deploy
|
||||
@ -23,14 +23,14 @@ ms.reviewer:
|
||||
|
||||
- Windows 10
|
||||
- Windows 11
|
||||
- Azure Active Directory joined
|
||||
- Azure Active Directory-joined
|
||||
- Hybrid Deployment
|
||||
- Certificate trust
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Ensure you have performed the configurations in [Azure AD joined devices for On-premises Single-Sign On](hello-hybrid-aadj-sso-base.md) before you continue.
|
||||
> Ensure you have performed the configurations in [Azure AD-joined devices for On-premises Single-Sign On](hello-hybrid-aadj-sso-base.md) before you continue.
|
||||
|
||||
Steps you will perform include:
|
||||
|
||||
@ -44,7 +44,7 @@ Steps you will perform include:
|
||||
|
||||
## Requirements
|
||||
|
||||
You need to install and configure additional infrastructure to provide Azure AD joined devices with on-premises single-sign on.
|
||||
You need to install and configure additional infrastructure to provide Azure AD-joined devices with on-premises single-sign on.
|
||||
|
||||
- An existing Windows Server 2012 R2 or later Enterprise Certificate Authority
|
||||
- A Windows Server 2012 R2 domain joined server that hosts the Network Device Enrollment Services role
|
||||
@ -75,7 +75,7 @@ Most environments change the user principal name suffix to match the organizatio
|
||||
|
||||
To include the on-premises distinguished name in the certificate's subject, Azure AD Connect must replicate the Active Directory **distinguishedName** attribute to the Azure Active Directory **onPremisesDistinguishedName** attribute. Azure AD Connect version 1.1.819 includes the proper synchronization rules needed for these attributes.
|
||||
|
||||
### Verify AAD Connect version
|
||||
### Verify Azure Active Directory Connect version
|
||||
|
||||
Sign-in to computer running Azure AD Connect with access equivalent to _local administrator_.
|
||||
|
||||
@ -471,13 +471,13 @@ Sign-in a domain controller with a minimum access equivalent to _Domain Admins_.
|
||||
|
||||
5. Click **Add**.
|
||||
|
||||
6. Click **Users or Computers...** Type the name of the _NDES Server_ you use to issue Windows Hello for Business authentication certificates to Azure AD joined devices. From the **Available services** list, select **HOST**. Click **OK**.
|
||||
6. Click **Users or Computers...** Type the name of the _NDES Server_ you use to issue Windows Hello for Business authentication certificates to Azure AD-joined devices. From the **Available services** list, select **HOST**. Click **OK**.
|
||||
|
||||
|
||||
|
||||
7. Repeat steps 5 and 6 for each NDES server using this service account. Click **Add**.
|
||||
|
||||
8. Click **Users or computers...** Type the name of the issuing certificate authority this NDES service account uses to issue Windows Hello for Business authentication certificates to Azure AD joined devices. From the **Available services** list, select **dcom**. Hold the **CTRL** key and select **HOST**. Click **OK**.
|
||||
8. Click **Users or computers...** Type the name of the issuing certificate authority this NDES service account uses to issue Windows Hello for Business authentication certificates to Azure AD-joined devices. From the **Available services** list, select **dcom**. Hold the **CTRL** key and select **HOST**. Click **OK**.
|
||||
|
||||
9. Repeat steps 8 and 9 for each issuing certificate authority from which one or more NDES servers request certificates.
|
||||
|
||||
@ -550,7 +550,7 @@ Sign-in to the NDES Server with _local administrator_ equivalent credentials.
|
||||
|
||||
1. Open an elevated command prompt.
|
||||
|
||||
2. Using the table above, decide which registry value name you will use to request Windows Hello for Business authentication certificates for Azure AD joined devices.
|
||||
2. Using the table above, decide which registry value name you will use to request Windows Hello for Business authentication certificates for Azure AD-joined devices.
|
||||
|
||||
3. Type the following command:
|
||||
|
||||
@ -558,7 +558,7 @@ Sign-in to the NDES Server with _local administrator_ equivalent credentials.
|
||||
reg add HKLM\Software\Microsoft\Cryptography\MSCEP /v [registryValueName] /t REG_SZ /d [certificateTemplateName]
|
||||
```
|
||||
|
||||
where **registryValueName** is one of the three value names from the above table and where **certificateTemplateName** is the name of the certificate template you created for Windows Hello for Business Azure AD joined devices. Example:
|
||||
where **registryValueName** is one of the three value names from the above table and where **certificateTemplateName** is the name of the certificate template you created for Windows Hello for Business Azure AD-joined devices. Example:
|
||||
|
||||
```console
|
||||
reg add HKLM\Software\Microsoft\Cryptography\MSCEP /v SignatureTemplate /t REG_SZ /d AADJWHFBAuthentication
|
||||
@ -573,7 +573,7 @@ Sign-in to the NDES Server with _local administrator_ equivalent credentials.
|
||||
|
||||
### Create a Web Application Proxy for the internal NDES URL.
|
||||
|
||||
Certificate enrollment for Azure AD joined devices occurs over the Internet. As a result, the internal NDES URLs must be accessible externally. You can do this easily and securely using Azure Active Directory Application Proxy. Azure AD Application Proxy provides single sign-on and secure remote access for web applications hosted on-premises, such as Network Device Enrollment Services.
|
||||
Certificate enrollment for Azure AD-joined devices occurs over the Internet. As a result, the internal NDES URLs must be accessible externally. You can do this easily and securely using Azure Active Directory Application Proxy. Azure AD Application Proxy provides single sign-on and secure remote access for web applications hosted on-premises, such as Network Device Enrollment Services.
|
||||
|
||||
Ideally, you configure your Microsoft Intune SCEP certificate profile to use multiple external NDES URLs. This enables Microsoft Intune to round-robin load balance the certificate requests to identically configured NDES Servers (each NDES server can accommodate approximately 300 concurrent requests). Microsoft Intune sends these requests to Azure AD Application Proxies.
|
||||
|
||||
@ -697,7 +697,7 @@ Sign-in the NDES server with access equivalent to _local administrators_.
|
||||
|
||||
10. Click **Enroll**
|
||||
|
||||
11. Repeat these steps for all NDES Servers used to request Windows Hello for Business authentication certificates for Azure AD joined devices.
|
||||
11. Repeat these steps for all NDES Servers used to request Windows Hello for Business authentication certificates for Azure AD-joined devices.
|
||||
|
||||
### Configure the Web Server Role
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
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.
|
||||
description: Learn how to provide single sign-on to your on-premises resources for Azure Active Directory-joined devices, using Windows Hello for Business.
|
||||
keywords: identity, PIN, biometric, Hello, passport, AADJ, SSO,
|
||||
ms.prod: m365-security
|
||||
ms.mktglfcycl: deploy
|
||||
@ -22,10 +22,10 @@ ms.reviewer:
|
||||
|
||||
- Windows 10
|
||||
- Windows 11
|
||||
- Azure Active Directory joined
|
||||
- Azure Active Directory-joined
|
||||
- Hybrid deployment
|
||||
|
||||
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 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.
|
||||
|
||||
## Key vs. Certificate
|
||||
|
||||
@ -33,10 +33,10 @@ Enterprises can use either a key or a certificate to provide single-sign on for
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
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 AADJ On-premises Single-sign On](hello-hybrid-aadj-sso-cert.md).
|
||||
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).
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
@ -43,8 +43,8 @@ Use this three-phased approach for configuring device registration.
|
||||
> 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
|
||||
> - 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)
|
||||
|
||||
@ -55,7 +55,7 @@ Use this three-phased approach for configuring device registration.
|
||||
|
||||
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.
|
||||
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:
|
||||
|
||||
@ -69,11 +69,11 @@ You can learn more about this scenario by reading [Review on-premises UPN suppor
|
||||
|
||||
## 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
|
||||
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.
|
||||
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).
|
||||
|
||||
@ -31,7 +31,7 @@ The Windows Hello for Business provisioning begins immediately after the user ha
|
||||
|
||||
|
||||
|
||||
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 **AzureADJoined** reads **Yes**.
|
||||
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**.
|
||||
|
||||
@ -52,7 +52,7 @@ The provisioning flow has all the information it needs to complete the Windows H
|
||||
- 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. AAD Connect synchronizes the user's key to the on-premises Active Directory.
|
||||
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.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> The following is the enrollment behavior prior to Windows Server 2016 update [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889).
|
||||
|
||||
@ -38,7 +38,7 @@ This section has you configure certificate templates on your Windows Server 2012
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
|
||||
@ -40,7 +40,7 @@ Windows Hello for Business cloud trust uses Azure Active Directory (AD) Kerberos
|
||||
|
||||
## Azure Active Directory Kerberos and Cloud Trust Authentication
|
||||
|
||||
Key trust and certificate trust use certificate authentication based Kerberos for requesting kerberos ticket-granting-tickets (TGTs) for on-premises authentication. This type of authentication requires PKI for DC certificates, and requires end-user certificates for certificate trust. Single sign-on (SSO) to on-premises resources from Azure AD joined devices requires more PKI configuration to publish a certificate revocation list (CRL) to a public endpoint. Cloud trust uses Azure AD Kerberos that doesn't require any of the above PKI to get the user a TGT.
|
||||
Key trust and certificate trust use certificate authentication based Kerberos for requesting kerberos ticket-granting-tickets (TGTs) for on-premises authentication. This type of authentication requires PKI for DC certificates, and requires end-user certificates for certificate trust. Single sign-on (SSO) to on-premises resources from Azure AD-joined devices requires more PKI configuration to publish a certificate revocation list (CRL) to a public endpoint. Cloud trust uses Azure AD Kerberos that doesn't require any of the above PKI to get the user a TGT.
|
||||
|
||||
With Azure AD Kerberos, Azure AD can issue TGTs for one or more of your AD domains. Windows can request a TGT from Azure AD when authenticating with Windows Hello for Business and use the returned TGT for logon or to access traditional AD-based resources. Kerberos service tickets and authorization continue to be controlled by your on-premises AD DCs.
|
||||
|
||||
@ -53,7 +53,7 @@ More details on how Azure AD Kerberos enables access to on-premises resources ar
|
||||
| Requirement | Notes |
|
||||
| --- | --- |
|
||||
| Multi-factor Authentication | This requirement can be met using [Azure AD multi-factor authentication](/azure/active-directory/authentication/howto-mfa-getstarted), multi-factor authentication provided through AD FS, or a comparable solution. |
|
||||
| Patched Windows 10 version 21H2 or patched Windows 11 and later | If you're using Windows 10 21H2, KB5010415 must be installed. If you're using Windows 11 21H2, KB5010414 must be installed. There's no Windows version support difference between Azure AD joined and Hybrid Azure AD joined devices. |
|
||||
| Patched Windows 10 version 21H2 or patched Windows 11 and later | If you're using Windows 10 21H2, KB5010415 must be installed. If you're using Windows 11 21H2, KB5010414 must be installed. There's no Windows version support difference between Azure AD joined and Hybrid Azure AD-joined devices. |
|
||||
| Fully patched Windows Server 2016 or later Domain Controllers | Domain controllers should be fully patched to support updates needed for Azure AD Kerberos. If you're using Windows Server 2016, [KB3534307](https://support.microsoft.com/en-us/topic/january-23-2020-kb4534307-os-build-14393-3474-b181594e-2c6a-14ea-e75b-678efea9d27e) must be installed. If you're using Server 2019, [KB4534321](https://support.microsoft.com/en-us/topic/january-23-2020-kb4534321-os-build-17763-1012-023e84c3-f9aa-3b55-8aff-d512911c459f) must be installed. |
|
||||
| Azure AD Kerberos PowerShell module | This module is used for enabling and managing Azure AD Kerberos. It's available through the [PowerShell Gallery](https://www.powershellgallery.com/packages/AzureADHybridAuthenticationManagement).|
|
||||
| Device management | Windows Hello for Business cloud trust can be managed with group policy or through mobile device management (MDM) policy. This feature is disabled by default and must be enabled using policy. |
|
||||
@ -83,7 +83,7 @@ If you haven't deployed Azure AD Kerberos, follow the instructions in the [Enabl
|
||||
|
||||
### Configure Windows Hello for Business Policy
|
||||
|
||||
After setting up the Azure AD Kerberos Object, Windows Hello for business cloud trust must be enabled using policy. By default, cloud trust won't be used by Hybrid Azure AD joined or Azure AD joined devices.
|
||||
After setting up the Azure AD Kerberos Object, Windows Hello for business cloud trust must be enabled using policy. By default, cloud trust won't be used by Hybrid Azure AD joined or Azure AD-joined devices.
|
||||
|
||||
#### Configure Using Group Policy
|
||||
|
||||
@ -202,7 +202,7 @@ To configure the cloud trust policy, follow the steps below:
|
||||
|
||||
## Provisioning
|
||||
|
||||
The Windows Hello for Business provisioning process begins immediately after a user has signed in if certain prerequisite checks are passed. Windows Hello for Business cloud trust adds a prerequisite check for Hybrid Azure AD joined devices when cloud trust is enabled by policy.
|
||||
The Windows Hello for Business provisioning process begins immediately after a user has signed in if certain prerequisite checks are passed. Windows Hello for Business cloud trust adds a prerequisite check for Hybrid Azure AD-joined devices when cloud trust is enabled by policy.
|
||||
|
||||
You can determine the status of the prerequisite check by viewing the **User Device Registration** admin log under **Applications and Services Logs\Microsoft\Windows**. This information is also available using the [**dsregcmd /status**](/azure/active-directory/devices/troubleshoot-device-dsregcmd) command from a console.
|
||||
|
||||
@ -210,7 +210,7 @@ You can determine the status of the prerequisite check by viewing the **User Dev
|
||||
|
||||
The cloud trust prerequisite check detects whether the user has a partial TGT before allowing provisioning to start. The purpose of this check is to validate whether Azure AD Kerberos is set up for the user's domain and tenant. If Azure AD Kerberos is set up, the user will receive a partial TGT during sign-in with one of their other unlock methods. This check has three states: Yes, No, and Not Tested. The *Not Tested* state is reported if cloud trust is not being enforced by policy or if the device is Azure AD joined.
|
||||
|
||||
This prerequisite check isn't done for provisioning on Azure AD joined devices. If Azure AD Kerberos isn't provisioned, a user on an Azure AD joined device will still be able to sign in.
|
||||
This prerequisite check isn't done for provisioning on Azure AD-joined devices. If Azure AD Kerberos isn't provisioned, a user on an Azure AD joined device will still be able to sign in.
|
||||
|
||||
### PIN Setup
|
||||
|
||||
|
||||
@ -85,7 +85,7 @@ If you do not have an existing public key infrastructure, please review [Certifi
|
||||
> [!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.
|
||||
> * Publish your certificate revocation list to a location that is available to Azure AD-joined devices, such as a web-based URL.
|
||||
|
||||
### Section Review
|
||||
|
||||
|
||||
@ -31,8 +31,8 @@ You're ready to configure device registration for your hybrid environment. Hybri
|
||||
> [!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
|
||||
> * 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)
|
||||
|
||||
@ -40,7 +40,7 @@ You're ready to configure device registration for your hybrid environment. Hybri
|
||||
|
||||
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.
|
||||
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:
|
||||
|
||||
|
||||
@ -83,7 +83,7 @@ The minimum required Enterprise certificate authority that can be used with Wind
|
||||
> [!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.
|
||||
> * 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"]
|
||||
|
||||
@ -31,7 +31,7 @@ The Windows Hello for Business provisioning begins immediately after the user ha
|
||||
|
||||
|
||||
|
||||
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 **AzureADJoined** reads **Yes**.
|
||||
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**.
|
||||
|
||||
|
||||
@ -38,7 +38,7 @@ This section has you configure certificate templates on your Windows Server 2012
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
|
||||
@ -34,7 +34,7 @@ Alternatively, you can create copy the .ADMX and .ADML files from a Windows 10 C
|
||||
|
||||
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 needs one Group Policy setting:
|
||||
Hybrid Azure AD-joined devices needs one Group Policy setting:
|
||||
* Enable Windows Hello for Business
|
||||
|
||||
### Configure Domain Controllers for Automatic Certificate Enrollment
|
||||
|
||||
@ -99,7 +99,7 @@ It's fundamentally important to understand which deployment model to use for a s
|
||||
A deployment's trust type defines how each Windows Hello for Business client authenticates to the on-premises Active Directory. There are two trust types: key trust and certificate trust.
|
||||
|
||||
> [!NOTE]
|
||||
> Windows Hello for Business is introducing a new trust model called cloud trust in early 2022. This trust model will enable deployment of Windows Hello for Business using the infrastructure introduced for supporting [security key sign-in on Hybrid Azure AD joined devices and on-premises resource access on Azure AD Joined devices](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). More information will be available on Windows Hello for Business cloud trust once it is generally available.
|
||||
> Windows Hello for Business is introducing a new trust model called cloud trust in early 2022. This trust model will enable deployment of Windows Hello for Business using the infrastructure introduced for supporting [security key sign-in on Hybrid Azure AD-joined devices and on-premises resource access on Azure AD Joined devices](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). More information will be available on Windows Hello for Business cloud trust once it is generally available.
|
||||
|
||||
The key trust type does not require issuing authentication certificates to end users. Users authenticate using a hardware-bound key created during the built-in provisioning experience. This requires an adequate distribution of Windows Server 2016 or later domain controllers relative to your existing authentication and the number of users included in your Windows Hello for Business deployment. Read the [Planning an adequate number of Windows Server 2016 or later Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more.
|
||||
|
||||
@ -191,7 +191,7 @@ If your organization does not have cloud resources, write **On-Premises** in box
|
||||
|
||||
### Trust type
|
||||
|
||||
Hybrid Azure AD joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates. Hybrid Azure AD joined devices and Azure AD joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates.
|
||||
Hybrid Azure AD-joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates. Hybrid Azure AD-joined devices and Azure AD-joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates.
|
||||
|
||||
Choose a trust type that is best suited for your organizations. Remember, the trust type determines two things. Whether you issue authentication certificates to your users and if your deployment needs Windows Server 2016 domain controllers.
|
||||
|
||||
@ -259,10 +259,10 @@ If you choose to use AD FS with the Azure MFA server adapter, write **AD FS with
|
||||
|
||||
Windows Hello for Business provides organizations with many policy settings and granular control on how these settings may be applied to both computers and users. The type of policy management you can use depends on your selected deployment and trust models.
|
||||
|
||||
If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **2a** on your planning worksheet. You have the option to manage non-domain joined devices. If you choose to manage Azure Active Directory joined devices, write **modern management** in box **2b** on your planning worksheet. Otherwise, write** N/A** in box **2b**.
|
||||
If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **2a** on your planning worksheet. You have the option to manage non-domain joined devices. If you choose to manage Azure Active Directory-joined devices, write **modern management** in box **2b** on your planning worksheet. Otherwise, write** N/A** in box **2b**.
|
||||
|
||||
> [!NOTE]
|
||||
> Azure Active Directory joined devices without modern management automatically enroll in Windows Hello for Business using the default policy settings. Use modern management to adjust policy settings to match the business needs of your organization.
|
||||
> Azure Active Directory-joined devices without modern management automatically enroll in Windows Hello for Business using the default policy settings. Use modern management to adjust policy settings to match the business needs of your organization.
|
||||
|
||||
If box **1a** on your planning worksheet reads **on-prem**, write **GP** in box **2a** on your planning worksheet. Write **N/A** in box **2b** on your worksheet.
|
||||
|
||||
@ -278,7 +278,7 @@ Windows Hello for Business is a feature exclusive to Windows 10 and Windows 11.
|
||||
|
||||
If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **3a** on your planning worksheet. Optionally, you may write **1511 or later** in box **3b** on your planning worksheet if you plan to manage non-domain joined devices.
|
||||
> [!NOTE]
|
||||
> Azure Active Directory joined devices without modern management automatically enroll in Windows Hello for Business using the default policy settings. Use modern management to adjust policy settings to match the business needs of your organization.
|
||||
> Azure Active Directory-joined devices without modern management automatically enroll in Windows Hello for Business using the default policy settings. Use modern management to adjust policy settings to match the business needs of your organization.
|
||||
|
||||
Write **1511 or later** in box **3a** on your planning worksheet if any of the following are true.
|
||||
* Box **2a** on your planning worksheet read **modern management**.
|
||||
@ -306,7 +306,7 @@ If box **1a** on your planning worksheet reads **cloud only**, ignore the public
|
||||
|
||||
If box **1b** on your planning worksheet reads **key trust**, write **N/A** in box **5b** on your planning worksheet. Key trust doesn't require any change in public key infrastructure, skip this part and go to **Cloud** section.
|
||||
|
||||
The registration authority only relates to certificate trust deployments and the management used for domain and non-domain joined devices. Hybrid Azure AD joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates. Hybrid Azure AD joined devices and Azure AD joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates.
|
||||
The registration authority only relates to certificate trust deployments and the management used for domain and non-domain joined devices. Hybrid Azure AD-joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates. Hybrid Azure AD-joined devices and Azure AD-joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates.
|
||||
|
||||
If box **2a** reads **GP** and box **2b** reads **modern management**, write **AD FS RA and NDES** in box **5b** on your planning worksheet. In box **5c**, write the following certificate templates names and issuances:
|
||||
|
||||
|
||||
@ -80,7 +80,7 @@ If the credentials are certificate-based, then the elements in the following tab
|
||||
| SubjectName | The user’s distinguished name (DN) where the domain components of the distinguished name reflect the internal DNS namespace when the SubjectAlternativeName does not have the fully qualified UPN required to find the domain controller. </br>This requirement is relevant in multi-forest environments as it ensures a domain controller can be located. |
|
||||
| SubjectAlternativeName | The user’s fully qualified UPN where a domain name component of the user’s UPN matches the organizations internal domain’s DNS namespace. </br>This requirement is relevant in multi-forest environments as it ensures a domain controller can be located when the SubjectName does not have the DN required to find the domain controller. |
|
||||
| Key Storage Provider (KSP) | If the device is joined to Azure AD, a discrete SSO certificate is used. |
|
||||
| EnhancedKeyUsage | One or more of the following EKUs is required: </br>- Client Authentication (for the VPN) </br>- EAP Filtering OID (for Windows Hello for Business)</br>- SmartCardLogon (for Azure AD joined devices) </br>If the domain controllers require smart card EKU either:</br>- SmartCardLogon</br>- id-pkinit-KPClientAuth (1.3.6.1.5.2.3.4) <br>Otherwise:</br>- TLS/SSL Client Authentication (1.3.6.1.5.5.7.3.2) |
|
||||
| EnhancedKeyUsage | One or more of the following EKUs is required: </br>- Client Authentication (for the VPN) </br>- EAP Filtering OID (for Windows Hello for Business)</br>- SmartCardLogon (for Azure AD-joined devices) </br>If the domain controllers require smart card EKU either:</br>- SmartCardLogon</br>- id-pkinit-KPClientAuth (1.3.6.1.5.2.3.4) <br>Otherwise:</br>- TLS/SSL Client Authentication (1.3.6.1.5.5.7.3.2) |
|
||||
|
||||
## NDES server configuration
|
||||
|
||||
|
||||
Reference in New Issue
Block a user