LDAP filters with 3.6.0a?

In all of the documentation I can find on doing LDAP properly with OpenFire, it references use of the /opt/openfire/conf/openfire.xml in setting query strings. Is this even valid now that 3.6 throws everything in the database? I assume these documents for filtering LDAP queries are invalid.



I have no issue doing OpenLDAP but find implementing LDAP on OpenFire to be extremely difficult. There is no proper documentation on the subject as far as I am concerned and I’d like to see who can help in detailing where and how to handle filters on the new version. My questions are as follows:

Step 2 of 3: User Mapping

The Advanced “search” and “user” filters still seem a bit vague in determining how to filter just users from a specified based DN OU.

Now that vCard information appears to be in the DB, how to do add the vCard mappings?

Step 3 of 3: Group Mapping

Why are there not any more examples on setting proper:

Group Field:

Member Field:

Group Filter

I’ve tried setting a search filter such as the following and just get errors galore:

“(objectCategory=person)(objectClass=user)(memberOf=cn=Users,ou=company r,dc=domain,dc=local)(!(userAccountControl:1.2.840.113556.1.4.803:=2))”

Again, I’m just frustrated because I have some OpenLDAP experience and yet find myself scrating my head over something that shouldn’t be this difficult. Raw LDAP output looks nothing like some of these settings

All the settings can be edited directly through the openfire admin site. Go to the system properties find the appropriate property you wish to edit and make the changes you wish.

As for filters generally the default settings for openfire will be sufficient to get you going. the filters will then limit the results. you can not set a user filter based on OU that would be a baseDN. you can base a user filter based on group membership. You can filter groups shown using a group filter.

With Active Directory Services, I found that I had to set the following options:

ldap.nameField displayName
ldap.groupSearchFilter "(objectClass=group)"
ldap.searchFields "Username/sAMAccountName,Name/cname"
ldap.searchFilter “(objectClass=organizationalPerson)”

After setting these options, my “groups” showed up appropriately, but I’m still showing all OU objects in the User Summary Screen (machine$ and user.name). This leads me to believe that the ldap.usernameField = sAMAccountName is still to vague to parse just user accounts as it is also pulling machine sAMAccountName fields. I can live with it, but it’s not ideal and is none the less my issue here.

Although this is now resolved, I’d like to say that the documentation needs to be grouped better on this site. All these LDAP docs and the LDAP-Guide were helpful in their own way, but were overlooked several times due to being so scattered about. Thank you for your help Todd.


Time to clean up the documentation and centralize it better guys. A lot of this was helpful, but would have otherwise not been found if it hadn’t been for the forum guru’s coming to the rescue.

you could try this user filter: (&(objectCategory=person)(objectClass=user))

This should remove computers.

(&(objectCategory=person)(objectClass=user)) will not work as objectCategory will list the full CN and is not object identifier Windows Active Directory.

I’d like to use (&(objectClass=organizationalPerson)(!(objectClass=computer))) but am worried about using exclamations here. Can I use them or do I need to substitute with &#33?

The (&(objectClass=organizationalPerson)(!(objectClass=computer))) actually worked perfectly. I am actually reading here that objectCategory would work as well, but I got it working this way anyway. Whoo hoo! Time for the next project. Thanks for your help!

Last thing to note. I’d really like to see the “save changes” moved out until step 3 of 3 on the LDAP configuration. The reason is that I had gone through step 2 and walked away for a bit only to find my session was timed out. This in turn locked me out entirely and forced me to hand edit the Database from the MySQL Query Analyzer to get it back in working order. If it had been in the end of step 3 I could have had a chance to note that it wasn’t correct and reverse it.

While I like having a lot of the openfire.xml settings in the database, this is one example where it would have been better off back in a text file.

Please consider reversing it.