Adsf

Revolutionize Remote Access with Microsoft Entra Private Access: SSO via Windows Hello & Cloud Kerberos Trust

 

Revolutionize Remote Access with Microsoft Entra Private Access: SSO via Windows Hello & Cloud Kerberos Trust


Overview

In my previous blog, i demonstrated how Microsoft Entra Private Access transforms remote access by eliminating the need for traditional VPNs. We explored accessing file servers using a Microsoft Entra ID joined device signed in with a password.

Microsoft Entra ID joined devices rely on Active Directory domain and user information synchronized via Microsoft Entra ID Connect. The Windows domain controller locator identifies the domain controllers, ensuring seamless access. The user's User Principal Name (UPN) and password are then used to request a Kerberos Ticket Granting Ticket (TGT)—a core component of Single Sign-On (SSO). For a detailed breakdown of this flow, check out How SSO to on-premises resources works on Microsoft Entra joined devices.


Why Kerberos-Based SSO with WHfB Matters

SSO simplifies access to on-premises resources by removing the hassle of multiple logins, and Kerberos enhances this process by ensuring secure and efficient authentication. With Microsoft Entra Private Access, you can publish on-premises resources like file servers or domain controllers and enable SSO for Entra joined devices.

But why stop at password-based SSO? Enter Windows Hello for Business (WHfB)—a passwordless authentication method that provides an even more secure and seamless user experience. With Cloud Kerberos Trust, WHfB ensures that your organization leverages cutting-edge authentication technologies.

The Key Benefits of Using WHfB with Entra Private Access

  1. Enhanced Security: Passwordless authentication reduces the risk of password-related breaches.
  2. Seamless Experience: Users get instant access to on-premises resources without repeatedly entering credentials.
  3. Future-Ready: WHfB aligns with modern security practices and standards, ensuring your organization stays ahead.

In this Blog, we'll dive into the steps required to enable Kerberos-based SSO for on-premises resources published through Microsoft Entra Private Access using WHfB. Stay tuned as we walk through prerequisites, configuration steps, and best practices to revolutionize your organization's remote access.


Prerequisites: Preparing Your Environment

Before configuring SSO, ensure the following:

  1. Active Directory Setup:
    • A functional Active Directory (AD).
  2. Entra Private Access Forwarding Profile:

    • Enable the forwarding profile.
  3. Connector Installation:

    • Install the latest Microsoft Entra Private Access connector on a Windows server with access to your domain controllers.
  4. Global Secure Access Configuration:
    • Ensure the latest version is deployed.

Please refer to my previous blogs for the setup and configuration of Microsoft Entra Private Access.


Publishing On-Premises Resources

To allow SSO for on-premises resources, you'll publish them using Enterprise Applications in Microsoft Entra.

Step 1: Create an Enterprise Application

  • Sign in as an Application Administrator.
  • Go to Global Secure Access > Applications > Enterprise Applications.
  • Select New Application.

Step 2: Add a Resource

  • Configure the application to publish the required resource (e.g., a file share).
  • Define an app segment with the file server's IP address\FQDN using port 445/TCP (SMB protocol).
  • Save the settings.

Step 3: Assign Access

  • Open the created enterprise application.
  • Go to Users and Groups to assign users or groups access to the resource.
We previously published a File Server during the preparation of our earlier blog, and we will use the same setup for this.

Entra Private Access File Server Application

Configuring SSO for Entra ID Devices

Microsoft Entra ID Joined Devices

For devices where users log in using passwords:

  • No additional configuration is required.
  • Entra ID synchronizes domain and user details through Entra ID Connect.
  • Kerberos tickets are automatically requested using the user's credentials.

We have already tested this in our previous blog with File Server access.

Microsoft Entra ID Joined or Hybrid Joined Devices with WHfB

To enable Windows Hello for Business SSO using Cloud Kerberos Trust: Please refer my Blog:
Mastering Windows Hello for Business: Your Ultimate Deployment Guide

Title:"WHfB Hybrid, Cloud Kerberos Trust Deployment "

Publishing Domain Controllers for Kerberos

To issue Kerberos tickets, domain controllers must be published.

Steps to Publish Domain Controller using Entra Private Access:

Create a new Enterprise Application for your domain controllers.


Add app segments for each domain controller's IP or FQDN:
  • Publish the required ports:
    • UDP & TCP     88 : Kerberos
    • UDP                389: DC Locator
    • UDP & TCP    464: Password Change Request
    • UDP                123: Time Synchronization

Note: Avoid using wildcard FQDNs; specify individual IPs or FQDNs instead.

Below Screenshot shows the configuration

DC Published through Entra Private Access

  • Assign access to users synchronized from AD.
Entra Private Access App User Assignment

Configuring Private DNS for Entra Private Access

To enable seamless SSO, private DNS resolution is required.

Steps:

  • Navigate to Global Secure Access > Applications > Quick Access.
  • Select the Private DNS tab and enable it.
  • Add DNS suffixes for your Active Directory forests.
  • Save the configuration.
Below Screenshot shows the configuration
Entra Private Access, Private DNS configuration

End-User Experience: Accessing the File Server with Windows Hello for Business Login


Let’s test the end-user experience when logging in with Windows Hello for Business from an Entra-joined Windows 11 PC (in my case, I used a PIN to log in). The user will then attempt to access a file server published using Entra Private Access.

