Lotus what? Nah mate, the world has moved on.

Thursday, 18 November 2010

IBM i and Enterprise upgrades - Ensuring MSSO works.

Another 10 minute job that took three days, well not quite but it felt like it. We upgraded the dev environment for a big project I am running to 8.5.2 and the next step was to test SSO between Portal 5.1 and Domino. We accessed the Portal environment and clicked on the email icon. The next screen we expected was iNotes 7 mail. What we got was enter user credentials. #fail!

For those of us with limited attention spans, or certainly most twitter users, I have documented the answer here with my experiences following. The issue was to make sure that the domain field is properly populated in the LTPA setup in Portal. If not, Portal will issue a token using a hostname and not domain. Domino will not use the hostname for authentication as it requires a wild card domain for SSO authentication.
Of course it was immediately assumed that Domino was to blame as it was the last services to be upgraded. #fail 1.

Well, as with all challenges more is learned when things go wrong so here are my experiences.

The first thing I spotted in the Domino directory was the Web SSO Configuration document. It was set to Token Format:- LtpaToken (compatible with Domino 7 and prior releases) I immediately made an assumption that this is could be the issue (shame on me). I changed this field to LtpaToken and LtpaToken2 compatible with all releases. #fail 2.

Firstly, duh, Portal is authenticating and passing the token to Domino so this field is irrelevant. I can save you asking uncle Google now and let you know that all this field does is issue two Ltpa tokens using one key when authenticating to Domino.

This is a good document for some background information.

Here are the convoluted steps I took because I did not focus and made assumptions.

Activate debugs on Domino to see what was going wrong.
tell http debug session on
tell http debug thread on
tell http debug postdata on
tell http debug responsedata on
set config LDAPDEBUG=7
set config debug_sso_trace_level=3
stop consolelog
start consolelog

Top tip: Add the commands to custom commands when using the console in Domino Administrator.

These debugs provide wonderful reams of information that shows you what Domino is up to. However, you will soon be overwhelmed and crave the simplicity of no debugs! There was nothing really in the debug. I could see the LDAP server find the name and resolve properly and all seemed ok.

Next step was to go back to the SSO docs and check the realms and slashes. One confusing point was that the realm should add on a \:389 but due to the magic of Domino 7 upwards you do not need to add the \ before :389. Confusing but helpful.

Now for the "quirkiness" of Domino. Rant removed for own sanity.

Domino HTTP can operate in two distinct ways. It can use a legacy configuration to make sure it is compatible with older methods and to ensure migrations are easy. The old method required an IP Address for each and every site and logical site and a web server could only have one SSL cert. Not great and based on the old CERN server. We say legacy but most companies that do not use the great features of Domino will be on this type of config.

Domino can also use site documents and then it uses HTTP 1.1 headers and persistent connections or both. This is much closer to the Apache server and other modern web servers. With this configuration you can assign a separate SSL cert for each logical site plus a whole lot more such as url redirection etc.

To create a SSO config a web SSO document(s) must be created for either the legacy mode or 1.1 mode. In essence the difference between the two is simply entering the Organisation or not.

If there is no entry in Organisation field it becomes the legacy document listed in Web Configurations and first in the view called * - Web SSO Configurations.

If there is an organisation listed then it can be found Internet Sites and Web SSO configuration: Ltpa token name.

Please note that even some IBM products still require legacy mode for legitimate technical reasons so a hybrid model is most common meaning that you will have two SSO documents. This will really bite you if not careful. Also, forget about shortcuts. Once the configuration is complete you must reboot all servers to make SSO work properly.

Some may argue here and let me tell you from experience that when you go on site and somebody messed with the SSO document without your knowledge and a server is rebooted and the dreaded SSO Invalid message comes up you will get a call at stupidaclock saying you said ICM and failover will work and it does not and now a 1000 angry bees can’t access iNotes email. Buzzz, buzzzz, sting, sting, ouch!

This is taking longer than expected and I am ranting so here is how you should have isolated the issue.
  1. Start Domino and check for the entry Web SSO loaded after the HTTP server is started.
  2. Use Firefox and clear all cookies
  3. Sign on to a Domino web database and check the cookies.
  4. There should be one domain entry with two, if configured for Ltpatoken2, entries.
  5. Now open a database on the Sametime or Quickr server that requires authentication
  6. You should be automatically signed in
  7. Now access the Portal URL. You should be signed in automatically.
  8. Tell the Portal admin to fix the Portal config and go have a tea break
To redo the config simply import the WAS SSO Key. You do not have to recreate the document as the key will not expire. The key expiry is set to minutes, 300 recommended, and simply tells the cookie when it should expire and challenge you for credentials.

Simples hey!

Some more reading for you:


Post a Comment

Thank you for taking the time to comment. Your opinion is important and of value and we appreciate the positive feedback! If you are "Negative Nancy" then please do us, and humanity, a favor, and piss off.

Total Pageviews

Google+ Followers


Blog Archive

Popular Posts

Recent Comments

Rays Twitter feed


Web sites come and go and information is lost and therefore some pages are archived. @rayd123 . Powered by Blogger.