I have noticed in the Azure community, that there is a seemingly common desire for something that has been missing from Azure since its inception, and that is a Kerberos realm service in Azure Active Directory. A solution to support customers whilst they transition to modern authentication methods and re-develop their applications and processes. Native support for this function has been a long time coming and is a topic of conversation in wider circles than one would assume. Luckily, this wait now appears to be over…
Traditional Active Directory, in a traditional Windows Server environment, uses the NTLM and Kerberos protocols to provide authentication services and is a key component of security architecture in a domain. Kerberos authentication protocol is named after the mythical three-headed guardian dog of Hades, because the protocol has three different components and is used to make access secure. To simplify, the components consist of an application, the server and the domain controller which acts as third-party broker in the process, that issues tokens to access the application based on trust relationships.
Kerberos in its many iterations has been around and used for many years now, being originally conceived in the late 1970s. Azure Active Directory (AAD), however, uses modern identity services like OAuth, OpenID Connect and SAML, which work in a different way. They leverage newer technology and architecture and use a multi-tenant cloud identity service implemented completely differently to traditional Windows Server domains. It supports features like multifactor authentication and conditional access which are now becoming standard organisational cybersecurity requirements. With that in mind, the two are not compatible historically.
If you needed Kerberos authentication services in your Azure environment previously, you would need to either stand up a Windows Server Domain Controller as an IaaS VM, which could support extending your on-premises DC via a VPN, or you could use the managed Azure Active Domain Services service.
Kerberos Realms in Azure Active Directory is now in preview! Azure Active Directory can now be configured to be the issuer of Kerberos tickets, bringing 100% cloud authentication that step closer.
Just like Kerberos, three different components are required for this to work. In this example we will use Azure Virtual Desktop:
- The VM - these need to be Azure AD joined and have their configuration changed. This needs to be Windows 10 release KB5007253 or above, Windows 11, or Server 2022.
- The service that we're going to access – for example, Azure Files for FSLogix profiles in Azure Virtual Desktop (one of the first supported in preview).
- An Azure Active Directory application, which is going to function as a service principle, so Azure AD can talk to the file share and complete the Kerberos authentication process.
User accounts need to be hybrid users meaning that they need to be synced from the traditional Active directory over to Azure Active Directory using Azure AD Connect. Admittedly, this doesn’t make the architecture 100% cloud-based yet, but development is certainly happening to move it that way in the future. There doesn’t however need to be any line of site for the client between traditional AD and the client, the service can be done solely through Azure Active Directory.
For Azure AD to do the brokering between the client and the service, both must be known to it, so there must be a record of each held. So, you would have the client that is AAD joined, but the storage account service must have representation in AAD as well. This is done as an app registration under the AAD tab within the portal.
Together with the storage account representation there must be a key created so that the storage account can share with AAD, to prove that they trust each other. This all works over port 443 Kerberos Proxy over the internet so has no issues with security.
Hopefully this is useful, however if you want to discuss anything regarding the Microsoft Azure Platform in more detail, please get in touch and we can arrange a call to discuss further.