Re: Can a Bind result in a Referral?

[Howard Chu]

Mike Stevens wrote:
> Many thanks for your prompt response and for pointing me at the appropriate 
> spec, Howard.
> 
> I don't believe that chaining and proxies are an option as I have no control 
> over the configuration of the LDAP server and must instead adapt the client to
> accommodate servers that utilise referrals.
> 
> One alternative I've considered is:
> 
> 1) Disable referral chasing in the client:
> 
> ldap_set_option( ld , LDAP_OPT_REFERRALS , LDAP_OPT_OFF ); 
> 
> 
> 2) Bind to the top level server using master credentials.
> 3) Search for the specified user; if the user doesn't exist at that server, 
> one or more referrals will be returned.
> 4) Iterate over each referral attempting to bind to each one using the user's 
> credentials until either the bind succeeds or I run out of referral 
> candidates.
> 
> If you have time to comment on that proposal, I'd be very grateful.

That's a lot of work. I would just set up my own slapd configured with two 
back-ldap instances.

first instance pointed at server B, marked subordinate.

second instance pointed at server A.

Point all clients at this slapd, all done, move on.
> 
> Kind regards,
> Mike
> 
> 
> On Wed, 11 May 2022 at 22:57, Howard Chu  > wrote:
> 
> Mike Stevens wrote:
> > Good day.
> >
> >  
> >
> > I’m an LDAP novice and am attempting to modify an LDAP client to 
> accommodate an LDAP server environment that makes use of referrals.
> >
> >  
> >
> > I have installed openLDAP 2.4.44 on 2 RHEL 7.9 servers.
> >
> >
> > The initial entries in the tree on serverA contains :
> >
> >
> > # xxx.com  
> > dn: dc=xxx,dc=com
> > description: xxx.com  
> > dc: xxx
> > o: xxx.com  
> > objectClass: top
> > objectClass: dcObject
> > objectClass: organization
> >
> > # Users, xxx.com  
> > dn: ou=Users,dc=xxx,dc=com
> > ou: Users
> > description: xxx Users
> > objectClass: organizationalUnit
> >
> > # search reference
> > *ref: ldap://serverB.xxx.com:389/dc=uk,dc=xxx,dc=com??sub 
> 
> *
> >
> > # mike, Users, xxx.com  
> > dn: uid=mike,ou=Users,dc=xxx,dc=com
> > cn: mike
> > ou: Users
> > uid: mike
> > givenName: Mike
> > mail: m...@uk.xxx.com   >
> > objectClass: Person
> > objectClass: organizationalPerson
> > objectClass: inetOrgPerson
> >
> >
> >
> > I believe the "ref" entry is known as a subordinate referral;
> >
> > it was created by populating the tree from an LDIF file that contained 
> the following:
> >
> >
> > dn: dc=uk,dc=xxx,dc=com
> > objectClass: referral
> > objectClass: extensibleObject
> > dc: uk
> > ref: ldap://serverB.xxx.com:389/dc=uk,dc=xxx,dc=com 
>  
> 
> >
> >
> > The intent is to redirect any requests received by serverA that refer 
> to the subtree uk.xxx.com   to serverB.
> >
> >
> > The tree on serverB contains:
> >
> >
> > # xxx.com  
> > dn: dc=xxx,dc=com
> > description: xxx.com  
> > dc: xxx
> > o: xxx.com  
> > objectClass: top
> > objectClass: dcObject
> > objectClass: organization
> >
> > # uk.xxx.com  
> > dn: dc=uk,dc=xxx,dc=com
> > dc: uk
> > o: uk.xxx.com  
> > description: xxx Users in the UK
> > objectClass: dcObject
> > objectClass: organization
> >
> > # mike, uk.xxx.com  
> > dn: uid=mike,dc=uk,dc=xxx,dc=com
> > cn: mike
> > uid: mike
> > givenName: Mike
> > mail: m...@uk.xxx.com   >
> > objectClass: person
> > objectClass: organizationalPerson
> > objectClass: inetOrgPerson
> >
> >
> > Now, if I perform a search on serverA specifying a base of uk.xxx.com 
>  , I get an RC=10 Referral result as 
> expected:
> >
> > [root@serverA ~]# ldapsearch -x  '(uid=mike)' -b dc=uk,dc=xxx,dc=com  
> -LL
> > version: 1
> >
> > Referral (10)
> > Matched DN: dc=uk,dc=xxx,dc=com
> > Referral: ldap://serverB.xxx.com:389/dc=uk,dc=xxx,dc=com??sub 
> 
> 

