Double Hop Kerberos
You fix the double hop kerberos issue by turning on ticket delegation in your directory. This lets a middle server pass a user login ticket to a back-end database. Teams often set up broad trust rules across many servers to make this work fast. Those wide permissions let one compromised middle server act as any user on downstream systems. How double hop kerberos works in practice A single hop happens when a user logs straight into one web app or server. The user gets a ticket from the domain
Hop Kerberos: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You fix the double hop kerberos issue by turning on ticket delegation in your directory. This lets a middle server pass a user login ticket to a back-end database. Teams often set up broad trust rules across many servers to make this work fast. Those wide permissions let one compromised middle server act as any user on downstream systems.
How double hop kerberos works in practice
A single hop happens when a user logs straight into one web app or server. The user gets a ticket from the domain controller and hands it to that server. The trouble starts when that first server must fetch data from a second server. By default, the first server cannot pass the user identity to the next machine. The second server sees an anonymous request and blocks the login right away.
To solve this, admins set up delegation rules inside the central domain controller. The older method is unconstrained delegation, where the first server holds the user ticket. That server can then use the ticket on any other machine in the network. This creates a huge risk if an attacker takes over that first web server.
A safer native method is constrained delegation, which limits where the server can send tickets. Admins list the exact target services that the middle server is allowed to contact. Resource-based constrained delegation flips this model so the target database owns the trust list. The database admin decides which front-end servers can forward user identities to the database. Each service needs a valid Service Principal Name registered in the directory to accept tickets. If a name is missing or duplicated, the ticket exchange fails and drops the user.
What ticket delegation solves and what it misses
Native delegation solves the basic problem of proving who a user is across two hops. The back-end database sees the real user identity instead of a shared app account. This helps teams track which person opened a session on the final database server. It also avoids storing static database passwords inside config files on the middle server.
Hop Kerberos: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Still, ticket delegation only decides who can log in at the start of a session. Once the database accepts the ticket, the user gets full access to their assigned role. Kerberos cannot read or check the actual SQL queries or commands running inside that session. If an engineer has write permissions, they can drop a table or pull sensitive rows. Delegation also cannot mask sensitive fields like emails, phone numbers, card numbers, or national IDs. The directory logs show that a ticket was issued, not what data left the database.
Managing multi-hop database and server sessions
Large networks often have dozens of middle servers talking to core Postgres or SQL databases. Keeping Service Principal Names and delegation lists clean across all these machines takes constant work. When a login fails on the second hop, error messages rarely point to the real cause. Teams often fall back to shared service accounts just to keep apps and scripts running. That choice erases user identity on the second hop and weakens your audit logs. To stay safe, teams need controls that check every command and rewrite sensitive result fields.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Why does my login fail on the second server hop?
The first server lacks permission to forward your ticket to the second server. You must enable constrained delegation and check that the Service Principal Name is set right.
What is the difference between constrained and unconstrained delegation?
Unconstrained delegation lets a middle server impersonate a user on any service in the domain. Constrained delegation restricts that server so it can only pass tickets to specific named targets.
Does Kerberos delegation log the queries a user runs on the database?
No, Kerberos only handles the login handshake and issues tickets for the session. It does not inspect, log, or filter the queries or commands run after login.