RE: cache userPassword with bind
--On Thursday, April 25, 2024 8:24 AM + Marc wrote: I am just testing if some application is efficiently authenticating with a simple bind (and not doing searches) In a later stage I would like to maybe optimize authenticating against ldap with credential caching. When I saw this I just thought I could do something with it. (In another thread I posted about having binds max out at 150req/s, while searches are ~9000req/s) Again, you've failed to provide any useful information about your setup, along with using an ldap benchmarking tool I've never heard of, so it's difficult to really draw any conclusions. Binds are always going to be slower than other operations since they involve things such as TLS (if used), DNS, and other items. Well written LDAP clients bind, and then use a persistent connection to do their operations. As far as ldctl, as best I can tell, it's a single host based benchmark system, which is generally not a valid way to benchmark LDAP, since clients are generally distributed. In the past I've been trivially able to overwhelm the client's ability to do networking with tools like that. Valid LDAP benchmarking tools are distributed in nature (slamd, jmeter, etc) which better reflect real world traffic patterns. --Quanah
RE: cache userPassword with bind
> > > Am just testing with an alpine linux container and an ldap db with ~10 > > entries, almost nothing. Yet when I look in top res memory is 700MB. So > I > > assume everything is already cached, but I don't really get then this > > logging. I don't even get why 700MB is being used, my data is probably > > > few 100KB. > > It's the ACL cache, which is internal and you have no control over. oh ok that makes sense. > You've provided virtually no information on your environment's > configuration for slapd. I would note that if you're seeing "result not > in > cache" then you have your logging level turned up insanely high on the > server, which will slow down everything. > I am just testing if some application is efficiently authenticating with a simple bind (and not doing searches) In a later stage I would like to maybe optimize authenticating against ldap with credential caching. When I saw this I just thought I could do something with it. (In another thread I posted about having binds max out at 150req/s, while searches are ~9000req/s)
RE: cache userPassword with bind
--On Wednesday, April 24, 2024 8:37 PM + Marc wrote: Am just testing with an alpine linux container and an ldap db with ~10 entries, almost nothing. Yet when I look in top res memory is 700MB. So I assume everything is already cached, but I don't really get then this logging. I don't even get why 700MB is being used, my data is probably a few 100KB. It's the ACL cache, which is internal and you have no control over. You've provided virtually no information on your environment's configuration for slapd. I would note that if you're seeing "result not in cache" then you have your logging level turned up insanely high on the server, which will slow down everything. --Quanah
RE: cache userPassword with bind
> > > > > > I am testing a bit with bind's. With consecutive binds with the > same > > > test account I always get 'result not in cache'. How can I get this > in > > > cache? > > > > > > > > access_allowed: result not in cache (userPassword) > > > > > > > > 6628dba5.0659c27a 0x7ff072843b38 conn=1023 op=0 BIND > > > dn="uid=test,dc=me,dc=local" method=128 > > > > 6628dba5.0660ea46 0x7ff072843b38 => access_allowed: result not in > > cache > > > (userPassword) > > > > 6628dba5.066470b9 0x7ff072843b38 => access_allowed: auth access to > > > "uid=test,dc=me,dc=local " "userPassword" requested > > > > 6628dba5.0667703c 0x7ff072843b38 => slap_access_allowed: backend > > > default auth access granted to "(anonymous)" > > > > 6628dba5.0668099f 0x7ff072843b38 => access_allowed: auth access > > granted > > > by read(=rscxd) > > > > > > > > > I think you need to index the userPassword attribute. For that you > need > > > to add the appropriate > > > olcDBIndex entry to your database configuration. > > > > > > > > > https://www.openldap.org/doc/admin26/guide.html#MDB%20Database%20Directiv > > > es > > > > After doing this : > > > > mv slapd.ldif slapd.ldif.bak > > > > adding to the mdb section in slapd.conf > > index userPasswordpres,eq > > > > /etc/openldap # slapindex userPassword > > /etc/openldap # echo $? > > 0 > > > > I am still getting this > > access_allowed: result not in cache (userPassword) > > > > Or is this related to adding openldap-overlay-proxycache ? Am just testing with an alpine linux container and an ldap db with ~10 entries, almost nothing. Yet when I look in top res memory is 700MB. So I assume everything is already cached, but I don't really get then this logging. I don't even get why 700MB is being used, my data is probably a few 100KB.
RE: cache userPassword with bind
> > > > I am testing a bit with bind's. With consecutive binds with the same > > test account I always get 'result not in cache'. How can I get this in > > cache? > > > > > > access_allowed: result not in cache (userPassword) > > > > > > 6628dba5.0659c27a 0x7ff072843b38 conn=1023 op=0 BIND > > dn="uid=test,dc=me,dc=local" method=128 > > > 6628dba5.0660ea46 0x7ff072843b38 => access_allowed: result not in > cache > > (userPassword) > > > 6628dba5.066470b9 0x7ff072843b38 => access_allowed: auth access to > > "uid=test,dc=me,dc=local " "userPassword" requested > > > 6628dba5.0667703c 0x7ff072843b38 => slap_access_allowed: backend > > default auth access granted to "(anonymous)" > > > 6628dba5.0668099f 0x7ff072843b38 => access_allowed: auth access > granted > > by read(=rscxd) > > > > > > I think you need to index the userPassword attribute. For that you need > > to add the appropriate > > olcDBIndex entry to your database configuration. > > > > > https://www.openldap.org/doc/admin26/guide.html#MDB%20Database%20Directiv > > es > > After doing this : > > mv slapd.ldif slapd.ldif.bak > > adding to the mdb section in slapd.conf > index userPasswordpres,eq > > /etc/openldap # slapindex userPassword > /etc/openldap # echo $? > 0 > > I am still getting this > access_allowed: result not in cache (userPassword) > Or is this related to adding openldap-overlay-proxycache ?
RE: cache userPassword with bind
> > I am testing a bit with bind's. With consecutive binds with the same > test account I always get 'result not in cache'. How can I get this in > cache? > > > > access_allowed: result not in cache (userPassword) > > > > 6628dba5.0659c27a 0x7ff072843b38 conn=1023 op=0 BIND > dn="uid=test,dc=me,dc=local" method=128 > > 6628dba5.0660ea46 0x7ff072843b38 => access_allowed: result not in cache > (userPassword) > > 6628dba5.066470b9 0x7ff072843b38 => access_allowed: auth access to > "uid=test,dc=me,dc=local " "userPassword" requested > > 6628dba5.0667703c 0x7ff072843b38 => slap_access_allowed: backend > default auth access granted to "(anonymous)" > > 6628dba5.0668099f 0x7ff072843b38 => access_allowed: auth access granted > by read(=rscxd) > > > I think you need to index the userPassword attribute. For that you need > to add the appropriate > olcDBIndex entry to your database configuration. > > https://www.openldap.org/doc/admin26/guide.html#MDB%20Database%20Directiv > es After doing this : mv slapd.ldif slapd.ldif.bak adding to the mdb section in slapd.conf index userPasswordpres,eq /etc/openldap # slapindex userPassword /etc/openldap # echo $? 0 I am still getting this access_allowed: result not in cache (userPassword)
Re: cache userPassword with bind
Am 24.04.24 um 12:40 schrieb Marc: > I am testing a bit with bind's. With consecutive binds with the same test > account I always get 'result not in cache'. How can I get this in cache? > > access_allowed: result not in cache (userPassword) > > 6628dba5.0659c27a 0x7ff072843b38 conn=1023 op=0 BIND > dn="uid=test,dc=me,dc=local" method=128 > 6628dba5.0660ea46 0x7ff072843b38 => access_allowed: result not in cache > (userPassword) > 6628dba5.066470b9 0x7ff072843b38 => access_allowed: auth access to > "uid=test,dc=me,dc=local " "userPassword" requested > 6628dba5.0667703c 0x7ff072843b38 => slap_access_allowed: backend default auth > access granted to "(anonymous)" > 6628dba5.0668099f 0x7ff072843b38 => access_allowed: auth access granted by > read(=rscxd) I think you need to index the userPassword attribute. For that you need to add the appropriate olcDBIndex entry to your database configuration. https://www.openldap.org/doc/admin26/guide.html#MDB%20Database%20Directives
