We have a slightly complicated IDAM setup:
I.e. the end user's machine and browser sit in one network with the parent AD, and our Jetty-based application and the AD that it can talk to (local AD) sit in the other.
There is a two-way trust between the two ADs. The browser in the parent network has the local domain in trusted sites.
The Jetty server's setup is as follows:
- it uses a keytab file generated against a principal in the local AD
- it is running as a Windows service under a user defined in the local AD
- the realm, domain-realm mapping and kdc are defined against the domain of the local AD
- it uses spnego - isInitiator is set to false; doNotPrompt is true; storeKey is true
The problem is:
- as a test, accessing the server from a browser inside the local network (ie linked to the local AD) works - Kerberos debug info appears in the logs, I can see correct Kerberos negotiation in the HTTP traffic, and the user is signed in automatically. Brilliant.
however, accessing the server from a browser inside the parent network (which is how our users will do things) doesn't work! The browser gets a 401 unauth back but then prompts for credentials, which when entered give a blank screen. Then clicking into the address bar and hitting Enter does one of two things, depending on whether the credentials are for the remote or local AD:
- local AD credentials then log in fine, with Kerberos from scratch in the logs (GET request, 401 unauth response, Kerberos headers request, etc)
- remote AD credentials do not log in (GET request, 401 unauth response, what looks like an NTLM header:
Authorization: Negotiate <60 or so random chars>)
Either way, the fact that it's prompting is wrong!
Is there an explanation for these symptoms? Can the setup we have do what we want?
In terms of what about the above description could be wrong: any configuration I've mentioned regarding the Jetty server should be accurate, as I did it. I'm happy to provide more details. Any config regarding either AD or the parent network browser is potentially suspect, because it's not under my control and I've had the configuration reported to me rather than seen it for myself.
Without seeing the packet capture, I'd guess the HTTP/www.website.com SPN needs to be registered to the account running the application. Microsoft's Directory Services team has a great multi-part post addressing this topic at the following URL.
https://blogs.technet.microsoft.com/askds/2008/05/29/kerberos-authentication-problems-service-principal-name-spn-issues-part-1/
Run a packet capture (netmon, wireshark) from a client in each environment to identify what SPN is being looked up. Once that's determined, use the setspn cmd to register it to the account running the application.
FWIW, Kerberos only works while on the LAN. If someone needs access where the domain controllers are not accessible, then you'll want to consider an SSO such as Shibboleth or ADFS.
EDIT: as mentioned by @alex-h, the browsers will need to be configured to silently authenticate via Kerberos.
Lastly, this is a common issue with Microsoft Sharepoint deployments. They want SSO via Kerberos to happen silently once users have authenticated to the domain. Thus if the above answers don't solve your issue, try checking their forums such as the following:
Kerberos on Chrome, Safari or FireFox
Please try 1st from a browser that does not have NTLM enabled(Chrome/Firefox). It seems that the issue is that you have pre authentication enabled and it might be possible that the two way trust might not be in place.
For the pre authentication have a look here https://support.microsoft.com/en-us/kb/2749007 and here https://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html.