From 0b7eac5837a53f60ab1c4c66f1fef7ec00fdba5f Mon Sep 17 00:00:00 2001 From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com> Date: Fri, 31 Mar 2023 09:01:58 -0400 Subject: [PATCH] update --- windows/security/docfx.json | 12 +++--- .../hello-cert-trust-policy-settings.md | 6 --- .../hello-key-trust-policy-settings.md | 3 -- .../vpn/vpn-conditional-access.md | 38 ++++++++----------- 4 files changed, 21 insertions(+), 38 deletions(-) diff --git a/windows/security/docfx.json b/windows/security/docfx.json index 03b5fbffd6..5d4dda26a8 100644 --- a/windows/security/docfx.json +++ b/windows/security/docfx.json @@ -78,33 +78,33 @@ }, "appliesto":{ "identity-protection/**/*.md": [ - "✅ Windows 10", - "✅ Windows 11" + "✅ Windows 11", + "✅ Windows 10" ], "identity-protection/credential-guard/**/*.md": [ - "✅ Windows 10", "✅ Windows 11", + "✅ Windows 10", "✅ Windows Server 2022", "✅ Windows Server 2019", "✅ Windows Server 2016" ], "identity-protection/smart-cards/**/*.md": [ - "✅ Windows 10", "✅ Windows 11", + "✅ Windows 10", "✅ Windows Server 2022", "✅ Windows Server 2019", "✅ Windows Server 2016" ], "identity-protection/user-account-control/**/*.md": [ - "✅ Windows 10", "✅ Windows 11", + "✅ Windows 10", "✅ Windows Server 2022", "✅ Windows Server 2019", "✅ Windows Server 2016" ], "identity-protection/virtual-smart-cards/**/*.md": [ - "✅ Windows 10", "✅ Windows 11", + "✅ Windows 10", "✅ Windows Server 2022", "✅ Windows Server 2019", "✅ Windows Server 2016" diff --git a/windows/security/identity-protection/hello-for-business/hello-cert-trust-policy-settings.md b/windows/security/identity-protection/hello-for-business/hello-cert-trust-policy-settings.md index 2655617fd3..b3059ee0c0 100644 --- a/windows/security/identity-protection/hello-for-business/hello-cert-trust-policy-settings.md +++ b/windows/security/identity-protection/hello-for-business/hello-cert-trust-policy-settings.md @@ -5,12 +5,6 @@ ms.collection: - highpri - tier1 ms.date: 12/12/2022 -appliesto: -- ✅ Windows 11 -- ✅ Windows 10 -- ✅ Windows Server 2022 -- ✅ Windows Server 2019 -- ✅ Windows Server 2016 ms.topic: tutorial --- # Configure Windows Hello for Business group policy settings - on-premises certificate Trust diff --git a/windows/security/identity-protection/hello-for-business/hello-key-trust-policy-settings.md b/windows/security/identity-protection/hello-for-business/hello-key-trust-policy-settings.md index b82f904d68..3fd25ec607 100644 --- a/windows/security/identity-protection/hello-for-business/hello-key-trust-policy-settings.md +++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-policy-settings.md @@ -5,9 +5,6 @@ description: Configure Windows Hello for Business Policy settings for Windows He appliesto: - ✅ Windows 11 - ✅ Windows 10 -- ✅ Windows Server 2022 -- ✅ Windows Server 2019 -- ✅ Windows Server 2016 ms.topic: tutorial --- # Configure Windows Hello for Business group policy settings - on-premises key trust diff --git a/windows/security/identity-protection/vpn/vpn-conditional-access.md b/windows/security/identity-protection/vpn/vpn-conditional-access.md index 57e7acde2a..392b5cf099 100644 --- a/windows/security/identity-protection/vpn/vpn-conditional-access.md +++ b/windows/security/identity-protection/vpn/vpn-conditional-access.md @@ -53,23 +53,19 @@ After the server side is set up, VPN admins can add the policy settings for cond Two client-side configuration service providers are leveraged for VPN device compliance. - VPNv2 CSP DeviceCompliance settings: - - - **Enabled**: enables the Device Compliance flow from the client. If marked as **true**, the VPN client attempts to communicate with Azure AD to get a certificate to use for authentication. The VPN should be set up to use certificate authentication and the VPN server must trust the server returned by Azure AD. - - **Sso**: entries under SSO should be used to direct the VPN client to use a certificate other than the VPN authentication certificate when accessing resources that require Kerberos authentication. - - **Sso/Enabled**: if this field is set to **true**, the VPN client looks for a separate certificate for Kerberos authentication. - - **Sso/IssuerHash**: hashes for the VPN client to look for the correct certificate for Kerberos authentication. - - **Sso/Eku**: comma-separated list of extended key usage (EKU) extensions for the VPN client to look for the correct certificate for Kerberos authentication. - + - **Enabled**: enables the Device Compliance flow from the client. If marked as **true**, the VPN client attempts to communicate with Azure AD to get a certificate to use for authentication. The VPN should be set up to use certificate authentication and the VPN server must trust the server returned by Azure AD. + - **Sso**: entries under SSO should be used to direct the VPN client to use a certificate other than the VPN authentication certificate when accessing resources that require Kerberos authentication. + - **Sso/Enabled**: if this field is set to **true**, the VPN client looks for a separate certificate for Kerberos authentication. + - **Sso/IssuerHash**: hashes for the VPN client to look for the correct certificate for Kerberos authentication. + - **Sso/Eku**: comma-separated list of extended key usage (EKU) extensions for the VPN client to look for the correct certificate for Kerberos authentication. - HealthAttestation CSP (not a requirement) - functions performed by the HealthAttestation CSP include: + - Collects TPM data used to verify health states + - Forwards the data to the Health Attestation Service (HAS) + - Provisions the Health Attestation Certificate received from the HAS + - Upon request, forward the Health Attestation Certificate (received from HAS) and related runtime information to the MDM server for verification - - Collects TPM data used to verify health states - - Forwards the data to the Health Attestation Service (HAS) - - Provisions the Health Attestation Certificate received from the HAS - - Upon request, forward the Health Attestation Certificate (received from HAS) and related runtime information to the MDM server for verification - > [!NOTE] -> Currently, it is required that certificates used for obtaining Kerberos tickets must be issued from an on-premises CA, and that SSO must be enabled in the user's VPN profile. This will enable the user to access on-premises resources. -> +> It's required that certificates used for obtaining Kerberos tickets to be issued from an on-premises CA, and that SSO to be enabled in the user's VPN profile. This will enable the user to access on-premises resources. > In the case of AzureAD-only joined devices (not hybrid joined devices), if the user certificate issued by the on-premises CA has the user UPN from AzureAD in Subject and SAN (Subject Alternative Name), the VPN profile must be modified to ensure that the client does not cache the credentials used for VPN authentication. To do this, after deploying the VPN profile to the client, modify the *Rasphone.pbk* on the client by changing the entry **UseRasCredentials** from 1 (default) to 0 (zero). ## Client connection flow @@ -80,15 +76,11 @@ The VPN client side connection flow works as follows: When a VPNv2 Profile is configured with \ \true<\/Enabled> the VPN client uses this connection flow: -1. The VPN client calls into Windows 10's or Windows 11's Azure AD Token Broker, identifying itself as a VPN client. - -2. The Azure AD Token Broker authenticates to Azure AD and provides it with information about the device trying to connect. The Azure AD Server checks if the device is in compliance with the policies. - -3. If compliant, Azure AD requests a short-lived certificate. - -4. Azure AD pushes down a short-lived certificate to the Certificate Store via the Token Broker. The Token Broker then returns control back over to the VPN client for further connection processing. - -5. The VPN client uses the Azure AD-issued certificate to authenticate with the VPN server. +1. The VPN client calls into Windows 10's or Windows 11's Azure AD Token Broker, identifying itself as a VPN client. +1. The Azure AD Token Broker authenticates to Azure AD and provides it with information about the device trying to connect. The Azure AD Server checks if the device is in compliance with the policies. +1. If compliant, Azure AD requests a short-lived certificate. +1. Azure AD pushes down a short-lived certificate to the Certificate Store via the Token Broker. The Token Broker then returns control back over to the VPN client for further connection processing. +1. The VPN client uses the Azure AD-issued certificate to authenticate with the VPN server. ## Configure conditional access