Re: Can a Bind result in a Referral?

[Mike Stevens]

Many thanks for your prompt response and for pointing me at the appropriate
spec, Howard.

I don't believe that chaining and proxies are an option as I have no
control over the configuration of the LDAP server and must instead adapt
the client to accommodate servers that utilise referrals.

One alternative I've considered is:

1) Disable referral chasing in the client:

ldap_set_option( ld , LDAP_OPT_REFERRALS , LDAP_OPT_OFF );


2) Bind to the top level server using master credentials.
3) Search for the specified user; if the user doesn't exist at that server,
one or more referrals will be returned.
4) Iterate over each referral attempting to bind to each one using the
user's credentials until either the bind succeeds or I run out of referral
candidates.

If you have time to comment on that proposal, I'd be very grateful.

Kind regards,
Mike


On Wed, 11 May 2022 at 22:57, Howard Chu  wrote:

> Mike Stevens wrote:
> > Good day.
> >
> >
> >
> > I’m an LDAP novice and am attempting to modify an LDAP client to
> accommodate an LDAP server environment that makes use of referrals.
> >
> >
> >
> > I have installed openLDAP 2.4.44 on 2 RHEL 7.9 servers.
> >
> >
> > The initial entries in the tree on serverA contains :
> >
> >
> > # xxx.com 
> > dn: dc=xxx,dc=com
> > description: xxx.com 
> > dc: xxx
> > o: xxx.com 
> > objectClass: top
> > objectClass: dcObject
> > objectClass: organization
> >
> > # Users, xxx.com 
> > dn: ou=Users,dc=xxx,dc=com
> > ou: Users
> > description: xxx Users
> > objectClass: organizationalUnit
> >
> > # search reference
> > *ref: ldap://serverB.xxx.com:389/dc=uk,dc=xxx,dc=com??sub <
> http://serverB.xxx.com:389/dc=uk,dc=xxx,dc=com??sub>*
> >
> > # mike, Users, xxx.com 
> > dn: uid=mike,ou=Users,dc=xxx,dc=com
> > cn: mike
> > ou: Users
> > uid: mike
> > givenName: Mike
> > mail: m...@uk.xxx.com 
> > objectClass: Person
> > objectClass: organizationalPerson
> > objectClass: inetOrgPerson
> >
> >
> >
> > I believe the "ref" entry is known as a subordinate referral;
> >
> > it was created by populating the tree from an LDIF file that contained
> the following:
> >
> >
> > dn: dc=uk,dc=xxx,dc=com
> > objectClass: referral
> > objectClass: extensibleObject
> > dc: uk
> > ref: ldap://serverB.xxx.com:389/dc=uk,dc=xxx,dc=com <
> http://serverB.xxx.com:389/dc=uk,dc=xxx,dc=com>
> >
> >
> > The intent is to redirect any requests received by serverA that refer to
> the subtree uk.xxx.com  to serverB.
> >
> >
> > The tree on serverB contains:
> >
> >
> > # xxx.com 
> > dn: dc=xxx,dc=com
> > description: xxx.com 
> > dc: xxx
> > o: xxx.com 
> > objectClass: top
> > objectClass: dcObject
> > objectClass: organization
> >
> > # uk.xxx.com 
> > dn: dc=uk,dc=xxx,dc=com
> > dc: uk
> > o: uk.xxx.com 
> > description: xxx Users in the UK
> > objectClass: dcObject
> > objectClass: organization
> >
> > # mike, uk.xxx.com 
> > dn: uid=mike,dc=uk,dc=xxx,dc=com
> > cn: mike
> > uid: mike
> > givenName: Mike
> > mail: m...@uk.xxx.com 
> > objectClass: person
> > objectClass: organizationalPerson
> > objectClass: inetOrgPerson
> >
> >
> > Now, if I perform a search on serverA specifying a base of uk.xxx.com <
> http://uk.xxx.com>, I get an RC=10 Referral result as expected:
> >
> > [root@serverA ~]# ldapsearch -x  '(uid=mike)' -b dc=uk,dc=xxx,dc=com
>  -LL
> > version: 1
> >
> > Referral (10)
> > Matched DN: dc=uk,dc=xxx,dc=com
> > Referral: ldap://serverB.xxx.com:389/dc=uk,dc=xxx,dc=com??sub <
> http://serverB.xxx.com:389/dc=uk,dc=xxx,dc=com??sub>
> >
> > ... and I can chase that referral using the -C option to retrieve the
> entry from serverB:
> >
> > [root@Mike21 ~]# ldapsearch -x  '(uid=mike)' -b dc=uk,dc=ibm,dc=com
>  -LL -C
> > version: 1
> >
> > dn: uid=mike,dc=uk,dc=xxx,dc=com
> > cn: mike
> > uid: mike
> > givenName: Mike
> > mail: m...@uk.xxx.com 
> > objectClass: person
> > objectClass: organizationalPerson
> > objectClass: inetOrgPerson
> >
> > But, if I attempt a bind to serverA using the user that exists in
> serverB, I get an authentication failure:
> >
> > [root@serverA ~]# ldapsearch -x -b 'dc=uk,dc=xxx,dc=com' -D
> uid=mike,dc=uk,dc=xxx,dc=com -w passw0rD
> > ldap_bind: Invalid credentials (49)
> >
> > Now, I realise that the failure would be expected as the bind DN doesn't
> exist at serverA.
> > But I read that every request apart from unbind and abandon can result
> in a referral.
> > So why doesn't the bind follow the "ref" to serverB?
> > Is that possible and have I not configured my server correctly?
>
> No. See RFC3296 section 5.6.1.
> >
> > Ultimately, what I'd like to do in my client is something like:
> >
> > ld_user = ldap_init( "ldap://serverA:389/dc=uk,dc=xxx,dc=com; , 0 );
> >
> > ... followed by :
> 

Re: Can a Bind result in a Referral?

[Howard Chu]

Mike Stevens wrote:
> Good day.
> 
>  
> 
> I’m an LDAP novice and am attempting to modify an LDAP client to accommodate 
> an LDAP server environment that makes use of referrals.
> 
>  
> 
> I have installed openLDAP 2.4.44 on 2 RHEL 7.9 servers.
> 
> 
> The initial entries in the tree on serverA contains :
> 
> 
> # xxx.com 
> dn: dc=xxx,dc=com
> description: xxx.com 
> dc: xxx
> o: xxx.com 
> objectClass: top
> objectClass: dcObject
> objectClass: organization
> 
> # Users, xxx.com 
> dn: ou=Users,dc=xxx,dc=com
> ou: Users
> description: xxx Users
> objectClass: organizationalUnit
> 
> # search reference
> *ref: ldap://serverB.xxx.com:389/dc=uk,dc=xxx,dc=com??sub 
> *
> 
> # mike, Users, xxx.com 
> dn: uid=mike,ou=Users,dc=xxx,dc=com
> cn: mike
> ou: Users
> uid: mike
> givenName: Mike
> mail: m...@uk.xxx.com 
> objectClass: Person
> objectClass: organizationalPerson
> objectClass: inetOrgPerson
> 
> 
> 
> I believe the "ref" entry is known as a subordinate referral;
> 
> it was created by populating the tree from an LDIF file that contained the 
> following:
> 
> 
> dn: dc=uk,dc=xxx,dc=com
> objectClass: referral
> objectClass: extensibleObject
> dc: uk
> ref: ldap://serverB.xxx.com:389/dc=uk,dc=xxx,dc=com 
> 
> 
> 
> The intent is to redirect any requests received by serverA that refer to the 
> subtree uk.xxx.com  to serverB.
> 
> 
> The tree on serverB contains:
> 
> 
> # xxx.com 
> dn: dc=xxx,dc=com
> description: xxx.com 
> dc: xxx
> o: xxx.com 
> objectClass: top
> objectClass: dcObject
> objectClass: organization
> 
> # uk.xxx.com 
> dn: dc=uk,dc=xxx,dc=com
> dc: uk
> o: uk.xxx.com 
> description: xxx Users in the UK
> objectClass: dcObject
> objectClass: organization
> 
> # mike, uk.xxx.com 
> dn: uid=mike,dc=uk,dc=xxx,dc=com
> cn: mike
> uid: mike
> givenName: Mike
> mail: m...@uk.xxx.com 
> objectClass: person
> objectClass: organizationalPerson
> objectClass: inetOrgPerson
> 
> 
> Now, if I perform a search on serverA specifying a base of uk.xxx.com 
> , I get an RC=10 Referral result as expected:
> 
> [root@serverA ~]# ldapsearch -x  '(uid=mike)' -b dc=uk,dc=xxx,dc=com  -LL
> version: 1
> 
> Referral (10)
> Matched DN: dc=uk,dc=xxx,dc=com
> Referral: ldap://serverB.xxx.com:389/dc=uk,dc=xxx,dc=com??sub 
> 
> 
> ... and I can chase that referral using the -C option to retrieve the entry 
> from serverB:
> 
> [root@Mike21 ~]# ldapsearch -x  '(uid=mike)' -b dc=uk,dc=ibm,dc=com  -LL -C
> version: 1
> 
> dn: uid=mike,dc=uk,dc=xxx,dc=com
> cn: mike
> uid: mike
> givenName: Mike
> mail: m...@uk.xxx.com 
> objectClass: person
> objectClass: organizationalPerson
> objectClass: inetOrgPerson
> 
> But, if I attempt a bind to serverA using the user that exists in serverB, I 
> get an authentication failure:
> 
> [root@serverA ~]# ldapsearch -x -b 'dc=uk,dc=xxx,dc=com' -D 
> uid=mike,dc=uk,dc=xxx,dc=com -w passw0rD
> ldap_bind: Invalid credentials (49)
> 
> Now, I realise that the failure would be expected as the bind DN doesn't 
> exist at serverA.
> But I read that every request apart from unbind and abandon can result in a 
> referral.
> So why doesn't the bind follow the "ref" to serverB?
> Is that possible and have I not configured my server correctly?

No. See RFC3296 section 5.6.1.
> 
> Ultimately, what I'd like to do in my client is something like:
> 
> ld_user = ldap_init( "ldap://serverA:389/dc=uk,dc=xxx,dc=com; , 0 );
> 
> ... followed by :
> 
>err = ldap_simple_bind_s( ld_user, "uid=mike,dc=uk,dc=xxx,dc=com" , 
> password);
> 
> ... and have LDAP authenticate the given user against serverB based on the 
> referral in serverA.
> 
> Is this sort of set up possible?

You will need to configure chaining or some other proxy mechanism instead.
> 
> Many thanks for your advice,
> Mike
> 


-- 
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Can a Bind result in a Referral?

[Mike Stevens]

Good day.



I’m an LDAP novice and am attempting to modify an LDAP client to
accommodate an LDAP server environment that makes use of referrals.



I have installed openLDAP 2.4.44 on 2 RHEL 7.9 servers.


The initial entries in the tree on serverA contains :


# xxx.com
dn: dc=xxx,dc=com
description: xxx.com
dc: xxx
o: xxx.com
objectClass: top
objectClass: dcObject
objectClass: organization

# Users, xxx.com
dn: ou=Users,dc=xxx,dc=com
ou: Users
description: xxx Users
objectClass: organizationalUnit

# search reference
*ref: ldap://serverB.xxx.com:389/dc=uk,dc=xxx,dc=com??sub
*

# mike, Users, xxx.com
dn: uid=mike,ou=Users,dc=xxx,dc=com
cn: mike
ou: Users
uid: mike
givenName: Mike
mail: m...@uk.xxx.com
objectClass: Person
objectClass: organizationalPerson
objectClass: inetOrgPerson



I believe the "ref" entry is known as a subordinate referral;

it was created by populating the tree from an LDIF file that contained the
following:


dn: dc=uk,dc=xxx,dc=com
objectClass: referral
objectClass: extensibleObject
dc: uk
ref: ldap://serverB.xxx.com:389/dc=uk,dc=xxx,dc=com


The intent is to redirect any requests received by serverA that refer to
the subtree uk.xxx.com to serverB.


The tree on serverB contains:

# xxx.com
dn: dc=xxx,dc=com
description: xxx.com
dc: xxx
o: xxx.com
objectClass: top
objectClass: dcObject
objectClass: organization

# uk.xxx.com
dn: dc=uk,dc=xxx,dc=com
dc: uk
o: uk.xxx.com
description: xxx Users in the UK
objectClass: dcObject
objectClass: organization

# mike, uk.xxx.com
dn: uid=mike,dc=uk,dc=xxx,dc=com
cn: mike
uid: mike
givenName: Mike
mail: m...@uk.xxx.com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson


Now, if I perform a search on serverA specifying a base of uk.xxx.com, I
get an RC=10 Referral result as expected:

[root@serverA ~]# ldapsearch -x  '(uid=mike)' -b dc=uk,dc=xxx,dc=com  -LL
version: 1

Referral (10)
Matched DN: dc=uk,dc=xxx,dc=com
Referral: ldap://serverB.xxx.com:389/dc=uk,dc=xxx,dc=com??sub

... and I can chase that referral using the -C option to retrieve the entry
from serverB:

[root@Mike21 ~]# ldapsearch -x  '(uid=mike)' -b dc=uk,dc=ibm,dc=com  -LL -C
version: 1

dn: uid=mike,dc=uk,dc=xxx,dc=com
cn: mike
uid: mike
givenName: Mike
mail: m...@uk.xxx.com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson

But, if I attempt a bind to serverA using the user that exists in serverB,
I get an authentication failure:

[root@serverA ~]# ldapsearch -x -b 'dc=uk,dc=xxx,dc=com' -D
uid=mike,dc=uk,dc=xxx,dc=com -w passw0rD
ldap_bind: Invalid credentials (49)

Now, I realise that the failure would be expected as the bind DN doesn't
exist at serverA.
But I read that every request apart from unbind and abandon can result in a
referral.
So why doesn't the bind follow the "ref" to serverB?
Is that possible and have I not configured my server correctly?

Ultimately, what I'd like to do in my client is something like:

ld_user = ldap_init( "ldap://serverA:389/dc=uk,dc=xxx,dc=com; , 0 );

... followed by :

err = ldap_simple_bind_s( ld_user, "uid=mike,dc=uk,dc=xxx,dc=com"
, password);

... and have LDAP authenticate the given user against serverB based on the
referral in serverA.

Is this sort of set up possible?

Many thanks for your advice,
Mike

Re: dynlist vs memberof performance issues

[Howard Chu]

Soisik Froger wrote:
> On 01/09/2021 17:17, Quanah Gibson-Mount wrote:
>>
>>
>> --On Wednesday, September 1, 2021 2:07 PM +0100 Mark Cairney
>>  wrote:
>>
>>> Hi,
>>>
>>> I've been out the LDAP loop for a bit but the recent discussion of the
>>> memberof overlay on 2.5 piqued my curiosity. Having upgraded a Dev box,
>>> removed the memberof elements from the database and replaced the
>>> memberof overlay with dynlist the queries appear to work as expected but
>>> are both a) slow and b) heavily CPU-intensive on the LDAP server.
>>
>>
>> As an aside, I would note that you appear to be indexing "pres"
>> unnecessarily.  Please read
>> 
>>
>> If the group object is large you may be having slow searches due to indices
>> being collapsed to a range.  You would need to run the search with trace
>> logging to determine if that's the case as was recently discussed on the
>> list.
>>
>> Regards,
>> Quanah
>>
> 
> Hi,
> 
> We are also observing very long query time involving memberOf when using 
> dynlist migrating a 2.4 OpenLDAP docker install to 2.5.11. We have followed 
> community
> recommendation and replaced the deprecated memberOf overlay with dynlist to 
> calculate memberOf attributes, and removed the memberof elements from the data
> before importing it.
> 
> Using dynlist, we have noticed an important drop of performance in queries 
> involving the memberOf attributes on (relatively) large database (about 36000 
> users
> and 9000 groups dispatched in 150 branches) compared to 2.4: Queries on 
> memberOf attributes that used to be processed in 0.200 seconds now takes 
> about 6-7
> seconds. In the example below, the search base is a branch with a relatively 
> small number of users (about 350) and the targeted group contains 260 users:
> 
> time ldapsearch -x -h 172.17.0.2 -D "cn=admin,dc=domain,dc=com" -w "secret" 
> -b "ou=people,dc=branch,dc=domain,dc=com"
> "(memberof=cn=dev,ou=groups,dc=branch,dc=domain,dc=com)" uid
> 
> real    0m6,358s
> user    0m0,024s
> sys    0m0,020s
> 
> If the group used in memberOf has 1200 members, the query takes over 30 
> seconds. These results are obtained using an OpenLDAP running in a simple 
> docker
> container on a host with 8CPU/16GB RAM.
> 
> When using the memberOf overlay instead of dynlist to calculate memberOf, the 
> performance are back to what is used to be in 2.4 (< 0.200 second for the 
> above
> ldapsearch).
> 
> We believe our config to be very standard: member attribute is indexed and 
> dynlist is loaded and configured as below
> 
> dn: olcOverlay={3}dynlist,olcDatabase={1}mdb,cn=config
> objectClass: olcOverlayConfig
> objectClass: olcDynListConfig
> olcOverlay: {3}dynlist
> olcDynListAttrSet: {0}groupOfURLs memberURL member+memberOf@groupOfNames
> 
> Are this performance issues an expected side-effect of switching to dynlist - 
> as the memberOf attributes are now dynamically calculated while the memberOf
> overlay used to writes these attributes - or something is more likely wrong 
> with our install or could be tuned to improve these performances?

That's just the cost of dynamically calculating these attributes, yes.

It's possible we can make some other optimizations to the overlay to reduce the 
amount of work in calculating memberOf if you're only
using it in a filter and not returning all of its values. Looks like it could 
be a fairly significant refactoring to achieve that though.
> 
> Some organizations have applications that relies on memberOf queries to be 
> fast, and expects to keep these performances when upgrading to 2.5. From what 
> we
> observed, we can only advise them to stick with the legacy memberOf overlay 
> if they need these queries to stay fast, or rethink their approach to avoid 
> querying
> memberOf on large databases.

Makes sense.
> 
> Regards,
> 


-- 
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: dynlist vs memberof performance issues

[Soisik Froger]

On 01/09/2021 17:17, Quanah Gibson-Mount wrote:



--On Wednesday, September 1, 2021 2:07 PM +0100 Mark Cairney
 wrote:


Hi,

I've been out the LDAP loop for a bit but the recent discussion of the
memberof overlay on 2.5 piqued my curiosity. Having upgraded a Dev box,
removed the memberof elements from the database and replaced the
memberof overlay with dynlist the queries appear to work as expected but
are both a) slow and b) heavily CPU-intensive on the LDAP server.



