powered by Jive Software

Ldap users and groups, filtering

I know this has been addressed in the past and answered by Speedy but I’m stuck. I’m trying to filter my AD to only allow users that are members of certain groups.

I copied and pasted Speedy’s suggestions for filtering below, with a few changes to reflect my environment. The filtering makes sense to me except that I get locked out at a certain point. Any advice?

Everything is under the default CN=Users in AD…

AD domain = touchstone.com

access group = IMAllowed

roster groups = Texas Site, Arkansas Site, *** Site
(*note - I’ll be using *Site as part of a wildcard search, so all my groups end with Site for that reason)

First create your security groups:

Created regular security groups, Texas Site, Arkansas Site, Illinois Site, etc.

Make Texas Site, Arkansas Site, and all other “Site” groups members of the IMAllowed group.

Added my users as members of each respective “Site” group.
(included my openfire admin account (imadmin) in both Texas and the IMAllowed groups.)

Next, set your system properties in openfire:

ldap.baseDN
DC=touchstone,DC=com

ldap.groupSearchFilter
(objectClass=group)(cn=*Site)

Now if I stop at this point and restart Openfire… ALL of my domain users/computer accounts, etc are listed under users (as expected) and only the appropriate “Site” groups show up under Groups with their individual members nested inside.

Problem comes in at this point when it’s time to only filter the appropriate users. I set the searchfilter like speedy suggests:

ldap.searchfilter
(&(objectclass=organizationalPerson)(|(memberOf:1.2.840.113556.1.4.1941:=CN=IMAl lowed,CN=Users,DC=touchstone,DC=com)))

Save and restart Openfire. At the login prompt, I cannot login with imadmin or any other account I set as admin. At this point I have to set the Setup variable to false and try again.

Any ideas?

Thanks in advance,

Buster

Have you tried running your search filter from the command line with something like ldapsearch or another simple tool?

I did a search on our AD environment using basically the same thing (different DN for group, obviously) and it worked fine for me. The OR search in your filter seems unnecessary, although it doesn’t seem to change the results of my testing - Maybe it was left over.

For what it is worth, I always include a couple of service accounts in my filter in case I break the group part:

(&(objectCategory=user)(|(|(memberOf=CN=Instant Messaging Users,OU=Global SECURITY Groups,DC=domain,DC=local)(sAMAccountName=imldap))(sAMAccountName=esunixldap)))

Still can have a bad filter, but I usually run it through ldapsearch first to make sure it’s not garbage.

David,

Thanks for the reply. I did try a search on my AD environment using:

ldifde -f users.txt -d “DC=touchstone,DC=com” -r “(&(objectClass=organizationalPerson)(memberOf:1.2.840.113556.1.4.1941:=CN=IMAl lowed,CN=Users,DC=touchstone,DC=com))”

and it returned a text file with the appropriate users. I could connect with an IM client prior to applying the searchFilter but cannot connect afterwards. Nor can my admin account login to the management interface. I don’t get it.

I tried using domain local groups and global groups. It seems to me that the problem must be at the interface between the ldap query and Openfire parsing the users that are returned.

Thanks for the suggestion of adding the service account in the filter…definitely makes troubleshooting much easier.

Any other ideas?

Enable debug logging and ldap debug logging. See what the debug logs shows when you login to admin console with AD credentials.

What JRE are you using?

This is the error before logging in upon starting the server:

2013.03.19 10:53:46 org.jivesoftware.openfire.ldap.LdapVCardProvider - Error loading vcard mapping: Error on line 1 of document : The element type “br” must be terminated by the matching end-tag “”. Nested exception: The element type “br” must be terminated by the matching end-tag “”.

2013.03.19 10:53:46 org.jivesoftware.openfire.vcard.VCardManager - Error loading vcard provider: org.jivesoftware.openfire.ldap.LdapVCardProvider

java.lang.NullPointerException

at org.jivesoftware.openfire.ldap.LdapVCardProvider.initTemplate(LdapVCardProvider .java:163)

at org.jivesoftware.openfire.ldap.LdapVCardProvider.(LdapVCardProvider.java: 136)

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)

at java.lang.reflect.Constructor.newInstance(Unknown Source)

at java.lang.Class.newInstance0(Unknown Source)

at java.lang.Class.newInstance(Unknown Source)

at org.jivesoftware.openfire.vcard.VCardManager.initialize(VCardManager.java:259)

at org.jivesoftware.openfire.XMPPServer.initModules(XMPPServer.java:596)

at org.jivesoftware.openfire.XMPPServer.start(XMPPServer.java:485)

at org.jivesoftware.openfire.XMPPServer.(XMPPServer.java:212)

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)

at java.lang.reflect.Constructor.newInstance(Unknown Source)

at java.lang.Class.newInstance0(Unknown Source)

at java.lang.Class.newInstance(Unknown Source)

at org.jivesoftware.openfire.starter.ServerStarter.start(ServerStarter.java:113)

at org.jivesoftware.openfire.starter.ServerStarter.main(ServerStarter.java:58)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

at java.lang.reflect.Method.invoke(Unknown Source)

at com.exe4j.runtime.LauncherEngine.launch(Unknown Source)

at com.exe4j.runtime.WinLauncher.main(Unknown Source)

I do not see a log file for ldap debugging anywhere?

I have tried the default jre that comes with 3.8.1 and also jre7.

You need to set ldap.debugEnabled to true and cycle Openfire. it will then log to debug log.

Hey David,

I have that set to true in server properties. debug.log stays at 0kb after cycling Openfire and after attempted logins to the admin console as well as an IM client. My solution, albeit a pain in the butt, was to create a group and add all 500 of my employees as individual members. Using memberOf:1.2.840.113556.1.4.1941 just doesn’t work for me with Openfire even though it works when I run queries against ldap with it.