With OpenLDAP dynamic groups, I cannot manage to get groups to populate correctly in Openfire. The groups have been working fine for quite a while for other things, but with Openfire, it actually pulls the dummy entry for member. Member is a required attribute, so there has to be something there, but in most situations, that is never seen as OpenLDAP replaces it with the results of the search in labeledURI field.
When I watch the logs on one of the LDAP servers while checking a small group I see this go by:
conn=87 op=1 SRCH base=“dc=xxxx,dc=com” scope=2 deref=3 filter="(&(cn=*)(ou:dn:=group))"
conn=87 op=1 SRCH attr=cn description member
slap_global_control: unrecognized control: 1.2.840.113556.1.4.473
conn=87 op=1 SEARCH RESULT tag=101 err=0 nentries=6 text=
It appears that the ldap server did indeed send 6 results, but they never show up in Openfire’s group list. I’m not sure if this is because Java is trying to use a control that OpenLDAP doesn’t support or not.
This is the entry:
dn: cn=l3,ou=Group,dc=xxxx,dc=com
objectClass: groupOfNames
objectClass: labeledURIObject
objectClass: top
cn: l3
labeledURI: ldap:///ou=People,dc=xxxx,dc=com??one?(&(objectclass=posixAccount)(ou=l3))
member: cn=fake,ou=Security,dc=xxxx,dc=com
Has anyone else gotten this to work, or is this a bug of some kind?
So nobody uses dynamic groups with openfire?
deksai wrote:
dn: cn=l3,ou=Group,dc=xxxx,dc=com
labeledURI: ldap:///ou=People,dc=xxxx,dc=com??one?(&(objectclass=posixAccount)(ou=l3))
Has anyone else gotten this to work, or is this a bug of some kind?
It seems to me that your baseDN does not include Group OU?
Heh, that’s why it isn’t good to post after being tired. I posted the wrong part of the log. Thanks for catching that.
Anyway, here is the correct part of log during an attempt to look at groups, but it still doesn’t work.
conn=2 op=1 SRCH base=“dc=xxxx,dc=com” scope=2 deref=3 filter="(&(cn=*)(ou:dn:=group))"
conn=2 op=1 SRCH attr=cn description member
slap_global_control: unrecognized control: 1.2.840.113556.1.4.473
conn=2 op=1 SEARCH RESULT tag=101 err=0 nentries=10 text=
conn=2 op=2 UNBIND
conn=2 fd=16 closed
There has to be one real “member” in a groupOfNames object, so I have a fake entry there (cn=fake,ou=Security,dc=xxxx,dc=com). When openfire runs the query, it only takes the fake entry. If I bind as the openfire user and run the query using ldapsearch, I get the correct results (every dynamic member and also the fake entry).
Although, I’ve found that jxplorer will not see the dynamic group members either, so there has to be some difference in the queries that these two programs are issuing.
There is a ‘drop-down’ that switch between OpenLDAP and M$ AD in OF configuration. Did you choose OpenLDAP? As far as I know group membership is held in a different places in OpenLDAP and MS AD. What query did You run manually?