2

Background:

  1. Web server running LAMP stack
  2. Web server has VPN tunnel to AD network at HQ
  3. Multiple AD networks around the globe with VPN tunnels and trust relationships to HQ network
  4. Kerberos authentication configured on webserver and working for all networks using keytab files
  5. I am the web administrator but have no access to any of the AD network configurations

We have a problem with one AD network that only manifests with IE or Chrome when the PC used to access our web server is bound to the AD in question. No token is passed and there are no entries in the server logs related to token negotiation. If we use Firefox and enable the network.negotiate-auth options then the user is able to log in without issue however they get an authorisation required error when using IE. The web site is in the intranet zone and IWA is checked (this is controlled by the GPO)

If the users try to access the site with IE or Chrome from outside of their AD they get presented with the expected authentication login prompt and a token then gets sent properly.

I have spoken to the network administrators and they are certain that there is no special configuration required for AD to ensure Kerberos authentication works but I cannot understand why authentication works for six other AD networks and fails for this 1 if it isn't down to the AD configuration itself.

Am I missing something? What could explain the failure to negotiate a token?

[Note - this is not urgent, and as I am leaving the office now will answer any requests for more details on Monday]

Jameel
  • 79
  • 5

2 Answers2

1

The problem was that a token was being sent and negotiation attempted automatically when inside the AD network but it always failed because of the encryption used when generating the keytab.

Originally we used -crypto DES-CBC-CRC but as soon as we changed to using -crypto RC4-HMAC-NT the issue went away.

Jameel
  • 79
  • 5
0

Not an expert in this but I am inclined to think that if no negotiation tokens are being exchanged the problem might lie with the application not having its SPN registered with the keytab's associated username.

If that is the case, the following command run on the AD server might fix it:

setspn –a HTTP/(yourhostname) (keytabusername)

e.g. setspn -a HTTP/intranetappsrv.mycompany.com jbossaccount

zyked
  • 28
  • 1
  • 4
  • Thanks for the suggestion, I've relayed it to the network administrator - I'll post the response / results when I have them. – Jameel Apr 22 '14 at 10:27
  • SysAdmin for the network in question has just reported back - no joy, the problem still exists. – Jameel Apr 23 '14 at 12:15