Kerberos authentication failing
I am setting up SSO in a corporate environment using CAS/Jasig to authenticate to the corporate LDAP using SPNEGO (Kerberos). When I attempt to access the secured resource in my FF browser, the initial Negoiate challenge is sent from CAS/Jasig and FF responds with a NTLMSSP token. CAS/Jasig dutifully responds back with another Negotiate header which, if I'm following everything correctly, FF is supposed to use to establish a Channel Binding Token. The call to function InitializeSecurityContext fails with a return code of -2146893054 and the auth process fails over to "challenge user for credentials" at that point.
What I've done
- verified the CAS/Jasig server can communicate with the LDAP directory using Kerberos. Server keytab file is fine, test run using the hadoop library's KerberosTestUtils class works perfectly.
- verified the client has Kerberos tickets - in fact, the klist utility from M$ says there are 29, including one valid today from one of the 4 AD domain controllers used here.
- rummaging about the iwebs, code -2146893054 corresponds to (I think) M$ SEC_E_UNSUPPORTED_FUNCTION exception. Docs say the this usually means an invalid context attribute flag was sent to the function. I've attempted the auth several different ways with negotiateauth debugging set to 5, but it doesn't seem to matter whether the session uses REQ_DELEGATE or REQ_MUTUAL_AUTH or both or neither (these are the only 2 configurable flags I can see in the source code for the nsAuthSSPI::GetNextToken function, which is where the error is thrown). The 2nd call to InitializeSecurityContext fails regardless
- other iweb sites indicate this error could be a mismatch between the client & the server, either in system time or encryption level required. I've verified that both the client machine and the CAS/Jasig server have system times within 2s of each other and both are requiring 128 bit encryption
I'm stuck now - near as I can tell, FF is supposed to shoot back another Authorization token in response to this 2nd Negotiate challenge to establish a secure channel, but none is being sent due to this error. I'm also confused why FF insists on sending an NTLMSSP token - why won't it send a Kerberos token? Any guidance as to where to look next would be appreciated.
Toutes les réponses (7)
First thought: https://access.redhat.com/site/docume.../sso-config-firefox.html More to come.
sorry for the long wait for my reply, vacation/holiday time intervened.
Thx for the link, but I've already been to that site - that's how I learned how to run FF w/enhanced logging and found the information about the error code I report above.
Just to be sure, I performed the configuration on a completely different machine. Good news is this time things did not blow up on the client side - the security context initialized just fine. In fact, on the new machine, FF did in fact send a Kerberos token rather than an NTLM token in response to the negotiate challenge. So that's good - there are remaining issues to get the whole thing working but they're on the CAS server side of things and have nothing to do with FF. One hurdle cleared.
However I still have the same question as above though: what is causing FF on the original machine to return a NTLM token in response to the negotiate challenge when FF on the new machine returns a Kerberos token? Is there some config parameter I'm missing? How does FF decide what kind of token to send back to a server once it's determined that yes, this server is one listed in the network,negotiate-auth.trusted-uris?
As much as the forum knows about Network connection: https://support.mozilla.org/en-US/kb/advanced-settings-browsing-network-u...
I am wondering if there was a change that the old NTLM token may still be a cached preference? "Override automatic cache management:" in that article may help determine if the old machine does have the NTLM token cached.
I also asked an expert, and they recommended the best way to check if it is a preference that has be cached on the 1st machine is to create a new profile and test it in the new profile. Profile Manager - Create, remove or switch Firefox profiles
I hope this puts you in the right direction.
You can remove all data stored in Firefox from a specific domain via "Forget About This Site" in the right-click context menu of an history entry ("History > Show All History" or "View > Sidebar > History") or via the about:permissions page.
Using "Forget About This Site" will remove all data stored in Firefox from that domain like bookmarks, cookies, passwords, cache, history, and exceptions, so be cautious and if you have a password or other data from that domain that you do not want to lose then make a note of those passwords and bookmarks.
You can't recover from this 'forget' unless you have a backup of the involved files.
It doesn't have any lasting effect, so if you revisit such a 'forgotten' website then data from that website will be saved once again.
Thx to you both - I created a completely new profile in FF to eliminate the possibility of a cached NTLM token. Unfortunately, that didn't help - I still get an NTLM token from the original machine.
And just to be clear - the failing machine it still throwing the error I describe in the original post, e.g. the FF's call to function InitializeSecurityContext fails with a Windows return code of -2146893054. So while I can move on in the sense of "I have other machines that will allow me to hopefully get a successful Kerberos authentication configured and running", the one that is failing happens to be the standard desktop image that all users here in the corp office have. As such, I really need to figure out why FF is throwing that particular error so I can tell our corp desktop people what they need to do to our standard image before this whole thing will work.
That error is IIS Web Server error and in the past has been concluded to be a DNS error. Refhttps://bugzilla.mozilla.org/show_bug.cgi?id=489536
So I am reading more bugs with this error code and it happens in web auto proxies and thunderbird LAN only environment. Both are not related, but what they have in common is web server and the error is unicode? or it is not? Are you using two legged or multilegged? http://msdn.microsoft.com/en-us/libra.../aa375512%28v=vs.85%29.aspx
It looks like that error code can be deciphered in that documentation as well. Are you using a proxy in your environment? https://bugzilla.mozilla.org/show_bug.cgi?id=276094
If you are using a proxy please check the ISA configuration, are both computers using the proxy?
I also found some plug ins that you can try if the isa configuration just will not work. However finding the root of the issue for the difference between the two computers may be the key to why one does not work over the other.
- http://code.google.com/p/firefox-ntlmauth/
- https://addons.mozilla.org/en-US/firefox/addon/integrated-auth-for-firefox/
Hope this helps.