Leavers showing as off line through the Sametime Gateway

An internal user described a problem where as a leaver was showing as on line to IBM colleagues via their Sametime client, further more chats sent to the leaver was being received by the leaver’s manager. Our Gateway is federated with IBM’s so I can chat with them. I was a bit sceptical at first but after reproducing it I took a peek.

The manager had added the leaver’s email address to their person document so that email sent to the leaver was routed to them. Running a query for the leaver’s email address using ldapsearch resolved the email address to the  manager.Looking at the trace.log on the Gateway I could see the interaction and the email address resolving to the manager.

I created a mail in database document and added the email addresses of the leaver to it, gave it a name and then pointed the database to the manager’s mail file but still the leaver showed as on line. Looking at the trace.log again showed that

VPUsersCache  3 com.ibm.rtc.gateway.vp.util.cache.VPUsersCache getSTId Retrieved STId: {CN=Manager,O=ACME,}, for email: leaver@acme.com

This tells me that the email is being cached against the manager’s ID. After a restart of the Gateway the leaver does not show on line.



Sametime Proxy in iNotes – death of STLinks?

I was chatting with an IBM’er at the Exceptional Web Experience – IBM Portal Excellence Conference 2010 in Düsseldorf and asked him when Lotus products would start using the Sametime Proxy for awareness thus replacing the need to use STLinks. He told me it was coming soon. Not long afterwards a Developerworks article was  released detailing exactly how to do this.

The results are impressive and broadens the consistent UI between the Notes client, Proxy web client and now iNotes and most importantly it loads quickly.

This is not supported yet but is planned to be available in Sametime 8.5.2.

