We've had problems with SSSD being slow sometimes, but not others, and there never seemed to be any obvious cause why, but I think I've tracked it down to problems with dereferencing. We do see errors about dereferencing in the log, but I didn't realize until now what it was referring to.
In theory, a search like this should give us the cn and objectclass of all members of the group, but I get only the attributes of the group itself. Whether I give the "-E 'deref=...'" or not I get the same output. Redacted output below:
ldapsearch [bind username and password stuff, etc] -E 'deref=uniqueMember:cn,objectclass' 'cn=Global System Administrators' # extended LDIF # # LDAPv3 # base <[our base DN]> (default) with scope subtree # filter: cn=Global System Administrators # requesting: ALL # with dereference control #
# Global System Administrators, Groups, [our base DN] dn: cn=Global System Administrators,ou=Groups,[our base DN] control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAAAA uniqueMember: uid=user1,ou=Users,ou=[Office1],[our base DN] uniqueMember: uid=user2,ou=Users,ou=[Office2],[our base DN] uniqueMember: uid=user3,ou=Users,ou=[Office2],[our base DN] uniqueMember: uid=user4,ou=Users,ou=[Office1],[our base DN] objectClass: top objectClass: groupofuniquenames objectClass: posixgroup cn: Global System Administrators gidNumber: 1001002 description: Global System Administrators
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
Hi,
if you would specify the control as critical -E '!deref=....' you would get an error the the deref attr needs to be of dn syntax. In 389 ds uniquemember is specified as "Name and Optional UID" syntax, which is dn [#UID], but the deref plugin just checks for dn syntax.
Feel free to open a ticket to get this fixed.
Ludwig
On 03/19/2014 09:10 PM, Jonathan Vaughn wrote:
We've had problems with SSSD being slow sometimes, but not others, and there never seemed to be any obvious cause why, but I think I've tracked it down to problems with dereferencing. We do see errors about dereferencing in the log, but I didn't realize until now what it was referring to.
In theory, a search like this should give us the cn and objectclass of all members of the group, but I get only the attributes of the group itself. Whether I give the "-E 'deref=...'" or not I get the same output. Redacted output below:
ldapsearch [bind username and password stuff, etc] -E 'deref=uniqueMember:cn,objectclass' 'cn=Global System Administrators' # extended LDIF # # LDAPv3 # base <[our base DN]> (default) with scope subtree # filter: cn=Global System Administrators # requesting: ALL # with dereference control #
# Global System Administrators, Groups, [our base DN] dn: cn=Global System Administrators,ou=Groups,[our base DN] control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAAAA uniqueMember: uid=user1,ou=Users,ou=[Office1],[our base DN] uniqueMember: uid=user2,ou=Users,ou=[Office2],[our base DN] uniqueMember: uid=user3,ou=Users,ou=[Office2],[our base DN] uniqueMember: uid=user4,ou=Users,ou=[Office1],[our base DN] objectClass: top objectClass: groupofuniquenames objectClass: posixgroup cn: Global System Administrators gidNumber: 1001002 description: Global System Administrators
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
389-users@lists.fedoraproject.org