SSOGEN / Sign-in methods / Kerberos Authentication: Windows Desktop Sign-In Without a Password
Integration
Kerberos Authentication: Windows Desktop Sign-In Without a Password
Kerberos authentication in SSOGEN lets a person who is already signed in to a company Windows computer open My Apps or a protected application without typing a password. Windows holds the proof, the browser passes it on, and SSOGEN checks it.
Kerberos authentication gives employees on domain-joined Windows computers a sign-in with no password prompt. They open My Apps or a protected application and they are in. SSOGEN calls this Windows desktop sign-in; elsewhere it is known as integrated Windows authentication.
The mechanism is Kerberos:
- A person signs in to Windows and the domain issues a ticket.
- A browser that trusts the SSOGEN address sends that ticket along.
- SSOGEN opens it with a key it holds, finds the person in your Active Directory and signs them in.
This page covers what users experience and what you put in place. Commands and every field are in the Windows desktop sign-in guide.
What people experience
Maria Lopez is on her office laptop, on the office network. She opens My Apps and lands on her applications, with no password page.
If the application’s policy requires a second step, such as an authenticator code, SSOGEN asks for it, as after a password.
When a condition is not met, she gets the normal sign-in page and signs in another way. That happens when:
- she is at home or on a network you did not list
- her browser has no Windows ticket
- her Windows account matches no one in SSOGEN, or is disabled
- she has just signed out
After a failed attempt or a sign-out, SSOGEN pauses Windows sign-in in that browser for twelve hours. She can still choose Windows sign-in from the list.
How it works with your sign-in policies
Your authentication policies stay in control.
- It counts as single-factor. SSOGEN cannot tell whether Windows used a password, a smart card or Windows Hello, so it rates the sign-in at password strength. A policy that requires a second factor still asks for one. A policy that requires a passkey is met by a passkey, not by Windows sign-in.
- Policy decides where it applies. A policy accepts Windows sign-in once you add the connection to that policy’s providers.
- It is built for managed computers. List only networks where your domain manages every browser.
What has to exist first
| Requirement | Detail |
|---|---|
| A working directory connection | The Windows account is looked up in your Active Directory connection each time |
| A service account for SSOGEN | Supports AES, has no delegation settings, holds no other service names, and is not shared with another product |
| A service principal name | HTTP/ plus the exact SSOGEN host name, registered on that one account |
| A keytab | Exported for that name with AES256; stored encrypted by SSOGEN and never shown again |
| Browser policy | Chrome and Edge AuthServerAllowlist, or Firefox network.negotiate-auth.trusted-uris |
| A network zone | Windows sign-in is offered only to people on the zones you list |
| Clock agreement | Kerberos allows a five-minute difference, and SSOGEN allows no more |
Registering the name and exporting the keytab are two commands on a domain controller:
setspn -S HTTP/sso.acme.example svc-ssogen-platformktpass /princ HTTP/sso.acme.example@ACME.EXAMPLE /mapuser svc-ssogen-platform /crypto AES256-SHA1 /ptype KRB5_NT_PRINCIPAL /pass * /out ssogen-platform.keytabExporting a keytab changes that account’s key, which is why the account serves SSOGEN only. People open SSOGEN by its normal host name, not an IP address or alias.
What you configure in SSOGEN
You create the connection as a draft through the administration API. Its settings are:
- the service principal
- the realms, and the directory each one maps to
- the network zones
auto_attempt: with true, the sign-in page tries Windows sign-in by itself before showing the form; with false, it is a choice in the list
SSOGEN refuses a keytab file that is not a keytab, has no entry for your service principal, or holds only RC4 or DES keys.
Test with a real ticket
The normal Test is refused for this connection, because only a real ticket proves it works.
- Validate the draft.
- Start the test to get an address.
- Open that address within five minutes, on a domain-joined computer, signed in to the Admin Console as the same administrator.
The result page shows:
- The Windows account. The account SSOGEN received.
- The directory. The directory it maps to.
- The person. The SSOGEN person it would sign in.
- The factor. That the sign-in would be single-factor.
No session is created. SSOGEN also checks for risky delegation. A warning means an account is trusted to delegate to SSOGEN’s name, which would let that account sign in as anyone.
Fix it in AD, test again, then activate.
When it fails
People land on the normal sign-in page, sometimes with a message. The exact reason is recorded in the audit trail.
| Cause | Fix |
|---|---|
| The browser sent NTLM instead of Kerberos | Check the name with setspn -Q: it must be registered once, and the person must use that host name |
| The keytab is out of date | Export a new one after the service account’s password changes |
| Only some people fail | Large tickets cut by a proxy: allow big request headers, and never log the Authorization header |
| Nobody is signed in automatically after sign-out | That is the twelve-hour pause, not a fault |
Questions people ask
What is Kerberos authentication?
It is the sign-in protocol built into Active Directory. A ticket proves a user’s identity to a service, so no password is sent.
Is Kerberos the same as LDAP?
No. LDAP sign-in sends a typed password to the directory to check. Kerberos needs no typed password. In SSOGEN they work together: Kerberos finds the person through the directory.
Can people still use a password?
Yes. Outside the office, on unlisted networks and on unmanaged computers, they sign in with their directory password.
Where to go next
Kerberos is one of the sign-in methods of SSOGEN, a complete identity provider.
- Steps. The steps are in the Windows desktop sign-in guide.
- Applications. For a protected application, see Oracle EBS SSO.
- Methods. Back to all sign-in methods.
- Domain controller. A browser’s NTLM fallback shows up as event 4776.