Random thoughts from an unusual company

Problem Solving The 1-2-3 Punch. LDAP, WAS and SSO

Gabriella Davis  8 May 2012 22:46:35
Last weekend I was working on a Sametime install and ran across 3 separate problems that took more time than I'd like to resolve.  I thought I'd post here in case it's of use to anyone else.

Problem No.1: Domino LDAP

The customer gave me details of a Domino-based LDAP server to use for the install of Sametime.  Initially I only had Anonymous access as no credentials had been set up and it was a weekend so I didn't want to bother anyone else.  I installed the SSC and then went to configure LDAP but after clicking the "next" screen on LDAP base entry I got an error telling me I needed a base entry.  This was a surprise since WAS usually recognises Domino LDAP and lets me proceed without a base entry so I knew something was wrong.  Time to start troubleshooting...
Image:Problem Solving The 1-2-3 Punch.  LDAP, WAS and SSO
Firstly I know the SSC server can see the LDAP server or I wouldn't have made it as far as this screen, so I need to find out what's wrong with the LDAP server itself.  I install Softerra's LDAP Browser on the SSC and try to connect to the LDAP Domino server using the same details I tried to give the SSC.  The connection works but shows an error loading the rootDSE, basically a schema error.  In addition, Softerra can't query the server well enough to tell it's a Domino server which is suspicious.  I go and look at the Global Configuration document in Domino and see that the list of attributes available to Anonymous LDAP queries has been severely cut down from the default list so I reset that to "default' and relaunch LDAP.  This time I don't get the rootDSE problem but I do still get an error.  So I take another look and see that the LDAP server has a secondary directory specified in Directory Assistance pointing to a Notes database on a remote server and that database doesn't allow Anonymous access.  I move a replica of the database to the LDAP server and open up access for Anonymous and LDAP works fine.  I remove Anonymous and remove "available to LDAP clients" from the Directory Assistance document just in case and all is still fine.  Problem No.1 Solved.

Problem No.2: SSO Not Working

Everything is now installed but when I launch the Sametime Proxy client I get the error "server temporarily unavailable".  Usually this is down to the trusted servers field in Sametime but I confirmed that was OK so after more testing I decided to see if the Meeting Server had the same issue.  The Meeting Server via a browser can authenticate me fine but when I go from there to the Sametime Community Server homepage in Domino, I arrive not logged in.  So no SSO. Then I shut and restart the browser and try logging in first to the Domino Community Server and from there moving to the Meeting server homepage.  I arrive at the Meeting Server home page logged in.  Good. So we've narrowed the problem down, it is SSO from WAS to Domino not from Domino to WAS.  Since that's the case it's almost certainly my problem with the Sametime Proxy Server.  So I focus on fixing the SSO from the Meeting Server to Domino.  I enable LDAP debugging on the Domino server running Sametime (NOT the LDAP server) by adding:


which logs LDAP activity to the console (and to console.log if you have it running).  From the logs I can see that the token isn't able to be decrypted.  That's strange.  The usual fix for that is to re-export and import the WAS keys but after doing that carefully twice more, I go looking elsewhere.

On checking (on my 11inch screen) I realised the Domino LTPA token document had scrolled off the bottom and that the default value when I imported the Websphere keys was set to 'token compatible with Domino v7 or earlier' which requires LtpaToken.  I changed it to "compatible with all releases of Domino) which generates both LtpaToken and LtpaToken2 then went to check WAS.

Image:Problem Solving The 1-2-3 Punch.  LDAP, WAS and SSO
Logging into the SSC I go to my Global Security and Single Sign On section and check that interoperabiilty mode is checked.  It wasn't, which meant it was only generating a Ltpatoken2 .  So the default install gave me a WAS LtpaToken2 and a Domino LtpaToken that would never be able to talk.  I enabled Interoperability mode (I didn't have to, having changed Domino to recognise LtpaToken2, but I wanted to) restarted EVERYTHING and my Meeting Server could pass its credentials successfully to the Sametime Community Server.   Problem No.2 solved.

Image:Problem Solving The 1-2-3 Punch.  LDAP, WAS and SSO

One thing that sidetracked me was this IBM document http://ibm.co/IGGQnz which ,although full of really useful details, does make the statement that the reason for getting the "unable to decrypt token" message can only be down to the keys being wrong.  In my case that wasn't true, it was simply incompatible token settings between WAS and Domino.

Problem No.3: Sametime Proxy Server STILL Won't Login

So the Meeting server is working, I have SSO in both directions but my Sametime Proxy server is still showing "server temporarily unavailable".  Luckily I still have my LDAP debugging on and I test by first logging into the Meeting server then moving to Domino's homepage then onto the Proxy Server.  Checking the console output I see that although the Meeting Server uses the correct Web SSO document in Domino (called LtpaSTToken), the Proxy server arrives asking for the token LtpaToken which exists but is used by other servers and is secured from the Community Server. So why is the Sametime Proxy server trying to use the wrong Web SSO document in Domino? After all the configuration for which document to use is entirely within Domino itself and not configured in WAS.  Then I remember that Sametime has always had a problem with using a Ltpatoken called anything but Ltpatoken.  There used to be a sametime.ini setting that allowed you to override that and force Sametime to use a named token.  I find the technote and it's still true for Sametime 8.5x so I add the value ST_TOKEN_TYPE="LtpaSTToken" to the [AuthToken] section of sametime.ini and restart EVERYTHING again.  Problem fixed.


1Alan Head  09/05/2012 10:48:58  Problem Solving The 1-2-3 Punch. LDAP, WAS and SSO

Thanks, a very useful summary. Hadn't seen the WEBSESS_VERBOSE debug setting for Domino HTTP before.

Re the Base DN; is it possible to get around the WAS requirement for one in Federated Repository setup? I'm trying to find a way to integrate my multiple O Domino domain cleanly.

Thanks also for the Connections101.net series, its going to be a great resource for Domino admins.

2Gabriella Davis  09/05/2012 11:59:13  Problem Solving The 1-2-3 Punch. LDAP, WAS and SSO

Alan use a C= for base dn in ST. it's a level above O that most Domino sites don't use and WAS will federate all O's with that as the base dn

3Keith Brooks  09/05/2012 14:15:09  Problem Solving The 1-2-3 Punch. LDAP, WAS and SSO

Nice work Gab, nicely written up.

4Alan Head  10/05/2012 17:36:44  Problem Solving The 1-2-3 Punch. LDAP, WAS and SSO

Thanks, will give that a go.

5Luis Canelo  09/10/2012 19:02:31  Problem Solving The 1-2-3 Punch. LDAP, WAS and SSO

Hi, this document has been really helpful with my installation, i got SSO to work both ways between Community and Meeting server and all my Lotus Domino Servers in my company, but i haven't been able to make it work with iNotes, i have followed every tip i found but still can't login vía web (Firefox and IE), we have Domino 8.5.3 and Sametime 8.5.1, any advice?

6Alberto Marcos  22/05/2013 08:21:49  Problem Solving The 1-2-3 Punch. LDAP, WAS and SSO

For the problem 3, if still isn't working change in the sametime.ini:



Restart all and smile.

7Hussein  27/11/2014 18:10:58  Problem Solving The 1-2-3 Punch. LDAP, WAS and SSO


I installed SSO on Domino8.5.3 i access my domino web applications with AD credentials and it runs well

I have another Domino web application that runs on Dimino server 7.0.2. I configered SSO WITH a new Ltpatoken but here SSO doesn't work

Is it possible to logon using SSO on domino v7?

Best regards

Hussein k.