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 []
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 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 [] 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 – <>, 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 []
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 =
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.


Communities/Quickr Connector – Community creator is not the owner of the Teamspace in Quickr

When the Quickr Connector is installed into Communities (Connections) a Quickr Teamspace can be created and linked to the Community to further increase collaboration.

The creation of the Teamspace within Quickr doesn’t use the Community owners credentials but the authentication alias resource created within the ISC.

This can cause confusion for the user who has created the Teamspace from the Community because their name does not appear as the owner. The default setting is for the creator of the Community to be given Manager access to the Teamspace in Quickr but by changing the communities-quickr-config.xml as detailed below the Community owner will now be listed as an owner in Quickr.



QuickrPlaceType name=”DominoTeamspace” enabled=”true”>
<comm:placeTemplate>Standard Place</comm:placeTemplate>

When creating a new Teamspace from a Community the owner will be wpsadmin as well as  the user. This may still cause confusion with users asking “who is wpsadmin?”

The way to remove wpsadmin is by removing it from the members folder within the Quickr Teamspace BUT the members folder is hidden by default because the ACL is managed from the Community.

As of Quickr Fix Pack 12 you can now show the members section by using the code below which should be in your qpconfig.xml. Once you have made the below changes, restart HTTP on the Quickr server, have the user log into their Quickr Teamspace and enter the members folder and then remove wpsadmin. Removing wpsadmin will not break the synchronisation of the ACL with the Community.




attribute         value    default  description
=========         =====    =======  ===========
enabled        true     no         Show the members folder when a Quickr place is created from within a Community.
false    yes      Hides the members folder.

<!– =============== START OF SAMPLE =================
<webservices enabled=”true”>
<atomws_response type=”get” />
<add_place_action enabled=”true” />
<views_include_rooms enabled=”false” />
<show_members_folder_in_toc enabled=”true” />
<use_short_place_name enabled=”true” />
=============== END OF SAMPLE =================== –>