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
--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.
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
I've spent days trying to figure out how could I enable the memberOf
overlay, and it doesn't seem to be easy for an LDAP-noob. I've read
like 50+ tutorials which didn't help me get it working.
Use case: I want to have 2 main groups which control access to
different services on my network. A "unixusers" which is a minimum to
log in to Linux servers (having a hostObject entry for the user is
another requirement, which is irrelevant to this question, as I
already solved that problem); and a "cloudusers" group which enables
log in to my ownCloud instance.
The groups should enforce the following rules:
– Only users in "cloudusers" should be allowed to log in to ownCloud.
– Users in "unixusers" are allowed to log in to a set of Linux servers
controlled by "host" (hostObject) entries.
– Users not in the "unixusers" group may not log in to any Linux
systems, even if they have "host" entries.
– ownCloud complains that the memberOf overlay is not enabled, hence
it doesn't let me restrict access to the "cloudusers" group. It would
allow any users regardless of any group memberships, which is not
– I have a similar problem on Linux with PAM: I can't really get it to
consider "unixusers" membership for user logins, although I got the
"host" entries working correctly, so at least I can already restrict
access with that.
My guess is that it all boils down to the lack of memberOf overlay. I
also figured that memberOf would need groupOfNames groups, while I
need posixGroup type groups. I evaluated the possibility to use
groupOfNames, but it lacks the necessary gidNumber attribute which is
a requirement for Unix groups. But anyway, I can't enable memberOf
even for groupOfNames. I can't enable memberOf by any means.
My OpenLDAP uses the new configuration method and it completely
ignores slapd.conf, so the config must be injected with ldapadd to
Could you please help me with this?
I'm trying to configure a not complex (as I believe) ACL ... but have some
I have two posixGroup groups
my users resides in ou=People,dc=foo
so, in subtree ou=People,dc=foo I need to allow anything to admins (and
it is not difficult of course)
for example this works for me:
access to dn.subtree="ou=People,dc=foo"
by set="[cn=admin,ou=group,dc=foo]/memberUid & user/uid" manage
by self write
by users read
by * break
but in addition I need to allow my coadmins to do the same things except
manipulations upon the objects which belong to admins (
so, the question is: how? (if it is possible at all) :(
Zeus V. Panchenko jid:firstname.lastname@example.org
IT Dpt., I.B.S. LLC GMT+2 (EET)
mailing lists wrote:
> I am testing the chain overlay from a read-only slave (consumer) slapd server
> to a read-write master (provider), but what I am seeing is an anonymous bind
> from the consumer to the provider instead of the authorization identity
> configurated in the chain directive.
Have you successfully run test032 in the test suite? Have you compared your
config to the config used in that test?
> afaik, the bind dn in the provider must be the chain binddn configured in the
> consumer, but it gets an anonymous bind.
> any suggestion about what can be my mistake??
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--On Sunday, April 23, 2017 12:38 AM +0000 Jesper Grøndahl
> Our log level is stats and sync.
> The logs look like this, for the user being modified
> nonpresent_callback: rid=005 present UUID
> 528929d6-acaa-1036-922a-a3f5c9285d9d, dn uid=xxx,ou=users,dc=ruc,dc=dk
> Entry uid=xxx,ou=users,dc=ruc,dc=dk CSN
> 20170406140323.504919Z#000000#002#000000 greater than snapshot
It would appear you have serious issues with your installation, since the
CSNs are off by 3 days. I would note that 2.4.40 is not stable for MMR as
well. I would ensure you aren't suffering from clock skew across your
servers, and upgrade to the current OpenLDAP release as well.
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
Is there an reliable way to detect whether LDAPI support is enabled in the OpenLDAP build
on a particular platform? I vaguely remember the developer discussions about disabling
LDAPI on platforms where the peer credentials are not secure.
Background: I'd like to detect with python-ldap whether to enable LDAPI in automatic
testing or not.
I'm looking into a Debian bug report: https://bugs.debian.org/860947
/* XXX not threadsafe */
static int sasl_initialized = 0;
I'm not yet sure whether it's the cause of that report, but it does seem
to be problematic. I'm seeing spurious "no such mechanism" results
and/or crashes in mutiple environments performing SASL binds in
- slapd with multiple syncrepl clients all using SASL binds,
- the ldclt tool from the 389-ds project, and
- the test program I'm about to describe below.
I wrote a test program for this issue, and I'd like to ask the list to
check the code before I submit an ITS, in case I've made a mistake that
renders my test invalid.
gcc -g sasltest.c -pthread -llber -lldap -lsasl2 -DSASL
As I understand it, -lldap_r should not be needed here since each thread
creates its own LDAP instance. (It doesn't seem to change the results,
Built without -DSASL, it uses simple binds, and appears to work fine,
but again, I'm not confident my code is correct.