3

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

Steven
  • 83
  • 7
  • 1
    Hello Steven, could you please check the local hosts file and include a line or two for your localhost server as in the https://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 07 '19 at 13:44
  • Hi, Sorry for delay here, not been at work this week, will try to check over weekend, thanks! – Steven Oct 11 '19 at 15:15

1 Answers1

3

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.

DoubleD
  • 3,862
  • 1
  • 6
  • 14
  • 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 '19 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 '19 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 '19 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 '19 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 '19 at 14:43
  • So, here's the thing, in order to test basic functionality, we currently bypass all of this, using a Laptop with Windows Server 2012 installed. We start any app of our suite and we send a request from firefox on the separate Laptop to the app, this laptop with Windows Server isn't connected to the Corporate AD in any way Doing this, Kerberos does create a ticket and we can test authentication, however, this solution is far from ideal. And we thought it would be far easier to setup the same with AWS so we don't need to cart around with a laptop, but also to be able to test the Front End – Steven Oct 21 '19 at 14:56
  • Does that laptop have Active Directory installed, or does it have connectivity to your AD environment in AWS? One of those should be the case. – DoubleD Oct 21 '19 at 15:42
  • It has an Active Directory installed, as I have in AWS – Steven Oct 22 '19 at 07:23
  • So, within that environment your DCs can generate Kerberos tickets for your clients. If you want to use Kerberos tickets with corporate users or corporate machines, you will have to establish an AD trust with that domain. There is no workaround possible; this is how Kerberos functions by design. – DoubleD Oct 22 '19 at 20:10
  • Thank you so much for all your replies, you've really helped me get a better insight on this, however, when it comes to kerberos I never seem to know enough to be able to tackle a task, it's very hard to get info out there. A final thought is that if I installed firefox on the Windows Server that I have in AWS and accessed the application deployed on the CI machines (which are also under CORP domain) I might be able to emulate what we're doing with the separate laptop... I might post a new question if that approach doesn't work :) Thanks again! – Steven Oct 24 '19 at 07:19