openldap-technical August 2017

openldap-technical@openldap.org

32 participants
54 discussions

Problem with "force user to password reset at first login
by Rajagopal Rc 30 Oct '23

30 Oct '23

Hi, I am trying to force users to change their password at first login or after password reset by administrator. Tried following: 1)Password policy 'pwdMustChange TRUE' doesn't seems to be working as non of the users get prompt to change their password at first login. 2) used the 'pwdReset TRUE' attribute in users attributes, and it won't prompt to change the password and didn't allow to login i observe below messages in log "slapd[12684]: connection restricted to password changing only slapd[12684]: send_ldap_result: err=50 matched="" text="Operations are restricted to bind/unbind/abandon/StartTLS/modify password" slapd[12684]: conn=1053 op=1 SEARCH RESULT tag=101 err=50 nentries=0 text=Operations are restricted to bind/unbind/abandon/StartTLS/modify password" Please help me configure the option to force all users to change their password at first login or after pwd reset by administrator. Thanks & Regards Raj Tata Consultancy Services Mailto: rajagopal.rc(a)tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you

5 9

Re: Syncrepl and multipe values
by Quanah Gibson-Mount 24 Feb '18

24 Feb '18

--On Friday, January 06, 2017 6:50 PM +0000 Matheus Eduardo Bonifacio Morais <matheus_morais(a)sicredi.com.br> wrote: > > > > Issue 8559 opened. > > > > I'm trying to work on a patch but I'm not sure if the best solution is to > fix accesslog to avoid duplicated values or if the sample LDIF (in its > description) should result in a constraint violation. What do you think? The accesslog should never write an operation that can't be replicated. If the MOD is a valid LDAP operation (which I think it is), then it should be accepted at the frontend. The issue may be more in delta-syncrepl's handling of the write op than anything else. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 3

syncrepl error (53) with 3-way delta-mmr (consumer state is newer than provider)
by Sven Mäder 01 Sep '17

01 Sep '17

Hi We have a 3-way delta-mmr syncrepl setup (Debian Stretch with slapd 2.4.44+dfsg-5+deb9u1). 2 of those 3 hosts were powered off for about 4 hours. After the bootup and slapd start, the host which was running all the time during the downtime started to log: SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider! Purging the accesslog database fixed the issue. Could this have happened due to a timesync problem? We noticed, that right after boot, the ntpd service was oscillating in its time offset from 0.0192 to 0.0003 for ~3 minutes. Does somebody have experience with this? Do we need to delay slapd or force an `ntpdate` before slapd starts in the boot process? Because slapd has the following LSB headers in the init script # Required-Start: $remote_fs $network $syslog it is started (using systemd service file autogenerated from init.d script) right after network.target has been reached and simultaneously with ntpd. Whereas slapd only takes about 1 second to start, ntpd takes about 10 seconds and it might even take much longer to get the time in sync. Kind regards -- Sven Mäder IT Services Group Physics Department, ETH Zurich

2 2

Re: pwdfailuretime with multi-sync
by Quanah Gibson-Mount 31 Aug '17

31 Aug '17

--On Wednesday, August 30, 2017 9:21 AM -0700 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Wednesday, August 30, 2017 2:49 PM +0800 Chris Leung > <chris(a)q-station.net> wrote: > >> Sometime, the user password is replicated without problem after switched >> to REFRESH, however, sometime password can't be sync. > > Error 16 means "no such attribute exists". My guess would be you have > ACLs that block your replica from replicating userPassword. I'd also > guess that you originally loaded the replica via a slapcat of the other > master, so some accounts have passwords, and others don't. This is all > guesswork of course, but it would match the behavior you're seeing. Also, I would confirm that you have identical overlay configurations between the two masters. It sounds like on has ppolicy and perhaps the other one doesn't? Also be sure and read the ppolicy manpage closely on replication behavior. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Re: Removing Berkeley DB Log Files
by Douglas Duckworth 31 Aug '17

31 Aug '17

Thanks, a lot everyone! Performance looks good now. No deadlocks and nothing being purged from the cache. I have started pointing more sssd clients at the cluster. Thanks, Douglas Duckworth, MSc, LFCS HPC System Administrator Scientific Computing Unit Physiology and Biophysics Weill Cornell Medicine E: doug(a)med.cornell.edu O: 212-746-6305 F: 212-746-8690 On Thu, Aug 31, 2017 at 2:51 AM, Ulrich Windl < Ulrich.Windl(a)rz.uni-regensburg.de> wrote: > >>> Douglas Duckworth <dod2014(a)med.cornell.edu> schrieb am 30.08.2017 um > 16:06 in > Nachricht > <CAAKHBKm0FKBR4BLNpy6jrszFp35Eid_J2F19MKmfS+G47EKCJA(a)mail.gmail.com>: > [...] > > Only four clients are currently using this cluster so perhaps I should > > actually use DB_CONFIG before putting it into production. > > Maybe you could start considering this from a moderately loaded and sized > server: > set_cachesize 0 15000000 1 > set_lg_regionmax 262144 > set_lg_bsize 2097152 > set_flags DB_LOG_AUTOREMOVE > set_lk_max_locks 30000 > set_lk_max_objects 30000 > --- > > Also note "olcDbConfig: <DB_CONFIG setting>" is probably the modern way to > do it. > > Regards, > Ulrich > > >

