There are good and not so good reasons for either option:

• To get the discussion started there seems to be the obvious choice to keep on using the Domino Directory when switching to LDAP. This way users can work in their familiar directory structure without the need to impose the rather technical structure of (our) AD.
• On the other hand it appears to be quite reasonable to also implement SPNEGO.  This however requires the use of Active Directory as a LDAP source.
• On the flip-side there is the obvious issue of the non-hierarchic structure of the Domino groups. Combine this with the requirement to have a base entry for LDAP defined as mentioned by Gabriella Davis and you are left with yet another point for consideration. Especially if you are reluctant to make existing groups in the Domino Directory hierarchic – who is doing that anyhow?

I am wondering how other environments have designed their solution. Did you really append an organisation to the name of groups just to make them available in an LDAP tree?
How did you maintain group entries in the vpuserinfo.nsf when moving between directories? Person entries are easily managed utilising the name change task but groups are rarely replicated between directories, hence the benefit of previously added public groups to the contact list is just gone.
Is there any way to use Domino as a LDAP source but still provide SSO in a Windows environment? I am wondering whether there is the possibility to have the Websphere server connecting to two directories, one for authentication, the other one for online awareness. Similar to the portal configuration described here. Or maybe utilising a Domino server for authentication with shared LTPA keys between Websphere and Domino?

I am sorry for everyone who expected any answers to their own questions in here. Do not hesitate though to leave a comment if you are having a suggestion for any of the questions raised in here or below.

If you are receiving an error “SQL5005C System Error” immediately after the launch of the operating system you have most likely missed to add your current user ID to the DB2Admin group on the local machine.

SQL5005C System Error

When re-installing the Sametime Gateway to convert it from a Single Server to a Network Deployment you are obviously faced with the task to re-configure the system, which definitely includes the SSL configuration. There might possibly be a way to transfer most of the configuration using Websphere scripts. In absence of any experience in this area I am going to describe the manual steps here.

Very important: create a backup of your Websphere directory before removing the old installation of the Gateway. I am assuming here that you have followed IBM’s instructionsfor the SSL setup of the single server and didn’t create a custom keystore. In this case you’ll find a key.p12 file within the profile config, which is the NodeDefaultKeyStore and a trust.p12 file, reflecting the NodeDefaultTrustStore.

On setting up the new Sametime Gateway server using network deployment you will be creating a new key store. Instead of creating a certificate request though you are going to import the existing certificate.

1. Select Personal Certificates under Additional properties and choose Import.
2. Choose Key store file and type the path to you key.p12 file.
3. Leave Type set to PKCS12.
4. Enter the Key file password. The default key store password, if you haven’t changed it, is WebAS .
5. Hit the ‘Get Key File Aliases’ button and select the alias to import in the drop down below.
6. Define the alias name for the import and hit okay.

Repeat above steps for all trust certificates using the trust.p12 file of the old installation and the CellDefaultTrustStore of the new installation. You can now continue with the SSL configuration for the cluster, the SIP and XMPP proxy.

As a side note to above: it is strongly recommended to change the password for your DefaultKeyStores. Otherwise an attacker might possibly be able to steal and misuse your identity.

Adam Brown – Starting up Lotus Connections automatically

Thanks for sharing!