The Connections project I’m currently working on is somewhat complex: Connections 4, Domino for mail, iNotes, Traveler, and Sametime Community server (not all on the same server), Sametime Standard, FileNet, and MS Active Directory 2008 for LDAP and authentication across the environment.
Being that I’m still a relative ‘newbie’ as far as WebSphere Application Server (WAS) is concerned, having only really used it for the setup and maintenance of the IBM/Lotus products sitting on top of it, I approached the SSO implementation with a degree of uncertainty and slight concern. We’re yet to implement SSO to include FileNet, that’s happening in the next week or two, so it was specifically for Connections, iNotes, Sametime awareness, Sametime Chat, and Sametime Meetings.
Sametime Standard is installed on a single WAS, Connections is on a separate server, and there are currently two Domino servers. So I generated the LTPA token in the Connections WAS, ensured that the LTPA domain was the same across all environments, and imported the token into Sametime Standard WAS and the Domino servers. And it worked, almost. Connections, iNotes, chat, awareness, and the Sametime Proxy server web chat client all worked when logging in with AD credentials. Sametime Meeting Server didn’t, and as soon as anyone logged into Meeting Server they were disconnected from everything else. The confusing aspect for me was that the Sametime Proxy and Sametime Meeting servers are both installed on the same WAS – with different IP addresses and DNS aliases so that they will play nicely together – so as the LTPA token is imported into WAS, I would have expected both the Proxy and Meeting servers to either work with SSO, or not.
What I’d missed was the Federated Repository Realm Name on the Sametime Standard WAS server. I’d changed it on the Connections server but Sametime was using the default realm name. This was what was breaking SSO for the Meeting Server and a quick rename and reboot sorted the problem.