In this technology preview you also need to be running Domino 8.5.2 (iNotes) and Sametime 8.5 (not 8.5.1 or You will need to make some changes to you Notes.ini and replace your STProxyServer application via the SSC with the version provided in the article.

One thing I did notice, I got errors in IE8 when accessing iNotes but it works perfectly in Firefox.

The death of STLinks? I hope so.

No awareness in Sametime 8.5.1 Meeting – /C=US

I set up for a customer a Sametime 8.5.1 proof of concept environment consisting of two Linux servers hosting all the WAS components, Domino LDAP and a Windows Sametime Community server. This install was the “Cell Profile” which means that all components run with their own Deployment Manager and Node Agent and you can install multiple components on the same physical server.

Having been bitten in the early days by the Base DN issue I installed all components with a blank base DN because I was using a Domino directory as my LDAP repository. All components installed fine and when accessing the individual DM’s ISC’s and navigating to Users and Groups – Manage Users/Manage Groups I could search and return those users/groups I wanted.

The problem I came across is after enabling integration with the Meeting server and the Proxy server to power awareness in Meetings, awareness just didn’t work.

I enabled debugging on the Community server and found output such as the following in STUsers*.txt which shows that it is appending C=US to the dn which means that the Community server cannot resolve the name and hence why awareness is not working. I also found that SSO worked only in the one direction, Meetings –> STCenter.

101021_134743.595,INF,Users   ,got a request to get the home cluster for CN=Ben Williams,O=ACME
101021_134743.595,INF,LDAP Aut,getting tokens for [CN=Ben Williams,O=ACME]
101021_134743.595,INF,Token Au,get tokens – userId: CN=Ben Williams,O=ACME
101021_134743.595,INF,Token Au,getTokenFromDomino: getting tokens for: CN=Ben Williams,O=ACME
101021_134743.704,INF,Token Au,SECTokenListGenerate returned with status <0>
101021_134743.704,INF,Token Au,LTPA token was successfully generated
101021_134743.704,INF,LDAP Aut,stGetTokens returned [0]
101021_134743.704,FTL,LDAP Aut,authenticating user by tokens
101021_134743.704,INF,LDAP Aut,Starting auth by tokens for [CN=Ben Williams,O=ACME] in org[]
101021_134743.704,FTL,LDAP Aut,checking LDAP format….
101021_134743.704,INF,Token Au,Received token with type <1>
101021_134743.704,INF,Token Au,Validating LTPA/LTPA2 tokens
101021_134743.704,INF,Token Au,Created token entry of type <1>
101021_134743.704,INF,Token Au,SECTokenListValidate returned with status (0)
101021_134743.704,INF,Token Au,User ID extracted from the token is – CN=Ben Williams/O=ACME
101021_134743.704,INF,Token Au,Verify LTPA/LTPA2 token succeeded
101021_134743.704,INF,Token Au,getUserIdSubStrAccordingToConfig: full userId is CN=Ben Williams/O=ACME
101021_134743.704,INF,Token Au,getUserIdSubStrAccordingToConfig: the userId extracted according to uid_prefix and uid_postfix is CN=Ben Williams/O=ACME
101021_134743.704,INF,Token Au,authentication returned code ST_DDA_API_OK for name: CN=Ben Williams/O=ACME
101021_134743.704,INF,LDAP Aut,token for user user [CN=Ben Williams/O=ACME] was successfully verified
101021_134743.704,INF,LDAP Aut,AuthTokenContext::operationBeforeDirSearch verifyTokenAndExtractUserId has returned successfully.
Original login name – <CN=Ben Williams,O=ACME>, extracted user id – <CN=Ben Williams/O=ACME>.
Using the extracted user id.
101021_134743.704,INF,LDAP    ,Entering to isChild
101021_134743.704,INF,LDAP    ,dn = CN=Ben Williams,O=ACME, base =
101021_134743.704,INF,LDAP Aut,Looking up [req -1] [CN=Ben Williams,O=ACME] in [acmeldap.acme.com]
101021_134743.704,INF,ASYNC   ,VpUsrAuthenticate::getUserDetail: pass to authentication BB
101021_134743.704,INF,CRASH   ,ReqMgr::addAuthReq: got new reqId <0xffffffff>
101021_134743.704,INF,LDAP Aut,—- Thread ID: 2844
101021_134743.704,INF,LDAP Aut,Looking up CN=Ben Williams,O=ACME
101021_134743.704,INF,CRASH   ,—- Thread ID: 6128
101021_134743.704,INF,CRASH   ,ReqMgr::addAuthReq:added
101021_134743.704,INF,LDAP Aut,—- Thread ID: 636
101021_134743.704,INF,LDAP Aut,User CN=Ben Williams,O=ACME looked up
101021_134743.704,INF,LDAP Aut,user [CN=Ben Williams/O=ACME] successfully authenticated by token
101021_134743.704,INF,LDAP Aut,Async auth done. [req -1]

[user CN=Ben Williams,O=ACME] [name Ben Williams] [home ] [organization ]
101021_134743.767,INF,Users   ,VpUsrAuthenticate::handleCheckUser: authenticating user with loginName=Ben.Williams@acme.com by a single token
101021_134743.767,FTL,LDAP Aut,authenticating user by tokens
101021_134743.767,INF,LDAP Aut,Starting auth by tokens for [Ben.Williams@acme.com] in org[]
101021_134743.767,INF,Token Au,Received token with type <0>
101021_134743.767,INF,Token Au,Validating LTPA/LTPA2 tokens
101021_134743.767,INF,Token Au,Created token entry of type <0>
101021_134743.767,INF,Token Au,SECTokenListValidate returned with status (0)
101021_134743.767,INF,Token Au,User ID extracted from the token is – CN=Ben Williams/O=ACME/C=US
101021_134743.767,INF,Token Au,Verify LTPA/LTPA2 token succeeded
101021_134743.767,INF,Token Au,getUserIdSubStrAccordingToConfig: full userId is CN=Ben Williams/O=ACME/C=US
101021_134743.767,INF,Token Au,getUserIdSubStrAccordingToConfig: the userId extracted according to uid_prefix and uid_postfix is CN=Ben Williams/O=ACME/C=US
101021_134743.767,INF,Token Au,authentication returned code ST_DDA_API_OK for name: CN=Ben Williams/O=ACME/C=US
101021_134743.767,INF,LDAP Aut,token for user user [CN=Ben Williams/O=ACME/C=US] was successfully verified
101021_134743.767,INF,LDAP Aut,AuthTokenContext::operationBeforeDirSearch verifyTokenAndExtractUserId has returned successfully.
Original login name – <Ben.Williams@acme.com>, extracted user id – <CN=Ben Williams/O=ACME/C=US>.
Using the extracted user id.
101021_134743.767,INF,LDAP    ,Entering to isChild
101021_134743.767,INF,LDAP    ,dn = CN=Ben Williams,O=ACME,C=US, base =
101021_134743.767,INF,LDAP Aut,Looking up [req -2] [CN=Ben Williams,O=ACME,C=US] in [acmeldap.acme.com]
101021_134743.767,INF,ASYNC   ,VpUsrAuthenticate::authenticateByToken: pass to authentication BB reqId <0xfffffffe>
101021_134743.767,INF,CRASH   ,ReqMgr::addAuthReq: got new reqId <0xfffffffe>
101021_134743.767,INF,LDAP Aut,—- Thread ID: 2844
101021_134743.767,INF,LDAP Aut,Looking up CN=Ben Williams,O=ACME,C=US
101021_134743.767,INF,CRASH   ,—- Thread ID: 6128
101021_134743.767,INF,CRASH   ,ReqMgr::addAuthReq:added
101021_134743.767,FTL,LDAP Aut,—- Thread ID: 636
101021_134743.767,FTL,LDAP Aut,Failed looking up [CN=Ben Williams,O=ACME,C=US]. Trying directory-wide search
101021_134743.767,INF,LDAP Aut,—- Thread ID: 2844
101021_134743.767,INF,LDAP Aut,Searching [base ] [filter (&(objectclass=organizationalPerson)(|(mail=CN=Ben Williams/O=ACME/C=US)(cn=CN=Ben Williams/O=ACME/C=US)(uid=CN=Ben Williams/O=ACME/C=US)))] [scope Subtree]
101021_134743.767,INF,LDAP Aut,—- Thread ID: 636
101021_134743.767,INF,LDAP Aut,Search of [CN=Ben Williams/O=ACME/C=US] failed because the user was not found
101021_134743.767,INF,LDAP Aut,AuthContext::changeConversionFlagIfSearchAllowed()=> all the attempts to search for a LDAP record of [CN=Ben Williams,O=ACME,C=US] has been finished
101021_134743.767,INF,LDAP Aut,AuthContext::nextDir – done dir = acmeldap.acme.com
101021_134743.767,INF,LDAP Aut,Async auth failed. [req -2]

With a bit of help from IBM we were able to resolve the issue by making the following changes.

Make the following changes to the Meeting server DM as well as the SSC and remember to ensure that you make a backup of the wimconfig.xml and that you synchronise after each change and restart.

Log into the ISC
Go to Global Security –> Federated Repositories –>

for the Domino Federated Repository –

1.)Setting – Distinguished name of a base entry that uniquely identifies this set of entries in the realm  – to match the Domino org.

