Index seems to return wrong amount of candidate causing really poor search performance
by chrichardso27＠gmail.com
Hi,
Considering the following assumptions;
- OpenLDAP version 2.4.51
- attributes objectClass and abc are indexed based on equality
- the EQUALITY of attribute abc is based on distinguishedNameMatch
- The database contains roughly 2 million entries
- 2 entries have defined the attribute abc with a dn value cn=foo,dc=bar and objectClass=someClass
- 2 entries have defined the attribute abc with a dn value cn=bar,dc=baz and objectClass=someClass
Now, the issue started with really slow search performance using objectClass=someClass & abc=cn=foo,dc=bar as filter criteria. Debugging a while seems to indicate that the objectClass filter returns roughly 2 million entries as candidates. Now, one would expect that the second filter would return only the 2 potential candidates from the abc index, or a subset of the whole database but this is not the case. The second filter also returns nearly the whole database entries as potential candidates and causes really slow query performance. Interestingly, this only occurs when attribute abc has value cn=foo,dc=bar, but for some reason for the entry having attribute abc with value cn=bar,dc=baz the query returns immediately. In both cases, the actual entries matching the search return immediately but for the problematic search "(&(objectClass=someClass)(abc=cn=foo,dc=bar))", the completion of the search takes a long time (around 15 seconds to be precise).
The issue started suddenly and wasn't a degradation of query performance over time.
Few things I have tried
- Rebuilt the whole database again
- Reindex the existing database again
- Testing with bdb and mdb as backends
- Increased cache sizes for bdb to hold the whole database in cache
- For bdb adjust the page size of the indexes according to suggestion by db_tuner
- Change the order of the filters
None of these made any difference. At the moment, there does not seem to be any good options to try. Any ideas or help would be greatly appreciated!
2 months, 1 week
Best way two update a full OpenLDAP database from LDIF file
by Prunk Dump
Hello !
My network infrastructure uses some special database not compatible
with LDAP. But I need an OpenLDAP server to administer my Web Services
accounts on my DMZ.
So I have written a script to export our "special" database to an LDIF
file. This works pretty well. I've successfully loaded it on my
OpenLDAP server.
But now I don't know how to update my OpenLDAP database from the new
generated LDIF files (when users are added, updated or removed)
without disturbing the whole LDAP service (it's not a very good idea
to delete the entire database and recreate it from the new LDIF file
as it stop the service completely during the operation).
Is there a way to update an OpenLDAP database to fit a new given LDIF file ?
-> Updating/deleting the OUs
-> Deleting the objects that are not present.
-> Deleting the attributes removed.
-> Updating the attributes that have changed without deleting the object.
Doing this step by step to disturb as little as possible the OpenLDAP service.
Thanks for the help.
Regards,
Baptiste.
8 months, 2 weeks
Unable to bind with LDAP DN having encoded chars
by radiatejava
I am using openldap client library 2.4.44 on Centos 7.3, LDAP v3
setting. I am having an issue with LDAP bind when the DN has encoded
representation of special characters like é (e acute). Actual DN is
CN=mithun,OU=Groupes de Sécurité,DC=mytest,DC=net and when it is sent
by the app (frontend) to our backend, it is coming as
CN=mithun,OU=Groupes de S\u00e9curit\u00e9,DC=insaaadev,DC=net.
Basically, é comes encoded as \u00e9 which is as per the encoding
mentioned here https://www.fileformat.info/info/unicode/char/e9/index.htm
To further try out, I directly hardcoded the DN to
CN=mithun,OU=Groupes de S\u00e9curit\u00e9,DC=mytest,DC=net and that
worked fine. I want to understand why it fails when the DN in the same
format comes from the frontend app. Appreciate your help, thanks.
8 months, 3 weeks
Backup/Restore Overlays MemberOf
by Lars Päßler
Hello,
I am running OpenLDAP 2.4.47 on Debian 10 for a while and now I enabled
the overlay for memberOf. Is there any good option for backup and
restore, because slapcat and slapadd aren't working.
Thanks and kind regards
Lars
8 months, 3 weeks
Re: How to set credential to ldap_gssapi_bind_s?
by Árpád Nagy
Hello,
Thanks for the answer!
What function should I use if I must supply username/password and I want to
bind using GSSAPI?
Is it possible somehow with Open LDAP?
Regards,
Arpad
Quanah Gibson-Mount <quanah(a)symas.com> ezt írta (időpont: 2021. jan. 27.,
Sze, 18:10):
>
>
> --On Wednesday, January 27, 2021 4:16 PM +0100 Árpád Nagy
> <arpadnagy.bp(a)gmail.com> wrote:
>
> >
> > According this it is executed only if 'dn' and 'creds' is NULL.
> > My question is how can I set the user name and password which I want to
> > authenticate on LDAP server?
>
> Using GSSAPI implies that the connecting client already has access to a
> kerberos5 ticket, which is used for the authentication step and thus there
> is no username or password to be supplied.
>
> If you must supply a username/password, then you're using the wrong
> function.
>
> Regards,
> Quanah
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
8 months, 4 weeks
OpenLDAP proxy to AD with client certificates
by David Cunningham
Hello,
I would like to configure slaps.conf to proxy requests to an AD server.
1.) I want SLAPD to always connect to this AD server as a specific user
2.) I want SLAPD to run all queries including searches against this AD server using the defined user.
3.) I want clients connecting to SLAPD to query AD to be authenticated by revokable client certificate only. If the connecting client has a valid certificate that matches a CA, then it’s LDAP query is allowed and proxied to Active Directory.
4.) The client should also be able to rebind as user after doing a user DN search (to verify username/password).
Does that make sense?
9 months
How to set credential to ldap_gssapi_bind_s?
by Árpád Nagy
Hello,
I try to bind to LDAP server using GSSAPI.
I try to use ldap_gssapi_bind_s method (gssapi.c):
int
ldap_gssapi_bind_s(
LDAP *ld,
LDAP_CONST char *dn,
LDAP_CONST char *creds )
{
if ( dn != NULL ) {
return LDAP_NOT_SUPPORTED;
}
if ( creds != NULL ) {
return LDAP_NOT_SUPPORTED;
}
return ldap_int_gss_spnego_bind_s(ld);
}
According this it is executed only if 'dn' and 'creds' is NULL.
My question is how can I set the user name and password which I want to
authenticate on LDAP server?
Regards,
Arpad
9 months
Syncprov shows issue with entry
by Nick Milas
Hello,
I would like to ask you for your guidance regarding the following.
We have an openldap (v2.4.56) master server syncing with three other
openldap slaves.
The master seems being unable to complete successfully syncing a
particular entry and it keeps trying for ever. Logs follow.
I have realized this only now, but it seems that this is happening for
long. (It is recorded in all the logs I have available.)
What is the suggested way to resolve this situation?
=======================================================================================================
...
Jan 16 14:48:09 ldap.noa.gr slapd[1655]: conn=1048 op=1
syncprov_search_response: Entry cn=thermo,ou=Aliases,dc=noa,dc=gr CSN
20200910151806.461875Z#000000#000#000000 older or equal to ctx
20200910151806.461875Z#000000#000#000000
Jan 16 14:48:09 ldap.noa.gr slapd[1655]: conn=1048 op=1
syncprov_search_response:
cookie=rid=601,csn=20210116055411.875566Z#000000#000#000000
Jan 16 14:48:09 ldap.noa.gr slapd[1655]: conn=1048 op=1
syncprov_sendinfo: refreshPresent
cookie=rid=601,csn=20210116055411.875566Z#000000#000#000000
Jan 16 14:48:09 ldap.noa.gr slapd[1655]: conn=1048 op=1
syncprov_search_response: detaching op
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_op_search: got a persistent search with a
cookie=rid=601,csn=20200910151806.461875Z#000000#000#000000
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_findbase: searching
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_op_search: registered persistent search
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_findcsn: mode=FIND_CSN csn=20200910151806.461875Z#000000#000#000000
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_findcsn: csn==20200910151806.461875Z#000000#000#000000 found
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_findcsn: mode=FIND_PRESENT csn=
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_sendinfo: present syncIdSet cookie=
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_sendinfo: present syncIdSet cookie=
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_sendinfo: present syncIdSet cookie=
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_sendinfo: present syncIdSet cookie=
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_sendinfo: present syncIdSet cookie=
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_sendinfo: present syncIdSet cookie=
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_sendinfo: present syncIdSet cookie=
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_sendinfo: present syncIdSet cookie=
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_sendinfo: present syncIdSet cookie=
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_sendinfo: present syncIdSet cookie=
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_sendinfo: present syncIdSet cookie=
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_sendinfo: present syncIdSet cookie=
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_search_response: Entry cn=thermo,ou=Aliases,dc=noa,dc=gr CSN
20200910151806.461875Z#000000#000#000000 older or equal to ctx
20200910151806.461875Z#000000#000#000000
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_search_response:
cookie=rid=601,csn=20210116055411.875566Z#000000#000#000000
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_sendinfo: refreshPresent
cookie=rid=601,csn=20210116055411.875566Z#000000#000#000000
Jan 16 14:51:09 ldap.noa.gr slapd[1655]: conn=1058 op=1
syncprov_search_response: detaching op
=========================================================================================================
Thank you in advance for your advice!
Cheers,
Nick
9 months
openldap performance problems
by Zetan Drableg
Every time my "updater" process writes an LDIF to LDAP, clients start
seeing timeouts during authentication. Even with a small number of inserts
or removals, this problem shows up.
openldap 2.4.47, MBD, 16 core Linux server, 6 nodes in a n-way multimaster
replication configuration. The on disk database is 1.5gigs.
Can anyone suggest tunables for this problem?
I've tried "threads 64" but that didn't improve things.
[2021-01-24 00:01:45] connection_input: conn=2721465 deferring operation:
binding
[2021-01-24 00:01:45] connection_input: conn=2721505 deferring operation:
binding
[2021-01-24 00:01:45] connection_read(17): no connection!
[2021-01-24 00:01:46] connection_input: conn=2721694 deferring operation:
binding
[2021-01-24 00:01:47] connection_input: conn=2721844 deferring operation:
binding
[2021-01-24 00:01:48] connection_input: conn=2722210 deferring operation:
binding
[2021-01-24 00:01:48] connection_input: conn=2722208 deferring operation:
binding
[2021-01-24 00:01:48] connection_input: conn=2722283 deferring operation:
binding
Thank you
9 months
