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