Openfire LDAP Group Query Help

Nehemiah_Gough · January 30, 2008, 12:03am

Hello,

I am running Openfire 3.4.3 and am running into a problem with my LDAP filtering for my groups. In the past we had a Wildfire server setup with a very similar query for groups with no issue, but things do not seem to be working with Openfire the way we want it to. We have about 2400+ users listed in various OUs of our Domain and growing. We have our users separated into Jabber groups depending on their roles in the company. The search filter for users requires that they be in the SG.Jabber.Users group as a requirement to be a user. The search filter for the group requires that they be in the specific SG.Jabber.Role.xxx group and that the SG.Jabber.Role.xxx group be a member of the SG.Jabber.Groups group or it will not show. The “groupMemberField” option has been commented out so it should be defaulting to “member” as it’s value (I have tried with it’s value pointing to member, same results).

The query appears to work because the users are found and the groups are found, but somehow, random amounts of users in groups are missing. A user who shows up under “Users” from the admin console, will not necessarily show up under the group that Openfire indicates they are registered to. Logging in using Spark to the server as the user is possible. They can even see members of other groups, but they cannot be seen by other members. If they attempt to message the user, they do not show as messaging from the specific group, but from nowhere (like a user from a non shared /group).

I will include both the user and group queries from my openfire.xml,

user:

<usernameField>sAMAccountName</usernameField>
<searchFilter>(& (objectCategory=CN=Person,CN=Schema,CN=Configuration,DC=backoffice,DC=company,D C=com)(sAMAccountName=) (!(userAccountControl:1.2.840.113556.1.4.803:=2)) (memberOf=CN=SG.Jabber.Users,OU=Jabber,OU=_Other,OU=v2,DC=backoffice,DC=company ,DC=com) )</searchFilter>

group:

<groupSearchFilter>(&(objectCategory=CN=Group,CN=Schema,CN=Configurati on,DC=backoffice,DC=company,DC=com)(memberOf=CN=SG.Jabber.Groups,OU=Jabber,OU=_O ther,OU=v2,DC=backoffice,DC=company,DC=com))</groupSearchFilter>

I have been trying variants of these but have not been able to get a successful query that will show all the users. I have investigated these users, and they do not appear any different than the other users. I’ve removed their jabber groups and re-added them in hopes that the server would see these users anew, but no luck.

Any advice would be greatly appreciated!

Jonas · January 30, 2008, 3:24pm

Ok…if I got that right and your users are able to login, I’d say your userfilter is correct or at least functional.

Are your groups sorted as they should and only users behaving strange?

Are users “unique” (Every user in exactly one group only?) As far as I read somewhere here Openfire has troubles handling groups that contain a single user more than once (in the same or different groups). I cannot confirm or reject that, my users only appear once in my groups.

Nehemiah_Gough · January 30, 2008, 4:05pm

Hey No.2,

With our current setup, users depending on their roles can appear in multiple security groups. Can anyone confirm this bug with Openfire handling multiple groups? This may help.

Unfortunately this seems to be a separate issue. I can identify users that only have one Openfire group and are still invisible. I have a group with 700 some users, yet only 500 out of those are visible. The majority of the users in this group are not in any other Openfire group. The closest posts I could find related to this issue are these:

http://www.igniterealtime.org/community/message/162134

http://www.igniterealtime.org/community/message/163451

Cameron_Moore · January 30, 2008, 5:26pm

Some thoughts:

Is it only happening to large groups? LDAP servers will sometimes limit the amount of results that will be returned for a single query (ie. max 500 results). You might want to look into that. I think they call it using paged results, but it’s been a while. Openfire should be doing that already,but who knows.
Are the users odd in any way? For example, non-alpha characters in usernames or anything like that.
Turn on LDAP debugging and see what you find.

My first thought was that it’s a bug, but you’ll definately need to get more details on exactly what’s going wrong for us to determine that.

Carl_Hertz · January 30, 2008, 5:43pm

