Domain Join, Kerberos, and Implications for Sage Estimating

1. Overview

When a Windows PC signs a user in, the mechanics behind that logon screen differ substantially depending on whether the machine is:

• Domain-joined to an on-premises Active Directory (AD) — logon as DOMAIN\username
• Entra ID joined (formerly Azure AD joined) — logon as user@company.com
• Hybrid Entra ID joined — joined to both simultaneously (the common transitional state)

This document explains what happens under the hood in each case, answers whether Kerberos still exists on an Entra-joined machine, and covers how this affects legacy on-premises applications such as Sage Estimating.

2. Traditional AD Domain Join (DOMAIN\username)

• The PC has a computer account object stored in Active Directory.
• At logon, Winlogon passes credentials to the Kerberos Security Support Provider (SSP), falling back to NTLM only if Kerberos isn't available.
• The machine must have network line-of-sight to a Domain Controller (DC), which functions as the Key Distribution Center (KDC).

The logon flow produces:

1. A Kerberos TGT (Ticket Granting Ticket) — proves the user authenticated to the domain.
2. Service tickets issued on demand for specific resources (file shares, SQL Server, internal web apps, print servers, etc.).
3. Group Policy, SYSVOL, and most on-prem resource access (SMB shares, internal LOB apps using Windows Integrated Auth) all depend on this Kerberos/LDAP/SMB plumbing.
4. Off-network limitation: without VPN or DirectAccess, a domain-joined machine off the corporate network cannot contact a DC and falls back to cached credentials — no fresh ticket issuance is possible.

3. Entra ID Joined PC

• The device is registered as a device object inside the Entra ID tenant — there is no AD computer object at all.
• Sign-in is brokered by the Cloud Authentication Provider (Cloud AP) / Web Account Manager (WAM), not the Kerberos SSP.
• Authentication is performed against Entra ID's Security Token Service (STS) over the internet, using OAuth 2.0 / OpenID Connect (OIDC) — not Kerberos.
• The key artifact issued is a Primary Refresh Token (PRT):
  • This is the cloud equivalent of a Kerberos TGT.
  • It enables single sign-on (SSO) to Entra-integrated apps (Microsoft 365, Azure resources, and any SaaS app federated through Entra ID) without repeated prompts.
• No DC is required at all — the device authenticates fine from any internet connection (home, coffee shop, mobile hotspot).
• Natively supports modern authentication methods as first-class citizens: Windows Hello for Business, FIDO2 security keys, the Microsoft Authenticator app, etc.

4. Does Kerberos Still Exist on an Entra-Joined Machine?

Short answer: not in the traditional sense — but Microsoft built a specific bridge for it.

Cloud Kerberos Trust

Microsoft introduced Azure AD Kerberos (aka Cloud Kerberos Trust) to solve two specific problems where a lightweight Kerberos capability was still needed, even on cloud-native devices:

1. Windows Hello for Business key trust/certificate provisioning on Entra-joined devices, without requiring the device to have direct network access to a real on-prem Domain Controller during provisioning.
2. Kerberos authentication to Azure Files (SMB shares hosted in Azure), letting cloud-only or hybrid users mount file shares using Kerberos-based auth.

How it works: A special Kerberos Server object (AzureADKerberos) is created in Entra ID, synced from a corresponding object in on-prem AD. This allows Entra ID itself to issue a limited-purpose Kerberos TGT for these specific scenarios — without the device needing direct line-of-sight to a traditional DC.

This is not general-purpose Kerberos for arbitrary on-prem resource access — it's a targeted mechanism for the two scenarios above.

5. The Common Middle Ground: Hybrid Entra ID Join

Most enterprises today operate in a Hybrid Azure AD Join model, where the device is joined to both on-prem AD and Entra ID simultaneously:

• Full traditional Kerberos/NTLM still works for on-prem resources — the device still needs DC line-of-sight for that (typically via VPN when off-network).
• A PRT is also issued in parallel, enabling cloud SSO to Entra-integrated apps.
• This is the practical transitional architecture many organizations run while migrating from fully on-prem to cloud-native device management.

6. Summary Comparison Table

7. How This Relates to Sage Estimating

Sage Estimating (SQL) uses a SQL Server-based architecture. The estimating client connects to a Sage license server and to a Sage Estimating SQL Server instance.

7.1 Architecture

• The estimating client runs on a supported Windows workstation or Windows Server environment.
• Sage Estimating data is stored in a Sage Estimating SQL Server instance, using SQL Server Express, Standard, or another supported SQL Server edition depending on the deployment.
• Sage Estimating supports two user authentication types: Windows Authentication and SQL Server Authentication. Sage documentation states that Windows Authentication is recommended for most companies, particularly in a networked environment, while SQL Server Authentication can be used when a networked system is needed but there is no domain.

7.2 Does Sage Require Kerberos Specifically?

Not as a custom Sage authentication protocol. Sage Estimating supports Windows Authentication, and Windows Authentication depends on the Windows authentication mechanisms available in the environment. In an Active Directory domain environment, that typically means Kerberos when conditions are met, with NTLM fallback in some cases.

Kerberos will actually succeed (rather than silently falling back to NTLM) only if:

• The machine is domain-joined (traditional AD, or hybrid-joined) — Kerberos needs a DC/KDC in the picture.
• The SQL Server service account has a properly registered SPN (Service Principal Name) in AD for the SQL instance.
• There's no double-hop problem — if a user connects through a middle-tier server (e.g., Sage app server → SQL Server) rather than client-to-SQL directly, Kerberos delegation must be explicitly configured, or it will fail/fallback to NTLM.

In Windows Integrated Authentication environments, missing SPNs or delegation issues can affect whether Kerberos is used successfully. This is a Windows/SQL Server authentication consideration rather than a Sage-specific authentication protocol.

7.3 Where This Connects to Entra ID

For Sage Estimating environments that use Windows Authentication against Active Directory resources, Entra ID-only joined devices may present authentication challenges because they do not have the same traditional domain-joined Kerberos/NTLM relationship with an on-premises Active Directory domain.

For those environments, common architectural approaches include domain-joined or hybrid-joined workstations, or publishing Sage from a domain-joined Windows Server/RDS-style environment. Confirm the supported topology against Sage’s current documentation for the exact Sage Estimating version in use.

7.4 Bottom Line

Sage Estimating does not appear, based on public Sage documentation reviewed here, to have its own custom Kerberos requirement. Sage supports Windows Authentication and SQL Server Authentication. When Windows Authentication is used in an Active Directory-integrated SQL Server environment, the environment must provide a functional Windows authentication path. In practice, that is the point where Kerberos and NTLM considerations become relevant.

Note: Sage's supported configurations can change by product version. Confirm current supported topologies against Sage's official system requirements and compatibility documentation for your exact version before planning a migration.