SSC – anonymous LDAP bind

A customer was having a problem with getting the SSC to return users or groups using the “Manage Users” section after connecting to an LDAP source. When trying to search for a user they were getting the following errors in the SSC.

CWWIM4548E The LDAP attribute used as an external identifier ‘dominounid’ has a null value for entity ‘CN=Ben Williams,O=Acme’.

The Domino LDAP repository was managed by another company so we couldn’t see the schema but running an LDIF showed we weren’t seeing all the user attributes. To work around this the customer edited the wimconfig.xml (making a backup first!) and adding the line in bold below.

<config:externalIdAttributes name=”distinguishedName”/>
<config:attributes name=”userPassword” propertyName=”password”/>
<config:attributes name=”krbPrincipalName” propertyName=”kerberosId”>

Make sure the change is synchronised to all the nodes and the DM is then shut down and then started again. If you have any application servers installed then make sure the node agents and application servers are also restarted.

The customer was eventually provided with a bind account to use and the above change was undone.


Meeting federation/clustering fails with multiple IPs

I was asked to visit a customer who was having problems federating a primary node (Meeting server) with the SSC. They had some other problems as well which meant that I thought it was best to uninstall, clean up and reinstall.

After the two Meeting servers were reinstalled I hit the same problem when trying to federate the primary node. I looked in the addnode.log and noticed an error with an exception, unfortunately I didn’t take a note of the error but the crux of it was that during the addnode process the IP address the DM was resolving for the PN was incorrect.

Looking at the Windows 2008 server I noticed that it had two NICs, a primary and a management LAN. I added host file entries for the SSC and the two Meeting servers to all three servers after which federation worked fine.

I do not know why WAS picked the management IP, there is probably an algorithm it uses to decide but it is wise to be mindful of this if installing on a server with multiple IPs.

DB2 HADR – clustered Meeting servers

I needed to create a cluster of Sametime Meeting servers to ensure high availability. With WebSphere (like Domino) this is relatively easy but what about the database? DB2 HADR (High Availability and Disaster Recovery) ensures that two databases are kept in sync with each other in case one of the databases fails.

HADR does this by creating a primary and standby database. The primary is always in use whilst the standby is kept in sync using internal processes to ship database log buffers to it. A process at the standby server then replays the log records directly to the standby database. If the primary fails the standby database can be promoted to primary to take over responsibilities.

  • This is not a seamless fail over, it requires manual interaction to promote the standby database.
  • To achieve seamless fail over other tools such as TSA or HACMP must be used.
  • The standby cannot be accessed, only the primary can be read or written to.
  • In DB2 v9.7 the standby can be used for reads but if you cannot write to it I am unsure of the effect this might have on Sametime.

Instead of installing the limited use (CZLF7ML) version of DB2 for Linux I opted to use the full version (C1X0UEN) which gave me greater control over user accounts and install directory. I decided to use the GUI to set up HADR, good thing about it is that at almost every step you can see the command that the GUI is compiling should you wish to script it next time round.

Screen shots detailing HADR set up.

The deployment plans for the Meeting servers both have to point to the same DB2 fqhn as defined in the “Connect to DB2 databases” in the SSC. If the primary DB2 server should fail WebSphere will not be able to read/write to it even if the standby has been promoted to the primary. To fix this Automatic Client Reroute can be used within WebSphere.

You need to make each DB2 server aware of the other so that when a client connects it knows how to reroute it should it fail. You need to run the following command on each server referencing the other in the command line.

./db2 update alternate server for database STMS using hostname port 50000

Log in to the SSC and go to Resources – JDBC – Data sources. You will see a number of JDBC data sources, normally two for each Meeting node and two for the cluster.

Click on each (checking at the bottom of the page that it references STMS and not STSC) and then select “WebSphere Application Server data source properties” on the right hand side.

Under “DB2 automatic client reroute options” you have options of adding alternate servers and the ports they listen on. You configure your second database here. Make sure the changes synchronise with your nodes and that the applications servers are restarted afterwards.

If your primary database fails WebSphere will then connect to the alternate DB2 server as long as the alternate server has been made the primary.

Portal to Sametime – SSO & LTPAToken issue

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. [4098]
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.