1 0

Re: 2.4.45 slapadd segfault
by Quanah Gibson-Mount 31 Aug '17

31 Aug '17

--On Thursday, August 31, 2017 4:49 PM +0100 Howard Chu <hyc(a)symas.com> wrote: > Christopher Wood wrote: >> Good morning, long time no list. >> >> For backstory, I downloaded the 2.4.45 source tarball from >> https://www.openldap.org/software/download/, compiled, ran "make test" >> (which was fine as near as I can tell), but doing a slapadd of cn=config >> caused a segfault. >> >> I used the points on http://www.openldap.org/faq/data/cache/59.html to >> create the following backtrace: >> >> https://gist.github.com/christopherwood/701fbc70ef352a3bf2d2893a9ae0a65e >> >> And this is the ldif (temporary password is fakepass333): >> >> https://gist.github.com/christopherwood/2cf46f5a3384f9edc89e7eabbefc465e >> >> Does anything jump out at you as obviously wrong or a good place to >> look? I've chopped the ldif down from the original with confidential >> data and am still reducing, but it's still segfaulting. > > Yes. Look at your LDIF line 62 more carefully. Compare it to line 65 if > it's still not obvious to you. > > Granted it shouldn't SEGV but the backtrace shows it was shutting itself > down already because it (correctly) rejected your input. There are a number of errors with that LDIF file, outside of what Howard already pointed out. ;) The objects in 54 & 62 are also missing their RDN as a value too. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: 2.4.45 slapadd segfault
by Howard Chu 31 Aug '17

31 Aug '17

Christopher Wood wrote: > Good morning, long time no list. > > For backstory, I downloaded the 2.4.45 source tarball from https://www.openldap.org/software/download/, compiled, ran "make test" (which was fine as near as I can tell), but doing a slapadd of cn=config caused a segfault. > > I used the points on http://www.openldap.org/faq/data/cache/59.html to create the following backtrace: > > https://gist.github.com/christopherwood/701fbc70ef352a3bf2d2893a9ae0a65e > > And this is the ldif (temporary password is fakepass333): > > https://gist.github.com/christopherwood/2cf46f5a3384f9edc89e7eabbefc465e > > Does anything jump out at you as obviously wrong or a good place to look? I've chopped the ldif down from the original with confidential data and am still reducing, but it's still segfaulting. Yes. Look at your LDIF line 62 more carefully. Compare it to line 65 if it's still not obvious to you. Granted it shouldn't SEGV but the backtrace shows it was shutting itself down already because it (correctly) rejected your input. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

2.4.45 slapadd segfault
by Christopher Wood 31 Aug '17

31 Aug '17

Good morning, long time no list. For backstory, I downloaded the 2.4.45 source tarball from https://www.openldap.org/software/download/, compiled, ran "make test" (which was fine as near as I can tell), but doing a slapadd of cn=config caused a segfault. I used the points on http://www.openldap.org/faq/data/cache/59.html to create the following backtrace: https://gist.github.com/christopherwood/701fbc70ef352a3bf2d2893a9ae0a65e And this is the ldif (temporary password is fakepass333): https://gist.github.com/christopherwood/2cf46f5a3384f9edc89e7eabbefc465e Does anything jump out at you as obviously wrong or a good place to look? I've chopped the ldif down from the original with confidential data and am still reducing, but it's still segfaulting. More details: OpenLDAP 2.4.45 Release (2017/06/01) [root@poc209 ~]# uname -a Linux poc209 3.10.0-514.26.2.el7.x86_64 #1 SMP Tue Jul 4 15:04:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux [root@poc209 ~]# cat /etc/redhat-release CentOS Linux release 7.3.1611 (Core) / and /var are ext4. Configure was like this, albeit on one line: ./configure --enable-debug --enable-dynamic --enable-syslog --enable-proctitle --enable-ipv6 --enable-local --enable-slapd --enable-dynacl --enable-aci --enable-cleartext --enable-crypt --enable-lmpasswd --enable-spasswd --enable-modules --enable-rewrite --enable-rlookups --enable-slapi --disable-slp --enable-wrappers --enable-backends=mod --enable-bdb=yes --enable-hdb=yes --enable-mdb=yes --enable-monitor=yes --disable-ndb --enable-overlays=mod --disable-static --enable-shared --with-cyrus-sasl --without-fetch --with-threads --with-pic --with-tls=openssl --with-gnu-ld --prefix=/opt/openldap

1 0

Re: syncrepl error (53) with 3-way delta-mmr (consumer state is newer than provider)
by Quanah Gibson-Mount 31 Aug '17

31 Aug '17

--On Wednesday, August 30, 2017 3:51 PM +0200 Sven Mäder <maeder(a)phys.ethz.ch> wrote: > SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is > newer than provider! This would generally indicate that the accesslog DB was empty at startup, and it generated a new CSN. This is a general problem with delta-syncrepl -- If the accesslog DB goes empty, there are a host of issues that can ensue (See ITS#8100 for example). Generally you need a script that writes a change on all masters in your cluster on a regular interval so that the DB is never purged, and there is always an active contextCSN value that's stored in the DB for each serverID. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Removing Berkeley DB Log Files
by Douglas Duckworth 30 Aug '17

30 Aug '17

Thanks for the reply, Howard. Thanks for pointing me in the right direction. From what I have read there are two options. 1) Copy /usr/share/openldap-servers/DB_CONFIG.example to /var/lib/domain then rebuild the database. 2) Enable checkpointing in slapd.conf Does enabling checkpointing in slapd.conf require rebuilding the database or can I simply restart slapd.conf? We are not using online configuration. Best Doug Thanks, Douglas Duckworth, MSc, LFCS HPC System Administrator Scientific Computing Unit Physiology and Biophysics Weill Cornell Medicine E: doug(a)med.cornell.edu O: 212-746-6305 F: 212-746-8690 On Fri, Aug 25, 2017 at 8:55 AM, Howard Chu <hyc(a)symas.com> wrote: > Douglas Duckworth wrote: > > Hi > > > > I am running openldap-servers-2.4.40-16.el6.x86_64 cluster on Centos > 6.9. My > > /var/lib/ldap directory contains many 10MB log files. /var partition > rather > > small... > > > > I've read they can be removed either by running "sudo db_archive -d -h > > /var/lib/ldap/domain" or by defining "DB_LOG_AUTOREMOVE" within the file > > "DB_CONFIG." That file does not presently exist whereas the db_archive > > command does not actually remove any of the log files. > > If the db_archive command doesn't remove anything, that means it thinks > all of > the log files are still in active use. > > Read the docs more carefully. > https://urldefense.proofpoint.com/v2/url?u=http-3A__docs. > oracle.com_cd_E17076-5F05_html_programmer-5Freference_ > transapp-5Flogfile.html&d=DwICaQ&c=lb62iw4YL4RFalcE2hQUQealT9- > RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m= > WP95x8mwSiEHHqUWRqJv6WdpfcTtJDAUAKN756yEEDA&s= > Kfi27b4v7vABZjPQYMkeo4xBqUyDGZeyB8pHAFin8xY&e= > > > > > Can I remove the old log files manually using rm? > > Not if the above is true, you will corrupt the logs and the DB will fail to > open on a subsequent restart. > > > If not should I create > > /var/lib/ldap/DB_CONFIG then restart slapd to make this removal > automatic? > > > Do you have any idea why db_archive does not work or produce any helpful > error > > to stdout? > > There's no error message because there's no error, everything is working as > designed. > > You need to do periodic checkpoints to allow log files to be closed, and > then > db_archive will be able to remove some of them. > > -- > -- Howard Chu > CTO, Symas Corp. https://urldefense.proofpoint. > com/v2/url?u=http-3A__www.symas.com&d=DwICaQ&c=lb62iw4YL4RFalcE2hQUQealT9- > RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m= > WP95x8mwSiEHHqUWRqJv6WdpfcTtJDAUAKN756yEEDA&s=IT7tNF72SCugdO8WpRd- > oNsk4nPNpdjE2aUFL4R4X_M&e= > Director, Highland Sun https://urldefense.proofpoint. > com/v2/url?u=http-3A__highlandsun.com_hyc_&d=DwICaQ& > c=lb62iw4YL4RFalcE2hQUQealT9-RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e- > CbhH6xUjnRkaqPFUS2wTJ2cw&m=WP95x8mwSiEHHqUWRqJv6WdpfcTtJDAUAKN756yEEDA&s= > XqfYCnjG9ibPbeW05QZOlWdl9u0ZH-7IXkxx0gh238k&e= > Chief Architect, OpenLDAP https://urldefense.proofpoint. > com/v2/url?u=http-3A__www.openldap.org_project_&d=DwICaQ&c= > lb62iw4YL4RFalcE2hQUQealT9-RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e- > CbhH6xUjnRkaqPFUS2wTJ2cw&m=WP95x8mwSiEHHqUWRqJv6WdpfcTtJDAUAKN756yEEDA&s=- > tGdeTJRpeaRbljBBUq49XgfNWzVElqiGEgv0LeqspU&e= >

2 5

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical August 2017