As an aside, I would note that you appear to be indexing "pres"
unnecessarily.  Please read


If the group object is large you may be having slow searches due to indices
being collapsed to a range.  You would need to run the search with trace
logging to determine if that's the case as was recently discussed on the
list.

Regards,
Quanah



Hi,

We are also observing very long query time involving memberOf when using 
dynlist migrating a 2.4 OpenLDAP docker install to 2.5.11. We have followed 
community recommendation and replaced the deprecated memberOf overlay with 
dynlist to calculate memberOf attributes, and removed the memberof elements 
from the data before importing it.

Using dynlist, we have noticed an important drop of performance in queries 
involving the memberOf attributes on (relatively) large database (about 36000 
users and 9000 groups dispatched in 150 branches) compared to 2.4: Queries on 
memberOf attributes that used to be processed in 0.200 seconds now takes about 
6-7 seconds. In the example below, the search base is a branch with a 
relatively small number of users (about 350) and the targeted group contains 
260 users:

time ldapsearch -x -h 172.17.0.2 -D "cn=admin,dc=domain,dc=com" -w "secret" -b 
"ou=people,dc=branch,dc=domain,dc=com" "(memberof=cn=dev,ou=groups,dc=branch,dc=domain,dc=com)" uid

real0m6,358s
user0m0,024s
sys 0m0,020s

If the group used in memberOf has 1200 members, the query takes over 30 
seconds. These results are obtained using an OpenLDAP running in a simple 
docker container on a host with 8CPU/16GB RAM.

When using the memberOf overlay instead of dynlist to calculate memberOf, the 
performance are back to what is used to be in 2.4 (< 0.200 second for the above 
ldapsearch).

We believe our config to be very standard: member attribute is indexed and 
dynlist is loaded and configured as below

dn: olcOverlay={3}dynlist,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcDynListConfig
olcOverlay: {3}dynlist
olcDynListAttrSet: {0}groupOfURLs memberURL member+memberOf@groupOfNames

Are this performance issues an expected side-effect of switching to dynlist - 
as the memberOf attributes are now dynamically calculated while the memberOf 
overlay used to writes these attributes - or something is more likely wrong 
with our install or could be tuned to improve these performances?

Some organizations have applications that relies on memberOf queries to be 
fast, and expects to keep these performances when upgrading to 2.5. From what 
we observed, we can only advise them to stick with the legacy memberOf overlay 
if they need these queries to stay fast, or rethink their approach to avoid 
querying memberOf on large databases.

Regards,

--
Soisik Froger

Worteks | https://www.worteks.com