10

We have a slightly complicated IDAM setup:

enter image description here

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.

Rob Grant
  • 103
  • 6
  • is TCP/88 open between the browser for the servers listed in dns results for _kerberos._tcp.OurITOrgDomain and _kerberos._tcp.partentdomain? can you kinit from the machine 'browser' with the credentials you need to authenticate on the Jetty server? – Jacob Evans Aug 08 '16 at 18:14
  • http://www.roguelynn.com/words/explain-like-im-5-kerberos/ might shed some light to how your firewall may be causing your issues (again, 88 to both dcs from your client) – Jacob Evans Aug 08 '16 at 18:24
  • There are too many variables for a detailed step-by-step explanation without taking a network capture. Then you'll quickly see if the SPNs are properly setup or if the browser needs to be configured to silently authenticate. – user2320464 Aug 09 '16 at 19:49

2 Answers2

3

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.

  • Internet Explorer - while the TechNet article isn't specifically for your application, the steps are the same.
  • Firefox - same as the IE link, not exact match but steps are the same.

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

Community
  • 1
user2320464
  • 759
  • 5
  • 14
  • A good answer, better than mine! – Alex H Aug 03 '16 at 08:25
  • Thanks to both of you - it'll take me a couple of days to read through the linked docs, but I haven't abandoned the question or anything! – Rob Grant Aug 04 '16 at 21:02
  • Uh, this actually wasn't it, but I think it's probably best to accept this answer as the real one is a very unusual case that I'll add as a separate answer. Thank you very much! – Rob Grant Aug 18 '16 at 09:10
0

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.

Alex H
  • 1,814
  • 11
  • 18