[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement



> 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.