openldap-technical

openldap-technical@openldap.org

18 participants
9785 discussions

Re: Proposal to strengthen slapd EXTERNAL authentication
by Howard Chu 28 Jun '23

28 Jun '23

Sean Gallagher wrote: > On 26/06/2023 7:40 pm, Howard Chu wrote: >> That feature is already available using TLSVerifyClient in the slapd config. > > Not really. Using the TLSVerifyClient mechanism could be made to work and would be a nice solution but it isn't there yet. To make this this work, you would > need to pass to libldap, some type of specification of the names of legitimate clients. Then in the tls_o.c:tlso_verify_cb() function, compare the name on the > client cert with the specification and return the pass/fail status back to the TLS layer. Then it would all "just work". > > The average user might be surprised to learn that TLSVerifyClient does not currently involve checking the client's name. You would intuitively think that was > pretty important. The point of a certificate-based authentication system is not to have to implement authentication rules for each and every individual user. An LDAP server should only trust certificates issued by a single CA; that CA should only be issuing certs to valid users. Ideally, the LDAP server should be the CA, which is what slapo-autoca is designed for. An LDAP server is not a web server or a client. There is no reason for it to trust certs from multiple CAs. > >> Pure nonsense. > > Pure hubris. > > It's sad when it takes a disaster to affect real change. Pure ignorance. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

6 12

Re: observation on serverID / URI match
by cYuSeDfZfb cYuSeDfZfb 28 Jun '23

28 Jun '23

Hi, Thanks Quanah. Just to follow-up: Yes, with an ldap listener on 0.0.0.0, openldap is *still* able to determine it's own serverID when multiple are configured, based on the above-mentioned code. In my config I do: serverID 1 ldaps://my.ldapserver1.com serverID 2 ldaps://my.ldapserver2.com (nota bene FQDN) and the local hostname is obviously NOT a FQDN but just a (short) hostname. But it is still matched correctly, which is phenomenal, and not something I could read / understand from the docs! :-) I also tested, by changing the config to a non-existing "serverID 2 ldaps:// my.ldapserver5.com <http://my.ldapserver2.com>", and then we do get the "read_config: no serverID / URL match found. Check slapd -h arguments." Impressed by openldap's cleverness. :-) Regards! On Tue, 27 Jun 2023 at 17:40, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Monday, June 26, 2023 10:18 PM +0200 cYuSeDfZfb cYuSeDfZfb > <cyusedfzfb(a)gmail.com> wrote: > > > Now we wonder if the serverID is determined and set correctly or > > not.... and even with loglevel -1 the auto-determined "local serverID" > > is not logged on start. > > > > > > Does anyone know? > > > > > > Can the serverID also be determined from the local hostname? Or is there > > any other magic going on? > > > This is determined in the following code block in servers/slapd/config.c: > > < > https://git.openldap.org/openldap/openldap/-/blob/master/servers/slapd/conf… > > > > So that's the magic you are looking for. > > Regards, > Quanah >

1 0

observation on serverID / URI match
by cYuSeDfZfb cYuSeDfZfb 27 Jun '23

27 Jun '23

Hi, In an attempt to standardize our config as much as possible, we included in our slapd.conf: serverID 1 ldaps://my.ldapserver1.com serverID 2 ldaps://my.ldapserver2.com serverID 3 ldaps://my.ldapserver3.com serverID 4 ldaps://my.ldapserver4.com The hostname of the RHEL9 servers is set to ldapserver1 & ldapserver2, but on the hosts slapd is configured to run like: /opt/symas/lib/slapd -d 0 -h ldap:/// ldaps:/// ldapi:/// -u ldap -g ldap (so... NO uri specified, also not in /etc/default/symas-openldap) We expected to receive an error like: no match between serverID and URI found, but much to our surprise we don't. :-) Now we wonder if the serverID is determined and set correctly or not.... and even with loglevel -1 the auto-determined "local serverID" is not logged on start. Does anyone know? Can the serverID also be determined from the local hostname? Or is there any other magic going on? And otherwise... why is everything starting regularly, and are we not getting the error message? (we are running a 4 server multi-master replication setup, and replication with the above setting in place is still working normally)

2 1

What drives CPU usage spikes?
by Quanah Gibson-Mount 27 Jun '23

27 Jun '23

