Tips about Configuring IBM Connections to work with SPNEGO as Authentication Mechanism

Recently a customer asked me to review his Connections environment and implement SSO via SPNEGO. He started implementing it, but he couldn´t make to work, so he wanted me to pick up where he left it and make it work. I had a fair share of troubles to make it work and along the way I found some “typical” problems, so I thought I share these issues (and some other I had in the past) with you and hopefully save you some time.

Invest time in reading the Documentation about the Technology you plan to use

On the second thought invest a lot of time. The configuration will make sense only if you know the basics about Kerberos, SPNEGO and WebSphere Security in general. It will also help you a great deal troubleshooting and things like a WireShark trace (yes it may come all the way to that) will make much more sense. I strongly urge you to read the following article:

https://www.ibm.com/developerworks/websphere/library/techarticles/0809_lansche/0809_lansche.html

I never found a better article explaining how SPNEGO works in combination with WebSphere, it´s old, but it´s good.

I also recommend using the WebSphere documentation instead of Connections documentation (where it makes sense of course), I think that it is generally more in depth and more up to date. Which is OK I guess because Implementing SPNEGO has a lot more to do with WebSphere than with Connections Applications.

Plan Accordingly

Make sure your environment is up to date and there are no discrepancies between the Test and Production environment (a Test environment is essential). And keep it that way, I mean if you hit a “brick wall” in the Test Environment, do not go ahead and update the Production because a new Update came out. This will save you a lot of headache. Different versions mean different problems, so the chances are you will be trying to solve different problems in the Production than in the Test environment, when implementing SPNEGO, while the Production is down and someone is waiting for the whole thing to go online again.

Make sure Test and Production environments are the same

Here is where the details matter, I know that it is not always possible to have the exact same copy of a Production environment as a Test environment, but make sure that at least the things like DNS, Shares, User Access Rights… are the same as in Production. Difference between “CNAME” Alias and a “Host (A)” Record can have a lot of impact.

We had an issue, this will surely be a plague of the Test Environments, where the WebSphere Server Hostname, Primary Administration User and the URL for Connections Access, had a “Name-Clash” (as described in the URL pasted above) so make sure you check that and/or consider when building a Test environment.

Do it Step by Step

I have made a mistake doing to many configuration changes at once, which essentially made it impossible to discover which part of the configuration led to an error. SPNEGO Implementation can be a combination of many different Configuration changes like: Primary Administrative User change, DNS changes and so on. So as my friend Martin Leyrer advised me, split the configuration in small steps/tasks, do one step, resync, restart and test and only after you are 100% happy with the change proceed with the next step.

Do you really need Kerberos?

As much as I know, SPNEGO is a “web friendly” version of Kerberos, right? So, it always made sense for me to do the Kerberos Configuration part in WebSphere before continuing with the SPNEGO part. Well I was wrong, the only Use-Case where you will need Kerberos implemented for IBM Connections is when you want to use IBM Connections Mail Plug-In with Exchange, which is not developed for Connections 6, so there´s that…

If you just want to achieve SSO from a Domain joined PC, then SPNEGO part will be sufficient. In that constellation Kerberos could just be another source of issues as Charlie Price made me realize that two months ago. 😀

LTPA Errors going through the roof

We had an issue with LTPA, basically everything we tried to do in Connections GUI produced a mass of LTPA Errors in the logs. I tried everything, regenerating the LTPA Keys and so on, I contacted the support team, but we could not solve the issue. So, I asked Sharon Bellamy James for advice and she told me to export the LTPA Token from WebSphere and import it again, this solved that issue. The GUI looked much better and there were no LTPA Errors anymore.

Service Principal Name

When creating a Service Principal Name, never use “HTTPS/” in the “KTPASS” command, even though you are accessing Connections via “HTTPS”, only use “HTTP/”. For Examle:

ktpass -out c:\Node1.keytab –princ HTTP/connections.axians.local@AXIANS.LOCAL -mapuser connections_user -mapOp set –pass Password1 -ptype KRB5_NT_PRINCIPAL

If you need more than one keytab files and Service Principal Names, use a separate AD User for every one of them.

Delegation User Setting

This is quite easy to forget, no matter what you do, Kerberos won´t work if your Service User Account used in the “KTPASS” command does not have the following setting set:

Although, I am not 100% sure you need to do this when you are Configuring SPNEGO without doing the Kerberos part in WebSphere. I will surely test this next time when I have a chance.

Disable TAI Authentication

For SPNEGO to work with WebSphere as it should, you need to disable TAI Authentication:

Go to Security –> Global Security –> Custom Properties