End-user and Administrative Benefits of Entra ID Authentication

Entra ID, formerly known as Azure AD, offers the convenience of single sign-on and the enhanced security of passwordless authentication for end users. You can read this report for more details on the benefits of passwordless authentication. This combination not only streamlines the user experience but also strengthens the security of the authentication process. For example, I do not have a password for my account at work. When I log on to my Windows 11 machine, I either smile for the camera and use face recognition or enter my PIN. I never have to worry about changing my password. My company’s resources are in the cloud and all authentication and authorization is done using Entra ID

Many companies depend on an on-premises Active Directory to secure access to applications and resources that have not been migrated to the cloud for a variety of reasons, including technical challenges and business decisions.  Access to these on-premises resources can block an organization’s migration to Entra ID (Azure AD) joined machines. What if it was possible to leverage all of the benefits of Entra ID and be able to access on-premises resources without having to join a workstation to a domain?

Seamlessly Access Resources Protected by Entra ID and Active Directory

Windows Hello for Business cloud Kerberos Trust allows you to access on-premises resources using Kerberos authentication from a workstation that is Entra ID (Azure AD) joined. Hybrid joins are not required. Using cloud Kerberos Trust, a user can log on to a Windows machine using Windows Hello for Business and access on-premises resources such as file shares or an IIS website with Kerberos authentication.

Here is a high-level overview of how Kerberos works: Kerberos uses a secure ticketing system to grant users access to resources. The first thing a client needs is a Ticket Granting Ticket, also known as a TGT. The TGT acts like a special key used to ask for another ticket called a Service Ticket. This Service Ticket grants access to something specific, like a file share or a SQL database. In a pure on-premises scenario, Active Directory domain controllers issue TGTs.

In a typical Windows Hello for Business deployment, there are no domain controllers.  

Using cloud Kerberos trust, an administrator can create an Entra ID Kerberos Server object in Active Directory that is securely published to Entra ID by following the steps in this article. The Kerberos server object technically is an RODC (read-only domain controller) object. This RODC object is not associated with any actual servers. It is like creating a computer object in AD before joining a computer to the domain.

Using the published Kerberos Server object, Entra ID can generate a Kerberos TGT for an on-premises Active Directory domain. It is important to understand that the ticket generated by Entra ID is a partial TGT, and only includes the user’s SID, with no authorization data. Once the client can contact an on-premises domain controller, the partial TGT is exchanged for a complete TGT.  The client, in possession of both a TGT and a Primary Refresh Token (PRT) from Entra ID, now has seamless access to both cloud applications and a company’s on-premises resources.

Figure 1 shows how this flow works.

Implementing Cloud Kerberos Trust

Details for implementing Cloud Kerberos Trust are available online. The article provides all the information you need to get Cloud Kerberos Trust working. However, there are three additional items that should be considered when implementing Cloud Kerberos Trust.

First, the list of unsupported scenarios includes Remote Desktop Protocol (RDP) using a security key. Cloud Kerberos Trust can connect to a server via RDP that supports Remote Credential Guard. To use Remote Credential Guard, the RDP client mstsc.exe must be launched with the “/remoteguard” switch. Additionally, the server that you connect to must support RestrictedAdmin mode. This is done by adding a new DWORD value named “DisableRestrictedAdmin” to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\ and setting the value to 0.

Second, Microsoft’s article mentions that the AzureADHybridAuthenticationManagement PowerShell module used to create the Kerberos server object in Entra ID depends on the AzureADPreview module. The AzureAD and AzureADPreview modules will be deprecated on March 30^th, 2024. At some point, Microsoft will have to update the module to use the Microsoft Graph PowerShell SDK instead. This should be considered when choosing where to install the AzureADHybridAuthenticationManagement module.  

Finally, it is important to recognize that by using Cloud Kerberos Trust, AD is essentially trusting Entra ID (Azure AD). While this is technically nothing like a traditional trust in Active Directory, similar precautions should be in place. Highly privileged accounts in Entra ID should be protected using tools like Privileged Identity Management. Privileged users should exist in the environment they manage. Do not sync privileged AD accounts into Entra ID. Likewise, ensure that standard AD accounts being synced to Entra ID are not members of privileged Entra ID roles.

What’s Next?

Could the Cloud Kerberos Trust be the final step in allowing you to move workstations to Azure AD joined machines? If your users still work with a handful of on-premises applications that cannot be migrated anytime soon, it might be worth testing cloud Kerberos trust for your scenario. You could allow your users to continue to work with on-premises applications and reap the benefits of Entra ID and modern, passwordless authentication.