In our 2.6.4 deployment, we had a significant spike in CPU usage one day last week that lasted approximately 2 hours (8 AM UTC to 10 AM UTC). During this time, some clients started timing out when talking to the LDAP service, and search response times spiked as well, up to 9.5 seconds on searches that normally take < 3 seconds (they do have large result sets). This happened on all 6 of the read nodes that we have in our load balance pool, so whatever the issue was hit all of them at the same time. It did not happen to 2 specialized read nodes that only serve one specific service, so it was something about the traffic going to those 6 nodes. The number of ops/second during that time frame was actually lower than usual across the cluster, with a peak of 200 ops/second. We often have higher peaks than that without this type of CPU usage spiking. I'm curious what with modern slapd + LMDB should be looked for that would drive such a spike. I thought perhaps there were a significant number of write operations at the same time, but this was not the case, there was no unusual level of write activity. There were also much lower than usual number of concurrent connections across the cluster during this time (~800), we usually have closer to 2k-3k concurrent connections. The total number of initiated operations during the time frame was also within normal range. There was also nothing unusual about amount of network traffic, it fit right in with normal traffic levels. One thing that I did see is that there was an unusually high number of 'deferring operation: binding' messages. We normally average about 400/day, but on this specific day we hit > 1500 such messages. Thanks, Quanah

3 4

Re: problem, and solution | database monitor
by cYuSeDfZfb cYuSeDfZfb 26 Jun '23

26 Jun '23

I created https://bugs.openldap.org/show_bug.cgi?id=10073 Thanks for making available a great product. On Mon, 26 Jun 2023 at 18:41, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Thursday, June 22, 2023 10:46 AM +0200 cYuSeDfZfb cYuSeDfZfb > <cyusedfzfb(a)gmail.com> wrote: > > > > > > > Hi, > > > > > > I'm posting this mostly for the archives, so that a search for the error > > below will help a next person. > > Hi, > > Please open a bug on this issue at https://bugs.openldap.org > > Thanks! > > Regards, > Quanah > > > >

1 0

RE25 testing call (2.5.15) #1
by Quanah Gibson-Mount 26 Jun '23

26 Jun '23

