How does a browser get Kerberos TGT and Service ticket

Question

On a Windows host, which is a member of AD domain and authentication is Kerberos-based, how does a browser get TGT and Service ticket to access a specific service (for e.g. a proxy with kerberos authentication)? I want to understand what APIs it uses at the implementation level.

I did find gokrb5 Golang library on guthub which implements this, but it needs keytab file to get TGT and Service tickets. How does browser able to get kerberos tickets without keytab file?

Answer 1

On a Windows host, which is a member of AD domain and authentication is Kerberos-based, how does a browser get TGT and Service ticket to access a specific service (for e.g. a proxy with kerberos authentication)? I want to understand what APIs it uses at the implementation level.

The browser uses SSPI, which is Microsoft's variant of GSS-API – a generic security protocol API that allows you to interact with Kerberos as well as NTLM.

With SSPI (as well as GSS-API), the browser does not directly deal with tickets at all – it only asks SSPI to output a 'token' for a specific service principal, and from there SSPI takes care of all ticket acquisition (on Windows – by talking to LSASS.EXE).

Experiment with sspilib or pyspnego in Python (I have a few examples), or sspi-rs in Rust.

(The "mechanism" or "security package" in SSPI is commonly set to 'Negotiate' (aka SPNEGO) instead of raw 'Kerberos', but the API remains exactly the same...and usually SPNEGO just short-circuits to Kerberos anyway.)

The .NET API System.IdentityModel.Selectors.KerberosSecurityTokenProvider also uses SSPI or GSS-API behind the scenes.

I did find gokrb5 Golang library on guthub which implements this, but it needs keytab file to get TGT and Service tickets. How does browser able to get kerberos tickets without keytab file?

It derives the key from the user's password. User (client) principals have password-derived keys instead of randomly-generated ones (either MD4 or PBKDF2-SHA1 is used for key derivation).

But also, it's not the browser that actually deals with Kerberos – it's the SSPI backend (Windows LSASS.EXE) that does so. The browser only asks Windows (via SSPI) for a token for a given service and never gets access to the original key. (Think of it like ssh-agent.)

So when you log in to an Active Directory account, Windows derives your account's Kerberos key from your password and uses that to acquire the TGT. If you're a local account, you can store Kerberos usernames and passwords in "Windows Credential Store" and those will also be used by SSPI to get TGTs.

(In fact, on AD, even services which accept tickets also have password-derived keys; where Linux hosts have a system keytab, Windows hosts have a "computer account password" that serves the same function.)

Gokrb5 is an outlier because (as with many things in Golang) it insists on implementing the entire protocol from scratch, instead of providing an interface to the Kerberos support provided by OS. Because of that, it doesn't have access to your logon credentials and you must provide either a keytab or a password to get the TGT.

Finally, the client's key (whether from password or keytab) is only used to acquire the initial ticket (the TGT) – afterwards, only the TGT is used for service tickets.