A Kerberos referral ticket is a ticket used to direct authentication from one domain controller to another domain in a trusted path. It is a stepping stone in cross-domain authentication. If misused, referral tickets can help attackers traverse trust relationships and request service tickets in domains they should not reach.
Expanded Definition
A Kerberos referral ticket is a ticket-granting artifact that tells a client to continue authentication with another domain in a trusted path, rather than stopping at the first domain controller. In enterprise IAM, it is the mechanism that makes cross-domain and cross-forest access possible without re-entering credentials at every hop.
Definitions vary across vendors on the exact operational scope, but the core security meaning is consistent: a referral ticket is not the final service ticket, and it should only route authentication through trusted, policy-approved relationships. In practice, that means administrators must treat trust paths as security boundaries, not just routing conveniences. This matters because Kerberos referral behaviour can intersect with delegation, constrained delegation, and privilege inheritance in ways that are easy to overlook. The most common misapplication is assuming referral tickets are harmless plumbing, which occurs when cross-domain trust is enabled without validating which accounts, services, and SPNs can traverse it.
For a broader NHI governance lens, see the Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0.
Examples and Use Cases
Implementing Kerberos referrals rigorously often introduces trust-management overhead, requiring organisations to weigh seamless cross-domain access against the risk of over-broad lateral movement.
- A user in a parent domain authenticates to a file service in a child domain, and the first domain controller issues a referral ticket to continue the Kerberos flow.
- A service account running an application in one forest requests access to a database in another trusted forest, relying on referrals to locate the appropriate realm.
- A merger creates multiple domain boundaries, and referral tickets help preserve single sign-on while administrators rework trust relationships and service principal names.
- A security team reviews referral paths after noticing unusual ticket requests, using cross-domain logs to detect abuse of trusted routing.
- A privileged automation identity reaches a remote domain through a trust path, which makes referral ticket handling part of the identity’s operational blast radius.
For lifecycle and secret governance context, the Ultimate Guide to NHIs is especially relevant, while NIST Cybersecurity Framework 2.0 frames the access-control discipline behind these scenarios.
Why It Matters in NHI Security
Kerberos referral tickets matter because they can expand the effective reach of non-human identities across domains, forests, and service boundaries. If an attacker compromises a service account or API-driven identity that can obtain referrals, trust relationships can become a shortcut to broader access than the identity should ever have had. That is why NHI governance cannot stop at local account hygiene; it must include trust-path review, ticket usage monitoring, and privilege containment across domains.
NHI Management Group’s research shows how often identity weaknesses become systemic: 97% of NHIs carry excessive privileges, and only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs. Those conditions make referral tickets especially important in environments where service identities are already over-entitled and under-observed. The NIST Cybersecurity Framework 2.0 reinforces the need to manage access pathways, not just credentials.
Organisations typically encounter referral-ticket risk only after suspicious cross-domain access is detected or a service account is abused, at which point Kerberos trust traversal becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Cross-domain ticket flow can enable lateral movement through weak trust paths. |
| NIST CSF 2.0 | PR.AC-4 | Identity permissions and access pathways must be managed across boundaries. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust treats every trust path as explicit and continuously verified. |
| NIST SP 800-63 | AAL2 | Identity assurance informs how much access a Kerberos-backed identity should receive. |
| CSA MAESTRO | Agentic and automated identities must be constrained across delegated trust paths. |
Review Kerberos trust relationships and restrict referral paths to only approved non-human identities.