This is the first testing call for OpenLDAP 2.5.15. Depending on the results, this may be the only testing call. NOTE: This release adds support for OpenSSL 3.0 to the 2.5 release series. Generally, get the code for RE25: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_5/o…> Extract, configure, and build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Thanks! OpenLDAP 2.5.15 Engineering Added libldap openssl3 support (ITS#9436, ITS#10030) Fixed libldap handling of TCP KEEPALIVE options (ITS#10015) Fixed libldap with async connections (ITS#10023) Fixed libldap openssl TLSv1.3 cipher suite handling (ITS#10035) Fixed slapd callback handling with overlays that do extended operations (ITS#9990) Fixed slapd conversion of pcache configurations (ITS#10031) Fixed slapd cn=config modification handling with abandon (ITS#10045) Fixed slapo-constraint handling of push replication (ITS#9953) Fixed slapo-dynlist filter evaluation efficiency (ITS#10041) Fixed slapo-pcache handling of invalid schema (ITS#10032) Fixed slapo-ppolicy handling of push replication (ITS#9953) Fixed slapo-ppolicy handling of pwdMinDelay (ITS#10028) Fixed slapo-syncprov abandon handling (ITS#10016) Fixed slapo-translucent handling of invalid schema (ITS#10032) Fixed slapo-unique handling of push replication (ITS#9953) Fixed slapo-variant to improve regex handling (ITS#10048) Build Environment Fixed compatibility with stricter C99 compilers (ITS#10011) Keep .pc files during make clean (ITS#9989) Contrib Fixed slapo-variant handling of push replication (ITS#9953) Minor Cleanup ITS#9855 ITS#9995 ITS#9996 ITS#9997 ITS#9998 ITS#9999 ITS#10000 ITS#10003 ITS#10004 ITS#10033 ITS#10037 ITS#10039 ITS#10046 Regards, Quanah

2 1

RE26 testing call (2.6.5) #1
by Quanah Gibson-Mount 26 Jun '23

26 Jun '23

This is the first testing call for OpenLDAP 2.6.5. Depending on the results, this may be the only testing call. Generally, get the code for RE26: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_6/o…> Extract, configure, and build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Thanks! OpenLDAP 2.6.5 Engineering Fixed libldap handling of TCP KEEPALIVE options (ITS#10015) Fixed libldap with async connections (ITS#10023) Fixed libldap openssl TLSv1.3 cipher suite handling (ITS#10035) Fixed slapd callback handling with overlays that do extended operations (ITS#9990) Fixed slapd conversion of pcache configurations (ITS#10031) Fixed slapd cn=config modification handling with abandon (ITS#10045) Fixed slapd-mdb online indexer termination and cleanup (ITS#9993) Fixed slapd-mdb online indexer when interrupted (ITS#10047) Fixed slapd-monitor connection cleanup (ITS#10042) Fixed slapo-constraint handling of push replication (ITS#9953) Fixed slapo-dynlist filter evaluation efficiency (ITS#10041) Fixed slapo-pcache handling of invalid schema (ITS#10032) Fixed slapo-ppolicy handling of push replication (ITS#9953) Fixed slapo-ppolicy handling of pwdMinDelay (ITS#10028) Fixed slapo-syncprov abandon handling (ITS#10016) Fixed slapo-translucent handling of invalid schema (ITS#10032) Fixed slapo-unique handling of push replication (ITS#9953) Fixed slapo-variant to improve regex handling (ITS#10048) Build Environment Fixed compatibility with stricter C99 compilers (ITS#10011) Keep .pc files during make clean (ITS#9989) Contrib Fixed slapo-variant handling of push replication (ITS#9953) Minor Cleanup ITS#9855 ITS#9995 ITS#9996 ITS#9997 ITS#9998 ITS#9999 ITS#10000 ITS#10003 ITS#10004 ITS#10033 ITS#10037 ITS#10039 ITS#10046 Regards, Quanah

2 1

problem, and solution | database monitor
by cYuSeDfZfb cYuSeDfZfb 26 Jun '23

26 Jun '23

Hi, I'm posting this mostly for the archives, so that a search for the error below will help a next person. Today I wanted to setup the cn=Monitor backend, and after doing so, openldap failed to start with: backend_startup_one (type=monitor, suffix="cn=Monitor"): bi_db_open failed! (-1) The reason turned out to be: we had configured one of our databases ("database ldap") without a suffix. After I added a suffix, openldap started, and cn=Monitor worked as expected. I added a simple placeholder suffix (o=ldap,c=com) and now I need to find out what the database ldap was actually used for in our setup, and what the proper suffix should be. (does anyone perhaps know what openldap used as a default, if a "database ldap" suffix is omitted from the config?) Anyway: Hopefully this post will help a future someone with the same error message, as the error message had little to do the the cause.

2 1

slapacl issue
by Carsten Jäckel 26 Jun '23

26 Jun '23

Dear experts, in a testing environment (SLES 15 SP5, OpenLDAP 2.5.14) I use the following ACLs in olcAccess: {0}to dn.exact="cn=test,ou=users,dc=foo,dc=bar" by dn.exact="cn=test,ou=users,dc=foo,dc=bar" peername.ip="10.10.10.10" write by * none {1}to * by group.exact="cn=Admins,ou=groups,dc=foo,dc=bar" manage by * none break {2}to * by self read by anonymous auth by * none break If I run ldapmodify -xWD "cn=test,ou=users,dc=foo,dc=bar" to change the account cn=test,ou=users,dc=foo,dc=bar on the system with ip 10.10.10.10 everything works as expected. LDAP-Log: 2023-06-16T12:53:12.024030+02:00 tst1 slapd[1333]: conn=1016 fd=28 ACCEPT from IP=10.10.10.10:53558 (IP=0.0.0.0:636) 2023-06-16T12:53:12.039643+02:00 tst1 slapd[1333]: conn=1016 fd=28 TLS established tls_ssf=128 ssf=128 tls_proto=TLSv1.3 tls_cipher=TLS_AES_128_GCM_SHA256 2023-06-16T12:53:12.039773+02:00 tst1 slapd[1333]: conn=1016 op=0 BIND dn="cn=test,ou=users,dc=foo,dc=bar" method=128 2023-06-16T12:53:12.039841+02:00 tst1 slapd[1333]: conn=1016 op=0 BIND dn="cn=test,ou=users,dc=foo,dc=bar" mech=SIMPLE bind_ssf=0 ssf=128 2023-06-16T12:53:12.041918+02:00 tst1 slapd[1333]: conn=1016 op=0 RESULT tag=97 err=0 qtime=0.000014 etime=0.002242 text= 2023-06-16T12:53:30.488074+02:00 tst1 slapd[1333]: conn=1016 op=1 MOD dn="cn=test,ou=users,dc=foo,dc=bar" 2023-06-16T12:53:30.488474+02:00 tst1 slapd[1333]: conn=1016 op=1 MOD attr=description 2023-06-16T12:53:30.557458+02:00 tst1 slapd[1333]: conn=1016 op=1 RESULT tag=103 err=0 qtime=0.000022 etime=0.069664 text= 2023-06-16T12:53:33.035486+02:00 tst1 slapd[1333]: conn=1016 fd=28 closed (connection lost) Running the above command from another machine results in a Insufficient access (50) error as also expected. So I assume the ACLs to be working correctly. If I run slapacl -F /etc/symas/etc/openldap/slapd.d -o peername=10.10.10.10 -D cn=test,ou=users,dc=foo,dc=bar -b cn=test,ou=users,dc=foo,dc=bar on the system with ip 10.10.10.10 I get the following output: PROXIED attributeDescription "OU" inserted. PROXIED attributeDescription "DC" inserted. authcDN: "cn=test,ou=users,dc=foo,dc=bar" entry: none(=0) children: none(=0) description=test: none(=0) cn=test: none(=0) sn=test: none(=0) objectClass=person: none(=0) objectClass=top: none(=0) structuralObjectClass=person: none(=0) entryUUID=2304877c-4aed-103d-8c25-b91c1e3518c8: none(=0) creatorsName=cn=manager,dc=foo,dc=bar: none(=0) createTimestamp=20230227131940Z: none(=0) userPassword=****: none(=0) pwdChangedTime=20230227131959Z: none(=0) authTimestamp=20230616065542Z: none(=0) pwdLastSuccess=20230616103806Z: none(=0) entryCSN=20230616103806.257186Z#000000#000#000000: none(=0) modifiersName=cn=test,ou=users,dc=foo,dc=bar: none(=0) modifyTimestamp=20230616103806Z: none(=0) I expected to see write access in slapacl's output. If I remove the 'peername.ip="10.10.10.10"' part from olcAccess {0}to dn.exact="cn=test,ou=users,dc=foo,dc=bar" by dn.exact="cn=test,ou=users,dc=foo,dc=bar" peername.ip="10.10.10.10" write by * none the above slapacl command outputs write access correctly no matter if the parameter '-o peername=10.10.10.10' is set or not. olcAccess: {0}to dn.exact="cn=test,ou=users,dc=foo,dc=bar" by dn.exact="cn=test,ou=users,dc=foo,dc=bar" write by * none {1}to * by group.exact="cn=Admins,ou=groups,dc=foo,dc=bar" manage by * none break {2}to * by self read by anonymous auth by * none break slapacl -F /etc/symas/etc/openldap/slapd.d -o peername=10.10.10.10 -D cn=test,ou=users,dc=foo,dc=bar -b cn=test,ou=users,dc=foo,dc=bar PROXIED attributeDescription "OU" inserted. PROXIED attributeDescription "DC" inserted. authcDN: "cn=test,ou=users,dc=foo,dc=bar" entry: write(=wrscxd) children: write(=wrscxd) description=first test cn=test: write(=wrscxd) sn=test: write(=wrscxd) objectClass=person: write(=wrscxd) objectClass=top: write(=wrscxd) structuralObjectClass=person: write(=wrscxd) entryUUID=2304877c-4aed-103d-8c25-b91c1e3518c8: write(=wrscxd) creatorsName=cn=manager,dc=foo,dc=bar: write(=wrscxd) createTimestamp=20230227131940Z: write(=wrscxd) userPassword=****: write(=wrscxd) pwdChangedTime=20230227131959Z: write(=wrscxd) authTimestamp=20230616065542Z: write(=wrscxd) pwdLastSuccess=20230616105312Z: write(=wrscxd) entryCSN=20230616105330.487886Z#000000#000#000000: write(=wrscxd) modifiersName=cn=test,ou=users,dc=foo,dc=bar: write(=wrscxd) modifyTimestamp=20230616105330Z: write(=wrscxd) Am I doing something wrong? Any help is appreciated. Thanks, Carsten

2 1

Re: What drives CPU usage spikes?
by Erik de Waard 26 Jun '23

26 Jun '23

I see this on our consumers when waiting on writes to be accepted by the provider/ or when it's unreachable.

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical