I am trying to force users to change their password at first login or
password reset by administrator.
1)Password policy 'pwdMustChange TRUE' doesn't seems to be working as non
users get prompt to change their password at first login.
2) used the 'pwdReset TRUE' attribute in users attributes, and it won't
to change the password and didn't allow to login
i observe below messages in log
"slapd: connection restricted to password changing only
slapd: send_ldap_result: err=50 matched="" text="Operations are
restricted to bind/unbind/abandon/StartTLS/modify password"
slapd: conn=1053 op=1 SEARCH RESULT tag=101 err=50 nentries=0
text=Operations are restricted to bind/unbind/abandon/StartTLS/modify
Please help me configure the option to force all users to change their
at first login or after pwd reset by administrator.
Thanks & Regards
Tata Consultancy Services
Experience certainty. IT Services
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
I was experimenting with slapd by adding a lot of entries then deleting them. What I found is adding speed is not bad but deletion speed is lacking. With or without dbsync, delete speed is around half of that of adding. Naively, I thought deleting should be easier than adding, because in adding you actually need to pass and write whole entry of data, while in delete you can just mark the database page as free? The DB file did not shrink after massive deletion; which kind of suggest that deleting is only marking page as free, not really return them to the OS. I am using the latest git tree and the mdb backend.
Another related idea is delete a whole branch from the DIT. LDAP is already hierarchical, to delete all entries under a branch, one would assume that there must be an better way than deleting entries with a client side script, like what I am doing? With SQL you can drop a table. With LDAP, can I delete a whole branch?
I run a N-Way Multi-Master setup (N=4) and multiple read-only syncrepl.
I like to make sure I understand the "rid" correct.
According to http://www.openldap.org/doc/admin24/guide.html#olcSyncrepl,
the "rid" has to be unique per "slapd"
So I would configure on /every host/ (4x Multi-Master and multiple
rid=1..4 to identify the other servers.
The 4 Multi-Master server get 4 additional "ServerID 1..4
Is that right?
Thanks for clarification.
On Tue, Nov 27, 2018 at 3:17 PM Quanah Gibson-Mount <quanah(a)symas.com>
> --On Tuesday, November 27, 2018 2:22 PM -0800 Daniel Howard
> <dannyman(a)toldme.com> wrote:
> > I had been yearning for a config file, and it turns out I had them all
> > along!
> It's a database, not configuration files. Removing files from underneath
> database is generally not a good idea, although YMMV.
> > I am sharing my experience here, for the next person who finds themselves
> > googling around, trying to figure out how to remove or tweak a config in
> > OpenLDAP. It is nowhere near as complicated as what I had read.
> This is the wrong advice. It is also fairly trivial to do what you
> a) slapcat -n 0 -l /tmp/config.ldif
> b) Remove the duplicate entries from /tmp/config.ldif
> c) mv /path/to/current/config /path/to/current/config.old;mkdir -p
> d) slapadd -n 0 -l /tmp/config.ldif
I can see how a naive sysadmin might interpret the various text files in
/etc/ldap/slapd.d/cn=config/ as configuration files ... that could be
carefully edited by hand ... or managed programatically through the local
configuration management system.
I appreciate your admonition that this interpretation is wrong, and that
these would-be "config" files in the system configuration file hierarchy
are in fact a software-managed database, so we should not edit what appear
to be plain text configuration files, but simply export them to a text
file, carefully edit the export of the database, delete the entire config
file hierarchy, and then reimport the database.
If I may make a minor feature suggestion: whenever I get a file into /etc
that needs a special workflow, I like to put warnings in the comments at
the top of such files, advising that the file(s) shouldn't be edited by
hand, and explaining the proper workflow. (The visudo command is a golden
standard in this regard.)
djh@djh-p5510 ~> sudo head -3 /etc/sudoers
# This file MUST be edited with the 'visudo' command as root.
Perhaps this is a consideration that is already on the roadmap?
Back in April or May, I was trying to add and tweak a password policy,
invoking a command like this multiple times:
sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// -a -f ppolicy-overlay.ldif
This created multiple password policy overlays, and the LDAP server started
to crash with some frequency.
Of course, you can not use this interface to DELETE a policy overlay, so I
went about researching "hot to remove a ppolicy overlay" and go into some
complicated process where you have to export the database, remove olc*
entries, delete your database and re-import. My attention shifted to other
Yesterday, I turned back to the question of how to remove the duplicated
ppolicy overlays and started exporting the database, but I couldn't find
the ppolicy stuff in my slapcat output.
Another trip to the search mines and I discovered this gem:
While you are asked to configure stuff using an LDAP command that cannot
delete duplicate policy overlays, the config data doesn't get written into
the database, but just placed in plain-text files in a directory structure.
Removing duplicated overlays is as simple as stop slapd, remove the files,
start slapd. Similarly, you could tweak your ppolicy overlay or possibly
even bootstrap new servers by merely editing the right config files in the
I had been yearning for a config file, and it turns out I had them all
I am sharing my experience here, for the next person who finds themselves
googling around, trying to figure out how to remove or tweak a config in
OpenLDAP. It is nowhere near as complicated as what I had read.
I woke up to an issue today where SSH access to our servers no longer works due to issues with LDAP authentication. Oddly, ldapsearch with admin credentials interacts with the LDAP server fine. If I check for ldapusers using getent passwd, none are returned.
The slapd auditlog records the failed attempts.
When trying to su as an ldap user, it returns "no passwd entry".
Nothing "should" have changed over night, so any ideas of where to look will be appreciated.
The information contained in or attached to this e-mail is intended only for the use of the addressee. If you are not the intended recipient of this e-mail, or a person responsible for delivering it to the intended recipient, you are strictly prohibited from disclosing, copying, distributing, or retaining this e-mail or any part of it. It may contain information which is confidential and/or covered by legal, professional or other privilege under applicable law. If you have received this e-mail in error, please notify the author by replying to this e-mail immediately and delete this e-mail from your system. The views expressed in this email may not necessary be the views held by the organization. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
What can be the cause for ldapsearch without filter returning everything
as expected, but adding a filter (which works well against a 389 and an AD
installation) just returns nothing?
I can provide configs and logs if this is normal but unexpected (by me)
While I try to configure openldap 2.4.44 I get this error:
checking openssl/ssl.h usability... yes
checking openssl/ssl.h presence... yes
checking for openssl/ssl.h... yes
checking for SSL_library_init in -lssl... no
checking for ssl3_accept in -lssl... no
configure: error: Could not locate TLS/SSL package
ssl.h is in
and the version of openssl library is
The manual page slapd.access explains: "The disclose access level allows disclosure of information on error."
I don't quite understand what this is saying: Can the requester find out a specific object or attribute exists without actually reading its value?
I have been asked to look into adding an LDAP instance in AWS Cloud environment. This LDAP instance would participate in our current N-Way MMR that we have locally.
Does anyone have any recommendations, experience, or insight into attempting something like this?
Any help would be appreciated.
Identity Management Specialist
University of Massachusetts Amherst, IT NSS