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.