Contacts Status not updating when using LDAP and shared groups

my environnement is :

openfire version : 3.5.0 (tried as well : 3.4.1, 3.4.3 and 3.4.5 with same error)
OS = debian etch (4.0)
openldap version : 2.3.30
users = around 150user pulled from LDAP
groups = around 50 groups pulled from ldap and all shared groups to all users.
backend = mysql 5.0.32

ISSUE= everything works except the contact status are not updating at all ( all

subscription are equal to “TO” when it should be “BOTH” in any roster )

my users need to logout /login again to see the online users.

  • i tried the upgrade solution ->same issue

  • i tried the scratch fresh install ->same issue

  • I tried setup the ldap manully into the config file instead of the wizard –>same issue

  • I tried flushing cache adn restarting the server –>same issue

  • i tried different version ( from 3.3.0 to 3.5.0)-> same issue

  • I tried changing the varchar(50)of the mysql tables to varchar(255) and flush the cache and restart (from Group name length - Openfire Support - Ignite Realtime Community Forums )-> same problem.

The only workaround (IT"S not an acceptable solution for my

company) is to fetch the user from ldap but create all the groups

manually and populate them manually .–>but it’s voiding all the

point of using LDAP.

The shared groups feature are not working.!! that’s a fact. So can

someone please accept this forum thread as a bug and fix it… i’m

happy to provide any details/debug and even beta test any solution or

piece of code.

Here my openfire.xml conf just in case :

<?xml version=“1.0” encoding=“UTF-8”?>
<jive>
<adminConsole>
<!-- Disable either port by setting the value to -1 –>
<port>9090</port>
<securePort>9091</securePort>
</adminConsole>
<admin>
<authorizedUsernames>XXXXX,XXXXX,XXXX,XXXXX</authorizedUsernames>
</admin>
<locale>en</locale>
<connectionProvider>
<className>org.jivesoftware.database.DefaultConnectionProvider</classN ame>
</connectionProvider>
<database>
<defaultProvider>
<driver>com.mysql.jdbc.Driver</driver>
<serverURL>jdbc:mysql://localhost:3306/XXXXXXX</serverURL>
<username>XXXXX</username>
<password>XXXXXXXXXX</password>
<minConnections>5</minConnections>
<maxConnections>15</maxConnections>
<connectionTimeout>1.0</connectionTimeout>
</defaultProvider>
</database>
<ldap>
<host>localhost</host>
<port>389</port>
<baseDN>dc=squiz,dc=net</baseDN>
<adminDN>cn=XXXXX,dc=squiz,dc=net</adminDN>
<adminPassword>XXXXXX</adminPassword>
<connectionPoolEnabled>true</connectionPoolEnabled>
<sslEnabled>false</sslEnabled>
<ldapDebugEnabled>false</ldapDebugEnabled>
<autoFollowReferrals>true</autoFollowReferrals>
<usernameField>uid</usernameField>
<searchFilter>(&(uid=)(ou:dn:=Staff))</searchFilter>
<nameField>cn</nameField>
<emailField>mail</emailField>
<groupNameField>cn</groupNameField>
<groupMemberField>memberUid</groupMemberField>
<groupDescriptionField>description</groupDescriptionField>
<posixMode>false</posixMode>
<groupSearchFilter>(&(cn=)(ou:dn:=Groups))</groupSearchFilter>
</ldap>
<provider>
<vcard>
<className>org.jivesoftware.openfire.ldap.LdapVCardProvider</className >
</vcard>
<user>
<className>org.jivesoftware.openfire.ldap.LdapUserProvider</className& gt;
</user>
<auth>
<className>org.jivesoftware.openfire.ldap.LdapAuthProvider</className& gt;
</auth>
<group>
<className>org.jivesoftware.openfire.ldap.LdapGroupProvider</className >
</group>
</provider>
<setup>true</setup>
<log>
<debug>
<enabled>false</enabled>
</debug>
</log>
</jive>

Cheers, Aurelien

I just installed the last version openfire 3.5.2 and JRE 1.6.0 update7 -->still the same issue : all user STATUS are not propagated even after a restart of the server

Can anyone help with that issue before i move my company jabber server to jabberd2 ?

I’ve been encountering the same problem. From reading the discussions, this issue dates back to 2006. I’m not left with much hope for a quick resolution. We just upgraded from Wildfire to OpenFire 3.5.2 and with the upgrade, hooked into our LDAP server. Now we get no presence notifications. Looking at the TCP/IP traffic with wireshark shows that the openfire server simply does not notify clients.

Also, looking at the user’s rosters in openfire shows that all users are set to “To:” instead of Both.

I tried the cache setting trick mentioned elsewhere, reducing the cache timeout to 15000ms, no luck.

I thought maybe this was because I didn’t have subscriptions plugin configured prior to connecting my user accounts. I rebuilt my server and enabled that first. No joy.

If anyone has other suggestions, I’d really like to try them out.

I may have just figured this out.

The error.log showed that username was not valid. Something like this:

2008.07.24 15:25:58 [org.jivesoftware.openfire.ldap.LdapGroupProvider.populateGroups(LdapGroupProvi der.java:683)]
javax.naming.InvalidNameException: Invalid name: jeffr
at javax.naming.ldap.Rfc2253Parser.doParse(Unknown Source)
at javax.naming.ldap.Rfc2253Parser.parseDn(Unknown Source)
at javax.naming.ldap.LdapName.parse(Unknown Source)
at javax.naming.ldap.LdapName.(Unknown Source)

More important, was this clue in the debug.log:

2008.07.24 15:16:19 Trying to find group names for user: sullivan@jabber.office.sproutsys.com using query: (&(&(cn=*)(objectClass=posixGroup))(memberUid=uid=“sullivan”,ou=“People”,dc=spr outsys,dc=com))

Notice that memberUid= looks like a bad concatenation. It reminded me that I had left LDAP Group Mapping Posix Mode to No because once I got the filter set, I could see groups. True, I could see the right groups without it, but since I define my groups using only the uid string, I had to set posix mode to true. Once I flipped that, my presence updates started working and the debug/error logs got cleaner.

Sorry to bother, I hope this helps answer someone else’s frustration someday.

Hi scott,

Thanks to contribute with your experience.

Unfortunately for me i definetly not using the posix mode for my group member list in my ldap tree .i use the full dn :

for example :

**cn=mygroup1,ou=Groups,dc=company,dc=net **

memberUid=uid=user1,ou=Users,dc=company,dc=net

** uid=user2,ou=Users,dc=company,dc=net**

** uid=userX,ou=Users,dc=company,dc=net**

“posix mode” is for people that use the user name instead of the user full dn. so in my case if i enable posix mode it won’t work anymore

I will trial for a couple of day the svn trunk version (future 3.6.0 version) to see if it fix my bug despite nothing appears in the changelog related to this typical issue.

**However i noticed something that may help devs :
**

  • I force my users to stop using the server
  • disable shared group feature on my group “allusers” which include as the title say all the user of my company
  • flush all the cache items from the guy
  • resetup ldap from scratch with same settings (see my cobfig.xml on the top of this thread
  • **reactivate “shared groups” on my group “allusers” **
    **
    **

All the roster subscription are good(“BOTH”) so my problem is fixed (all presence are propagated) until my users start connecting and using the server …then after few hours of use all the roster subscription of all my users move back to “TO” adn so my problem comes back (presence are not propagated anymore).

OpenFire 3.6.4 with the same problem here.

Same problem.

Trying POSIX mode.

Same problem here, I just enabled posix and have not had anyone else come in to check yet, I did change some of the cache settings earlier using this article.

http://www.igniterealtime.org/community/docs/DOC-1673

This did not fix anything for me.

I am also using 3.6.4, Debian lenny server, ldap is openDS. Clients tested with this problem - psi, gtalk, adium, spark, pidgin and kopete.

Has anyone ever figured this out? It is a pretty big problem for a XMPP server to have.

Posix was a bad idea for me, I am using posix groups to group all of my ldap users for openfire, but when enabled posix mode made it so each user was not authorized for the other users. I disabled and am doing more testing of the cache changes. So far those are looking like they may have actually worked. I am waiting 20 minutes for some new users to show up and test out their status. Having a current user and myself alternate logging off/shutting down our clients the status/presense is updating properly.