Compare authenticating database users against an LDAP directory with using Kerberos/GSSAPI. What are the security and operational differences, and what stays in the database either way?
answer
- LDAP = password relay via bind; Kerberos = ticket + keytab
- LDAP simple bind vs search+bind (extra service account)
- Kerberos: SPN, DNS, clock skew, keytab rotation
- No password reaches the DB with Kerberos; SSO possible
- Neither creates roles or grants privileges
basics
~20 sWith LDAP the client sends its password to the database, which re-binds to the directory to verify it — so the database sees the plaintext password and needs TLS to the directory. With Kerberos the client presents a ticket obtained elsewhere; no password reaches the database, and single sign-on works. Both externalise identity only — roles and privileges stay in the database.
solid answer
~60 s**LDAP** authentication is a password relay. The client sends its password over the database connection; the server attempts a bind to the directory as that user (either constructing a DN from a prefix/suffix, or doing a search-then-bind to find the entry first). Consequences: the database process handles the user's corporate password in the clear, so both hops need TLS; repeated failures can lock out the directory account; and every login depends on directory latency and availability. **Kerberos/GSSAPI** is ticket-based. The client already holds a ticket-granting ticket from the KDC and requests a service ticket for the database's service principal. The database validates it with its keytab. The password never reaches the database, the exchange is mutually authenticating, and users get single sign-on. The costs are infrastructure: keytab management and rotation, correct service principal names, working forward/reverse DNS, and clock skew kept within a few minutes or tickets are rejected outright. Either way, only **authentication** is externalised. The role must exist in the database and hold its own privileges; group membership in the directory does not become a database privilege unless you build and run that mapping yourself.
go deeper
Know that both let the database verify identity against a central system instead of a local password, and that roles still have to exist in the database.
Contrast the mechanisms: LDAP relays a password via a bind, Kerberos validates a ticket with a keytab and supports single sign-on.
Bring failure modes — lockout amplification and directory availability for LDAP; clock skew, SPN and keytab rotation for Kerberos — and the offboarding gap left by role/group synchronisation.
Argue the identity strategy: federate identity centrally, keep authorization in the engine, and prefer short-lived tokens or workload certificates for service accounts over any standing shared secret.
## Why externalise authentication at all Local database passwords mean another credential to provision, rotate, and revoke on offboarding, on every instance. Sourcing identity from a central directory means one lifecycle: disable the person once and their database access attempts stop everywhere. That is the payoff. The two dominant mechanisms achieve it very differently. ## LDAP: relaying the password The database acts as a proxy for the directory's own authentication: - **Simple bind mode**: the server builds a distinguished name by concatenating a configured prefix and suffix around the supplied user name, then binds to the directory with that DN and the supplied password. A successful bind means authenticated. - **Search+bind mode**: the server first binds with a dedicated service account, searches for the entry matching an attribute (e.g. `mail` or `sAMAccountName`), then re-binds as the found DN with the user's password. This handles directories whose DN layout is not derivable from the login name, at the cost of an extra credential to manage. Security properties worth stating plainly: - The **user's password is present in the database server process**. If it is a corporate password, the database is now a place it can leak from. Both hops — client-to-database and database-to-directory — must use TLS, and the directory hop is the one people forget. - **No single sign-on, no modern factors.** It is a password flow; multi-factor typically does not fit. - **Lockout amplification.** An application with a stale password retrying in a loop can lock out the human's corporate account, causing damage far outside the database. - **Availability coupling.** Directory outage or high latency means login failures and slow connection storms. Add connection pooling so directory round-trips are not paid per query, and cache nothing you cannot reason about. Its virtue is simplicity: no ticket infrastructure, works from anywhere that can present a password, easy to deploy. ## Kerberos/GSSAPI: presenting a ticket The client authenticates to a Key Distribution Center once, receiving a ticket-granting ticket. To reach the database it requests a service ticket for the database's service principal name, and presents that ticket over the connection. The database validates it using its **keytab** — the long-term key for its own principal — without ever contacting the KDC for that login and without ever seeing a password. Stronger properties: - **No password on the wire or in the database process.** - **Mutual authentication**, so a rogue endpoint cannot harvest credentials. - **Single sign-on**: users already logged into the domain connect with no prompt at all, which also removes passwords from scripts and connection strings. - **Short-lived tickets** limit the value of any captured material. The costs are all operational: - **Keytabs** are files containing long-term secrets. They must be distributed securely, permission-restricted, and rotated — and rotating them wrongly breaks every login at once. - **Service principal names must be exactly right**, and clients typically canonicalise the host through DNS, so broken forward/reverse resolution produces failures that look nothing like an authentication problem. - **Clock skew** beyond a few minutes causes outright rejection; NTP is a hard dependency. - **Cross-realm trust** is required when clients and database live in different realms. - Diagnostics are notoriously opaque compared with "password authentication failed". ## What stays in the database, always This is the part interviews probe. Both mechanisms answer only "who is this?". They do not: - **Create roles.** The authenticated name must correspond to an existing database role, or the connection fails after successful external authentication — a confusing failure mode worth recognising. - **Grant privileges.** Directory group membership is not a database privilege. If you want "members of `db-analysts` can read the reporting schema", you must provision a database role, grant it, and run a synchronisation process that adds and removes members. That sync job is a real system with its own failure modes — chiefly failing to *remove* access. - **Enforce anything per statement.** Every statement is still authorized against catalog privileges, ownership and any policies. ## Choosing between them Kerberos where you already run a domain and want true single sign-on for humans, and you can staff the keytab/DNS/time discipline. LDAP where you need centralised passwords quickly, accept the password relay, and can guarantee TLS on both hops. For **service accounts**, both are often the wrong shape: short-lived tokens from a cloud IAM system, or client certificates from a workload-identity system, avoid the standing shared secret entirely. ## What interviewers listen for The password-relay observation for LDAP, the ticket/keytab model plus clock-skew sensitivity for Kerberos, and — the point most candidates miss — that neither one provisions roles or privileges, so offboarding is only complete if the role-to-group synchronisation actually removes access.
- A user is removed from the corporate directory. Are they immediately unable to use the database?They cannot form new connections, since authentication now fails at the directory or KDC. But the database role still exists with its privileges, and any session already established keeps running — authentication happened once at connect time. Complete offboarding means terminating live sessions and removing or revoking the database role, not just disabling the directory account.
- How do directory groups become database privileges?They do not, automatically. External authentication maps an identity to a database role; group membership carries no privilege. Teams build a synchronisation process that creates roles for groups, grants privileges to those roles, and adds or removes members as directory membership changes. The risky half is removal — a sync that only ever adds members quietly accumulates standing access.
- Why does Kerberos authentication fail across an entire fleet after a routine server change, with no credential involved?Usually clock skew or name resolution. Kerberos rejects tickets when clocks differ by more than a few minutes, and clients canonicalise the host name through DNS to build the service principal, so a changed record, a new alias, or broken reverse lookup makes the requested principal not match the keytab. Both failures are fleet-wide and instantaneous, which is why time sync and DNS are treated as hard dependencies.
saying these in an interview costs you the question
- Claiming LDAP authentication means the password never reaches the database
- Believing directory group membership automatically becomes database privileges
- Forgetting TLS on the database-to-directory hop
- Assuming disabling the directory account kills existing database sessions
- Overlooking clock skew, SPN and DNS as the usual Kerberos failure causes