Problem with "force user to password reset at first login
by Rajagopal Rc
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
1 month, 1 week
Re: Syncrepl and multipe values
by Quanah Gibson-Mount
--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>
5 years, 9 months
syncrepl error (53) with 3-way delta-mmr (consumer state is newer than provider)
by Sven Mäder
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
6 years, 3 months
Re: pwdfailuretime with multi-sync
by Quanah Gibson-Mount
--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>
6 years, 3 months
Re: Re: Removing Berkeley DB Log Files
by Douglas Duckworth
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
>
>
>
6 years, 3 months
Re: 2.4.45 slapadd segfault
by Quanah Gibson-Mount
--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>
6 years, 3 months
2.4.45 slapadd segfault
by Christopher Wood
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
6 years, 3 months
Re: syncrepl error (53) with 3-way delta-mmr (consumer state is newer than provider)
by Quanah Gibson-Mount
--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>
6 years, 3 months
Re: Removing Berkeley DB Log Files
by Douglas Duckworth
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=
>
6 years, 3 months
