diff --git a/.openpublishing.redirection.windows-security.json b/.openpublishing.redirection.windows-security.json index 2b34fcdd78..64189c6d0c 100644 --- a/.openpublishing.redirection.windows-security.json +++ b/.openpublishing.redirection.windows-security.json @@ -8054,6 +8054,11 @@ "source_path": "windows/security/identity-protection/hello-for-business/hello-feature-pin-reset.md", "redirect_url": "/windows/security/identity-protection/hello-for-business/pin-reset", "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-adequate-domain-controllers.md", + "redirect_url": "/windows-server/administration/performance-tuning/role/active-directory-server/capacity-planning-for-active-directory-domain-services", + "redirect_document_id": false } ] } \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/hello-deployment-guide.md b/windows/security/identity-protection/hello-for-business/hello-deployment-guide.md index 23f770c35f..3ecc3b1a4f 100644 --- a/windows/security/identity-protection/hello-for-business/hello-deployment-guide.md +++ b/windows/security/identity-protection/hello-for-business/hello-deployment-guide.md @@ -43,7 +43,7 @@ The trust model determines how you want users to authenticate to the on-premises - The certificate-trust model is for enterprises that *do* want to issue end-entity certificates to their users and have the benefits of certificate expiration and renewal, similar to how smart cards work today. - The certificate trust model also supports enterprises, which aren't ready to deploy Windows Server 2016 Domain Controllers. -> [!Note] +> [!NOTE] > RDP does not support authentication with Windows Hello for Business Key Trust or cloud Kerberos trust deployments as a supplied credential. RDP is only supported with certificate trust deployments as a supplied credential at this time. Windows Hello for Business Key Trust and cloud Kerberos trust can be used with [Remote Credential Guard](../remote-credential-guard.md). Following are the various deployment guides and models included in this topic: diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md index 7f82f9089c..0c5d9ba7d7 100644 --- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md +++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md @@ -16,11 +16,11 @@ Windows Hello for Business provisioning enables a user to enroll a new, strong, List of provisioning flows: -- [Microsoft Entra joined provisioning in a managed environment](#azure-ad-joined-provisioning-in-a-managed-environment) -- [Microsoft Entra joined provisioning in a federated environment](#azure-ad-joined-provisioning-in-a-federated-environment) -- [Microsoft Entra hybrid joined provisioning in a cloud Kerberos trust deployment in a managed environment](#hybrid-azure-ad-joined-provisioning-in-a-cloud-kerberos-trust-deployment-in-a-managed-environment) -- [Microsoft Entra hybrid joined provisioning in a key trust deployment in a managed environment](#hybrid-azure-ad-joined-provisioning-in-a-key-trust-deployment-in-a-managed-environment) -- [Microsoft Entra hybrid joined provisioning in a synchronous certificate trust deployment in a federated environment](#hybrid-azure-ad-joined-provisioning-in-a-synchronous-certificate-trust-deployment-in-a-federated-environment) +- [Microsoft Entra joined provisioning in a managed environment](#microsoft-entra-joined-provisioning-in-a-managed-environment) +- [Microsoft Entra joined provisioning in a federated environment](#microsoft-entra-joined-provisioning-in-a-federated-environment) +- [Microsoft Entra hybrid joined provisioning in a cloud Kerberos trust deployment in a managed environment](#microsoft-entra-hybrid-joined-provisioning-in-a-cloud-kerberos-trust-deployment-in-a-managed-environment) +- [Microsoft Entra hybrid joined provisioning in a key trust deployment in a managed environment](#microsoft-entra-hybrid-joined-provisioning-in-a-key-trust-deployment-in-a-managed-environment) +- [Microsoft Entra hybrid joined provisioning in a synchronous certificate trust deployment in a federated environment](#microsoft-entra-hybrid-joined-provisioning-in-a-synchronous-certificate-trust-deployment-in-a-federated-environment) - [Domain joined provisioning in an On-premises key trust deployment](#domain-joined-provisioning-in-an-on-premises-key-trust-deployment) - [Domain joined provisioning in an On-premises certificate trust deployment](#domain-joined-provisioning-in-an-on-premises-certificate-trust-deployment) @@ -108,6 +108,7 @@ List of provisioning flows: |C | The application sends the EDRS token, ukpub, attestation data, and device information to the Enterprise DRS for user key registration. Enterprise DRS validates the MFA claim remains current. On successful validation, the Enterprise DRS locates the user's object in 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. The Enterprise DRS returns a key ID to the application, which represents the end of user key registration.| ## Domain joined provisioning in an On-premises Certificate Trust deployment + ![Domain joined provisioning in an On-premises Certificate Trust deployment.](images/howitworks/prov-onprem-certtrust.png) [Full size image](images/howitworks/prov-onprem-certtrust.png) diff --git a/windows/security/identity-protection/hello-for-business/hello-planning-guide.md b/windows/security/identity-protection/hello-for-business/hello-planning-guide.md index 5c7a0cd1d5..ad098ec2dc 100644 --- a/windows/security/identity-protection/hello-for-business/hello-planning-guide.md +++ b/windows/security/identity-protection/hello-for-business/hello-planning-guide.md @@ -167,10 +167,11 @@ If your organization doesn't have on-premises resources, write **Cloud Only** in If your organization is federated with Azure or uses any service, such as AD Connect, Office365 or OneDrive, or your users access cloud and on-premises resources, write **Hybrid** in box **1a** on your planning worksheet. If your organization doesn't have cloud resources, write **On-Premises** in box **1a** on your planning worksheet. -> [!NOTE] -> * Main use case of On-Premises deployment is for "Enhanced Security Administrative Environments" also known as "Red Forests". -> * Migration from on-premise to hybrid deployment will require redeployment. +>[!NOTE] +> +>- Main use case of On-Premises deployment is for "Enhanced Security Administrative Environments" also known as "Red Forests" +>- Migration from on-premise to hybrid deployment will require redeployment ### Trust type @@ -277,7 +278,7 @@ Write **1703 or later** in box **3a** on your planning worksheet if any of the f ### Active Directory -The Active Directory portion of the planning guide should be complete. Most of the conditions are baseline prerequisites except for your domain controllers. The domain controllers used in your deployment are decided by the chosen trust type. +The Active Directory portion of the planning guide should be complete. Most of the conditions are baseline prerequisites except for your domain controllers. The domain controllers used in your deployment are decided by the chosen trust type. Review the trust type portion of this section if box **4d** on your planning worksheet remains empty. @@ -289,7 +290,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 nondomain joined devices. Microsoft Entra hybrid joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates. Microsoft Entra hybrid joined devices and Microsoft Entra 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 nondomain joined devices. Microsoft Entra hybrid joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates. Microsoft Entra hybrid joined devices and Microsoft Entra 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: @@ -305,8 +306,8 @@ If box **2a** reads **GP** and box **2b** reads **N/A**, write **AD FS RA** in b | Certificate Template Name | Issued To | | --- | --- | -| Exchange Enrollment Agent | AD FS RA | -| Web Server | AD FS RA | +| Exchange Enrollment Agent | AD FS RA | +| Web Server | AD FS RA | If box **2a** or **2b** reads modern management, write **NDES** in box **5b** and write the following certificate template names and issuances in box 5c on your planning worksheet. diff --git a/windows/security/operating-system-security/network-security/vpn/how-to-use-single-sign-on-sso-over-vpn-and-wi-fi-connections.md b/windows/security/operating-system-security/network-security/vpn/how-to-use-single-sign-on-sso-over-vpn-and-wi-fi-connections.md index f61993984e..a3bf98bb64 100644 --- a/windows/security/operating-system-security/network-security/vpn/how-to-use-single-sign-on-sso-over-vpn-and-wi-fi-connections.md +++ b/windows/security/operating-system-security/network-security/vpn/how-to-use-single-sign-on-sso-over-vpn-and-wi-fi-connections.md @@ -1,13 +1,13 @@ --- -title: How to use Single Sign-On (SSO) over VPN and Wi-Fi connections -description: Explains requirements to enable Single Sign-On (SSO) to on-premises domain resources over WiFi or VPN connections. -ms.date: 08/03/2023 +title: How to use single sign-on (SSO) over VPN and Wi-Fi connections +description: Explains requirements to enable single sign-on (SSO) to on-premises domain resources over WiFi or VPN connections. +ms.date: 12/12/2023 ms.topic: how-to --- -# How to use Single Sign-On (SSO) over VPN and Wi-Fi connections +# How to use single sign-on (SSO) over VPN and Wi-Fi connections -This article explains requirements to enable Single Sign-On (SSO) to on-premises domain resources over Wi-Fi or VPN connections. The following scenarios are typically used: +This article explains requirements to enable single sign-on (SSO) to on-premises domain resources over Wi-Fi or VPN connections. The following scenarios are typically used: - Connecting to a network using Wi-Fi or VPN - Use credentials for Wi-Fi or VPN authentication to also authenticate requests to access domain resources, without being prompted for domain credentials @@ -21,7 +21,7 @@ The credentials that are used for the connection authentication are placed in *C The credentials are placed in Credential Manager as a *session credential*: -- A *session credential* implies that it is valid for the current user session +- A *session credential* implies that it's valid for the current user session - The credentials are cleaned up when the Wi-Fi or VPN connection is disconnected > [!NOTE] @@ -30,22 +30,22 @@ The credentials are placed in Credential Manager as a *session credential*: For example, if someone using Microsoft Edge tries to access a domain resource, Microsoft Edge has the right Enterprise Authentication capability. This allows [WinInet](/windows/win32/wininet/wininet-reference) to release the credentials that it gets from Credential Manager to the SSP that is requesting it. For more information about the Enterprise Authentication capability, see [App capability declarations](/windows/uwp/packaging/app-capability-declarations). -The local security authority will look at the device application to determine if it has the right capability. This includes items such as a Universal Windows Platform (UWP) application. +The local security authority looks at the device application to determine if it has the right capability. This includes items such as a Universal Windows Platform (UWP) application. If the app isn't a UWP, it doesn't matter. -But, if the application is a UWP app, it will evaluate at the device capability for Enterprise Authentication. -If it does have that capability and if the resource that you're trying to access is in the Intranet zone in the Internet Options (ZoneMap), then the credential will be released. +But, if the application is a UWP app, it evaluates at the device capability for Enterprise Authentication. +If it does have that capability and if the resource that you're trying to access is in the Intranet zone in the Internet Options (ZoneMap), then the credential is released. This behavior helps prevent credentials from being misused by untrusted third parties. ## Intranet zone -For the Intranet zone, by default it only allows single-label names, such as *http://finance*. +For the Intranet zone, by default it only allows single-label names, such as `http://finance`. If the resource that needs to be accessed has multiple domain labels, then the workaround is to use the [Registry CSP](/windows/client-management/mdm/registry-csp). ### Setting the ZoneMap The ZoneMap is controlled using a registry that can be set through MDM. -By default, single-label names such as *http://finance* are already in the intranet zone. -For multi-label names, such as *http://finance.net*, the ZoneMap needs to be updated. +By default, single-label names such as `http://finance` are already in the intranet zone. +For multi-label names, such as `http://finance.net`, the ZoneMap needs to be updated. ## MDM Policy @@ -72,8 +72,8 @@ If the credentials are certificate-based, then the elements in the following tab | Template element | Configuration | |------------------|---------------| -| 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.
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.
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. | +| SubjectName | The user's distinguished name (DN) where the domain components of the distinguished name reflect the internal DNS namespace when the SubjectAlternativeName doesn't have the fully qualified UPN required to find the domain controller.
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.
This requirement is relevant in multi-forest environments as it ensures a domain controller can be located when the SubjectName doesn't have the DN required to find the domain controller. | | Key Storage Provider (KSP) | If the device is joined to Microsoft Entra ID, a discrete SSO certificate is used. | | EnhancedKeyUsage | One or more of the following EKUs is required:
If the domain controllers require smart card EKU either:Otherwise:
| @@ -86,9 +86,6 @@ For more information, see [Configure certificate infrastructure for SCEP](/mem/i You need IP connectivity to a DNS server and domain controller over the network interface so that authentication can succeed as well. -Domain controllers must have appropriate KDC certificates for the client to trust them as domain controllers. Because phones are not domain-joined, the root CA of the KDC's certificate must be in the Third-Party Root CA or Smart Card Trusted Roots store. +Domain controllers must have appropriate KDC certificates for the client to trust them as domain controllers. Because phones aren't domain-joined, the root CA of the KDC's certificate must be in the Third-Party Root CA or Smart Card Trusted Roots store. -Domain controllers must be using certificates based on the updated KDC certificate template Kerberos Authentication. -This requires that all authenticating domain controllers run Windows Server 2016, or you'll need to enable strict KDC validation on domain controllers that run previous versions of Windows Server. - -For more information, see [Enabling Strict KDC Validation in Windows Kerberos](https://www.microsoft.com/download/details.aspx?id=6382). +Domain controllers must be using certificates based on the updated *KDC certificate template* Kerberos Authentication.