> Pierangelo,=20 > > Thanks for responding. Here are some hopefully helpful answers: > > We have an Openfire (Java-based XMPP server, supporting ldap user/group = > lookups) server that will, when deployed, have thousands of users. = > Openfire works quite well with openldap, however we wanted to avoid = > manually maintaining the group objects since (as I said) they would be = > highly populated. > > Openfire supports two types of groups (in their terms): posix and = > non-posix. Basically what this means is that when in posix mode, = > Openfire looks for groups (e.g: cn=3Dusers) that contain UID-like = > objects (single username strings). When in NON-POSIX mode, however, = > Openfire will look for groups that contain DN-based members. =20 > > The member Attribute names (e.g: memberUid, uniqueMember, etc) are fully = > configurable to openfire, but we had limited success when trying = > different permutations. Some attribute-mappings work, some do not. = > Eventually, we found that the following works for Openfire: > > overlay dynlist > dynlist-attrset groupOfURLs memberURL memberUid > > With this record being returned when queried: > > dn: cn=3Dusers,cn=3Dgroups,dc=3Dexample,dc=3Dcom > cn: users > memberURL: = > ldap:///cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom?uid?one?(objectClass=3D= > simpleSecurityObject) > objectClass: groupOfURLs > memberUid: > uid=3Dopenfire-admin,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom= > > memberUid: uid=3Duser1,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom > memberUid: uid=3Duser2,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom > memberUid: uid=3Duser3,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom > memberUid: uid=3Duser4,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom > memberUid: uid=3Duser5,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom > memberUid: uid=3Duser6,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom > memberUid: uid=3Duser7,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom > memberUid: uid=3Duser8,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom > memberUid: uid=3Duser9,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom > > I know this doesn't look right (obviously memberUid is not typically a = > DN-based value) BUT THIS WORKS FOR OPENFIRE (which in the end, will be = > the only client that makes use of this record). We'd prefer to use = > DN-based member groups (e.g: this would be "Non-Posix" groups to = > openfire) since this is the only method that works with Openfire. > > HOWEVER on the other side of the situation, we want to begin using = > Dynamic Posix Groups, like so: > > overlay dynlist > dynlist-attrset posixGroup memberURL memberUid:uid > > With this record being returned when queried: > > dn: cn=3Dadmins,cn=3Dposix,cn=3Dgroups,dc=3Dexample,dc=3Dcom > objectClass: posixGroup > objectClass: top > objectClass: extensibleObject > cn: systems > gidNumber: 9001 > memberURL: = > ldap:///cn=3Dplain,cn=3Dauth,dc=3Dexample,dc=3Dcom?uid?one?(objectClass=3D= > adminUser) > memberUid: admin1 > memberUid: admin2 > memberUid: admin3 > memberUid: admin4 > memberUid: admin5 > > .... Which works wonderfully! Using shell commands like 'id' , 'groups' = > will work quite nicely on the posix/shell level. > > But all goes to crap when combining the above dynlist-attrsets. As I = > said, only one seems to be evaluated.
I'm afraid I don't quite understand. 1) I manually ran test003 2) I configured slapd with overlay dynlist dynlist-attrset groupOfURLs memberURL memberUid dynlist-attrset posixGroup memberURL memberUid:uid 3) I loaded the LDIF dn: ou=dynlist,dc=example,dc=com objectClass: organizationalUnit dn: cn=dl1,ou=dynlist,dc=example,dc=com objectClass: groupOfURLs memberURL: ldap:///dc=example,dc=com?uid?sub?(objectClass=person) dn: cn=dl2,ou=dynlist,dc=example,dc=com objectClass: posixGroup objectClass: extensibleObject memberURL: ldap:///dc=example,dc=com?uid?sub?(objectClass=person) gidNumber: 0 4) when I execute $ ldapsearch -x -b ou=dynlist,dc=example,dc=com I get # extended LDIF # # LDAPv3 # base <ou=dynlist,dc=example,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # dynlist, example.com dn: ou=dynlist,dc=example,dc=com objectClass: organizationalUnit ou: dynlist # dl1, dynlist, example.com dn: cn=dl1,ou=dynlist,dc=example,dc=com objectClass: groupOfURLs memberURL: ldap:///dc=example,dc=com?uid?sub?(objectClass=person) cn: dl1 memberUid: cn=Barbara Jensen,ou=Information Technology Division,ou=People, dc=example,dc=com memberUid: cn=Bjorn Jensen,ou=Information Technology Division,ou=People,dc =example,dc=com memberUid: cn=Dorothy Stevens,ou=Alumni Association,ou=People,dc=example,d c=com memberUid: cn=James A Jones 1,ou=Alumni Association,ou=People,dc=example,d c=com memberUid: cn=James A Jones 2,ou=Information Technology Division,ou=People ,dc=example,dc=com memberUid: cn=Jane Doe,ou=Alumni Association,ou=People,dc=example,dc=com memberUid: cn=Jennifer Smith,ou=Alumni Association,ou=People,dc=example,dc =com memberUid: cn=John Doe,ou=Information Technology Division,ou=People,dc=exa mple,dc=com memberUid: cn=Manager,dc=example,dc=com memberUid: cn=Mark Elliot,ou=Alumni Association,ou=People,dc=example,dc=co m memberUid: cn=Ursula Hampster,ou=Alumni Association,ou=People,dc=example,d c=com # dl2, dynlist, example.com dn: cn=dl2,ou=dynlist,dc=example,dc=com objectClass: posixGroup objectClass: extensibleObject memberURL: ldap:///dc=example,dc=com?uid?sub?(objectClass=person) gidNumber: 0 cn: dl2 memberUid: bjensen memberUid: bjorn memberUid: dots memberUid: jaj memberUid: jjones memberUid: jdoe memberUid: jen memberUid: johnd memberUid: melliot memberUid: uham # search result search: 2 result: 0 Success # numResponses: 4 # numEntries: 3 Isn't this what you expect? > I have tried incorporating the = > optional URI parameter into the dynlist-attrsets, but this totally broke = > the groups altogether (didn't expand at all). > > I guess I don't understand what role the first ObjectClass listed in the = > dynlist-attrset parameter plays - i assumed it would act appropriately = > for objects that are using the same OC that is listed in the rule. It represents the objectClass that, when present in an entry that is being returned by a search, triggers the dynlist expansion. p.
