Gabriella Davis 8 May 2012 22:46:35Last 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...
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.
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.
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.
- Comments