Re: back-mdb and alias dereferencing
On Tue, May 29, 2018 at 02:55:30PM +0100, Howard Chu wrote: > Henrik Bohnenkamp wrote: > > > I'm willing to try out any patch thrown my way. Somewhere is written > > that mdb will replace hdb/bdb eventually ... I believe this problem > > needs a fix before that can happen. > > You're welcome to submit your own patch for review. Well... here we go then: ITS#8875 -- Henrik Bohnenkamp Senior Sysadmin Linux & Applications Operation United Internet Corporate Services GmbH Brauerstraße 50 | 76135 Karlsruhe | Germany Phone: +49 721 91374 - 4159 E-mail: hbohnenk...@united-internet.de | Web: www.united-internet.de Amtsgericht Montabaur / HRB 23031 Geschäftsführer: Verena Amann, Markus Kadelke, Frank Krause, Guido Mannshausen Member of United Internet This e-mail may contain confidential and/or privileged information. If you are not the intended recipient of this e-mail, you are hereby notified that saving, distribution or use of the content of this e-mail in any way is prohibited. If you have received this e-mail in error, please notify the sender and delete the e-mail.
Re: back-mdb and alias dereferencing
Henrik Bohnenkamp wrote:
Hi,
I would like to bring up the problem with back-mdb and
alias-dereferening again. There is Bug ITS#7657 for this already, and
in
http://www.openldap.org/lists/openldap-technical/201504/msg8.html
the problem was also addressed. Probably in other places as well, but
I did not find anything else in the archives.
I would like to reconfigure all my LDAP clusters to use back-mdb,
however, I can't: my LDAP tree has about 2 Mio entries, 60 of
which are alias entries.
I observe that when using back-mdb and making search request with
search scope "sub" and deref=always, than this search request will
take seconds before a response... in contrast, with deref=never, the
same search request takes only millisecs. It does not matter whether
there are aliases in the search scope or not... with deref=always it
always takes seconds, each request keeping one CPU thread very busy.
So if many requests come in with sub/always (which unfortunately
happens a lot because many LDAP clients just set deref=always as a
default) it is a sure way to bring down an LDAP cluster configured with
back-mdb.
The problem has haunted me for a while (incidents, incidents :-), and
I have tried to find out where it comes from. I would like to share my
conjectures here.
A search request with sub/always eventually ends up in the function
search_aliases(..), located in back-mdb/search.c (code/linenumbers is
from v2.4.46 ):
157 /* Find all aliases in database */
158 MDB_IDL_ZERO( aliases );
159 rs->sr_err = mdb_filter_candidates( op, isc->mt, , aliases,
160 curscop, visited );
161 if (rs->sr_err != LDAP_SUCCESS || MDB_IDL_IS_ZERO( aliases )) {
162 return rs->sr_err;
163 }
164 oldsubs[0] = 1;
165 oldsubs[1] = e_id;
166
167 MDB_IDL_ZERO( visited );
168 MDB_IDL_ZERO( newsubs );
169
170 cursoro = 0;
171 ido = mdb_idl_first( oldsubs, );
172
173 for (;;) {
174 /* Set curscop to only the aliases in the current
scope. Start with
175 * all the aliases, then get the intersection with the
scope.
176 */
177 rs->sr_err = mdb_idscope( op, isc->mt, e_id, aliases,
curscop );
After adding a bit of extra debug code, I could see in the logs that
the time is actually spent in line 177, i.e. the mdb_idscope function.
What I believe is happening is the following: in line 159 the index
list of all aliases in the DB is constructed and put into the
"aliases" list. The list comes from the objectClass index, but since
there are so many alias entries, the index contains not an explicit
list, but a range... a range that covers basically *all* 2 Mio entries
in the DB. (this happens also with the hdb backend, so the fact that
"aliases" is a range is perhaps part, but not cause of the problem).
Then the for loop is entered in 173, and mdb_idscope in 177 is
called. The idea there is to compute the intersection of alias list
"aliases" and search scope, i.e. get all aliases that are in the
actual search scope.
This is done by walking through the 2 millions indexes represented by
the range in "aliases", and deciding whether the id is in the scope or
not. This, if I understand correctly, by walking up the LDAP tree from
leaf towards root (actually walking up the structure of the dn2id DB)
... if we encounter the search base on the way, the alias is part of
the search scope, if we reach the root, then not.
Computing this intersection is what costs time, and it does not
depend on whether the intersection is empty or not.
Apparently it is done differently in back_hdb and by extension,
back_bdb. I have not analysed that code there in detail but I believe
the intersection is computed by actually looking at 2 different ID
lists, one containing the aliases (range) again, the other one the
actual IDs of the search scope. Which, it appears, is more efficient.
So the problem seems to be to compute the relevant aliases to start
expanding from. The way it is done now the complexity seems to be
linear in the number of aliases, if not number of entries on the LDAP
tree.
For my own use cases at least it would be much more efficient to just
do a tree traversal of the search scope, pick up the relevant aliases
and put them in the list. I believe even for large trees this would
work quite well... if I search my whole tree for entries with
objectClass=alias (deref=never, of course), this is amazingly fast. I
am currently looking into how something like that could be
implemented, but I need to dive much deeper in the code before I could
come up with something worth considering. >
What are the views of the developers on this? Does the analysis sound
plausible? Could a fix be easily obtained?
Taking this approach is tricky. If you merely traverse the search
back-mdb and alias dereferencing
Hi,
I would like to bring up the problem with back-mdb and
alias-dereferening again. There is Bug ITS#7657 for this already, and
in
http://www.openldap.org/lists/openldap-technical/201504/msg8.html
the problem was also addressed. Probably in other places as well, but
I did not find anything else in the archives.
I would like to reconfigure all my LDAP clusters to use back-mdb,
however, I can't: my LDAP tree has about 2 Mio entries, 60 of
which are alias entries.
I observe that when using back-mdb and making search request with
search scope "sub" and deref=always, than this search request will
take seconds before a response... in contrast, with deref=never, the
same search request takes only millisecs. It does not matter whether
there are aliases in the search scope or not... with deref=always it
always takes seconds, each request keeping one CPU thread very busy.
So if many requests come in with sub/always (which unfortunately
happens a lot because many LDAP clients just set deref=always as a
default) it is a sure way to bring down an LDAP cluster configured with
back-mdb.
The problem has haunted me for a while (incidents, incidents :-), and
I have tried to find out where it comes from. I would like to share my
conjectures here.
A search request with sub/always eventually ends up in the function
search_aliases(..), located in back-mdb/search.c (code/linenumbers is
from v2.4.46 ):
157 /* Find all aliases in database */
158 MDB_IDL_ZERO( aliases );
159 rs->sr_err = mdb_filter_candidates( op, isc->mt, , aliases,
160 curscop, visited );
161 if (rs->sr_err != LDAP_SUCCESS || MDB_IDL_IS_ZERO( aliases )) {
162 return rs->sr_err;
163 }
164 oldsubs[0] = 1;
165 oldsubs[1] = e_id;
166
167 MDB_IDL_ZERO( visited );
168 MDB_IDL_ZERO( newsubs );
169
170 cursoro = 0;
171 ido = mdb_idl_first( oldsubs, );
172
173 for (;;) {
174 /* Set curscop to only the aliases in the current
scope. Start with
175 * all the aliases, then get the intersection with the
scope.
176 */
177 rs->sr_err = mdb_idscope( op, isc->mt, e_id, aliases,
curscop );
After adding a bit of extra debug code, I could see in the logs that
the time is actually spent in line 177, i.e. the mdb_idscope function.
What I believe is happening is the following: in line 159 the index
list of all aliases in the DB is constructed and put into the
"aliases" list. The list comes from the objectClass index, but since
there are so many alias entries, the index contains not an explicit
list, but a range... a range that covers basically *all* 2 Mio entries
in the DB. (this happens also with the hdb backend, so the fact that
"aliases" is a range is perhaps part, but not cause of the problem).
Then the for loop is entered in 173, and mdb_idscope in 177 is
called. The idea there is to compute the intersection of alias list
"aliases" and search scope, i.e. get all aliases that are in the
actual search scope.
This is done by walking through the 2 millions indexes represented by
the range in "aliases", and deciding whether the id is in the scope or
not. This, if I understand correctly, by walking up the LDAP tree from
leaf towards root (actually walking up the structure of the dn2id DB)
... if we encounter the search base on the way, the alias is part of
the search scope, if we reach the root, then not.
Computing this intersection is what costs time, and it does not
depend on whether the intersection is empty or not.
Apparently it is done differently in back_hdb and by extension,
back_bdb. I have not analysed that code there in detail but I believe
the intersection is computed by actually looking at 2 different ID
lists, one containing the aliases (range) again, the other one the
actual IDs of the search scope. Which, it appears, is more efficient.
So the problem seems to be to compute the relevant aliases to start
expanding from. The way it is done now the complexity seems to be
linear in the number of aliases, if not number of entries on the LDAP
tree.
For my own use cases at least it would be much more efficient to just
do a tree traversal of the search scope, pick up the relevant aliases
and put them in the list. I believe even for large trees this would
work quite well... if I search my whole tree for entries with
objectClass=alias (deref=never, of course), this is amazingly fast. I
am currently looking into how something like that could be
implemented, but I need to dive much deeper in the code before I could
come up with something worth considering.
What are the views of the developers on this? Does the analysis sound
plausible? Could a fix be easily obtained?
I'm willing to try out any patch thrown my way. Somewhere is written
that mdb will replace hdb/bdb eventually
Re: Alias dereferencing and performance
Could you get me a little more info about dereferencing set? *Karol Chrapek* | Infrastructure Architect Infrastructure Division mobile: +48 660 623 422 2015-09-03 9:04 GMT+02:00 Saša-Stjepan Bakša <ssba...@gmail.com>: > Hi Karol, > > Same problem here. Quanah suggested that we have to use dereferncing set > to when finding but with that option we have problem that some data is > missing from answer although speed is as with HDB. > > My database is in range from 1 Milion to 50 Milion objects. > > Br > > Sasa > > On 2 September 2015 at 07:42, Karol Chrapek <kchra...@fgtsa.com> wrote: > >> Hi, >> I have a question about the alias dereferencing and mdb performance. >> I installed from source ldap 2.4.42 with mdb support. >> In our current directory we have 367 007 objects and 42262 aliases. >> During the test I observed that the MDB is slower than the HDB during >> search with aliases dereferencing. >> I performed test search in small scope (5 objects where 6991 is >> aliases to other part of structure) with filter objectClass=User and >> dereferencing aliases set to always. >> I see that query to HDB take about 20s and query to MDB about 29s. On >> both server the load are low. Are in ldap configuration any option than can >> tune the alias dereferencing or we should redesign the structure to reduce >> number of aliases? >> >> >> >> *Karol* >> > >
Re: Alias dereferencing and performance
Hi Karol, Same problem here. Quanah suggested that we have to use dereferncing set to when finding but with that option we have problem that some data is missing from answer although speed is as with HDB. My database is in range from 1 Milion to 50 Milion objects. Br Sasa On 2 September 2015 at 07:42, Karol Chrapek <kchra...@fgtsa.com> wrote: > Hi, > I have a question about the alias dereferencing and mdb performance. > I installed from source ldap 2.4.42 with mdb support. > In our current directory we have 367 007 objects and 42262 aliases. During > the test I observed that the MDB is slower than the HDB during search with > aliases dereferencing. > I performed test search in small scope (5 objects where 6991 is > aliases to other part of structure) with filter objectClass=User and > dereferencing aliases set to always. > I see that query to HDB take about 20s and query to MDB about 29s. On both > server the load are low. Are in ldap configuration any option than can tune > the alias dereferencing or we should redesign the structure to reduce > number of aliases? > > > > *Karol* >
Alias dereferencing and performance
Hi, I have a question about the alias dereferencing and mdb performance. I installed from source ldap 2.4.42 with mdb support. In our current directory we have 367 007 objects and 42262 aliases. During the test I observed that the MDB is slower than the HDB during search with aliases dereferencing. I performed test search in small scope (5 objects where 6991 is aliases to other part of structure) with filter objectClass=User and dereferencing aliases set to always. I see that query to HDB take about 20s and query to MDB about 29s. On both server the load are low. Are in ldap configuration any option than can tune the alias dereferencing or we should redesign the structure to reduce number of aliases? *Karol*
Re: Alias dereferencing
=refreshOnly
int
erval=00:00:00:10 retry=5 5 300 5 timeout=1
olcSyncrepl: {1}rid=004 provider=ldap://spr2.lab.os
binddn=cn=admin,dc=spr b
indmethod=simple credentials=siemens searchbase=dc=spr type=refreshOnly
int
erval=00:00:00:10 retry=5 5 300 5 timeout=1
entryCSN: 20130329141637.442296Z#00#002#00
modifiersName: cn=admin,cn=config
modifyTimestamp: 20130329141637Z
dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
structuralObjectClass: olcSyncProvConfig
creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
entryUUID: e2aa5b24-2cc6-1032-8bf5-1905ee7d8e9d
createTimestamp: 20130329141542Z
entryCSN: 20130329141542.849443Z#00#002#00
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20130329141542Z
Output from ldapsearch done on server with mdb:
root@test7kde:~# ldapsearch -x -h 172.17.103.200 -D cn=admin,dc=spr -s sub
-a always -W -b pfUsername=user1,dc=USERNAME,dc=spr
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base pfUsername=user1,dc=USERNAME,dc=spr with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# search result
search: 2
result: 0 Success
# numResponses: 1
Output from ldapsearch done on server with hdb:
root@test7kde:~# ldapsearch -x -h 172.17.103.215 -D cn=admin,dc=spr -s sub
-a always -W -b pfUsername=user1,dc=USERNAME,dc=spr
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base pfUsername=user1,dc=USERNAME,dc=spr with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# 1, USERS, STANDARD, SPR
dn: uid=1,ds=USERS,o=STANDARD,dc=SPR
objectClass: sprUser
uid: 1
# userData, 1, USERS, STANDARD, SPR
dn: subdata=userData,uid=1,ds=USERS,o=STANDARD,dc=SPR
roamingAllowed: TRUE
objectClass: sprUserData
subdata: userData
prepaidFlag: TRUE
sn: TestProv
pfUsername: user1
givenName: pcrfUser
loginPassword: 123
pfPassword: 123
# applicationData, 1, USERS, STANDARD, SPR
dn: subdata=applicationData,uid=1,ds=USERS,o=STANDARD,dc=SPR
objectClass: sprUserData
subdata: applicationData
# aaa, applicationData, 1, USERS, STANDARD, SPR
dn: ds=aaa,subdata=applicationData,uid=1,ds=USERS,o=STANDARD,dc=SPR
objectClass: sprDs
ds: aaa
# 2g3g, aaa, applicationData, 1, USERS, STANDARD, SPR
dn: ds=2g3g,ds=aaa,subdata=applicationData,uid=1,ds=USERS,o=STANDARD,dc=SPR
objectClass: sprDs
ds: 2g3g
# pcrf, aaa, applicationData, 1, USERS, STANDARD, SPR
dn: ds=pcrf,ds=aaa,subdata=applicationData,uid=1,ds=USERS,o=STANDARD,dc=SPR
objectClass: sprDs
ds: pcrf
# 2g3gProf, 2g3g, aaa, applicationData, 1, USERS, STANDARD, SPR
dn:
subdata=2g3gProf,ds=2g3g,ds=aaa,subdata=applicationData,uid=1,ds=USERS,o=S
TANDARD,dc=SPR
service2g3g: defaultService
profile2g3g: profile1
productCode2g3g: prodCode
barringStatus2g3g: barringStatus
objectClass: spr2g3gUser
uniqueId2g3g: user1
apnGroup2g3g: apnGG
provider2g3g: me-myself-and-i
framedIPAddress2g3g: 1.1.1.1
accountGroup2g3g: acctGroup
subdata: 2g3gProf
msisdn: 1234560001
flagStatus2g3g: flagStatus
class2g3g: classs
type2g3g: type
creationDate2g3g: 01.10.2010.
classification2g3g: 111
poolGroup2g3g: poolGroup
status2g3g: ACTIVE
# pcrfProf, pcrf, aaa, applicationData, 1, USERS, STANDARD, SPR
dn:
subdata=pcrfProf,ds=pcrf,ds=aaa,subdata=applicationData,uid=1,ds=USERS,o=S
TANDARD,dc=SPR
profile: 3100
totalUsedVolume: 3
msisdn: 1234560001
objectClass: sprPcrfProf
totalMaximumVolume: 5
imsi: 1991234560001
subdata: pcrfProf
subscriberServiceProfile: TM3100
featureList: Faeture1
paymentTypexy: NeverPaid
pfUsername: user1
tariffId: 1
pcrfServiceId: 3100
# search result
search: 2
result: 0 Success
# numResponses: 9
# numEntries: 8
On Thu, Apr 18, 2013 at 4:11 PM, Quanah Gibson-Mount qua...@zimbra.comwrote:
--On Thursday, April 18, 2013 1:55 PM +0200 Saša-Stjepan Bakša
ssba...@gmail.com wrote:
I am using alias dereferencing with hdb backed because that was
application requirement. Now I am switching to mdb but I can't get the
same answer with ldapsearch.
Does dereferencing work for mdb?
OpenLDAP version? Example configuration?
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
Zimbra :: the leader in open source messaging and collaboration
Alias dereferencing
I am using alias dereferencing with hdb backed because that was application requirement. Now I am switching to mdb but I can't get the same answer with ldapsearch. Does dereferencing work for mdb? Lp Sasa
Re: Alias dereferencing
--On Thursday, April 18, 2013 1:55 PM +0200 Saša-Stjepan Bakša ssba...@gmail.com wrote: I am using alias dereferencing with hdb backed because that was application requirement. Now I am switching to mdb but I can't get the same answer with ldapsearch. Does dereferencing work for mdb? OpenLDAP version? Example configuration? --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration
Alias dereferencing
I'm trying to implement some aliases for several groups in my directory to provide a bit of aesthetics for a few applications that leverage the OpenLDAP users and groups. However, I seem to be running in to a little trouble, perhaps because I'm expecting alias dereferencing to do something it wasn't really designed to do. For reference, this is 2.4.21, but I was able to test on a 2.4.23 database with the same results. I'm using the autogroup module as well for some pseudo-static dynamic groups. Consider the following basic DIT and abbreviated set of entries (abbreviated entries denoted by '...'): dn: dc=example,dc=com dn: ou=Users,dc=example,dc=com dn: ou=Groups,dc=example,dc=com dn: uid=john,ou=Users,dc=example,dc=com objectClass: examplecomEmployee departmentName: sysadmins ... dn: uid=jane,ou=Users,dc=example,dc=com objectClass: examplecomEmployee departmentName: sysadmins ... dn: uid=joe,ou=Users,dc=example,dc=com objectClass: examplecomEmployee departmentName: sysadmins ... dn: cn=sysadmins,ou=Groups,dc=example,dc=com objectClass: top objectClass: groupOfURLs objectClass: posixGroup memberURL: ldap:///ou=Users,dc=example,dc=com?dn?sub?((objectClass=examplecomEmployee)(departmentName=sysadmins)) member: uid=john,ou=Users,dc=example,dc=com member: uid=jane,ou=Users,dc=example,dc=com member: uid=joe,ou=Users,dc=example,dc=com ... dn: cn=Systems Administrators,ou=Groups,dc=example,dc=com ou: Groups cn: Systems Admins objectClass: alias objectClass: extensibleObject aliasedObjectName: cn=sysadmins,ou=Groups,dc=example,dc=com When I initiate an ldapsearch and choose not to dereference, I see what I expect: j...@ldap1:~# ldapsearch -x -ZZ -LLL -a never -b dc=example,dc=com cn=Systems\ Administrators dn: cn=Systems Administrators,ou=Groups,dc=example,dc=com ou: Groups objectClass: alias objectClass: extensibleObject aliasedObjectName: cn=sysadmins,ou=Groups,dc=example,dc=com cn: Systems Administrators However, when I do choose to dereference, nothing is returned: j...@ldap1:~# ldapsearch -x -ZZ -LLL -a find -b dc=example,dc=com cn=Systems\ Administrators j...@ldap1:~# j...@ldap1:~# ldapsearch -x -ZZ -LLL -a always -b dc=example,dc=com cn=Systems\ Administrators j...@ldap1:~# I can only obtain the expected results if I set the search base to the *specific* entry I'm looking to dereference: j...@ldap1:~# ldapsearch -x -ZZ -LLL -a always -b cn=Systems\ Administrators,ou=Groups,dc=example,dc=com dn: cn=sysadmins,ou=Groups,dc=example,dc=com ou: Groups gidNumber: 4001 cn: sysadmins objectClass: groupOfURLs objectClass: top objectClass: posixGroup description: The sysadmin team members memberURL: ldap:///ou=Users,dc=example,dc=com?dn?sub?((objectClass=examplecomE mployee)(departmentName=sysadmins)) member: uid=john,ou=Users,dc=example,dc=com member: uid=jane,ou=Users,dc=example,dc=com member: uid=joe,ou=Users,dc=example,dc=com I find it hard to believe that setting the search base to the alias entry is the only way which one may reference the alias entry - I can't see many cases in which it would be useful to set the search base to something other than the highest part of the tree under which all the other entries you'd like to view are accessible. Essentially, I just want to be able to search for the more aesthetically named entry (cn=Systems Administrators) without having to explicitly set it as the search base, and have it return the entry specified by its aliasedObjectName. Is this possible, and if so, how? If not, what is the recommended approach to achieving this goal, other than perhaps setting an attribute from an AUXILIARY objectClass or similar? I don't really consider creating the entries with the more aesthetic names from the get-go as an option, because dealing with POSIX groups that have spaces in them is a pain, and not everything plays nice with such naming schemes. Thanks for any/all advice.
Re: Alias dereferencing
Ryan Steele wrote: I'm trying to implement some aliases for several groups in my directory to provide a bit of aesthetics for a few applications that leverage the OpenLDAP users and groups. However, I seem to be running in to a little trouble, perhaps because I'm expecting alias dereferencing to do something it wasn't really designed to do. For reference, this is 2.4.21, but I was able to test on a 2.4.23 database with the same results. I'm using the autogroup module as well for some pseudo-static dynamic groups. Consider the following basic DIT and abbreviated set of entries (abbreviated entries denoted by '...'): Your problem has nothing to do with alias dereferencing. dn: cn=sysadmins,ou=Groups,dc=example,dc=com objectClass: top objectClass: groupOfURLs objectClass: posixGroup memberURL: ldap:///ou=Users,dc=example,dc=com?dn?sub?((objectClass=examplecomEmployee)(departmentName=sysadmins)) member: uid=john,ou=Users,dc=example,dc=com member: uid=jane,ou=Users,dc=example,dc=com member: uid=joe,ou=Users,dc=example,dc=com ... dn: cn=Systems Administrators,ou=Groups,dc=example,dc=com ou: Groups cn: Systems Admins objectClass: alias objectClass: extensibleObject aliasedObjectName: cn=sysadmins,ou=Groups,dc=example,dc=com When I initiate an ldapsearch and choose not to dereference, I see what I expect: j...@ldap1:~# ldapsearch -x -ZZ -LLL -a never -b dc=example,dc=com cn=Systems\ Administrators dn: cn=Systems Administrators,ou=Groups,dc=example,dc=com ou: Groups objectClass: alias objectClass: extensibleObject aliasedObjectName: cn=sysadmins,ou=Groups,dc=example,dc=com cn: Systems Administrators However, when I do choose to dereference, nothing is returned: j...@ldap1:~# ldapsearch -x -ZZ -LLL -a find -b dc=example,dc=com cn=Systems\ Administrators j...@ldap1:~# j...@ldap1:~# ldapsearch -x -ZZ -LLL -a always -b dc=example,dc=com cn=Systems\ Administrators j...@ldap1:~# Clearly the result you got is correct. I can only obtain the expected results if I set the search base to the *specific* entry I'm looking to dereference: j...@ldap1:~# ldapsearch -x -ZZ -LLL -a always -b cn=Systems\ Administrators,ou=Groups,dc=example,dc=com dn: cn=sysadmins,ou=Groups,dc=example,dc=com ou: Groups gidNumber: 4001 cn: sysadmins objectClass: groupOfURLs objectClass: top objectClass: posixGroup description: The sysadmin team members memberURL: ldap:///ou=Users,dc=example,dc=com?dn?sub?((objectClass=examplecomE mployee)(departmentName=sysadmins)) member: uid=john,ou=Users,dc=example,dc=com member: uid=jane,ou=Users,dc=example,dc=com member: uid=joe,ou=Users,dc=example,dc=com I find it hard to believe that setting the search base to the alias entry is the only way which one may reference the alias entry And that is clearly not the case, in fact. Your last search is not equivalent to your previous searches, because the last time you omitted the **SEARCH FILTER**. Think about it. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
