I had a customer get in touch with me about a problem they were having when trying to start Sametime Classic meetings from IBM WebSphere Portal. They have a link in Portal to a load balancer which then directed HTTP traffic to one of two Sametime Classic Meeting servers.
When logging into Portal and selecting the link a browser would launch and the user would be logged into STCenter.nsf via SSO. When scheduling a meeting the Meeting Room Client (MRC) would load but as soon as the MRC tries to connect to Sametime Community services (chat) an error appears on the user’s screen.
I took this into a development environment and replicated the behaviour. After enabling debugging on the Sametime server I saw the following output in the stusers*.txt
101117_095933.869,INF,Users ,VpUsrAuthenticate::handleCheckUser: authenticating user with loginName=CN=Ben Williams/O=ACME by a single token
101117_095933.869,FTL,LDAP Aut,authenticating user by tokens
101117_095933.869,INF,LDAP Aut,Starting auth by tokens for [CN=Ben Williams/O=ACME] in org
101117_095933.869,FTL,LDAP Aut,checking LDAP format….
101117_095933.884,FTL,LDAP Aut,token verification failed. 
101117_095933.884,INF,LDAP Aut,AuthTokenContext::authenticateBeforeDirSearch verifyTokenAndExtractUserId failed with reason 4098
101117_095933.884,FTL,LDAP Aut,AuthContext::start: authenticateBeforeDirSearch failed with reason 4098
101117_095933.884,INF,Users ,VpUsrAuthenticate::checkedUser: VpUsrAuthenticate: bad login
I added debug_sso_trace_level=7 and Websess_verbose_Trace=1 to the Notes.ini but again nothing showed apart from when the browser opened STCenter.nsf, so on the Domino side of things SSO is working as expected.
Looking at the Java console output in the web browser when the MRC loaded I noticed “reverse proxy support disabled and detected” appear a few times. I observed this in the customer’s production environment and not in development so I ignored it which turned out to be a red herring.
It got me thinking about a problem I had with Sametime 8.0.2 and an LTPA parsing issue which produced similar errors although not exactly the same. That problem was fixed with a Sametime hot fix and was included in later versions of Sametime so it couldn’t be the same but must be along the same lines.
I exported the LTPAToken from the Portal deployment manager (DM) and imported it back into the Domino web SSO configuration document and restarted but this didn’t resolve the problem.
I then took more time looking at the Portal DM and noticed that Interoperability Mode was enabled which means that LTPAToken and LTPAToken2 are created.
Looking at the web SSO configuration document it was set to LTPAToken only.
After changing it to LTPAToken and LTPAToken2 and restarting things started working and users could now schedule and start meetings.