UserIDs, DNs and Case sensitivity in RTC, LDAP and Sametime
Hi,
we found an issue with the propagation of status info between RTC client and Sametime client and I think it has to do with the LDAP DNs and case sensitivity.
We cannot use our customer's Sametime installation in RTC because the status info is not propagated from Sametime client to RTC client. Thus, "Chat" is greyed out for all users.
The effect we have in detail:
Scenario A: Configure RTC Client - Instant Messaging with Sametime UserID "abcdef"
-> we can connect from RTC Client to Sametime Client and we can change Sametime status in RTC Client but we only see status propagated from RTC Client to Sametime (towards local client and towards other clients).
But no status info from Sametime Client is displayed at all in RTC, everbody is "offline", including the current account(!).
Scenario B: Configure RTC Client - Instant Messaging with Sametime UserID using LDAP DN "uid=abcdef,ou=Partners,ou=External,o=company"
-> same as A
Scenario B: Configure RTC Client - Instant Messaging with Sametime UserID using LDAP DN "uid=ABCDEF,ou=Partners,ou=External,o=company" (now matching case exactly as in the LDAP that is connected to Sametime)
-> same as A, but now we do see our own (!) status information reflected in RTC client (but still no status info from the others).
So something is case sensitive and DN-sensitive here.
So I can now chat with myself, but not with others.
I have tried logging in to Sametime Client with different combinations of UserID and/or DN in upper case and/or lower case but that made no difference at all.
Seems that local Sametime Client needs a DN matching case exactly as stored in LDAP. But how about back to RTC?
What string format is transferred between Sametime Client and RTC Client? UserID and/or LDAP-DN? Case sensitive or case-insensitive?
I need to add that the customer's Sametime is using a different LDAP with different DNs than the Authentication LDAP.
Is it possible that Sametime client gives out all UserIDs as DNs instead of plain UserIDs and/or RTC client also uses DNs but from "the other" LDAP and since all of these are different it does not work in our environment?
Thanks for any enlightenment and hints how I can solve this, maybe by respecting case sensitivity in the correct places...
Cheers,
Meik
we found an issue with the propagation of status info between RTC client and Sametime client and I think it has to do with the LDAP DNs and case sensitivity.
We cannot use our customer's Sametime installation in RTC because the status info is not propagated from Sametime client to RTC client. Thus, "Chat" is greyed out for all users.
The effect we have in detail:
Scenario A: Configure RTC Client - Instant Messaging with Sametime UserID "abcdef"
-> we can connect from RTC Client to Sametime Client and we can change Sametime status in RTC Client but we only see status propagated from RTC Client to Sametime (towards local client and towards other clients).
But no status info from Sametime Client is displayed at all in RTC, everbody is "offline", including the current account(!).
Scenario B: Configure RTC Client - Instant Messaging with Sametime UserID using LDAP DN "uid=abcdef,ou=Partners,ou=External,o=company"
-> same as A
Scenario B: Configure RTC Client - Instant Messaging with Sametime UserID using LDAP DN "uid=ABCDEF,ou=Partners,ou=External,o=company" (now matching case exactly as in the LDAP that is connected to Sametime)
-> same as A, but now we do see our own (!) status information reflected in RTC client (but still no status info from the others).
So something is case sensitive and DN-sensitive here.
So I can now chat with myself, but not with others.
I have tried logging in to Sametime Client with different combinations of UserID and/or DN in upper case and/or lower case but that made no difference at all.
Seems that local Sametime Client needs a DN matching case exactly as stored in LDAP. But how about back to RTC?
What string format is transferred between Sametime Client and RTC Client? UserID and/or LDAP-DN? Case sensitive or case-insensitive?
I need to add that the customer's Sametime is using a different LDAP with different DNs than the Authentication LDAP.
Is it possible that Sametime client gives out all UserIDs as DNs instead of plain UserIDs and/or RTC client also uses DNs but from "the other" LDAP and since all of these are different it does not work in our environment?
Thanks for any enlightenment and hints how I can solve this, maybe by respecting case sensitivity in the correct places...
Cheers,
Meik
6 answers
I have the same problem as you do, but Im not using any other LDAP server. My all accounts are stored in Domino directory and vpuserinfo.nsf for sametime users.
My user in RTC is online and I can chat with myself :-) but others are offline. Sametime ID which Im using is: CN=MY NAME/O=MYCOMPANY
RTC Client is 2.0.0.1 and now I am trying with Sametime Connect Client 7.5.1
It is sad that with google talk or Jabber client everything works well but with IBM product Im loosing all week to make thinks working. And documentation i sooooo poor :-(
My user in RTC is online and I can chat with myself :-) but others are offline. Sametime ID which Im using is: CN=MY NAME/O=MYCOMPANY
RTC Client is 2.0.0.1 and now I am trying with Sametime Connect Client 7.5.1
It is sad that with google talk or Jabber client everything works well but with IBM product Im loosing all week to make thinks working. And documentation i sooooo poor :-(
Unfortunately not.
We are now in testing process of RTC 3.0 and I hope it will start to working. Gmail is working out of the box, but IBM Sametime not.
Please raise this as a defect so development can take a look at this (if you have not done so already). In the first example, I have a sneaking suspicion that have two LDAPs (or two different sources of authentication) is causing the problem but this is really just a guess.
anthony
In my case, both OpenFire and RTC are integrated with LDAP for authentication. I have a suspicion that this is happening because of case sensitivity of user IDs. But it's just a hunch.
I created this defect. Please see if you can add to the discussion.
http://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=162186
Thanks.
I created this defect. Please see if you can add to the discussion.
http://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=162186
Thanks.