2.)Setting – “Distinguished name of a base entry in this repository” – to blank (empty)

3.) Edit the DM’s wimconfig.xml file under the profile_root/config/cells/cell_name/wim/config directory as follows (this example changes the mapping to “externalName”);

<config:uniqueUserIdMapping propertyForInput=”uniqueName” propertyForOutput=”uniqueName”/>

<config:uniqueUserIdMapping propertyForInput=”externalName” propertyForOutput=”externalName”/>

This is the key piece to prevent the appending of the O=ACME to the value in the token generated by WAS.

And then synchronise and restart the nodes and deployment manager.

Please note – if you make subsequent changes to the Global Security Federated Repository area using the ISC – Step 3 may need to be redone as changes may be lost.

What this does –

Step 1.) Insures that the username in the LTPA token created from Domino map to an existing repository in WAS – If there is no match, you get the “user not in defined realm” error in the logs.

Step 2.) Insures that Domino Flat groups can be found for policies

Step 3.) Insures that the username in the  LTPA token that WAS generates is resolvable by the Sametime Community Server. In general, Domino does not validate the username contained within the LTPA token, it grants the user “default” level access to the database based on the validity of the token.

The above has found it’s way into an APAR and should feature in a Technote soon and future releases of 8.5 should be configured this way out of the box.

Again, much thanks to IBM for assisting in fixing this.