Openfire (non Enterprise at least) will not page through LDAP. ;(

The LDAP page size is a forest-level setting in AD. Since our company has our pagelimit set to 1000, we can list up to 1000 users in Jabber, rather than our whole group of users. The answer is, for the free version at least, your limit per server is your LDAP page size. You can work around this by filtering users and groups.

However, there is a ‘neat’ bug in the newer builds of Openfire if you re-run the configuration… If you use the ‘&’ charater in your group or user filter statement, the XML parser in the setup program doesn’t parse it correctly… the xml will double-up the & escape sequence, so you will need to manually edit these out.

For example, our filter for users is:

(&(objectClass=user)(extensionAttribute10=jabber))

This should show up under c:\progfiles\openfire\conf\openfire.xml as:

<searchFilter>(&(objectClass=user)(extensionAttribute10=jabber))&l t;/searchFilter>

but the XML parser in the configuration program screws up and puts it as:

<searchFilter>(&&(objectClass=user)(extensionAttribute10=j abber))</searchFilter>

Hope that information helps you…

Nehemiah_Gough · January 30, 2008, 6:09pm

Hello hrothgar,

Thanks for the info.

We had encountered the limit issue with Wildfire with some particularly large groups, and found that over 1000 member limit due to the paging issue it does not show these additional users. We split them (and keep doing so) whenever that issue arises…unless the amount of users and behaviour has changed with Openfire (groups aren’t at 1000+ members, and usually doesnt show ANY users in that group when the limit is hit).
The users appear normal, I’ve even used an LDAP browser to compare anything that LDAP may be picking up. Nothing out of the normal. The example I have below is actually one of our more simple roles in our organization, nothing complex at all, just one Openfire group that they need.
Debug log shows the following for LDAP (sorry for the size but don’t want to miss anything):

2008.01.30 12:45:14 XMPPCallbackHandler: NameCallback: aandrews

2008.01.30 12:45:14 XMPPCallbackHandler: VerifyPasswordCallback

2008.01.30 12:45:14 LdapManager: Trying to find a user’s DN based on their username. sAMAccountName: aandrews, Base DN: dc=backoffice;dc=company;dc=com…

2008.01.30 12:45:14 LdapManager: Creating a DirContext in LdapManager.getContext()…

2008.01.30 12:45:14 LdapManager: Created hashtable with context values, attempting to create context…

2008.01.30 12:45:14 LdapManager: … context created successfully, returning.

2008.01.30 12:45:14 LdapManager: Starting LDAP search…

2008.01.30 12:45:14 LdapManager: … search finished

2008.01.30 12:45:14 LdapManager: In LdapManager.checkAuthentication(userDN, password), userDN is: CN=“Andrews, Anne”,OU=“Remote Instructors Domain Accounts”,OU=“Ed Services”,OU=“Operations”,OU=“v2”…

2008.01.30 12:45:14 LdapManager: Created context values, attempting to create context…

2008.01.30 12:45:14 LdapManager: … context created successfully, returning.

2008.01.30 12:45:14 XMPPCallbackHandler: AuthorizeCallback

2008.01.30 12:45:14 AuthorizationManager: Trying Default Mapping.map(aandrews)

2008.01.30 12:45:14 DefaultAuthorizationMapping: No realm found

2008.01.30 12:45:14 XMPPCallbackHandler: no username requested, using aandrews

2008.01.30 12:45:14 AuthorizationManager: Trying Default Policy.authorize(aandrews , aandrews)

2008.01.30 12:45:14 DefaultAuthorizationPolicy: Checking authenID realm

2008.01.30 12:45:14 LdapManager: Trying to find a user’s DN based on their username. sAMAccountName: aandrews, Base DN: dc=backoffice;dc=company;dc=com…

2008.01.30 12:45:14 LdapManager: Creating a DirContext in LdapManager.getContext()…

2008.01.30 12:45:14 LdapManager: Created hashtable with context values, attempting to create context…

2008.01.30 12:45:14 LdapManager: … context created successfully, returning.

2008.01.30 12:45:14 LdapManager: Starting LDAP search…

2008.01.30 12:45:14 LdapManager: … search finished

2008.01.30 12:45:14 LdapManager: Trying to find a user’s DN based on their username. sAMAccountName: aandrews, Base DN: dc=backoffice;dc=company;dc=com…

2008.01.30 12:45:14 LdapManager: Creating a DirContext in LdapManager.getContext()…

2008.01.30 12:45:14 LdapManager: Created hashtable with context values, attempting to create context…

2008.01.30 12:45:14 LdapManager: … context created successfully, returning.

2008.01.30 12:45:14 LdapManager: Starting LDAP search…

2008.01.30 12:45:14 LdapManager: … search finished

2008.01.30 12:45:14 LdapManager: Creating a DirContext in LdapManager.getContext()…

2008.01.30 12:45:14 LdapManager: Created hashtable with context values, attempting to create context…

2008.01.30 12:45:14 LdapManager: … context created successfully, returning.

2008.01.30 12:45:14 XMPPCallbackHandler: aandrews authorized to aandrews

2008.01.30 12:45:14 LdapManager: Trying to find a user’s DN based on their username. sAMAccountName: aandrews, Base DN: dc=backoffice;dc=company;dc=com…

2008.01.30 12:45:14 LdapManager: Creating a DirContext in LdapManager.getContext()…

2008.01.30 12:45:14 LdapManager: Created hashtable with context values, attempting to create context…

2008.01.30 12:45:14 LdapManager: … context created successfully, returning.

2008.01.30 12:45:14 LdapManager: Starting LDAP search…

2008.01.30 12:45:14 LdapManager: … search finished

2008.01.30 12:45:14 LdapManager: Creating a DirContext in LdapManager.getContext()…

2008.01.30 12:45:14 LdapManager: Created hashtable with context values, attempting to create context…

2008.01.30 12:45:14 LdapManager: … context created successfully, returning.

2008.01.30 12:45:14 Trying to find group names for user: aandrews@im.company.com using query: (&(&(cn=*)(&(objectCategory=CN=Group,CN=Schema,CN=Configuration,DC=backoffice,D C=company,DC=com)(memberOf=CN=SG.Jabber.Groups,OU=Jabber,OU=_Other,OU=v2,DC=back office,DC=company,DC=com)))(member=CN=“Andrews, Anne”,OU=“Remote Instructors Domain Accounts”,OU=“Ed Services”,OU=“Operations”,OU=“v2”,dc=backoffice;dc=company;dc=com))
2008.01.30 12:45:15 LdapManager: Trying to find a user’s DN based on their username. sAMAccountName: aandrews, Base DN: dc=backoffice;dc=company;dc=com…

2008.01.30 12:45:15 LdapManager: Creating a DirContext in LdapManager.getContext()…

2008.01.30 12:45:15 LdapManager: Created hashtable with context values, attempting to create context…

2008.01.30 12:45:15 LdapManager: … context created successfully, returning.

2008.01.30 12:45:15 LdapManager: Starting LDAP search…

2008.01.30 12:45:15 LdapManager: … search finished

2008.01.30 12:45:15 LdapManager: Trying to find a user’s DN based on their username. sAMAccountName: aandrews, Base DN: dc=backoffice;dc=company;dc=com…

2008.01.30 12:45:15 LdapManager: Creating a DirContext in LdapManager.getContext()…

2008.01.30 12:45:15 LdapManager: Created hashtable with context values, attempting to create context…

2008.01.30 12:45:15 LdapManager: … context created successfully, returning.

2008.01.30 12:45:15 LdapManager: Starting LDAP search…

2008.01.30 12:45:15 LdapManager: … search finished

2008.01.30 12:45:15 LdapManager: Creating a DirContext in LdapManager.getContext()…

2008.01.30 12:45:15 LdapManager: Created hashtable with context values, attempting to create context…

2008.01.30 12:45:15 LdapManager: … context created successfully, returning.

I’ve highlighted in red, where I suspect an issue may be occuring?

In response to chertz’s post, could the extra appended ampersand be affecting this particular query? To resolve this, can I just remove my ampersand and Openfire will automatically “append” the ampersand? Then after this bug is fixed I will just need to add it back, like a normal query?

Thanks for your help so far guys.

Carl_Hertz · January 30, 2008, 6:14pm

For the bug I am talking about, you will have to see how it is written in the openfire.xml file. If the apersand escape sequence is doubled up, simply delete out the second escape sequence. You will have to stop the service to be able to edit/save your changes to the XML. If this is the issue, once you edit the XML, you will not have to go back to it unless you use the setup program again… the problem is not with the server itself but with the XML parser in the setup program.

Nehemiah_Gough · January 30, 2008, 6:17pm

OK thanks Chertz,

So this bug only affects those who went through the setup portion for the LDAP? OK, yeah my openfire.xml is clean so I don’t think this is an issue, but always good to be aware of it. Also, this is happening in our small groups as well as amply sized groups. I can’t yet find a pattern on why it affects some users and not others.

Carl_Hertz · January 30, 2008, 6:34pm

–So this bug only affects those who went through the setup portion for the LDAP?

Yup. So this isn’t causing your issue. Sorry.

Jonas · January 31, 2008, 8:35am

That’s not completely true…it affects also those that update their server…as far as I remember the xml gets checked and is being rewritten with the wrong filter. Anyway…the bug is said to be fixed in 3.4.5 afaik (according to the bugtracker).

Anyways the only thing this bug does is either it screws your filter completely or (in my case) the server crashes when parsing the xml…so that should not be the case for this issue.

Nehemiah_Gough · January 31, 2008, 3:39pm

So to rule out other unforseen issues, that might have happened when I upgraded Openfire to 3.4.3 from 3.3.x, I did a fresh install to 3.4.4 this morning and created a new SQLServer 2k5 database (just to be sure). I still used the same openfire.xml config. The issue still seems to be the same. In groups where there should be 14 users, only 9 show, etc. Any ideas, or could this be a bug in the LDAP search filter with Openfire? ?

Cameron_Moore · January 31, 2008, 4:55pm

Try doing a manual LDAP query and make sure that you are really getting the results you want from the LDAP server.

Nehemiah_Gough · January 31, 2008, 6:57pm

Hey hrothgar,

At first I thought the issue was because I had written out the “(sAMAccount=)” command in the ldap.searchFilter query. I had noticed that this was failing when I tried to run the query directly in AD (I actually just needed to use sAMAccount=* ). I then read that the search filter automatically appends the (=) to your ldap.usernameField, so I realized it wasn’t necessary. However, even after removing this, the issue persists in Openfire. I get back the correct amount of users and correct amount of groups from bothe queries when ran through AD custom search. So now I have a bit more of an efficient query, but the issue persists.

I have my ldap.groupSearchFilter pulling members out of a primary group. These members consist of groups. Maybe there is a problem with pulling all the members out of these groups somehow? I can simplify and rewrite the query to search for a string of groups with a certain name?

to the effect of: (&(objectCategory=Group)(CN=SG.Jabber.Role.*))

I know I was reading that Openfire doesn’t support nested groups and queries flat, but this has worked without issue in the Wildfire implementation so I wonder what is affecting it with the later Openifre?

Nehemiah_Gough · February 15, 2008, 8:23pm

Update:

I decided to setup Openfire 3.4.5 on a brand new w2k3 server with everything clean, using Windows AD for LDAP. We also wanted to try out the Enterprise plugin as we were considering this. I ran through everything manually via the guide walkthroughs. Here’s the intersting part. On step 3, when I setup my custom LDAP Group filtering like so:

(&(memberOf=CN=SG.Jabber.Groups,OU=Jabber,OU=_Other,OU=v2,DC=my,DC=company,DC=co m))

I run a test, which brings back the initial 10 group results. It happens that one of the groups on here before do not populate with the correct amount of members, however this time it does via this test screen. For this group it shows correctly (shows 9 out of 9), whenever I run the test. However, when I save the settings, and log into the Openfire Admin console after finishing the initial setup. I can now go to Users/Groups>>Group Summary, pull up the same group and it shows an inaccurate amount (shows only six out of nine, versus the correct nine that it showed in the test during the initial setup), just as it does on our production im server. I really do not understand where the disconnect happens. I’ve changed the query, and it does not seem to matter. Do any Openfire devs or LDAP gurus have any theories on this situation? Can this be concluded to be a bug with the way Openfire queries LDAP? We’re really stuck in a bind here…please help.

Nehemiah_Gough · March 4, 2008, 3:37pm

Update:

I wanted to recreate an account as a workaround to this issue, as no new accounts so far have had this invisible user issue. What I did first was copy the original account. While doing this I had noticed that the copied account DID show up as a member of the groups that the original user did not show up in under the Admin Console group’s page. So I proceeded to make a new account with the exact same settings (username formatting/spelling included, permissions, etc). After I created the account, I noticed that the new account did not show up in the console like I had expected. So I deleted the new account, and then renamed the backup copy that was still showing up in the admin console as a member of its assigned groups to the original user’s name instead of “jdoebackup” to “jdoe”. After the rename, this account now also disappeared which baffled me, as it was working fine before I renamed the account. This led me to believe that the issue could be something related to the username or something affected in the renaming, or possibly something stored in the sql database that may had never been removed.

After doing a bit of tinkering, what I found out was that by adding an extra character in the “Full Name” field (no other field affects the outcome that I found), it causes the user to show up under the group. Our company has structured the Full Name to be in this format “Doe, John”. After I placed a space after the comma in the full name field, “Doe, John” the AD account now appears as a member of its appropriate groups. I’ve tried this with various other usernames that have had the invisibility issue and this does work as a temporary workaround. They are now listing correctly. I haven’t seen any pattern so far with the names that could cause this oddity.

Christopher_McCraken · March 18, 2008, 9:47pm

Having a similar problem with openfire.

I flipped on Debug, just to see if I could find some disparity between the users.

Here is user one. We will call him John Doe. He shows up in the userlist, and is properly populated.

2008.03.18 16:03:21 User DN based on username ‘cn=John Doe,ou=users,ou=OrgUnit,ou=corporate,dc=somedomain,dc=com’ not found.

2008.03.18 16:03:21 Exception thrown when searching for userDN based on username ‘cn=John Doe,ou=users,ou=OrgUnit,ou=corporate,dc=somedomain,dc=com’

org.jivesoftware.openfire.user.UserNotFoundException: Username cn=John Doe,ou=users,ou=OrgUnit,ou=corporate,dc=somedomain,dc=com not found

at org.jivesoftware.openfire.ldap.LdapManager.findUserDN(LdapManager.java:635)

at org.jivesoftware.openfire.ldap.LdapManager.findUserDN(LdapManager.java:561)

at org.jivesoftware.openfire.ldap.LdapUserProvider.loadUser(LdapUserProvider.java: 84)

at org.jivesoftware.openfire.user.UserManager.getUser(UserManager.java:200)

at org.jivesoftware.openfire.ldap.LdapGroupProvider.populateGroups(LdapGroupProvid er.java:698)

at org.jivesoftware.openfire.ldap.LdapGroupProvider.getGroup(LdapGroupProvider.jav a:99)

at org.jivesoftware.openfire.group.GroupManager.getGroup(GroupManager.java:201)

at org.jivesoftware.openfire.group.GroupCollection$UserIterator.getNextElement(Gro upCollection.java:102)

at org.jivesoftware.openfire.group.GroupCollection$UserIterator.hasNext(GroupColle ction.java:65)

at org.jivesoftware.openfire.roster.RosterManager.getSharedGroups(RosterManager.ja va:161)

at org.jivesoftware.openfire.roster.Roster.<init>(Roster.java:104)

at org.jivesoftware.openfire.roster.RosterManager.getRoster(RosterManager.java:85)

at org.jivesoftware.openfire.handler.PresenceUpdateHandler.broadcastUpdate(Presenc eUpdateHandler.java:280)

at org.jivesoftware.openfire.handler.PresenceUpdateHandler.process(PresenceUpdateH andler.java:122)

at org.jivesoftware.openfire.handler.PresenceUpdateHandler.process(PresenceUpdateH andler.java:110)

at org.jivesoftware.openfire.handler.PresenceUpdateHandler.process(PresenceUpdateH andler.java:174)

at org.jivesoftware.openfire.PresenceRouter.handle(PresenceRouter.java:130)

at org.jivesoftware.openfire.PresenceRouter.route(PresenceRouter.java:67)

at org.jivesoftware.openfire.spi.PacketRouterImpl.route(PacketRouterImpl.java:75)

at org.jivesoftware.openfire.net.StanzaHandler.processPresence(StanzaHandler.java: 321)

at org.jivesoftware.openfire.net.ClientStanzaHandler.processPresence(ClientStanzaH andler.java:84)

at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:245)

at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:167)

at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandl er.java:132)

Here is user two. We will call them Jane Doe. She cannot be seen in the userlist, and does not properly populate. But, she CAN be sent IM’s.

2008.03.18 16:03:21 User DN based on username ‘cn=Jane Doe,ou=users,ou=orgUnit,ou=corporate,dc=somedomain,dc=com’ not found.

2008.03.18 16:03:21 Exception thrown when searching for userDN based on username ‘cn=Jane Doe,ou=users,ou=orgUnit,ou=corporate,dc=somedomain,dc=com’

org.jivesoftware.openfire.user.UserNotFoundException: Username cn=Jane Doe,ou=users,ou=orgUnit,ou=corporate,dc=somedomain,dc=com not found