Kerberos 101

Authenticating with Domain Controller

The Kerberos protocol operates in two primary stages:

Authentication Service Request (AS-REQ):

• When you log in, you authenticate yourself to the domain controller (DC).
• Instead of sending the password over the network, the client uses the password to create a cryptographic key and sends a request to the DC.
• The DC performs the same cryptographic operation on its stored version of the password to verify the user’s identity.
• If successful, the DC issues a Ticket-Granting Ticket (TGT) to the client. This TGT allows the user to request service tickets for various resources within the domain without needing to re-authenticate each time.

Ticket-Granting Service (TGS):

• With the TGT, the client can request access to specific services.
• The client presents the TGT to the Ticket-Granting Service, which verifies the TGT and issues a service ticket for the requested resource.
• This service ticket is then used by the client to authenticate to the desired service.

Steps involved in Kerberos Authentication

• Initial Login: When you log in to a Windows machine, a background process is initiated to handle the Kerberos authentication. This process occurs while you are already accessing the desktop due to the fast logon feature.
• Communication with Domain Controller: The background process communicates with the domain controller using the credentials provided (password or smart card). The domain controller verifies these credentials and responds accordingly.
• Secure Password Handling: The Kerberos protocol ensures that the password is never transmitted over the network. Instead, it relies on cryptographic properties of the password. The client encrypts the password to generate a key, which is then used for authentication.
• Ticket-Granting Ticket (TGT): Once a TGT is obtained, it is stored in memory. This TGT allows for single sign-on (SSO) to various services within the domain. For example, accessing a network file share, a website on the intranet, or email services like Exchange does not require re-entering the password.
• Service Tickets: The TGT is used to obtain service tickets for accessing specific services. These service tickets authenticate the client to the respective service.

Microsoft introduced several extensions and modifications to the standard Kerberos protocol to enhance security and usability within Windows environments. These modifications ensure better integration with Active Directory and other Windows-specific services.

Windows 10 introduced the concept of hybrid logon, which integrates both domain credentials and cloud-based credentials (e.g., Azure Active Directory). This allows seamless access to both on-premises and cloud resources, providing a unified single sign-on experience across different environments.

Authenticating with Azure Active Directory (AAD)

1. Kerberos Logon:
   • When a user logs on to a domain-joined Windows machine, Kerberos handles the authentication by obtaining a Ticket Granting Ticket (TGT). This TGT is then used to access various network resources without needing to re-enter credentials​​.
2. Transfer of Credentials:
   • The Kerberos authentication package in Windows includes a feature called the transfer of credentials. This mechanism allows Kerberos to communicate with other authentication packages within Windows by announcing that it has authenticated a user and asking if any other package can use these credentials for further authentication tasks​​.
3. Communication with Cloud AP Package:
   • One of the key authentication packages is the Cloud Authentication Package (Cloud AP), which is responsible for managing communication with cloud services, including AAD. When Kerberos completes the logon process, it hands over the credentials to Cloud AP through the transfer of credentials mechanism​​.
4. Cloud AP and Plugins:
   • Cloud AP is designed to be protocol-agnostic, meaning it doesn’t inherently understand specific protocols like OAuth or Kerberos. Instead, it uses plugins that understand how to interact with different authentication systems. For Azure AD, Cloud AP uses a plugin that handles the communication with AAD using the OAuth protocol​​.
5. OAuth Protocol:
   • OAuth is an open standard for access delegation, commonly used for token-based authentication. When Cloud AP receives the credentials from Kerberos, it uses the OAuth protocol to communicate with AAD. This involves exchanging the provided credentials for OAuth tokens, which can then be used to access AAD-protected resources like Office 365, SharePoint, and other services​​.
6. Token Caching:
   • To enhance performance and reduce the need for frequent network calls, Windows caches OAuth tokens locally. When a user logs in, if the necessary tokens are already cached, Windows can proceed without immediately contacting AAD. This cached logon approach is similar to how Kerberos handles cached TGTs for faster resource access​​.
7. Primary Refresh Token (PRT):
   • One critical component in this process is the Primary Refresh Token (PRT), which is analogous to the TGT in Kerberos. The PRT is used to obtain OAuth tokens when they are needed. Windows periodically refreshes the PRT to ensure that tokens remain valid and up-to-date. This refresh process occurs every few hours, rather than at each logon, to optimize efficiency and maintain secure access​​.
8. Hybrid Domain Join:
   • In a hybrid domain join scenario, the machine is joined to both an on-premises Active Directory and Azure AD. This setup allows users to authenticate with their domain credentials while also gaining single sign-on (SSO) access to cloud resources. Kerberos handles the initial logon, and then Cloud AP uses OAuth to interact with AAD for cloud resource access​​.
9. Azure AD Join:
   • For devices that are Azure AD joined (but not necessarily domain joined), the process starts with an OAuth logon to Azure AD. Upon successful authentication, the machine and user gain access to both cloud and on-premises resources. The Azure AD join process uses cached credentials to minimize the need for frequent re-authentication with the cloud​​.

Windows Hello Logon

Windows Hello is a feature in Windows that provides a more secure and personal way to access your devices and applications using biometrics (facial recognition or fingerprint) or a PIN. Unlike traditional passwords, Windows Hello ensures that your credentials are stored locally on the device and are not transferable to other machines.

How Windows Hello Works

1. Initial Setup and Registration:
   • During the initial setup, users are prompted to register their biometrics (facial recognition or fingerprint) or set up a PIN.
   • This registration process involves capturing biometric data and storing a secure representation of this data on the device.
