mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-16 10:53:43 +00:00
updates
This commit is contained in:
Paolo Matarazzo
@ -1,55 +1,48 @@
|
||||
---
|
||||
title: Azure AD Join Single Sign-on Deployment
|
||||
description: Learn how to provide single sign-on to your on-premises resources for Azure Active Directory-joined devices, using Windows Hello for Business.
|
||||
ms.date: 08/19/2018
|
||||
title: Configure single sign-on (SSO) for Azure AD joined devices
|
||||
description: Learn how to configure single sign-on to on-premises resources for Azure AD-joined devices, using Windows Hello for Business.
|
||||
ms.date: 12/30/2022
|
||||
appliesto:
|
||||
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
|
||||
ms.topic: article
|
||||
---
|
||||
# Azure AD Join Single Sign-on Deployment
|
||||
# Configure single sign-on for Azure AD joined devices
|
||||
|
||||
[!INCLUDE [hello-hybrid-key-trust](./includes/hello-hybrid-keycert-trust-aad.md)]
|
||||
|
||||
Windows Hello for Business combined with Azure Active Directory-joined devices makes it easy for users to securely access cloud-based resources using a strong, two-factor credential. Some resources may remain on-premises as enterprises transition resources to the cloud and Azure AD-joined devices may need to access these resources. With additional configurations to your current hybrid deployment, you can provide single sign-on to your on-premises resources for Azure Active Directory-joined devices using Windows Hello for Business, using a key or a certificate.
|
||||
Windows Hello for Business combined with Azure AD-joined devices makes it easy for users to securely access cloud-based resources using a strong, two-factor credential. Some resources may remain on-premises as enterprises transition resources to the cloud and Azure AD-joined devices may need to access these resources. With additional configurations to the hybrid deployment, you can provide single sign-on to on-premises resources for Azure AD-joined devices using Windows Hello for Business, using a key or a certificate.
|
||||
|
||||
## Key vs. Certificate
|
||||
|
||||
Enterprises can use either a key or a certificate to provide single-sign on for on-premises resources. Both types of authentication provide the same security; one is not more secure than the other.
|
||||
|
||||
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.
|
||||
|
||||
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).
|
||||
> [!NOTE]
|
||||
> These steps are not needed when using the cloud Kerberos 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 don't have a relationship with your Active Directory domain. This factor changes the way in which users authenticate to Active Directory. Validate the following configurations to ensure they support Azure AD-joined devices:
|
||||
Unlike hybrid Azure AD-joined devices, Azure AD-joined devices don't have a relationship with your Active Directory domain. This factor changes the way in which users authenticate to Active Directory. Validate the following configurations to ensure they support Azure AD-joined devices:
|
||||
|
||||
- Certificate Revocation List (CRL) Distribution Point (CDP)
|
||||
- Domain Controller certificate
|
||||
- Network infrastructure in place to reach the on-premises domain controllers. If the machines are external, you can use any VPN solution
|
||||
> [!div class="checklist"]
|
||||
> - Certificate Revocation List (CRL) Distribution Point
|
||||
> - Domain controller certificates
|
||||
> - Network infrastructure in place to reach the on-premises domain controllers. If the machines are external, you can use any VPN solution
|
||||
|
||||
### CRL Distribution Point (CDP)
|
||||
|
||||
Certificates issued by a certificate authority can be revoked. When a certificate authority revokes as certificate, it writes information about the certificate into a revocation list (CRL).\
|
||||
Certificates issued by a certificate authority can be revoked. When a certificate authority revokes as certificate, it writes information about the certificate into a *certificate revocation list* (CRL).\
|
||||
During certificate validation, Windows compares the current certificate with information in the CRL to determine if the certificate is valid.
|
||||
|
||||
|
||||
|
||||
The preceding domain controller certificate shows a CRL distribution path (CDP) using Active Directory. The value in the URL begins with **ldap**. Using Active Directory for domain joined devices provides a highly available CRL distribution point. However, Azure Active Directory-joined devices can't read data from Active Directory, and certificate validation doesn't provide an opportunity to authenticate prior to reading the CRL. The authentication becomes a circular problem: the user is attempting to authenticate, but must read Active Directory to complete the authentication, but the user can't read Active Directory because they haven't authenticated.
|
||||
The preceding domain controller certificate shows a *CRL distribution point* (CDP) in Active Directory. The value in the URL begins with *ldap*. Using Active Directory for domain joined devices provides a highly available CRL distribution point. However, Azure AD joined devices can't read data from Active Directory, and certificate validation doesn't provide an opportunity to authenticate prior to reading the CRL. The authentication becomes a circular problem: the user is attempting to authenticate, but must read Active Directory to complete the authentication, but the user can't read Active Directory because they haven't authenticated.
|
||||
|
||||
To resolve this issue, the CRL distribution point must be a location that is accessible by Azure AD joined devices that doesn't require authentication. The easiest solution is to publish the CRL distribution point on a web server that uses HTTP (not HTTPS).
|
||||
To resolve this issue, the CRL distribution point must be a location accessible by Azure AD joined devices that doesn't require authentication. The easiest solution is to publish the CRL distribution point on a web server that uses HTTP (not HTTPS).
|
||||
|
||||
If your CRL distribution point doesn't list an HTTP distribution point, then you need to reconfigure the issuing certificate authority to include an HTTP CRL distribution point, preferably first, in the list of distribution points.
|
||||
|
||||
> [!NOTE]
|
||||
> If your CA has published both the *Base* and the *Delta CRL*, make sure to publish the *Delta CRL* in the HTTP path. Include web server to fetch the *Delta CRL* by allowing **double escaping** in the (IIS) web server.
|
||||
|
||||
### Domain Controller Certificates
|
||||
### Domain controller certificates
|
||||
|
||||
Certificate authorities write CRL distribution points in certificates as they're issued. If the distribution point changes, then previously issued certificates must be reissued for the certificate authority to include the new CRL distribution point. The domain controller certificate is one the critical components of Azure AD-joined devices authenticating to Active Directory.
|
||||
Certificate authorities write CDP information in certificates as they're issued. If the distribution point changes, then previously issued certificates must be reissued for the certificate authority to include the new CDP. The domain controller certificate is one the critical components of Azure AD-joined devices authenticating to Active Directory.
|
||||
|
||||
#### Why does Windows need to validate the domain controller certificate?
|
||||
|
||||
@ -69,6 +62,7 @@ Authenticating from a Hybrid Azure AD joined device to a domain using Windows He
|
||||
|
||||
Use this set of procedures to update the CA that issues domain controller certificates to include an http-based CRL distribution point. Expand each step to learn more:
|
||||
|
||||
<br>
|
||||
<details>
|
||||
<summary><b>Configure Internet Information Services to host CRL distribution point</b></summary>
|
||||
|
||||
@ -79,35 +73,35 @@ You need to host your new certificate revocation list on a web server so Azure A
|
||||
|
||||
### Install the web server
|
||||
|
||||
1. Sign-in to your server as a local administrator and start **Server Manager** if it didn't start during your sign in.
|
||||
2. Select the **Local Server** node in the navigation pane. Select **Manage** and select **Add Roles and Features**.
|
||||
3. In the **Add Role and Features Wizard**, select **Server Selection**. Verify the selected server is the local server. Select **Server Roles**. Select the check box next to **Web Server (IIS)**.
|
||||
4. Select **Next** through the remaining options in the wizard, accepting the defaults, and install the Web Server role.
|
||||
1. Sign-in to your server as a local administrator and start **Server Manager** if it didn't start during your sign in
|
||||
1. Select the **Local Server** node in the navigation pane. Select **Manage** and select **Add Roles and Features**
|
||||
1. In the **Add Role and Features Wizard**, select **Server Selection**. Verify the selected server is the local server. Select **Server Roles**. Select the check box next to **Web Server (IIS)**
|
||||
1. Select **Next** through the remaining options in the wizard, accepting the defaults, and install the Web Server role
|
||||
|
||||
### Configure the web server
|
||||
|
||||
1. From **Windows Administrative Tools**, Open **Internet Information Services (IIS) Manager**.
|
||||
2. Expand the navigation pane to show **Default Web Site**. Select and then right-click **Default Web site** and select **Add Virtual Directory...**.
|
||||
3. In the **Add Virtual Directory** dialog box, type **cdp** in **alias**. For physical path, type or browse for the physical file location where you'll host the certificate revocation list. For this example, the path **c:\cdp** is used. Select **OK**.
|
||||
1. From **Windows Administrative Tools**, Open **Internet Information Services (IIS) Manager**
|
||||
1. Expand the navigation pane to show **Default Web Site**. Select and then right-click **Default Web site** and select **Add Virtual Directory...**
|
||||
1. In the **Add Virtual Directory** dialog box, type **cdp** in **alias**. For physical path, type or browse for the physical file location where you'll host the certificate revocation list. For this example, the path `c:\cdp` is used. Select **OK**
|
||||
|
||||
> [!NOTE]
|
||||
> Make note of this path as you will use it later to configure share and file permissions.
|
||||
|
||||
4. Select **CDP** under **Default Web Site** in the navigation pane. Double-click **Directory Browsing** in the content pane. Select **Enable** in the details pane.
|
||||
5. Select **CDP** under **Default Web Site** in the navigation pane. Double-click **Configuration Editor**.
|
||||
6. In the **Section** list, navigate to **system.webServer/security/requestFiltering**.
|
||||
1. Select **CDP** under **Default Web Site** in the navigation pane. Open **Directory Browsing** in the content pane. Select **Enable** in the details pane
|
||||
1. Select **CDP** under **Default Web Site** in the navigation pane. Open **Configuration Editor**
|
||||
1. In the **Section** list, navigate to **system.webServer/security/requestFiltering**
|
||||
|
||||
In the list of named value-pairs in the content pane, configure **allowDoubleEscaping** to **True**. Select **Apply** in the actions pane.
|
||||
1. In the list of named value-pairs in the content pane, configure **allowDoubleEscaping** to **True**. Select **Apply** in the actions pane
|
||||
|
||||
7. Close **Internet Information Services (IIS) Manager**.
|
||||
1. Close **Internet Information Services (IIS) Manager**
|
||||
|
||||
### Create a DNS resource record for the CRL distribution point URL
|
||||
|
||||
1. On your DNS server or from an administrative workstation, open **DNS Manager** from **Administrative Tools**.
|
||||
2. Expand **Forward Lookup Zones** to show the DNS zone for your domain. Right-click your domain name in the navigation pane and select **New Host (A or AAAA)...**.
|
||||
3. In the **New Host** dialog box, type **crl** in **Name**. Type the IP address of the web server you configured in **IP Address**. Select **Add Host**. Select **OK** to close the **DNS** dialog box. Select **Done**.
|
||||
|
||||
4. Close the **DNS Manager**.
|
||||
1. On your DNS server or from an administrative workstation, open **DNS Manager** from **Administrative Tools**
|
||||
1. Expand **Forward Lookup Zones** to show the DNS zone for your domain. Right-click your domain name in the navigation pane and select **New Host (A or AAAA)...**
|
||||
1. In the **New Host** dialog box, type **crl** in **Name**. Type the IP address of the web server you configured in **IP Address**. Select **Add Host**. Select **OK** to close the **DNS** dialog box. Select **Done**
|
||||
|
||||
1. Close the **DNS Manager**
|
||||
|
||||
</details>
|
||||
<br>
|
||||
@ -116,36 +110,36 @@ You need to host your new certificate revocation list on a web server so Azure A
|
||||
|
||||
These procedures configure NTFS and share permissions on the web server to allow the certificate authority to automatically publish the certificate revocation list.
|
||||
|
||||
#### Configure the CDP file share
|
||||
### Configure the CDP file share
|
||||
|
||||
1. On the web server, open **Windows Explorer** and navigate to the **cdp** folder you created in step 3 of [Configure the Web Server](#configure-the-web-server).
|
||||
2. Right-click the **cdp** folder and select **Properties**. Select the **Sharing** tab. Select **Advanced Sharing**.
|
||||
3. Select **Share this folder**. Type **cdp$** in **Share name**. Select **Permissions**.
|
||||
|
||||
4. In the **Permissions for cdp$** dialog box, select **Add**.
|
||||
5. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, select **Object Types**. In the **Object Types** dialog box, select **Computers**, and then select **OK**.
|
||||
7. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, in **Enter the object names to select**, type the name of the server running the certificate authority issuing the certificate revocation list, and then select **Check Names**. Select **OK**.
|
||||
8. In the **Permissions for cdp$** dialog box, select the certificate authority from the **Group or user names list**. In the **Permissions for** section, select **Allow** for **Full control**. Select **OK**.
|
||||
|
||||
9. In the **Advanced Sharing** dialog box, select **OK**.
|
||||
1. On the web server, open **Windows Explorer** and navigate to the **cdp** folder you created in step 3 of [Configure the Web Server](#configure-the-web-server)
|
||||
1. Right-click the **cdp** folder and select **Properties**. Select the **Sharing** tab. Select **Advanced Sharing**
|
||||
1. Select **Share this folder**. Type **cdp$** in **Share name**. Select **Permissions**
|
||||
|
||||
1. In the **Permissions for cdp$** dialog box, select **Add**.
|
||||
1. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, select **Object Types**. In the **Object Types** dialog box, select **Computers**, and then select **OK**.
|
||||
1. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, in **Enter the object names to select**, type the name of the server running the certificate authority issuing the certificate revocation list, and then select **Check Names**. Select **OK**.
|
||||
1. In the **Permissions for cdp$** dialog box, select the certificate authority from the **Group or user names list**. In the **Permissions for** section, select **Allow** for **Full control**. Select **OK**.
|
||||
|
||||
1. In the **Advanced Sharing** dialog box, select **OK**.
|
||||
|
||||
> [!Tip]
|
||||
> Make sure that users can access **\\\Server FQDN\sharename**.
|
||||
|
||||
#### Disable Caching
|
||||
### Disable Caching
|
||||
1. On the web server, open **Windows Explorer** and navigate to the **cdp** folder you created in step 3 of [Configure the Web Server](#configure-the-web-server).
|
||||
2. Right-click the **cdp** folder and select **Properties**. Select the **Sharing** tab. Select **Advanced Sharing**.
|
||||
3. Select **Caching**. Select **No files or programs from the shared folder are available offline**.
|
||||
|
||||
|
||||
4. Select **OK**.
|
||||
|
||||
#### Configure NTFS permission for the CDP folder
|
||||
### Configure NTFS permission for the CDP folder
|
||||
|
||||
1. On the web server, open **Windows Explorer** and navigate to the **cdp** folder you created in step 3 of [Configure the Web Server](#configure-the-web-server).
|
||||
2. Right-click the **cdp** folder and select **Properties**. Select the **Security** tab.
|
||||
3. On the **Security** tab, select Edit.
|
||||
5. In the **Permissions for cdp** dialog box, select **Add**.
|
||||
|
||||
|
||||
6. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, select **Object Types**. In the **Object Types** dialog box, select **Computers**. Select **OK**.
|
||||
7. In the **Select Users, Computers, Service Accounts, or Groups** dialog box, in **Enter the object names to select**, type the name of the certificate authority, and then select **Check Names**. Select **OK**.
|
||||
8. In the **Permissions for cdp** dialog box, select the name of the certificate authority from the **Group or user names** list. In the **Permissions for** section, select **Allow** for **Full control**. Select **OK**.
|
||||
@ -200,7 +194,7 @@ The web server is ready to host the CRL distribution point. Now, configure the i
|
||||
|
||||
1. On the issuing certificate authority, sign-in as a local administrator. Start the **Certificate Authority** console from **Administrative Tools**.
|
||||
2. In the navigation pane, right-click **Revoked Certificates**, hover over **All Tasks**, and select **Publish**
|
||||
|
||||
|
||||
3. In the **Publish CRL** dialog box, select **New CRL** and select **OK**.
|
||||
|
||||
#### Validate CDP Publishing
|
||||
@ -221,9 +215,9 @@ With the CA properly configured with a valid HTTP-based CRL distribution point,
|
||||
1. Sign-in a domain controller using administrative credentials.
|
||||
2. Open the **Run** dialog box. Type **certlm.msc** to open the **Certificate Manager** for the local computer.
|
||||
3. In the navigation pane, expand **Personal**. Select **Certificates**. In the details pane, select the existing domain controller certificate includes **KDC Authentication** in the list of **Intended Purposes**.
|
||||
|
||||
|
||||
4. Right-click the selected certificate. Hover over **All Tasks** and then select **Renew Certificate with New Key...**. In the **Certificate Enrollment** wizard, select **Next**.
|
||||
|
||||
|
||||
5. In the **Request Certificates** page of the wizard, verify the selected certificate has the correct certificate template and ensure the status is available. Select **Enroll**.
|
||||
6. After the enrollment completes, select **Finish** to close the wizard.
|
||||
7. Repeat this procedure on all your domain controllers.
|
||||
@ -241,16 +235,15 @@ With the CA properly configured with a valid HTTP-based CRL distribution point,
|
||||
3. In the navigation pane, expand **Personal**. Select **Certificates**. In the details pane, double-click the existing domain controller certificate includes **KDC Authentication** in the list of **Intended Purposes**.
|
||||
4. Select the **Details** tab. Scroll down the list until **CRL Distribution Points** is visible in the **Field** column of the list. Select **CRL Distribution Point**.
|
||||
5. Review the information below the list of fields to confirm the new URL for the CRL distribution point is present in the certificate. Select **OK**.</br>
|
||||
|
||||
|
||||
|
||||
</details>
|
||||
|
||||
## Deploy the root CA certificate to Azure AD-joined devices
|
||||
|
||||
The domain controllers have a certificate that include the new CRL distribution point. Next, you need the enterprise root certificate so you can deploy it to Azure AD-joined devices. When you deploy the enterprise root certificates to a device, it ensures the device trusts any certificates issued by the certificate authority. Without the certificate, Azure AD-joined devices don't trust domain controller certificates and authentication fails.
|
||||
|
||||
Expand each step to learn more:
|
||||
The domain controllers have a certificate that include the new CRL distribution point. Next, you need the enterprise root certificate so you can deploy it to Azure AD-joined devices. When you deploy the enterprise root certificates to a device, it ensures the device trusts any certificates issued by the certificate authority. Without the certificate, Azure AD-joined devices don't trust domain controller certificates and authentication fails. Expand each step to learn more:
|
||||
|
||||
<br>
|
||||
<details>
|
||||
<summary><b>Export the enterprise root certificate</b></summary>
|
||||
|
||||
@ -258,13 +251,13 @@ Expand each step to learn more:
|
||||
1. Open the **Run** dialog box. Type **certlm.msc** to open the **Certificate Manager** for the local computer.
|
||||
1. In the navigation pane, expand **Personal**. Select **Certificates**. In the details pane, double-click the existing domain controller certificate includes **KDC Authentication** in the list of **Intended Purposes**.
|
||||
1. Select the **Certification Path** tab. In the **Certification path** view, select the topmost node and select **View Certificate**.
|
||||
1. 
|
||||
|
||||
1. In the new **Certificate** dialog box, select the **Details** tab. Select **Copy to File**.
|
||||
1. 
|
||||
|
||||
1. In the **Certificate Export Wizard**, select **Next**.
|
||||
1. On the **Export File Format** page of the wizard, select **Next**.
|
||||
1. On the **File to Export** page in the wizard, type the name and location of the root certificate and select **Next**. Select **Finish** and then select **OK** to close the success dialog box. <br>
|
||||
1. 
|
||||
|
||||
1. Select **OK** two times to return to the **Certificate Manager** for the local computer. Close the **Certificate Manager**.
|
||||
|
||||
</details>
|
||||
|
||||
@ -107,12 +107,12 @@ Sign in to the CA or management workstations with **Enterprise Admin** equivalen
|
||||
Before moving to the next section, ensure the following steps are complete:
|
||||
|
||||
> [!div class="checklist"]
|
||||
> * Configure domain controller certificates
|
||||
> * Supersede existing domain controller certificates
|
||||
> * Unpublish superseded certificate templates
|
||||
> * Publish the certificate template to the CA
|
||||
> * Deploy certificates to the domain controllers
|
||||
> * Validate the domain controllers configuration
|
||||
> - Configure domain controller certificates
|
||||
> -_ Supersede existing domain controller certificates
|
||||
> - Unpublish superseded certificate templates
|
||||
> - Publish the certificate template to the CA
|
||||
> - Deploy certificates to the domain controllers
|
||||
> - Validate the domain controllers configuration
|
||||
|
||||
> [!div class="nextstepaction"]
|
||||
> [Next: configure and provision Windows Hello for Business >](hello-hybrid-key-trust-provision.md)
|
||||
|
||||
@ -35,7 +35,7 @@
|
||||
href: hello-hybrid-key-trust-validate-pki.md
|
||||
- name: Configure and provision Windows Hello for Business
|
||||
href: hello-hybrid-key-trust-provision.md
|
||||
- name: On-premises SSO for Azure AD joined devices
|
||||
- name: Configure SSO for Azure AD joined devices
|
||||
href: hello-hybrid-aadj-sso.md
|
||||
- name: Certificate trust deployment
|
||||
items:
|
||||
@ -63,7 +63,7 @@
|
||||
href: hello-hybrid-cert-whfb-settings-policy.md
|
||||
- name: Sign-in and provision Windows Hello for Business
|
||||
href: hello-hybrid-cert-whfb-provision.md
|
||||
- name: On-premises SSO for Azure AD joined devices
|
||||
- name: Configure SSO for Azure AD joined devices
|
||||
href: hello-hybrid-aadj-sso.md
|
||||
- name: Using certificates for on-premises SSO
|
||||
href: hello-hybrid-aadj-sso-cert.md
|
||||
|
||||
Reference in New Issue
Block a user