User Login with windows hello PIN option
Windows Hello for Business Login

User Device Login status:
User Device Login status


File server access was successful, and the Kerberos ticket was obtained successfully
Accessing the File Server with Windows Hello for Business Login via Entra Private Access

Simplifying SMB File Share Access with Kerberos SSO and Microsoft Entra Private Access

This diagram illustrates the process of accessing an SMB file share using Microsoft Entra Private Access on a Windows device configured with Windows Hello for Business (WHfB) with Cloud Trust. 

In this example, We have configured  Quick Access Private DNS and two enterprise applications—one for Domain Controller and another for the SMB file share.


Kerberos SSO to Access an SMB File Share with WHfB

Image Source: Microsoft

Step-by-Step Description of the Authentication Process

Step A: User Attempts to Access SMB File Share

  • The user accesses the SMB file share using its Fully Qualified Domain Name (FQDN)\IP.
  • The GSA client intercepts this traffic and tunnels it to the SSE Edge.
  • Microsoft Entra ID evaluates authorization policies, such as:
    • User assignment to the application.
    • Conditional Access policies.
  • Upon successful authorization, Microsoft Entra ID issues a token for the SMB Enterprise Application.
  • The traffic, along with the access token, proceeds to the Private Access service.
  • The Private Access service validates the token and brokers the connection to the backend service.
  • The connection is then relayed to the Private Network Connector.

Step B: Private Network Connector Resolves Target Server

  • The Private Network Connector performs a DNS query to resolve the target server’s IP address.
  • The private network's DNS service responds with the IP address.
  • The connector initiates a connection to the SMB file share, which requests Kerberos authentication.

Step C: Locating Domain Controllers

  • The client generates an SRV DNS query to locate domain controllers.
  • The GSA client intercepts the DNS query, repeating authorization policies from Step A, for the Quick Access application.
  • The SRV DNS query is sent to the private network through the Private Network Connector.
  • The DNS service responds, providing the domain controllers’ details to the client via the connector.

Step D: Requesting Partial TGT

  • The Windows device requests a partial Ticket-Granting Ticket (TGT), also known as Cloud TGT, from Microsoft Entra ID (if not already available).
  • Microsoft Entra ID issues the partial TGT.

Step E: Domain Controller Locator Connection

  • Windows initiates a Domain Controller (DC) locator connection over UDP port 389, targeting each domain controller listed in the DNS response from Step C.
  • The GSA client intercepts this traffic, repeating authorization policies from Step A, for the enterprise application representing the domain controllers.
  • The connector forwards DC locator traffic to the domain controllers in the private network.
  • Domain controllers respond, and the fastest-response domain controller is cached by Windows.

Step F: Exchanging Partial TGT for Full TGT

  • The client exchanges the partial TGT for a full TGT from the selected domain controller.
  • The full TGT is then used to request and receive a Ticket Granting Service (TGS) ticket for the SMB file share.

Step G: Accessing the SMB File Share

  • The client presents the TGS to the SMB file share.
  • The SMB file share validates the TGS and grants access to the requested resource.

Troubleshooting

Avoiding Kerberos Negative Caching on Windows Machines

Kerberos is the preferred authentication method in Windows for validating user or host identities. However, Kerberos negative caching can delay ticket issuance when using the Global Secure Access (GSA) client.

Issue

Kerberos negative caching occurs when the GSA client attempts to connect to the nearest Domain Controller (DC), but the request fails due to:

  • The GSA client not being connected.
  • The DC being temporarily unreachable.

After a failure, the client waits for the default FarKdcTimeout (10 minutes) before retrying, even if the GSA client reconnects sooner. During this period, the client holds a negative cache entry, causing delays in accessing resources.

Solutions

Option 1: Adjust the FarKdcTimeout Value

Modify the default timeout in the Windows registry to reduce delays:

Navigate to:

 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

Create the Parameters key (if it doesn't exist.)

Add or modify the following entry:

Entry: FarKdcTimeout
Type: REG_DWORD
Value: Set a custom time-out (in minutes)
Adjust the FarKdcTimeout Value


**You can deploy this registry configuration to Entra Hybrid joined\ Entra-joined devices using a PowerShell script or Intune.

Option 2: Manually Flush the Kerberos Cache

Clear the Kerberos cache whenever the GSA client is restarted:

Open a Command Prompt as an administrator.(Not a feasible option if the user does not have administrative rights on their PC.)

Run the command KLIST PURGE_BIND


Conclusion

In this blog, i demonstrated how to use Kerberos SSO with Microsoft Entra Private Access to enable seamless and secure access to SMB file shares. By leveraging Windows Hello for Business and Cloud Trust, organizations can enhance user authentication while reducing reliance on traditional passwords.

We also addressed common challenges like Kerberos negative caching, providing actionable solutions to mitigate delays and improve the end-user experience. With practical deployment options using PowerShell scripts or Intune, IT administrators can streamline configuration for Entra-joined devices across their environment.

This integration showcases the power of modern authentication methods, reinforcing security and user convenience. By implementing these best practices, you can ensure a secure, efficient, and user-friendly access experience for your organization.

Feel free to reach out with questions or share your feedback in the comments!

 

Post a Comment

0 Comments

Add