user5336584 wrote:I've tried the Live Http Headers as of FF add-on to get the request/response header on Client as below FYI:
We have this working on PT 8.51 in environments with a Windows 2008 R2 domain controller and environments with a Windows 2003 domain controller.
When you checked the headers did you check whether the browser was sending the authorization header? It should start Negotiate YI..... if it is sending a Kerberos token. You can use tools such as Fiddler or HttpHeaders to check what the browser is sending.
If the browser is not sending a token then I'd try adding the site to your local intranet zone assuming you are using Internet Explorer. This should get rid of the domain user/password prompt and the browser will trust the site for Kerberos negotiation.In IE, the http://*.mydomain.com & https://*.mydomain.com already inserted in the local intranet zone. In the FF, at about:config, the network.negotiate-auth.trusted.uris is set as "mydomain.com"
We had a problem on one environment with Kerberos working over http but not https - this was because one environment was running an older Java version, 1.6.0_17 - updating to the correct version of JRockit to Java 1.6.0_26 has resolved that.For HTTPS login, in IE the Certificate Error with Red color highlighted, due to the certificate is not verified as a trusted CA. But the HTTPS can logged in and home page can displayed. (I guess the CA Error should not impact the HTTPS access, right?)
It might also be worth running a klist command (just type "klist" in a command prompt on the client machine) to see what tokens you have after trying to authenticate. You should see an entry corresponding to the server name.Here's the output for klist on my client server where to access the PIA from FF:
Another thing that could cause problems is a duplicate SPN. You can check for duplicates using the setspn command with the -x swicth (type "setspn -x" at a command prompt).I've run it from the Domain Controller, and the output show my the no dup entries: