Re: libldap with openssl
Hello, Le 10/01/2024 à 20:57, Quanah Gibson-Mount a écrit : --On Wednesday, January 10, 2024 4:38 PM -0300 dextá wrote: Quanah, Regarding ltb, which package contains libldap? Ok looks like LTB project doesn't separate it out. No, indeed, the libs are included in the main package : openldap-ltb Regards, and Symas? https://repo.symas.com/repo/deb/main/release25/pool/main/s/symas-openldap/ Pretty apparent: symas-openldap-lib --Quanah -- David Coutadeur | IAM integrator david.coutad...@worteks.com +33 7 88 46 85 34 16 avenue Hoche, Paris 75008 Worteks | https://www.worteks.com
Re: dynlist vs memberof performance issues
Hello, Le 26/07/2022 à 00:04, Howard Chu a écrit : David Coutadeur wrote: Hello, I have worked with Soisik on this particular topic. As you mentionned, in many cases we can just query directly the group. In our particular scenario, the software only allows one request for getting the mails of the users present in the dynamic group. Have you already tried using the deref control to return a mail attribute instead? Thanks for the idea. I suppose it could work indeed. I have not tested it yet, but it could be interresting to have the performance associated to such request. However, in my specific use case, it is not possible to configure a LDAP control in the software. Thus I think it would be great to have a server solution (if possible in 2.6), especially if dynlist is officially the memberof replacement. Regards, David Le 25 juillet 2022 19:38:52 GMT+02:00, Shawn McKinney a écrit : On May 23, 2022, at 3:10 AM, Soisik Froger wrote: I've just sent you sample slapd.conf and a data ldif that illustrate the long query time on large database. Thank you very much to take a look at this ! Hi Soisik, I've completed a review/test of dynlist, following your excellent example as sent off list. Here are my findings… As a baseline, here’s an example of a 'normal' search across a well populated user tree: # time ldapsearch -x -LLL -H ldap://m01:389 -D "dc=example,dc=com" -W -s sub -b 'ou=people,dc=example,dc=com' "(cn=load01-TEST1-*)" | grep dn: | wc -l 17470 real0m0.191s user0m0.128s sys 0m0.132s Compared with performing a search of the memberof attribute, generated by dynast. This pulls back the members of a large group (about 25K members): # time ldapsearch -x -LLL -H ldap://m01:389 -D "dc=example,dc=com" -W -s sub -b 'ou=people,dc=example,dc=com' "(memberof=cn=load01-test1-2,ou=groups,dc=example,dc=com)" | grep dn: | wc -l 23869 real4m6.167s user0m2.289s sys 0m2.037s That's 4 minutes to search across 100K users. The other search took < 200 ms. As you (and others) have pointed out, there's a significant performance penalty for searching attributes generated by dylist. It's possible that we can get modest improvements within a 2.7 timeframe. Unfortunately, we don't anticipate being able to get it back into range of a 'normal' search. So, that gets us into looking at mitigation. One approach, focus on what the client does. For example, instead of searching across the user tree for membership to a particular group, it's far more efficient to just pull back that list from the group entry itself. This is a technique that of course we’re already familiar with. I bring it up here for the sake of argument. The question: can we sidestep the memberOf performance problems by focusing on the the client? Or, is there a usecase that I've missed for which there's no remedy? Thanks — Shawn -- David Coutadeur | IAM integrator david.coutad...@worteks.com +33 7 88 46 85 34 137 boulevard de Magenta, Paris 75010 Worteks | https://www.worteks.com
Re: dynlist vs memberof performance issues
Hello, I have worked with Soisik on this particular topic. As you mentionned, in many cases we can just query directly the group. In our particular scenario, the software only allows one request for getting the mails of the users present in the dynamic group. Thus I think it would be great to have a server solution (if possible in 2.6), especially if dynlist is officially the memberof replacement. Regards, David Le 25 juillet 2022 19:38:52 GMT+02:00, Shawn McKinney a écrit : > >> On May 23, 2022, at 3:10 AM, Soisik Froger wrote: >> >> I've just sent you sample slapd.conf and a data ldif that illustrate the >> long query time on large database. Thank you very much to take a look at >> this ! > >Hi Soisik, > >I've completed a review/test of dynlist, following your excellent example as >sent off list. > >Here are my findings… > >As a baseline, here’s an example of a 'normal' search across a well populated >user tree: > ># time ldapsearch -x -LLL -H ldap://m01:389 -D "dc=example,dc=com" -W -s sub >-b 'ou=people,dc=example,dc=com' "(cn=load01-TEST1-*)" | grep dn: | wc -l >17470 > >real0m0.191s >user0m0.128s >sys 0m0.132s > >Compared with performing a search of the memberof attribute, generated by >dynast. This pulls back the members of a large group (about 25K members): ># time ldapsearch -x -LLL -H ldap://m01:389 -D "dc=example,dc=com" -W -s sub >-b 'ou=people,dc=example,dc=com' >"(memberof=cn=load01-test1-2,ou=groups,dc=example,dc=com)" | grep dn: | wc -l >23869 >real4m6.167s >user0m2.289s >sys 0m2.037s > >That's 4 minutes to search across 100K users. The other search took < 200 ms. > >As you (and others) have pointed out, there's a significant performance >penalty for searching attributes generated by dylist. > >It's possible that we can get modest improvements within a 2.7 timeframe. >Unfortunately, we don't anticipate being able to get it back into range of a >'normal' search. > >So, that gets us into looking at mitigation. One approach, focus on what the >client does. For example, instead of searching across the user tree for >membership to a particular group, it's far more efficient to just pull back >that list from the group entry itself. > >This is a technique that of course we’re already familiar with. I bring it up >here for the sake of argument. > >The question: can we sidestep the memberOf performance problems by focusing on >the the client? > >Or, is there a usecase that I've missed for which there's no remedy? > >Thanks > >— >Shawn
Re: SASL Authentication Pass-through
Le 19/04/2022 à 17:53, Quanah Gibson-Mount a écrit : --On Tuesday, April 19, 2022 4:32 PM +0200 David Coutadeur wrote: Hello, I confirm remoteauth is a good alternative to sasl delegation, but is there a way to configure timeouts in the overlay? Hi David, Not exactly sure what timeouts you are needing. Can you expand on exactly what the issue is you're encountering? It would likely be a feature request issue ticket. Hi Quanah, For example, if I define a remoteauth_mapping with a file containing a list of hostnames, the first one is checked first. After "remoteauth_retry_count" * "connect_timeout" seconds, (210s on my system), remoteauth test the second server in the list. In some circumstances, it could be nice to set the connect timeout lower (or higher). Regards, David Regards, Quanah
Re: SASL Authentication Pass-through
Hello, I confirm remoteauth is a good alternative to sasl delegation, but is there a way to configure timeouts in the overlay? Regards, David Le 11/04/2022 à 20:36, Quanah Gibson-Mount a écrit : --On Monday, April 11, 2022 7:23 PM + Dean Lewis wrote: If I had a choice, I wouldn't be using this version at all. As with most packages, I'd run the very latest. But I don't have a choice here so this question is about getting pass-through auth working with OpenLDAP 2.4 and AD. If that's possible, what am I missing in the configuration? No idea. Remoteauth was written because of a number of issues around using SASL passthrough. If your OpenLDAP servers are running RedHat (or derivatives), Debian, or Ubuntu, there are freely available options that allow you to be using current releases of OpenLDAP, such as the LTB project and the builds from Symas. Regards, Quanah -- David Coutadeur | IAM integrator david.coutad...@worteks.com +33 7 88 46 85 34 137 boulevard de Magenta, Paris 75010 Worteks | https://www.worteks.com
Re: RE25 Testing call #1 (OpenLDAP 2.5.12)
Hi, No compilation or running issue of OpenLDAP 2.5.12 for these distributions: - debian 10 - debian 11 - ubuntu 20 - centos 7 Regards, David Le 22/03/2022 à 18:18, Quanah Gibson-Mount a écrit : This is the first testing call for OpenLDAP 2.5.12. Depending on the results, this may be the only testing call. Generally, get the code for RE25: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_5/openldap-OPENLDAP_REL_ENG_2_5.tar.gz> 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.12 Engineering Fixed libldap to drop connection when non-LDAP data is received (ITS#9803) Fixed libldap to allow newlines at end of included file (ITS#9811) Fixed slapd slaptest conversion of olcLastBind (ITS#9808) Fixed slapd usage of thread local counters (ITS#9789) Fixed slapd to clear runqueue task correctly (ITS#9785) Fixed slapd bconfig locking for cn=config replication (ITS#9584) Fixed slapd syncrepl handling of new sessions (ITS#9584) Fixed slapd to clear connections on bind (ITS#9799) Fixed slapd syncrepl ODSEE replication of unknown attr (ITS#9801) Fixed slapd-asyncmeta memory leak in keepalive setting (ITS#9802) Fixed slapd-ldap memory leak in keepalive setting (ITS#9802) Fixed slapd-meta SEGV on config rewrite (ITS#9802) Fixed slapd-meta ordering on config rewrite (ITS#9802) Fixed slapd-meta memory leak in keepalive setting (ITS#9802) Fixed slapd-monitor SEGV on shutdown (ITS#9809) Fixed slapo-pcache SEGV on shutdown (ITS#9809) Fixed slapo-ppolicy operation handling to be consistent (ITS#9794) Build Environment Fix compilation with openssl exclusions (ITS#9791) Fix warnings from make jobserver (ITS#9788) Fix compiliation with certain versions of gcc (ITS#9790) Documentation Fixed slapd.conf(5)/slapd-config(5) syncrepl sizelimit/timelimit documentation (ITS#9804) Regards, Quanah -- David Coutadeur | IAM integrator david.coutad...@worteks.com +33 7 88 46 85 34 137 boulevard de Magenta, Paris 75010 Worteks | https://www.worteks.com
Re: RE26 testing call #1 (OpenLDAP 2.6.2)
Hi, No compilation or running issue of OpenLDAP 2.6.2 for on these distributions: - debian 10 - debian 11 - ubuntu 20 - centos 7 Regards, David Le 22/03/2022 à 18:21, Quanah Gibson-Mount a écrit : This is the first testing call for OpenLDAP 2.6.2. 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/openldap-OPENLDAP_REL_ENG_2_6.tar.gz> 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.2 Engineering Added libldap support for OpenSSL 3.0 (ITS#9436) Added slapd support for OpenSSL 3.0 (ITS#9436) Fixed ldapdelete to prune LDAP subentries (ITS#9737) Fixed libldap to drop connection when non-LDAP data is received (ITS#9803) Fixed libldap to allow newlines at end of included file (ITS#9811) Fixed slapd slaptest conversion of olcLastBind (ITS#9808) Fixed slapd to correctly init global_host earlier (ITS#9787) Fixed slapd bconfig locking for cn=config replication (ITS#9584) Fixed slapd usage of thread local counters (ITS#9789) Fixed slapd to clear runqueue task correctly (ITS#9785) Fixed slapd syncrepl handling of new sessions (ITS#9584) Fixed slapd to clear connections on bind (ITS#9799) Fixed slapd syncrepl ODSEE replication of unknown attr (ITS#9801) Fixed slapd-asyncmeta memory leak in keepalive setting (ITS#9802) Fixed slapd-ldap memory leak in keepalive setting (ITS#9802) Fixed slapd-meta SEGV on config rewrite (ITS#9802) Fixed slapd-meta ordering on config rewrite (ITS#9802) Fixed slapd-meta memory leak in keepalive setting (ITS#9802) Fixed slapd-monitor SEGV on shutdown (ITS#9809) Added slapo-autoca support for OpenSSL 3.0 (ITS#9436) Added slapo-otp support for OpenSSL 3.0 (ITS#9436) Fixed slapo-pcache SEGV on shutdown (ITS#9809) Fixed slapo-ppolicy operation handling to be consistent (ITS#9794) Build Enviornment Add ability to override default compile time paths (ITS#9675) Fix compiliation with certain versions of gcc (ITS#9790) Fix compilation with openssl exclusions (ITS#9791) Fix warnings from make jobserver (ITS#9788) Documentation admin26 Document new lloadd features (ITS#9780) Fixed slapd.conf(5)/slapd-config(5) syncrepl sizelimit/timelimit documentation (ITS#9804) Fixed slapd-sock(5) to clarify "sockresps result" behavior (ITS#8255) Regards, Quanah -- David Coutadeur | IAM integrator david.coutad...@worteks.com +33 7 88 46 85 34 137 boulevard de Magenta, Paris 75010 Worteks | https://www.worteks.com
Re: openldap-ltb segmentation fault
Hello Aaron, I suggested by Quanah, if you think there is a bug, you can open an issue here: https://github.com/ltb-project/openldap-rpm/issues Anyway, my guess is that somehow there is a difference between the command line launched manually and the one launched by slapd-cli. Can you reproduce the error with a fresh OpenLDAP LTB installation? Regards, David Le 28/03/2022 à 22:18, Aaron Bennett a écrit : Hi, I've got a new openldlap-ltb 2.5 system (running on rocky 8), and when I try to start it with "slapt-cli start", it dumps core: [root@kt-ldap-01 slapd.d]$ journalctl -xe Mar 28 16:13:06 kt-ldap-01 systemd-coredump[54716]: Resource limits disable core dumping for process 54714 (slapd). Mar 28 16:13:06 kt-ldap-01 systemd-coredump[54716]: Process 54714 (slapd) of user 0 dumped core. -- Subject: Process 54714 (slapd) dumped core -- Defined-By: systemd -- Support:https://access.redhat.com/support -- Documentation: man:core(5) -- -- Process 54714 (slapd) crashed and dumped core. -- -- This usually indicates a programming error in the crashing program and -- should be reported to its vendor as a bug. Mar 28 16:13:06 kt-ldap-01 slapd-cli[54688]: /usr/local/openldap/sbin/slapd-cli: line 350: 54714 Segmentation fault (core dumped) $SLA> Mar 28 16:13:06 kt-ldap-01 systemd[1]: systemd-coredump@13-54715-0.service: Succeeded. -- Subject: Unit succeeded -- Defined-By: systemd -- Support: https://access.redhat.com/support From debugging the shell script it looks like it's running slapd with these arguments: SLAPD_PARAMS='-h ldaps://kt-ldap-01-665.test.clarku.edu -F /usr/local/openldap/etc/openldap/slapd.d -u ldap -g ldap -l local4' So if I run: /usr/local/openldap/libexec/slapd -h ldaps://kt-ldap-01-665.test.clarku.edu -F /usr/local/openldap/etc/openldap/slapd.d -u ldap -g ldap -l local4 It works -- no segfault, no nothing. I can pretty easily write a systemd script that runs that command instead of wasting time with the slapd-cli stuff if that's a better approach. -Aaron --- Aaron Bennett Manager of Systems Administration Clark University ITS -- David Coutadeur | IAM integrator david.coutad...@worteks.com +33 7 88 46 85 34 137 boulevard de Magenta, Paris 75010 Worteks | https://www.worteks.com
Re: [EXT] Re: migrate from RedHat openldap 2.4 to LTB OpenLdap 2.5
Hello,
You need to remove the content of the entry "dn: cn=schema,cn=config",
exept the objectClass and cn attributes.
The cn=schema,cn=config entry should look like this:
dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema
You must not remove the other schemas under this entry. (except the
ppolicy schema)
Regards,
David
Le 15/03/2022 à 18:19, Aaron Bennett a écrit :
-Original Message-----
From: David Coutadeur
Sent: Thursday, March 10, 2022 3:45 PM
To: Aaron Bennett ; openldap-technical@openldap.org
Subject: [EXT] Re: migrate from RedHat openldap 2.4 to LTB OpenLdap 2.5
If you are using LTB package, you can also give a look at:
https://ltb-project.org/documentation/migrate_openldap_ltb_24_openldap_ltb_25.html
Hi David,
Can you expand on " Remove built-in schema definition in cn=schema,cn=config
entry" ?
If I remove the cn=schema,cn=config information, then the next section, "dn:
cn={0}core,cn=schema,cn=config" errors on import. I need for sure inetorgperson,
nis, eduPerson, samba. What am I missing here?
Best,
Aaron
Re: migrate from RedHat openldap 2.4 to LTB OpenLdap 2.5
Hello,
If you are using LTB package, you can also give a look at:
https://ltb-project.org/documentation/migrate_openldap_ltb_24_openldap_ltb_25.html
Regards,
David
Le 10/03/2022 à 19:06, Aaron Bennett a écrit :
Hi,
I'm moving from a two-node CentOS 7 cluster running essentially the RedHat
openldap-servers build (which I rebuild to use OpenSSL, but otherwise, left
alone).
I've provisioned a new Rocky Linux 8 system and have installed OpenLDAP 2.5
from the LTB repository, and have moved the old slapd.d directory out of the
way and put the slapd.d directory from the old servers in place. If I try to
run slapd-cli status, it throws this:
olcAttributeTypes: value #8 olcAttributeTypes: Inconsistent duplicate attributeType:
"pwdMustChange"
config error processing cn={5}samba,cn=schema,cn=config: olcAttributeTypes: Inconsistent
duplicate attributeType: "pwdMustChange"
slapcat: bad configuration directory!
olcAttributeTypes: value #8 olcAttributeTypes: Inconsistent duplicate attributeType:
"pwdMustChange"
config error processing cn={5}samba,cn=schema,cn=config: olcAttributeTypes: Inconsistent
duplicate attributeType: "pwdMustChange"
slapcat: bad configuration directory!
Looking here:
https://ltb-project.org/documentation/migrate_openldap_ltb_24_openldap_ltb_25.html,
it looks like there's more going on. Does anyone have any input as to how to
accomplish this? I do need to bring the old data in, ideally without having to
make changes to the samba scheme under the hood.
Best,
Aaron
---
Aaron Bennett
Manager of Systems Administration
Clark University ITS
Re: log analysis tools
Hello, For information, I have opened a pull request against the historical upstream repository: https://github.com/Matty9191/misc-shell-scripts/pull/4 Yet it seems there is not much activity on this repository, as there are two pull requests opened since 3 or 4 years. > Yes. There is a substantial amount of information logged in 2.5 that is not logged in 2.4. Quanah, could you give some documentation or any pointer regarding the evolution of the log format? Regards, David Le 21/02/2022 à 22:53, Quanah Gibson-Mount a écrit : --On Monday, February 21, 2022 7:03 PM +0100 David Coutadeur wrote: For information, I have contributed patch for the ldap-stats provided by LDAP Toolbox: I would suggest opening the pull request against the canonical upstream source of the script rather than the fork from ldap toolbox. Regards, Quanah
Re: log analysis tools
Hi, Le 21/02/2022 à 15:43, David Coutadeur a écrit : Hello, Le 06/02/2022 à 14:19, Clément OUDOT a écrit : Le sam. 5 févr. 2022 à 20:57, Quanah Gibson-Mount a écrit : --On Friday, February 4, 2022 10:12 PM -0500 Dave Macias wrote: > > > https://www.ltb-project.org/documentation/ldap-stats.html Is that the one I used to help maintain? I don't believe it's been updated for 2.5 and later, unless it was forked and someone else has started working on it. Hello Quanah, this is indeed a fork done inside LTB project, there was no git repo for this script (or I did not found it). Of course if there are changes in 2.5 log format, we can update the script. It does not seem there are much changes in log format in 2.5, am I wrong? I have basically tested the ldap-stats script and it behaves correctly. Of course with 2.6 that's a whole different ballgame. For information, I have contributed patch for the ldap-stats provided by LDAP Toolbox: https://github.com/ltb-project/ldap-scripts There is a new option (--log26) for enabling compatibility with the new openLDAP 2.6 log format. Feel free to use it and submit your remarks. Regards, David Clément. David -- David Coutadeur | IAM integrator david.coutad...@worteks.com +33 7 88 46 85 34 137 boulevard de Magenta, Paris 75010 Worteks |https://www.worteks.com
Re: log analysis tools
Hello, Le 06/02/2022 à 14:19, Clément OUDOT a écrit : Le sam. 5 févr. 2022 à 20:57, Quanah Gibson-Mount a écrit : --On Friday, February 4, 2022 10:12 PM -0500 Dave Macias wrote: > > > https://www.ltb-project.org/documentation/ldap-stats.html Is that the one I used to help maintain? I don't believe it's been updated for 2.5 and later, unless it was forked and someone else has started working on it. Hello Quanah, this is indeed a fork done inside LTB project, there was no git repo for this script (or I did not found it). Of course if there are changes in 2.5 log format, we can update the script. It does not seem there are much changes in log format in 2.5, am I wrong? I have basically tested the ldap-stats script and it behaves correctly. Of course with 2.6 that's a whole different ballgame. Clément. David
Re: log analysis tools
Hello, Le 06/02/2022 à 03:14, Paul B. Henson a écrit : On Fri, Feb 04, 2022 at 10:12:40PM -0500, Dave Macias wrote: https://www.ltb-project.org/documentation/ldap-stats.html Thanks for the pointer. There doesn't seem to be any way to download just the script? You have to get their whole tool package? I don't really want to add a repo just for this, I tried the manual download option on their page for CentoOS 8: https://www.ltb-project.org/download.html https://www.ltb-project.org/archives/openldap-ltb-2.5.11-el8.tar.gz But the second link just takes me to: https://www.ltb-project.org/ For information, there was indeed a broken link on LTB website. It is now fixed. Anyway, the scripts are not provided in the global OpenLDAP package archive. You can get them in the github repository here : https://github.com/ltb-project/ldap-scripts (and as mentionned by Quanah before, you can read the documentation here: https://www.ltb-project.org/documentation/index.html) Regards, David Meh. I'm really looking for query times too, which it doesn't seem to provide. I set up a test script which does a memberOf query every 5 minutes to alert me when they start taking 30+ seconds. Most of the time they're subsecond, but every now and again the exact same query takes 5-20 seconds, just here and there. Odd. At least the occasional slow query is better than continuous slow queries.
Re: Need to define behaviour when storing pwdChangedTime
Hi, For information, I have made a proposition in an issue here: https://bugs.openldap.org/show_bug.cgi?id=9794 Feel free to comment or propose other ideas. Regards, David Le 12/01/2022 à 17:45, Ondřej Kuzník a écrit : On Wed, Jan 12, 2022 at 05:28:32PM +0100, Michael Ströder wrote: On 1/12/22 10:35, David Coutadeur wrote: I suppose an admin changing the pwdChangedTime of an entry with the relax rule is a valid use case. This is IMO indeed a tricky one: I find arguments for the current behaviour but also for accepting submitted pwdChangedTime value in case relax rules control is used. Modify requests seem to support this, gating it on ACL (password administrator role) + Relax control. One could argue that the distinction between the two use-cases "admin restores userPassword/pwdChangedTime" and "admin sets new userPassword" can be deferred to ACL validation. The admin must have manage privilege on pwdChangedTime for the restore to succeed. Those two would be distinguished by providing the new pwdChangedTime value in the Add? From that perspective it might make sense to support this in Adds as we do in Modifies. Haven't thought about it too much yet. If you achieve consensus that the existing situation should change, please file an ITS addressing the above concerns and argue what Behera the draft intended. AFAIK you should already be able to add the user and then set userPassword+pwdChangedTime if you have the rights. Regards, -- David Coutadeur | IAM integrator david.coutad...@worteks.com +33 7 88 46 85 34 137 boulevard de Magenta, Paris 75010 Worteks | https://www.worteks.com
Re: Need to define behaviour when storing pwdChangedTime
Hello, Le 11/01/2022 à 16:27, Howard Chu a écrit : David Coutadeur wrote: Hi, When doing a backup / restore on my OpenLDAP 2.5.9 instance, I faced a behaviour that I think must be defined explicitely, in draft-behera-ldap-password-policy, or at least in OpenLDAP documentation. My backup contains an entry like this: dn: uid=test,ou=people,ou=branch,dc=example,dc=com cn: test sn: test givenName: test uid: test userPassword: secret pwdChangedTime: 20220110153431Z mail: t...@domain.com objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person There is also a valid default password policy: (which must be defined before the users in the backup file) dn: cn=default,ou=ppolicies,dc=example,dc=com objectClass: pwdPolicy objectClass: pwdPolicyChecker objectClass: organizationalRole cn: default pwdMaxAge: 7776000 pwdAttribute: userPassword pwdCheckQuality: 2 pwdLockout: TRUE pwdMaxFailure: 5 pwdMinLength: 6 pwdMustChange: TRUE pwdCheckModule: /usr/local/openldap/lib64/ppm.so When restoring the backup with this command: ldapadd -x -h '127.0.0.1:389' -D 'cn=Manager,dc=example,dc=com' -w 'secret' -f backup.ldif -e relax I have an error showing that the attribute pwdChangedTime is duplicated and must not be defined twice. Backups should be restored with slapadd. Or you should strip all operational attributes when using ldapadd. As you can see in the entry above, there is no operational attributes except pwdChangedTime. I need to include pwdChangedTime, else the password won't expire at the desired date. I assume that the password policy does not replace my pwdChangedTime value with the current date, but duplicates the attribute. The ppolicy overlay sets the attribute to the current time if you have an aging policy defined. Probably it should check that pwdChangedTime does not already exist, but it is not expected for normal users to be LDAPadding entries with this operational attribute included. I suppose an admin changing the pwdChangedTime of an entry with the relax rule is a valid use case. Thus, if it is a valid use case, we should be able to combine it with other operations, like changing the userPassword. So we should define the behaviour in such case. I agree with your suggestion: it seems more interresting for the given pwdChangedTime to take precedence over the one computed by the password policy. If it is ok for you, I can create an issue. Could you define this behaviour somewhere? 1/ Is it possible to update the pwdChangedTime attribute along with the userPassword ? 2/ If so, what value should be stored? (the given value or the current date?) 3/ Optionally, update OpenLDAP code according to the defined behaviour Thanks in advance for your answer. Regards, David -- David Coutadeur | IAM integrator david.coutad...@worteks.com +33 7 88 46 85 34 137 boulevard de Magenta, Paris 75010 Worteks | https://www.worteks.com
Need to define behaviour when storing pwdChangedTime
Hi, When doing a backup / restore on my OpenLDAP 2.5.9 instance, I faced a behaviour that I think must be defined explicitely, in draft-behera-ldap-password-policy, or at least in OpenLDAP documentation. My backup contains an entry like this: dn: uid=test,ou=people,ou=branch,dc=example,dc=com cn: test sn: test givenName: test uid: test userPassword: secret pwdChangedTime: 20220110153431Z mail: t...@domain.com objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person There is also a valid default password policy: (which must be defined before the users in the backup file) dn: cn=default,ou=ppolicies,dc=example,dc=com objectClass: pwdPolicy objectClass: pwdPolicyChecker objectClass: organizationalRole cn: default pwdMaxAge: 7776000 pwdAttribute: userPassword pwdCheckQuality: 2 pwdLockout: TRUE pwdMaxFailure: 5 pwdMinLength: 6 pwdMustChange: TRUE pwdCheckModule: /usr/local/openldap/lib64/ppm.so When restoring the backup with this command: ldapadd -x -h '127.0.0.1:389' -D 'cn=Manager,dc=example,dc=com' -w 'secret' -f backup.ldif -e relax I have an error showing that the attribute pwdChangedTime is duplicated and must not be defined twice. I assume that the password policy does not replace my pwdChangedTime value with the current date, but duplicates the attribute. Could you define this behaviour somewhere? 1/ Is it possible to update the pwdChangedTime attribute along with the userPassword ? 2/ If so, what value should be stored? (the given value or the current date?) 3/ Optionally, update OpenLDAP code according to the defined behaviour Thanks in advance for your answer. Regards, David
logfile-rotate directive fails in 2.6.0
Hello, Not sure this is a configuration problem or a bug, but when setting the logfile-rotate, I get: 617bc9ae.1b73de17 0x7f44f87c9740 /usr/local/openldap/etc/openldap/slapd.conf: line 12 (logfile-rotate 10 100 24) 617bc9ae.1b759154 0x7f44f87c9740 /usr/local/openldap/etc/openldap/slapd.conf: line 12: handler exited with 16384! My configuration file is below. I am using the 2.6.0 release. The strange part is that the same configuration converted into cn=config seems to work well. Regards, David # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/local/openldap/etc/openldap/schema/core.schema include /usr/local/openldap/etc/openldap/schema/cosine.schema include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema include /usr/local/openldap/etc/openldap/schema/dyngroup.schema logfile-rotate 10 100 24 logfile /var/log/slapd-ltb/slapd.log logLevel 256 sasl-host ldap.my-domain.com pidfile /usr/local/openldap/var/run/slapd.pid argsfile /usr/local/openldap/var/run/slapd.args # Load dynamic backend modules: # moduleload back_ldap.la modulepath /usr/local/openldap/libexec/openldap moduleload argon2.la moduleload back_mdb.la moduleload dynlist.la moduleload memberof.la moduleload ppolicy.la moduleload syncprov.la moduleload unique.la access to dn.base="" by * read access to dn.base="cn=subschema" by * read ### # config database definitions ### database config rootdn cn=config rootpw secret access to attrs="userPassword" by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth =wdx by * auth access to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage ### # MDB database definitions ### database mdb maxsize 4294967296 suffix dc=my-domain,dc=com rootdn cn=Manager,dc=my-domain,dc=com rootpw secret directory /usr/local/openldap/var/openldap-data index objectClass eq index cn eq,sub index uid pres,eq index givenName pres,eq,sub index l pres,eq index employeeType pres,eq index mail pres,eq,sub index sn pres,eq,sub limits group="cn=admin,ou=groups,dc=my-domain,dc=com" size=unlimited time=unlimited access to attrs="userPassword" by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth =wdx by group.exact="cn=admin,ou=groups,dc=my-domain,dc=com" =wdx by self =wdx by * auth access to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by group.exact="cn=admin,ou=groups,dc=my-domain,dc=com" write by users read
Checking synchronization status into cn=monitor in OpenLDAP 2.5
Hi, I am trying to get the synchronization status of a given consumer for each of his declared provider. Synchronization status = Is this provider synchronized with the current consumer? (TRUE / FALSE) Currently, I can do that by comparing contextCSN stored into consumers and providers. I have noted that in OpenLDAP 2.5 there are new piece of information into cn=monitor: |dn: cn=Consumer 000,cn=Database 1,cn=Databases,cn=Monitor objectClass: olmSyncReplInstance structuralObjectClass: olmSyncReplInstance cn: Consumer 000 creatorsName: cn=monitor modifiersName: cn=monitor createTimestamp: 20210908075111Z modifyTimestamp: 20210908075111Z olmSRProviderURIList: ldap://localhost:3389 olmSRConnection: IP=127.0.0.1:40908 olmSRSyncPhase: Persist olmSRNextConnect: 010100Z olmSRLastConnect: 20210908075211Z olmSRLastContact: 20210908082522Z olmSRLastCookieRcvd: rid=000,csn=20210908082522.652290Z#00#000#00 olmSRLastCookieSent: rid=000,sid=000,csn=20210907161949.876119Z#00#000#000 000 entryDN: cn=Consumer 000,cn=Database 1,cn=Databases,cn=Monitor subschemaSubentry: cn=Subschema hasSubordinates: FALSE| 1/ I haven't found any documentation about these attributes in OpenLDAP manual. Is there something in progress ? 2/ if I understand correctly the meaning of olmSRLastCookieRcvd, it should be the best candidate for computing the synchronization status. However, this attribut is empty at OpenLDAP startup, so I can't really rely on it. Do anyone see other means to get the synchronization status? Regards, David
Re: Evolution of slapd 2.5 configuration over time ?
Le 26/08/2021 à 17:24, Howard Chu a écrit : David Coutadeur wrote: Hello, I have noticed a few changes in the cn=config configuration between openldap 2.5.1 and 2.5.7. The main things that have changed: - many modifications in the configuration schema (cn=schema,cn=config) - some modifications in the additional schemas (core, cosine,...) - a few modifications in the database and overlay entries (for example, olcDbMaxEntrySize, olcPPolicyDisableWrite, objectClass: olcMemberOf -> objectClass: olcMemberOfConfig) It means that, when upgrading OpenLDAP, the previous configuration may not be compatible with the new OpenLDAP version. False. Additions to the schema are always forward-compatible. Where we have renamed objectclasses, we have kept the old name as an alias. So old configs will continue to work. Considering this, I have 2 questions: 1/ Do you plan to continue having evolutions of the configuration schema? Whenever the need arises. 2/ If so, will the previous 2.5 configuration be compatible in the future? We will never break compatibility unless it is totally unavoidable. Ok, thanks for your answers!
Evolution of slapd 2.5 configuration over time ?
Hello, I have noticed a few changes in the cn=config configuration between openldap 2.5.1 and 2.5.7. The main things that have changed: - many modifications in the configuration schema (cn=schema,cn=config) - some modifications in the additional schemas (core, cosine,...) - a few modifications in the database and overlay entries (for example, olcDbMaxEntrySize, olcPPolicyDisableWrite, objectClass: olcMemberOf -> objectClass: olcMemberOfConfig) It means that, when upgrading OpenLDAP, the previous configuration may not be compatible with the new OpenLDAP version. Considering this, I have 2 questions: 1/ Do you plan to continue having evolutions of the configuration schema? 2/ If so, will the previous 2.5 configuration be compatible in the future? Regards, David
Re: OpenLDAP 2.5.5 PPA for Ubuntu 20.04 LTS
Hi, For information, the LDAP Toolbox Community is providing packages for OpenLDAP. For now, only 2.4.59 packages are available (see https://ltb-project.org/download), but we are about to release a 2.5.7 version. Regards, David Le 23/08/2021 à 14:15, Saša-Stjepan Bakša a écrit : Hi, Does anyone maintain PPA for OpenLDAP 2.5.5 PPA for Ubuntu 20.04 LTS? On the Symas page, there is a package only for 2.4.59+dfsg-1ppa~bionic1 and since Quanah recommends the latest version for using dynlist I am in a bit of a problem. I just can't find the proper deb package for Ubuntu. Well to be honest, there is one for the latest Ubuntu but that one is still under development and I can't use that in production. Switching to another distro? Well, after so many years using Ubuntu I am not fond of the idea of switching to another distro. Building it from scratch? Maybe, if I can create an Ubuntu building environment. Br, Saša-Stjepan Bakša
Re: password complexity controls and gecos
Hello, If you are using ppm, you can take advantage of the checkRDN feature. It will check if password contains parts of the RDN. However, you cannot check against one or multiple specific attributes, like gecos, unless this attribute is chosen to be the RDN. You can open an issue here, https://github.com/ltb-project/ppm/issues and we will check if this feature could be interresting. David Le 07/07/2021 à 22:01, kevin martin a écrit : using ppolicy and a Default User Policy, along with ppm, I achieve the ability to control password length, password history, and complexity in as much as I can regulate that users must include numbers/special characters/letters (upper and lower case). However, what I can't find a way to add to this is to have the gecos field be checked against the password being submitted during a change to verify that a users userid and/or first or last names aren't part of the password. Is this possible in openldap? --- Regards, Kevin Martin
Proposition of overlay explockout
Hello, I'd like to point out a new overlay that I wrote: https://github.com/davidcoutadeur/explockout The aim is to require the user to wait for an exponential time before he can authenticate again, after some failed authentications. The overlay is quite simple: it relies on ppolicy for adding pwdFailureTime attribute and compute the time the user has to wait. Maybe some of you can consider it useful. Please anyone feel free to give your opinion, comments or improvements. Also if OpenLDAP team is interested, I would be glad to have it incorporated in official OpenLDAP contrib modules. David
Re: empty reqmod attribute
Hi, Le 31/08/2018 à 19:39, Quanah Gibson-Mount a écrit : Hi David, I can get: reqMod:: bWFpbDo9IA== which decoded is: "mail: " Ok, so it seems to be normal if I understand well... I thought empty values could not exist, and thus the - syntax had to be chosen: attribute:<+|-|=|#> [ value] My recollection is that additional commit past 2.4.46 fixes an issue similar to what you are encountering, however. ;) Ok, I will give a look specifically to these new commits. I have already checked all 2.4.45 and 2.4.46 fixes, and no one is matching exactly what I face. Thanks again for your help! David --Quanah --On Friday, August 31, 2018 10:56 AM +0200 David Coutadeur wrote: Hi Quanah, Thanks for your quick answer! I'll give a look to 2.4.45 and 2.4.46 commits + the one you pointed out. Could you confirm or infirm my assumption that reqMod attributes should never be empty? For example this one is empty in my accesslog: reqMod: inetUserStatus:= Regards, David Le 30/08/2018 18:53, Quanah Gibson-Mount a écrit : --On Thursday, August 30, 2018 7:18 PM +0200 David Coutadeur wrote: Hi, I am experiencing a segfault on an OpenLDAP 2.4.44 instance. Hi David, The primary focus for the 2.4.46 release was to fix several issues with sync replication (standard and/or delta-sync). I'd strongly advise upgrading to that release. Unfortunately, there was one issue that was not caught until after the 2.4.46 release, so you will want to apply this commit to the source as well, prior to building: <https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h =cc24cf620470e600d31fd68f63decae82b9745f3> Warm regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com> -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: empty reqmod attribute
Hi Quanah, Thanks for your quick answer! I'll give a look to 2.4.45 and 2.4.46 commits + the one you pointed out. Could you confirm or infirm my assumption that reqMod attributes should never be empty? For example this one is empty in my accesslog: reqMod: inetUserStatus:= Regards, David Le 30/08/2018 18:53, Quanah Gibson-Mount a écrit : --On Thursday, August 30, 2018 7:18 PM +0200 David Coutadeur wrote: Hi, I am experiencing a segfault on an OpenLDAP 2.4.44 instance. Hi David, The primary focus for the 2.4.46 release was to fix several issues with sync replication (standard and/or delta-sync). I'd strongly advise upgrading to that release. Unfortunately, there was one issue that was not caught until after the 2.4.46 release, so you will want to apply this commit to the source as well, prior to building: <https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=cc24cf620470e600d31fd68f63decae82b9745f3> Warm regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
empty reqmod attribute
Hi, I am experiencing a segfault on an OpenLDAP 2.4.44 instance. The architecture is: - 2 OpenLDAP - multimaster mirrormode - delta-syncrepl The error seems to be in the syncrepl process, in a particular accesslog entry. When I give a look to the entry, I realize that some attributes in reqmod are empty, which seems strange because the value can't be empty in the directory. For example: reqMod: inetUserStatus:= Does anyone know if this behaviour is normal, and what is happening? Thanks in advance. David
Strange behaviors on OpenLDAP proxy
Hi community, I have implemented two "OpenLDAP mirror directories": ldaps://ldap1 and ldaps://ldap2 (version 2.4.44) and a LDAP proxy with back_ldap + overlay pcache (version 2.4.44). I am trying to understand behaviors on the LDAP proxy: 1 - I don't succeed to configure a failover switch between OpenLDAP backends. The proxy switches too quickly due to a network disconnection (for example, network stays unavailable during n second). I would be interested whether there is a way to better control the switch even after network failure, for example, adding LDAP new parameters in order to send 3 attempts before performing failover. 2 - After that, when the network is up again and the first directory "ldap1" is back, new requests with already established connection to ldap1 are directed again to directory "ldap1" Is it possible to make all the trafic stay on ldap2? Is there a way to close open connections to ldap1 directory when the proxy switches to the ldap2 directory? 3. Finally, Is there a way to switch to the second directory when queries are too slow in the first directory? Thanks in advance. David
Re: OPENLDAP UPGRADE
Hi John,
It seems that an application is already listening on standard port, 389
or 636 I guess...
Just find which application and turn it down, then restart your server
again.
Regards,
David
Le 18/12/2013 17:05, Borresen, John - 0442 - MITLL a écrit :
In the process of upgrading to 2.4.38 (was able to work with the LTB group to
resolve the repo issue there), created a slapd.conf, and converted to the
slapd.d format successfully. - this is initially on a test server. Most of
the slapd.conf was migrated over from the 2.4.23 configuration that is
currently in production.
When starting slapd, receiving the following (and slapd does not start):
# /usr/local/openldap/libexec/slapd -u ldap -d 1 -F
/usr/local/openldap/etc/openldap/slapd.d
52b1c516 @(#) $OpenLDAP: slapd 2.4.38 (Nov 27 2013 13:40:34) $
clement@localhost.localdomain:/home/clement/build/BUILD/openldap-2.4.38/servers/slapd
ldap_pvt_gethostbyname_a: host=server_name, r=0
52b1c516 daemon_init: listen on ldap:///
52b1c516 daemon_init: 1 listeners to open...
ldap_url_parse_ext(ldap:///)
52b1c516 daemon: bind(7) failed errno=98 (Address already in use)
52b1c516 daemon: bind(7) failed errno=98 (Address already in use)
52b1c516 slap_open_listener: failed on ldap:///
52b1c516 slapd stopped.
52b1c516 connections_destroy: nothing to destroy.
Here is my slapd.conf:
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /usr/local/openldap/etc/openldap/schema/core.schema
#
## Added to support the inetOrgPerson objectClass
include /usr/local/openldap/etc/openldap/schema/cosine.schema
include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema
include /usr/local/openldap/etc/openldap/schema/java.schema
include /usr/local/openldap/etc/openldap/schema/misc.schema
include /usr/local/openldap/etc/openldap/schema/nis.schema
include /usr/local/openldap/etc/openldap/schema/openldap.schema
# include /usr/local/openldap/etc/openldap/pmi.schema
include /usr/local/openldap/etc/openldap/schema/ppolicy.schema
include /usr/local/openldap/etc/openldap/schema/2307bis.schema
include /usr/local/openldap/etc/openldap/schema/printers.schema
# Define global ACLs to disable default read access.
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
referralldap://server_name.test.ldap
pidfile /var/lib/openldap/run/slapd.pid
argsfile/var/lib/openldap/run/slapd.args
# Load dynamic backend modules:
# modulepath/usr/local/openldap/libexec/openldap
# moduleloadback_bdb.la
# moduleloadback_hdb.la
# moduleloadback_ldap.la
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base= by * read
# access to dn.base=cn=Subschema by * read
access to *
by self write
by users read
by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., access to * by * read)
#
# rootdn can always read and write EVERYTHING!
###
# BDB database definitions
###
databaseconfig
rootdn cn=admin,cn=config
rootpw {SSHA}_
databasebdb
suffix dc=test,dc=ldap
rootdn cn=ldapadmin,dc=test,dc=ldap
# Cleartext passwords, especially for the rootdn, should
# be avoid. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw {SSHA}_
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/openldap/openldap-data
# Indices to maintain
index objectClass eq
index cn,sn,mail eq,sub
index departmentNumbereq
index automountKeyeq
index entryCSNeq
index entryUUID eq
index gidNumber,memberUID eq
index uid eq
index
substring matching rule not working in extensible search filter
Hi everybody, I tryied this filter in a ldapsearch operation: ((objectClass=inetOrgPerson)(description:2.5.13.7:=*abcd)) but this results in a Bad search filter (-7). However if I write this without the joker it works: ((objectClass=inetOrgPerson)(description:2.5.13.7:=abcd)) I don't see any restriction on matching rule extensible notation in RFC 4515 (http://tools.ietf.org/html/rfc4515). Is this syntax not implemented in OpenLDAP, or did I make a mistake in my filter ? Thank you in advance, DC
