IBM Connections 4 - SPNEGO ain't working

This was a blast from the past for me, having been away from IBM Connections and WebSphere Portal for nearly a year.

I took a call from a customer with whom I worked in 2010-12, who was finding that SPNEGO-based Single Sign-On was NOT working for IBM Connections 4, even though it WAS working for WebSphere Portal 8, both of which run on WAS 8, and use the same Active Directory infrastructure.

In essence, they accessed any protected URL in Connections, but found that the HTTP 401 Authenticate/Negotiate response was never issued.

I made a few suggestions on the call, including referencing back to my Connections/SPNEGO/AD presentation: -

DanNotes 2012 - My Presentations are Here

including enabling tracing to see what's going on.

I also raised a question about DNS and reverse lookups ( IP addresses to hostnames ) as I know that had caused a problem in the past.

Later in the day, I received an email from my customer, with some good news - he'd fixed it, and it's all now working.

They enabled tracing, and could see the following in the logs: -

[24/09/13 14:23:17:458 BST] 00000081 WebAuthentica <  handleSSO: (null) Exit

[24/09/13 14:23:17:458 BST] 00000081 WebAuthentica 3   handleSpnegoWebAuthentication was skipped.

which made no sense, as the URL was definitely protected, and yet they were falling back to the fallback login page: - 

[24/09/13 14:23:17:458 BST] 00000081 WebAuthentica >  handleCustomLogin Entry

[24/09/13 14:23:17:458 BST] 00000081 WebAuthentica 3   Form based login is configured for the resource
[24/09/13 14:23:17:458 BST] 00000081 WebAuthentica >  getFormURL Entry

When they accessed an unprotected URL ( one not being protected by SPNEGO ), they could see a log entry acknowledging that the URL was to be skipped.

They then removed all of the SPNEGO filters e.g.

request-url!=noSPNEGO;

request-url!=/mobile;

request-url!=/nav;

request-url!=/bundles/js;

request-url!=/static

 validating them by reformatting the list in Notepad, and then identified the problem - they had: -

requesturl

rather than: -

request-url

:-)

Thanks to Dave and his team for sharing the problem and, better still, the solution :-)