Problem with LDAP, shared rosters and nested groups

Openfire Openfire Support
1

Hello :slight_smile:

We’re using Openfire 4.2.3 (hosted on CentOS 7) with ldap integration (hosted on Windows Server 2012 R2).
For tests we build the same AD infrastructure as shown by @speedy on this thread: How to Setup Authentication Groups with LDAP/AD

Basically that setup nearly does the job - but our active directory has a lot of nested user groups and these can’t be read/listed by openfire.

Test scenario:

AD groups and users:

Openfire Access Group (domain local sec group)
- 	Testgroup1 (global sec group)
	- test001 (name of user1 etc.)
	- test002
	- test003
	- Anothergroup1 (global sec group)
		- test007
		- test008
		- test009
- 	Testgroup2 (global sec group)
	- test004
	- test005
	- test006

ldap.searchfilter = (&(objectclass=organizationalPerson)(|(memberOf:1.2.840.113556.1.4.1941:=CN=Openfire Access Group,CN=Users,DC=mydomain,DC=local))(!(userAccountControl:1.2.840.113556.1.4.803:=2)))

(without spaces from the board)

ldap.groupSearchFilter = (&(objectClass=group)(cn=Testgroup*))

Shared rosters are activated for Testgroup1 and Testgroup2 (shown group only).
Now I expected, that all users of Testgroup1 AND Anothergroup1, as nested group of Testgroup1, see each other in the shared roster. The user test001 only saw the other two users test002 and test003, but not the users of the Anothergroup1 (test007-009).
(tested with local installed pidgin and bosh webchat)

When viewing the group in the Openfire adminpage, the problem still exists: at the end of the group page only the users test001-003 are listed, and the diginuished name of the nested group instead of their members:

  • cn=anothergroup1,cn=users,dc=mydomain,dc=local@mydomain.local *
  • test001
  • test002
  • test003

The first row seems to show, that openfire is thinking that anothergroup1 is a user object, instead of listening the nested users in that group.

Does anybody have a fix or suggestions for this problem with nested ad groups?

Thanks a lot.

Grelli

2

This might be caused by your group filter.
Since you are filtering groups by Testgroup*, than openfire may not be seeing “anothergroup1”

you can test this by changing the group name, or update the ldap.groupsearchfilter

3

Hi @speedy

Thx for your reply. :slight_smile:
I’m sorry I didn’t mention that I already tested other ldap filters. Actually I’m testing with the quite general group filter “(objectClass=group)” and this does not help - nested group users are still not shown. :frowning:

Any further ideas?

Thx a lot.

Grelli

4

This is a long shot, but what is the value of ldap.subTreeSearch ? A quick check of the code suggests that if it was set to false (default if not present is true) searches are limited to the top level.

Greg

5

Hello @gdt
nice idea, but in our setup the option was not set explicitly, so the default (true) settings were active. In a further test we do activate the settings in der config with no better result :frowning:

I’ve saw an interesting post from @Linus1: Extend LdapGroupProvider to support nested group in LDAP
so i’m not alone with that kind of ldap problem. He wrote he fixed this with a patch, but i can’t see the attachment he mentioned. Does anybody know if this problem was solved in the Openfire source code in the last 4 years?

Best regards
Grelli