Tickets Are Context
Kerberos work becomes easier when tickets are treated as context. A ticket is not just a credential artifact. It has a client principal, service principal, realm, flags, encryption type, lifetime, and intended service. Confusing those details leads to failed authentication and wrong assumptions about access.
I track which cache is active, which principal it belongs to, which service ticket was requested, and which protocol will use it. This is especially important when switching between LDAP, SMB, WinRM, MSSQL, and HTTP-based services.
SPNs Decide Service Access
Service Principal Names decide where a ticket is useful. A ticket for one service is not automatically accepted by another service, even when the host is the same. Understanding SPN format, hostname canonicalization, service class, and alternative service behavior is central to Kerberos tradecraft.
When authentication fails, I check whether the ticket service matches the protocol, whether DNS names match the SPN, whether the realm is correct, and whether the application expects a specific service class. Many failures are not bad credentials. They are ticket mismatch problems.
S4U And Delegation
S4U workflows are powerful because they move from identity to service access without needing a plaintext password for the impersonated user. But the configuration has to allow the path: protocol transition, delegation targets, service account rights, and KDC behavior all matter.
I separate S4U2Self and S4U2Proxy mentally. S4U2Self creates evidence for the impersonated identity to the delegating service. S4U2Proxy turns that evidence into a service ticket for an allowed target. Knowing which step failed makes troubleshooting much faster.
Roasting Is Signal
Kerberoasting and AS-REP roasting are useful, but they are only one part of identity review. A cracked password may provide direct access, but the more important question is what that account can reach. Service account permissions, SPNs, group memberships, delegation, local admin rights, and database access decide the value of the credential.
I treat roasting output as a starting point. If a credential is recovered, I validate access carefully and map the account before using it for remote actions. That reduces noisy attempts and helps identify cleaner paths.
Authentication Is Not Authorization
A successful Kerberos login proves identity, not permission. The service still decides authorization. A valid LDAP bind may not allow writes. A valid SMB session may not access admin shares. A valid WinRM authentication may not create a shell. Separating authentication from authorization avoids overestimating access.
Good Kerberos notes record both. Which ticket authenticated successfully? Which service accepted it? Which action was authorized? Those three facts are different and should not be collapsed into one result.