2. Local Storage of Credentials:
   • The credentials (biometric data or PIN) are stored locally on the device and protected by the Trusted Platform Module (TPM), which is a secure cryptoprocessor.
3. Logon Process:
   • Waking the Machine: When a user attempts to log in, the machine wakes up and activates the camera for facial recognition or the fingerprint scanner.
   • Capturing Biometric Data: The device captures the user’s biometric data (e.g., a facial image).
   • Authentication Subsystem: This data is sent to the authentication subsystem, which compares it against the stored data.
     • The subsystem ensures the user is physically present and alive (liveness detection) to prevent unauthorized access using photos or other means.
   • Generating the Key:
     • The authentication subsystem, in conjunction with the TPM, computes a special key based on the captured biometric data.
     • This key is used to decrypt another key stored on the machine.
   • Unlocking the Device:
     • If the biometric data matches and the decryption is successful, the device is unlocked.
     • This key is then used to authenticate the user to Active Directory or Azure Active Directory.
     • The key used for authentication is unique to the machine and cannot be transferred or reused on another device.
4. Security Advantages:
   • Localized Credentials: Credentials are bound to a single machine, reducing the risk of credential theft.
   • Biometric Security: Using biometrics adds an additional layer of security compared to traditional passwords, which are more susceptible to breaches and reuse.
   • TPM Protection: The involvement of TPM ensures that keys are stored securely and can only be used with the specific device, enhancing security.

Considerations for Different Environments

• Personal Devices: Ideal for devices that are primarily used by a single user.
• Shared Workspaces: In environment where users need access to multiple devices, they would need to setup Hello on each of those devices. In such environments, FIDO (Fast Identity Online) can be used as a more portable authentication method.

FIDO Logon in AAD

FIDO (Fast Identity Online) logon provides a portable and secure way to authenticate users across multiple devices. You can freely move from one machine to different machine without going through PIN/password setup. Just a tap on the security key is enough to log into the Windows. Here is how it works:

• The user plugs in a FIDO hardware key and performs an authentication action (e.g., tapping a button, entering a PIN, or using a fingerprint). This action unlocks a private key stored on the FIDO device.
• The FIDO credential provider sends the unlocked key information to the Local Security Authority (LSA). LSA delegates the handling of FIDO logon to specific authentication packages.
• These packages initiate a process known as the “pre-logon surrogate,” which involves preempting the usual authentication steps to handle the FIDO credentials.
• The Cloud Authentication Provider (CloudAP) recognizes the FIDO credential and performs an authentication exchange with Azure Active Directory (Azure AD).
• Azure AD verifies the FIDO credentials and returns authentication results to CloudAP.
• CloudAP passes the authentication results from Azure AD to the Negotiate package.
• This package integrates the results into the Windows logon process, even though Active Directory (AD) does not natively understand FIDO.
• Azure AD issues a Read-Only Domain Controller (RODC) Ticket Granting Ticket (TGT). This is a restricted form of the regular TGT used in Kerberos authentication. The RODC TGT is narrow in scope, providing minimal access required for authentication.
• The RODC TGT is passed through the Kerberos stack to the domain controller (DC).
• The domain controller trusts the RODC TGT from Azure AD, issuing a regular TGT in response.
• The issued TGT is then used to complete the logon process, granting the user access to the Windows environment.

Key Points:

• Portability: FIDO allows users to authenticate on multiple devices without needing to set up individual credentials on each device.
• Security: The authentication credentials (private keys) are stored on the FIDO device, not on the computer, enhancing security.
• Integration with Existing Infrastructure: The process enables FIDO authentication to work seamlessly with traditional AD environments through Azure AD integration and the use of RODC TGTs.

Azure AD Join

Azure AD Join allows devices to be registered directly with Azure Active Directory (AAD) rather than a traditional on-premises Active Directory (AD). This approach shifts the initial authentication responsibility from the domain controller to Azure AD. Here is how it works:

• When a user attempts to log on to an Azure AD joined device, the process begins with the Azure AD instead of the domain controller.
• The credential providers on the lock screen collect the user’s credentials, which are then verified against Azure AD using OAuth instead of the traditional Kerberos protocol.
• Similar to domain-joined devices, Azure AD joined devices cache login information. This cached information allows the device to authenticate the user without needing to contact Azure AD for every login attempt. This makes the offline logon experience much faster and smoother.
• When accessing cloud resources, no immediate communication with Azure AD is required as the necessary authentication tokens are cached. The actual communication with Azure AD happens only when a user attempts to access a cloud resource such as Office 365 or SharePoint.
• For on-premises resources, the process involves a flip in the traditional flow. Previously, the AD credentials would get the user to the desktop, and then those Kerberos credentials would be used for single sign-on.
• With Azure AD Join, the Azure AD credentials get the user to the desktop. Post login, these credentials are then used to communicate with the domain controller to acquire Kerberos tickets for accessing on-premises resources. Essentially, the Azure AD credentials serve as the basis for obtaining the necessary Kerberos tickets.
• Azure AD joined devices do not maintain a workstation account or a password in the on-premises AD. This reduces the management overhead associated with maintaining these accounts and credentials. The device management is handled through Intune, a cloud-based management solution.
• Users benefit from Single Sign-On capabilities for both cloud and on-premises resources. This seamless integration ensures that once logged in, users can access resources without repeatedly entering their credentials.

I hope you are enjoying this series of posts on Windows Authentication. If you haven’t already, do read Windows Authentication: Part 1 – Penfluence

Resources

Microsoft Kerberos – Win32 apps | Microsoft Learn

Microsoft Negotiate – Win32 apps | Microsoft Learn