Windows sign-in (Kerberos)¶

People on domain-joined PCs open Gate and are already in, as themselves. No login page, and no password ever reaches Gate. Works on the Windows Server, Linux and Mac editions.

How it works, in one paragraph¶

The browser asks a domain controller for a ticket to HTTP/ai.corp.example. The DC issues it for the account that holds that service name (Windows edition: the gMSA acutisgate$; Linux and Mac: gate-svc). Gate opens the ticket with that account's keys and knows exactly who is there. Four things must line up: the name, the service name, the browser policy, and AES.

The checklist¶

#	What	Windows edition	Linux / Mac
1	People open Gate by its DNS name (`https://ai.corp.example`), never an IP or a short name	You	You
2	`HTTP/ai.corp.example` is on Gate's account, and only there	Setup does it	`setspn -S` (Linux step 1)
3	Edge and Chrome are allowed to send sign-in to that name	Setup's GPO	Identity → Browser setup script
4	Gate's account supports AES	Setup does it (gMSA is AES only)	Tick the two AES boxes on `gate-svc`
5	The certificate is trusted by the PCs	Company CA	Trust the Gate CA, or `--cert`
6	Windows sign-in is ticked in Identity → Active Directory	You	You

Test it on a PC¶

As a normal user on a domain PC:

Refresh policy, and check the policy arrived:
```
gpupdate /force
```
Then open edge://policy (or chrome://policy) and look for AuthServerAllowlist containing ai.corp.example.
Ask for a ticket:
```
klist get HTTP/ai.corp.example
```
A ticket means AD is ready. Check the line KerbTicket Encryption Type: it should say AES-256.
Close every browser window, reopen, and go to https://ai.corp.example/gate. You should land in the console.
In Gate: Health check → Test this browser says who you would be signed in as, and whether by Kerberos or NTLM.

When it does not work¶

What you see	Cause	Fix
A login page instead of being signed in	The browser policy has not arrived, or Gate was opened by IP or short name	`gpupdate /force`, reopen the browser, use the full name. Check `edge://policy`.
`klist get` fails with KDC_ERR_S_PRINCIPAL_UNKNOWN	Nobody holds `HTTP/ai.corp.example`	Windows: run setup again. Linux/Mac: `setspn -S HTTP/ai.corp.example CORP\gate-svc`.
`klist get` works, Gate still shows a login page, the audit trail says old RC4 encryption	Gate's account lacks AES	Tick both AES boxes on `gate-svc` (or `Set-ADUser gate-svc -KerberosEncryptionType AES128,AES256`), then `klist purge` on the PC and try again.
"Your Windows sign-in could not be verified"	Two accounts hold the name, or the keys are old	`setspn -Q HTTP/ai.corp.example` must list exactly one account. Linux/Mac: re-enter `gate-svc`'s password in Identity → Active Directory.
Works in Edge, not in Firefox	Firefox has its own setting	In `about:config`, set `network.negotiate-auth.trusted-uris` to `ai.corp.example` (or push it with Firefox policies).
Works on PCs, not from home	Off the network, the PC cannot reach a DC	Use the VPN, or sign in with email and authenticator.
Some people are refused, others fine	They are not in the Who gets Gate group, or are disabled	Check Identity → People and the AD group.

Each fix has a page in the Health check reference.

Turn it off¶

Untick Windows sign-in in Identity → Active Directory. People then sign in with email, password and authenticator, and their groups still come from AD.