Firstly, please apologise me if I'm still confused about stuff here, Kerberos auth is quite the complex issue for a java dev

So, I have the following scenario:

A suite of webapps which use kerberos pre-authentication for access and LDAP profiles authorization for the sub-sections

I have a Windows Server in AWS with a forest (typical EXAMPLE.COM) with an Administrator user that is member of all necessary groups. All relevant ports are open and accessible, and if I do a search by username with Spring LDAP, it works fine

The company I work in has its own AD and my PC belongs to this AD, so technically I'm handling two ADs, however, I have no access to the CORP AD, obviously, it's just there. However, I've added a user to the Windows Server AD in AWS with the same username, password and member of all necessary groups JFI

The issue comes when starting the app in my local PC to test this. I have configured firefox as mentioned in this post, but when I try to access the app via browser (localhost:port) the Negotiate header never contains a ticket to authenticate against

Not sure any code would help here, but happy to share any snippets or start a chat if that could help

  • 1
    Hello Steven, could you please check the local hosts file and include a line or two for your localhost server as in the serverfault.com/a/394141/95089 example. If this is still not working maybe you could also share what browsers' versions you tried, Chrome, IE, FireFox?
    – LLub
    Oct 7, 2019 at 13:44
  • Hi, Sorry for delay here, not been at work this week, will try to check over weekend, thanks!
    – Steven
    Oct 11, 2019 at 15:15

1 Answer 1


It seems you may have some misunderstanding of Kerberos and/or Windows domains.

First of all, the browser doesn't generate a Kerberos ticket; a domain controller does. At most, the browser will ask the local security authority (LSASS) to do it. To get Kerberos working, you need to understand how authentication and trusts work in an AD environment.

The user in your local AD is completely separate from the user in the cloud AD, and they have no relationship at all to each other. The fact that you could authenticate between Windows machines in the past using the same user/pass is a legacy thing that will not work with Kerberos.

For cross-domain Kerberos authentication, you must establish an Active Directory trust. Whether this is a one-way or two-way trust depends on which resources are being accessed by which users across all applications. You'll need to talk to your AD team to sort that out; trust configurations are domain-wide.

The lack of a Negotiate header suggests that Kerberos isn't even starting. In order for that to happen, your client must be able to construct and validate the service principal name (SPN) of the remote host. Once it does that, it can request a service ticket that it will pass to the remote host for authentication.

Since SPNs are a Kerberos feature, it is impossible to validate the SPN of a host that is not part of your own domain/realm or a domain/realm that you trust. Once the trust is setup, SPN validation should be seamless if (1) DNS is setup properly and (2) the server has correct SPNs published in its Active Directory.

  • Hi, Sorry for delay here and thank you so much for detailed answer, not been at work this week, will try to check over weekend, thanks!
    – Steven
    Oct 11, 2019 at 15:15
  • Ok, so been trying this, as my DNS is corporate one and it can only be accessed with VPN, when I attempt to create a new Trust, it fails as it cannot contact it, any insights there? (I get a Cannot Continue - The New Trust Wizard cannot continue because the specified domain cannot be contacted - Either the domain does not exist, or network or other problems are preventing connection)
    – Steven
    Oct 21, 2019 at 14:34
  • Also, this You'll need to talk to your AD team to sort that out; trust configurations are domain-wide is a no-go, the corporate AD can not be modified under no circumstances, we're talking of an AD for all locations of the company I work for across all 5 continents Is that a show-stopper for setting up a Trust?
    – Steven
    Oct 21, 2019 at 14:39
  • There are a lot of open port prerequisites to establish a trust, and it requires Domain Admin / Enterprise Admin rights in both domains. You will require the consent and cooperation of your AD team(s)---and likely networking as well. Domain controllers are usually not advertised or accessible outside of their own forest (and forests with established trusts) for security reasons, so I would expect changes are necessary at both the server and network levels.
    – DoubleD
    Oct 21, 2019 at 14:41
  • @Steven From your most recent comment, it appears this will not be feasible. AD trusts are serious change to the security posture of the environment, in addition to the practical considerations.
    – DoubleD
    Oct 21, 2019 at 14:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .