powered by Jive Software

LDAP Group Roster Members


I’'ve managed to set up the groups to work well using the groupOfNames attribute. However, unless a user has logged into openfire, they are not shown as online in the roster.

Say, for example, Dave logs in - he’‘s in the Sales group. If George logs in (also in the sales group) he can see Dave, but Dave can’'t see George. If Dave logs out and back in, then he can then see George.

Is there a way for force George to be added to the list, so that he will show up on Dave’'s roster without Dave having to log out and log back in?

Are you using LDAP for user auth or just for groups? Openfire should be populating the group rosters from LDAP without each user having to log into the server. Can you share with us what your LDAP XML config looks like (see conf/openfire.xml)?





















  1. I am assuming that you are using AD

  2. Are you getting the users and groups populated correctly in server from LDAP

  3. Share any group from AD and give it a custom name via Group Options

  • Shared groups should automatically show AD members of that group as they log in
  1. If these features are not working then I would assume a configuration error in your LDAP config. Mine is below (note changes to AdminDN, vcard settings, and the addition of stuff for SSO):

<?xml version=“1.0” encoding=“UTF-8”?>


This file stores bootstrap properties needed by Openfire.

Property names must be in the format: “prop.name.is.blah=value”

That will be stored as:








Most properties are stored in the Openfire database. A

property viewer and editor is included in the admin console.


<!-- root element, all properties must be under this element -->



<!-- Disable either port by setting the value to -1 -->





<!-- Use this section to define users that will have admin privileges. Below,

you will find two ways to specify which users are admins. Admins will

have access to the admin console (only local users) and may have also access

to other functionalities like ad-hoc commands. -->

<!-- By default, only the user with the username “admin” can login

to the admin console. Alternatively, you can specify a comma-delimitted

list usernames that should be authorized to login to the admin console

by setting the <authorizedUsernames> field below. -->

<!-- <authorizedUsernames></authorizedUsernames> -->

<!-- Comma-delimitted list of bare JIDs. The JIDs may belong to local

or remote users. -->

<!-- <authorizedJIDs></authorizedJIDs> -->

<authorizedUsernames>toddg,troyf,tonyb,jime,bruceg,michaelk</authorize dUsernames>



<!-- Network settings. By default, Openfire will bind to all network interfaces.

Alternatively, you can specify a specific network interfaces that the server

will listen on. For example, This setting is generally only useful

on multi-homed servers. -->







<className>org.jivesoftware.database.EmbeddedConnectionProvider</class Name>


<!-- sasl configuration -->


<!-- Include a comma-separated list of the authentication mechanisms

to advertise support for to clients. Make sure GSSAPI is listed,

and best if it’'s listed first. The order of mechanisms is important;

clients should try to use the first mechanism they support

(although not all will). Some clients will try to use the most

secure first.

You can add other mechanisms in order to support non-GSSAPI clients,

or clients who cannot authenticate to the realm (like Windows 9X,

off-site, and so on). Keep in mind that by allowing other mechanisms

you are compromising the security of your realm. Be sure to talk

to the Security Officer/Directory/Manager/Administrator about any

policies your organization might have before enabling less secure

mechanisms. By removing PLAIN and ANONYMOUS from the list, you will

also disable non-SASL authentications.

Keep in mind that a mechanism listed here might not actually be

advertised, such as when the authProvider can’'t support the mechanism.

PLAIN and ANONYMOUS mechanisms also enable non-SASL authentication

(the old style XMPP auth), so removing them from this list will

disallow non-SASL authentication. -->



<!-- Specify the realm you used when you created the service principal

and keytab.–>


<!-- Mechanism-specific configuration here -->


<!-- Use true to turn on debugging information. This adds a lot

of noise to your log files, but it can help you spot problems

sooner in the initial setup. -->


<!-- Specify the location of the GSSAPI configuration file you edited. -->

<config>C:\Program Files\Openfire\conf\gss.conf</config>

<!-- Sets the system property with the same name. You’'ll probably want

“false” here (the default). For more details, see

http://java.sun.com/j2se/1.4.2/docs/api/org/ietf/jgss/package-summary.html -->

















<vCard xmlns=“vcard-temp”>













</ADR> <ADR>










</TEL> <TEL>
</TEL> <TEL>





























<className>org.jivesoftware.openfire.ldap.LdapVCardProvider</className >



<className>org.jivesoftware.openfire.ldap.LdapUserProvider</className& gt;



<className>org.jivesoftware.openfire.ldap.LdapAuthProvider</className& gt;



<className>org.jivesoftware.openfire.ldap.LdapGroupProvider</className >



<classList>org.jivesoftware.openfire.sasl.LooseAuthorizationPolicy org.jivesoftware.openfire.sasl.DefaultAuthorizationProvider</classList>

<!-- other options: null, LdapAuthorizationProvider, UnixK5LoginProvider, Strict and Lazy–>










Sorry, to clarify.

I’'m running openldap-2.3.27.

ServerSide - everything looks fine… the groups and users are populated correctly and log in and log out fine - and show up correctly in the users/groups tab.

It is clientside when the roster list is not correctly updated.

I need to do an upgrade to the next version now, so will see how that goes.

What platform are the clients running (Windows, Nix, Mac OS)?

I have had this problem in the past with the MSI installer from this site. Users that had the client installed from the MSI file had the issue of not updating. Uninstalling the MSI program, removing residual directories and reinstalling with the exe file fixed the issue 100% for me.

The only other option I can think of is firewall restrictions.