Re: Forbidden account password reuse of the last 5 password
You may set the "pwdInHistory" attribute to 5 to store the last 5 passwords used, and forbid their reuse. Le 14/02/2019 à 10:35, Matthieu Cerda a écrit : > Yes, you might want to use the password policy (ppolicy) overlay: > https://kb.symas.com/v2.4.45.2/man5/slapo-ppolicy/ > > Le 14/02/2019 à 07:58, Tian Zhiying a écrit : >> Hi >> >> Is there a feature that OpenLDAP password policy can forbidden user password >> reuse of the last 5 password? >> >> Thanks. >> >> >> >> -- Matthieu Cerda Infrastructure, BU Means @ NBS System
Re: Forbidden account password reuse of the last 5 password
Yes, you might want to use the password policy (ppolicy) overlay: https://kb.symas.com/v2.4.45.2/man5/slapo-ppolicy/ Le 14/02/2019 à 07:58, Tian Zhiying a écrit : > Hi > > Is there a feature that OpenLDAP password policy can forbidden user password > reuse of the last 5 password? > > Thanks. > > > > -- Matthieu Cerda Infrastructure, BU Means @ NBS System
Re: nonpresent_callback present UUID in logs
Le 22/10/2018 à 17:13, Quanah Gibson-Mount a écrit : > --On Monday, October 22, 2018 9:36 AM +0200 Florent LARTET > wrote: > >> Hello, >> I switched back to BDB and it works fine again. I also downgraded to >> Master-Slave to ensure the good working as suggested. >> But my initial question is still unanswered. Yes ? No ? > > It means it found the entry while doing the presence phase. However, > replication in general (MMR or not) is not safe with 2.4.31, nor is > back-mdb in that particular version. I'd strongly advise upgrading to > a current supported release. Hello, If you are unfamilliar with Debian packaging, or (more likely) do not want to maintain a build of OpenLDAP, you might want to use https://ltb-project.org/documentation/openldap-deb If you really want not to stray from official packages, you might find satisfaction using the wheezy-backports version, but I think the LTB project way is probably the best way to go > > Regards, > Quanah -- Matthieu Cerda Infrastructure, BU Means @ NBS System signature.asc Description: OpenPGP digital signature
Re: exempt some users from OpenLDAP password policy
Hello, Well, you might want to take a look at the recent thread "removing ppolicy overlay" (especially Frank Swasey's latest answer). If you do not want to go through the hassle of editing your LDAP database to remove all ppolicy attributes, you may leave the password policy overlay enabled without any default policy set, which would be basically the same as having it disabled since no policy would be enforced. For this to work, you will want to check if there is no "pwdPolicySubentry" attribute somewhere, that would explicitely enable a password policy on the object. Have a nice day, -- Matthieu CERDA Le 23/04/2018 à 07:22, Tayyab Saeed a écrit : > Dear All, > > How can we disable password policy completely? > > Thanks, > Tayyab Saeed > > *From: *"Dave Macias" > *To: *"Tayyab Saeed" > *Cc: *openldap-technical@openldap.org, "Matthieu Cerda" > > *Sent: *Thursday, April 19, 2018 5:36:04 PM > *Subject: *Re: exempt some users from OpenLDAP password policy > > What your ldap tree look like (the relevant parts, users, current > ppolicy)? > As far as links, there are soo many out there. Just search for one > that fits your enviroment > Here is how to add a ppolicy in the first place. > https://wiki.polaire.nl/doku.php?id=centos7_openldap_ppolicy > > How to add ppolicy to specific objects: > http://www.zytrax.com/books/ldap/ch6/ppolicy.html#examples > > As Matthieu already mentioned, assuming you already have a ppolicy, > then you would need to create a less restrictive policy and apply to > specific users using the pwdPolicySubentry attribute > > regards, > dave > > On Apr 15, 2018, 11:50 PM -0400, Tayyab Saeed <mailto:tayyab.sa...@nds.com.pk>>, wrote: > > Dear All, > > I am sorry but still unable to configure the same, could anyone > please share the complete steps / link so i can setup the same. > > Thanks, > Tayyab Saeed > > *From:* "Dave Macias" mailto:dav...@gmail.com>> > *To:* "Matthieu Cerda" <mailto:matthieu.ce...@nbs-system.com>> > *Cc:* openldap-technical@openldap.org > <mailto:openldap-technical@openldap.org> > *Sent:* Friday, April 13, 2018 8:27:04 PM > *Subject:* Re: exempt some users from OpenLDAP password policy > > Here is an example which you can apply per-user which needs to be > exempted: > > dn: cn=ppolicy-exclude,ou=policies,dc=organization,dc=org > cn: ppolicy-exclude > objectClass: top > objectClass: device > objectClass: pwdPolicyChecker > objectClass: pwdPolicy > pwdAttribute: userPassword > pwdAllowUserChange: TRUE > pwdMustChange: FALSE > pwdLockout: FALSE > > > On Fri, Apr 13, 2018 at 10:28 AM, Matthieu Cerda > <mailto:matthieu.ce...@nbs-system.com>> wrote: > > Hello, > > > You may either: > > * Set a relaxed default password policy using > olcPPolicyDefault / ppolicy_default (or no default policy > at all) and set more restrictive password policies on some > of your users by setting the pwdPolicySubentry attribute > on their object > * Set a restrictive default password policy, and a relaxed > ones on some of your users > > Using one or the other depends on the proportions of > exceptions you would generate: the less, the better > > -- > > Matthieu CERDA > > > Le 13/04/2018 à 11:38, Tayyab Saeed a écrit : > > Dear Peter / ALL, > > Thanks a lot for your reply. > > So how can we exempt some users from password policy ? > > Is it possible in OpenLDAP or not ? > > Thanks, > Tayyab Saeed > > > *From:* "Peter Gietz" > <mailto:peter.gi...@daasi.de> > *To:* openldap-technical@openldap.org > <mailto:openldap-technical@openldap.org> > *Sent:* Friday, April 13, 2018 1:08:31 PM > *Subject:* Re: exempt some users from OpenLDAP password policy > > Dear Tayyab, > > > well the error message says most of it. > > > The attribute pwdChangedTime is defined in sect. 5.3.2. of > https://tools.ietf.org/html/draft-behera-ldap-password-policy-10 >
Re: exempt some users from OpenLDAP password policy
Hello, You may either: * Set a relaxed default password policy using olcPPolicyDefault / ppolicy_default (or no default policy at all) and set more restrictive password policies on some of your users by setting the pwdPolicySubentry attribute on their object * Set a restrictive default password policy, and a relaxed ones on some of your users Using one or the other depends on the proportions of exceptions you would generate: the less, the better -- Matthieu CERDA Le 13/04/2018 à 11:38, Tayyab Saeed a écrit : > Dear Peter / ALL, > > Thanks a lot for your reply. > > So how can we exempt some users from password policy ? > > Is it possible in OpenLDAP or not ? > > Thanks, > Tayyab Saeed > > *From: *"Peter Gietz" > *To: *openldap-technical@openldap.org > *Sent: *Friday, April 13, 2018 1:08:31 PM > *Subject: *Re: exempt some users from OpenLDAP password policy > > Dear Tayyab, > > > well the error message says most of it. > > > The attribute pwdChangedTime is defined in sect. 5.3.2. of > https://tools.ietf.org/html/draft-behera-ldap-password-policy-10 as: > > ... > > NO-USER-MODIFICATION > USAGE directoryOperation ) > > > Which means, that an LDAP client is not allowed to modify the values > of this attribute, and that it is to be modified by the directory > server only. > > And this makes perfectly sense, that the value is changed, if and only > if the password is being changed. > > Cheers, > Peter > > Am 12.04.2018 um 22:55 schrieb Tayyab Saeed: > > Dear All, > > I have tried modifying pwdChangedTime & facing below error > > modifying entry > "uid=test1,ou=ITSupport,ou=people,dc=mydomain,dc=com" > ldap_modify: Constraint violation (19) > additional info: pwdChangedTime: no user modification allowed > > Thanks, > Tayyab Saeed > > > -- Matthieu Cerda Infrastructure, BU Means @ NBS System
Re: OpenLDAP slave failure in case of master indisponibility
Le 22/12/2017 à 14:39, Michael Ströder a écrit : > Matthieu Cerda wrote: >> I am observing a rather strange issue in the following setup: >> >> * 1 OpenLDAP master server (2.4.31) > 2.4.31 was released 2012-04-21 (over five years ago). > >> * 4 OpenLDAP slave servers (2.4.40) > 2.4.40 was released 2014-09-20 (three years ago). > > There have been so many fixes since then which may affect your > configuration => you should upgrade. > > Everything else is a waste of time, also for yourself. > > Ciao, Michael. > Fair point, I'll test with LTB project packages :) (wink Clément O.) Thank you! -- Matthieu Cerda Infrastructure, BU Means @ NBS System signature.asc Description: OpenPGP digital signature
Re: Openldap-ldb-2.4.44-2 - Issu with Password Management
Le 29/11/2017 à 08:38, Geoff Swan a écrit :
>
>
> On 2017-11-29 5:08 PM, Raja T Nair wrote:
>> Hello All,
>>
>> I'm using openldap-ltb-2.4.44-2
>> Using password-hash {SSHA512}
>>
>> We have an in-house portal which allows people to change their passwords.
>> It is written in PHP.
>>
>> version = php 5.6
>> lib = php-ldap
>> $entry['userpassword'] = $newpasswd;
>> ldap_modify($conn, $userdn, $entry);
>>
>> $newpasswd contains new password in plain text.
>>
>> It seems that the server does not encrypt the plain text string sent
>> to it from the portal, it only encodes it in base64.
>>
>> When an encrypted string is sent (SSHA512), the server rejects based
>> on password policy since no special character is present.
>>
>> We would want to make the first method to work. Can somebody help me
>> with this?
>>
>> ps: ldappasswd command works perfectly and the password gets
>> encrypted in SSHA512 and encoded in base64.
>>
>
> You need to also write the code which salts and hashes the password
> according to your elected scheme before writing it to the database.
Hello,
I think that ppolicy is not supposed to try to analyze a password that
is prefixed by a hash indicator... that is kinda weird.
The support for LDAP EXOP (especially "LDAP Password Modify Extended
Operation") has been merged to PHP 7.2, but did not exist before, so you
will not be able to use it until then, so you are stuck with the
hash-before-modify method.
I suggest, if you did not already, that you take a look at the
https://ltb-project.org/documentation/self-service-password project,
that is also PHP-based, has plan to support exops when they will be
available in PHP, so you might either inspire yourself from its code or
switch to using it :) (Also, one of its main developers, Clément Oudot,
lurks on this mailing list so you might get useful advice from him).
We actually do use SSP here with SSHA512 support AND ppolicy and it
works flawlessly.
--
Matthieu Cerda
Infrastructure, BU Means @ NBS System
signature.asc
Description: OpenPGP digital signature
Re: password change interception overlay
Hello Michael, Well, there is at least smbk5pwd in the contrib overlays. What do you need to sync ? Regards, -- Matthieu CERDA Le 28/04/2017 à 15:26, Michael Ströder a écrit : > HI! > > Does anybody know a publicly available overlay which intercepts userPassword > changes and > grabs the new password for password syncing? > > Ciao, Michael. > signature.asc Description: OpenPGP digital signature
Re: OpenLDAP userpassword instead SambaNTPassword
Le 10/01/2017 à 15:23, Tian Zhiying a écrit : > Hi > > I just intergrated OpenLDAP and Samba service, the prupose is to allow users > can use one account and password to login them. > > But after I change the password from " Self Service Password ", only > userpassword has changed, SambaNTPassword has not changed. > > Could you help me ? > > Thanks. > Hello Tian, Please note this is the OpenLDAP mailing list, not the LTB SSP one :) The reason is simple: you are missing '$samba_mode = true;' in your SSP configuration. Please take a look at http://ltb-project.org/wiki/documentation/self-service-password/0.8/config_ldap , section 'Samba' Have a nice day ! -- Matthieu CERDA signature.asc Description: OpenPGP digital signature
Re: Antw: Re: ppolicy overlay unable to set pwdAccountLockedTime on to-be-locked users due to ACLs
Le 03/01/2017 à 08:05, Ulrich Windl a écrit : >>>> Quanah Gibson-Mount schrieb am 03.01.2017 um 00:11 in > Nachricht : >> (...) >> >> Note the bit about "all the operations, ..." >> >> If you think of a way to reword it that you feel is a better explanation, >> that could certainly be considered. :) > > I think a notice who is the modifier on ppolicy changes would be woth it; > specifically if it's related to RootDN ;-) > I think I had already asked earlier about some notice on ACLs that ppolicy > may or may not need to work. Well I certainly didn't understand the message as 'every operation will be done assuming the rootdn identity' indeed. I agree with Ulrich, maybe a small note in the manpage saying exactly that might help, just in case ? Here is a proposal patch on slapo-ppolicy.5 manpage to clarify that. Thanks in advance, -- Matthieu Cerda From c6c03415e73fe762ee8f77d3e3cad97834913d00 Mon Sep 17 00:00:00 2001 From: Matthieu Cerda Date: Tue, 3 Jan 2017 14:45:37 +0100 Subject: [PATCH] Clarify slapo-ppolicy manpage about rootdn absence possible consequences --- doc/man/man5/slapo-ppolicy.5 | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/doc/man/man5/slapo-ppolicy.5 b/doc/man/man5/slapo-ppolicy.5 index 8306f9761..6d3edb9c4 100644 --- a/doc/man/man5/slapo-ppolicy.5 +++ b/doc/man/man5/slapo-ppolicy.5 @@ -28,7 +28,12 @@ Note that some of the policies do not take effect when the operation is performed with the .B rootdn identity; all the operations, when performed with any other identity, -may be subjected to constraints, like access control. +may be subjected to constraints, like access control. It means that +not defining a +.B rootdn +in your configuration is likely to lead to undesirable behavior (like +account locking using pwdLockout not working properly) unless you have +appropriate access control entries. .P Note that the IETF Password Policy proposal for LDAP makes sense when considering a single-valued password attribute, while -- 2.11.0 signature.asc Description: OpenPGP digital signature
Re: ppolicy overlay unable to set pwdAccountLockedTime on to-be-locked users due to ACLs
Thank you very much Quanah ! Do you think adding a note about mandatory rootdn setting in slapo-ppolicy manpage would be a worthy contribution ? (I'll gladly submit a patch) Or did I just miss something in the manpage or another one ? Happy new year to you and the OpenLDAP / Symas team, Regards, -- Matthieu CERDA Le 28/12/2016 à 20:27, Quanah Gibson-Mount a écrit : > --On Thursday, December 22, 2016 11:23 AM +0100 Matthieu Cerda > wrote: > >> Hello Howard and Ozgur, >> >> My answers are inlined in the following text. >> >> I attached a copy of the slapd.conf if you would like to take a look. > > Your slapd.conf has no rootdn configured. You need to configure it if > you want ppolicy to function correctly. > > Regards, > Quanah signature.asc Description: OpenPGP digital signature
Re: ppolicy overlay unable to set pwdAccountLockedTime on to-be-locked users due to ACLs
Hello Howard and Ozgur,
My answers are inlined in the following text.
I attached a copy of the slapd.conf if you would like to take a look.
Thanks for taking the time to answer my questions, it's appreciated.
Have a nice day !
Howard Chu wrote :
Matthieu Cerda wrote:
Hello folks,
I just stumbled upon a (maybe not) surprising technical issue with my
OpenLDAP setup: ppolicy seems unable to update pwdAccountLockedTime on
my users.
(...)
The documentation (http://www.openldap.org/doc/admin24/overlays.html)
advises nothing about ACLs.
That is not the documentation, that is only a guide. The manpages are
the authoritative documentation.
Got it, i was misled by the '/doc' in the URL I guess.
Is this and issue or a misconfiguration ?
Read the slapo-ppolicy(5) manpage.
(Note: the default password policy I use has pwdLockout: TRUE,
pwdMaxFailure: 3 and pwdLockoutDuration:0)
The manpage says nothing about ACL's except: 'Note that some of the
policies do not take effect when the operation is performed with the
rootdn identity; all the operations, when performed with any other
identity, may be subjected to constraints, like access control.'
To clarify, I'm obviously not testing the ppolicy on a rootdn (the
database does not have any actually), it is a random user without any
specific privilege (besides beeing allowed access to * with read rights
when authenticated).
My current understanding of ppolicy pwdLockout attribute is that when a
user exceeds its pwdMaxFailure count when pwdLockout is TRUE, the
overlay itself sets pwdAccountLockedTime internally according to the
pwdLockoutDuration value, bypassing ACLs (in this case, my setup should
work). If it is not the case, who needs write access to the attribute ?
Do I need a rootdn set, even if I do not use it, for this to work
properly maybe ?
Thanks in advance,
Ozgur Karatas wrote:
Hello,
The "deleted access denied by read" error has been fixed to OpenLDAP
next version, I remember.
I think it was from that slapo-ppolicy and has been fix in the 2.4.11
version.
http://www.openldap.org/devel/cvsweb.cgi/Attic/CHANGES
Well this is a 2.4.40 OpenLDAP, it should be OK then ?
---8<---
# slapd -V
@(#) $OpenLDAP: slapd (Jan 16 2016 23:00:08) $
root@chimera:/tmp/buildd/openldap-2.4.40+dfsg/debian/build/servers/slapd
---8<---
I also tried with LTB project's 2.4.44 release with the same results,
so I doubt this is a known bug (or even a bug at all), I think my
configuration is incorrect but I am currently incapable or seeing why.
Regards,
--
Ozgur Karatas###
# Global Directives:
# Features to permit
#allow bind_v2
# Schema and objectClass definitions
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/ppolicy.schema
# Where the pid file is put. The init.d script
# will not stop the server if you change this.
pidfile /var/run/slapd/slapd.pid
# List of arguments that were passed to the server
argsfile/var/run/slapd/slapd.args
# Read slapd.conf(5) for possible values
loglevelnone
# Where the dynamically loaded modules are stored
modulepath /usr/lib/ldap
moduleload back_mdb
# Load overlays
moduleload ppolicy
moduleload syncprov
# The maximum number of entries that is returned for a search operation
sizelimit 500
# The tool-threads parameter sets the actual amount of cpu's that is used
# for indexing.
tool-threads 1
# Default password hashing algorithm
password-hash {SSHA}
# The userPassword by default can be changed
# by the entry owning it if they are authenticated.
# Others should not be able to see it, except the
# admin entry below
# These access lines apply to database #1 only
access to attrs=userPassword,shadowLastChange
by dn="uid=mcerda,ou=people,dc=company,dc=com" write
by self write
by anonymous auth
by * none
# Ensure read access to the base for things like
# supportedSASLMechanisms. Without this you may
# have problems with SASL not knowing what
# mechanisms are available and the like.
# Note that this is covered by the 'access to *'
# ACL below too but if you change that as people
# are wont to do you'll still need this if you
# want SASL (and possible other things) to work
# happily.
access to dn.base="" by * read
# The admin dn has full write access, everyone else
# can read everything.
access to *
by dn="uid=mcerda,ou=people,dc=company,dc=com" write
by users read
by * none
# For Netscape Roaming support, each user gets a roaming
# profile for which they have write access to
#access to dn=".*,ou=Roaming,o=morsnet"
#by dn="
ppolicy overlay unable to set pwdAccountLockedTime on to-be-locked users due to ACLs
Hello folks,
I just stumbled upon a (maybe not) surprising technical issue with my
OpenLDAP setup: ppolicy seems unable to update pwdAccountLockedTime on
my users.
Setup:
* OpenLDAP 2.4.40(+dfsg-1+deb8u2) on Debian jessie
* Password policy and ACLs:
---8<---
dn: cn=default,ou=policies,dc=company,dc=com
objectClass: top
objectClass: person
objectClass: pwdPolicy
cn: passwordDefault
cn: default
pwdAttribute: userPassword
sn: passwordDefault
pwdAllowUserChange: TRUE
pwdCheckQuality: 0
pwdExpireWarning: 0
pwdFailureCountInterval: 0
pwdGraceAuthNLimit: 0
pwdInHistory: 3
pwdLockout: TRUE
pwdLockoutDuration: 300
pwdMaxAge: 0
pwdMaxFailure: 3
pwdMinAge: 0
pwdMinLength: 8
pwdMustChange: FALSE
pwdSafeModify: FALSE
---8<---
---8<---
access to attrs=userPassword,shadowLastChange
by dn="uid=mcerda,ou=people,dc=company,dc=com" write
by self write
by anonymous auth
by * none
access to dn.base="" by * read
access to *
by dn="uid=mcerda,ou=people,dc=company,dc=com" write
by users read
by * none
---8<---
* pwdFailureTime gets updated on each failed login attempt on users
until pwdMaxFailure is reached (3)
* Testing for account locking is done both by observing we appearance in
user object and using '-e ppolicy' on ldapsearch (ppolicy_use_lockout is
enabled)
Everytime an user reaches pwdMaxFailure count, the debug log (level
65535) gives:
---8<---
585947a5 => mdb_entry_get: found entry:
"cn=default,ou=policies,dc=company,dc=com"
585947a5 mdb_entry_get: rc=0
585947a5 mdb_modify: uid=fbar,ou=people,dc=company,dc=com
585947a5 slap_queue_csn: queueing 0x65696ef4bce0
20161220150053.705334Z#00#000#00
585947a5 mdb_dn2entry("uid=fbar,ou=people,dc=company,dc=com")
585947a5 => mdb_dn2id("uid=fbar,ou=people,dc=company,dc=com")
585947a5 <= mdb_dn2id: got id=0x9
585947a5 => mdb_entry_decode:
585947a5 <= mdb_entry_decode
585947a5 mdb_modify_internal: 0x0009:
uid=fbar,ou=people,dc=company,dc=com
585947a5 => access_allowed: result not in cache (pwdAccountLockedTime)
585947a5 => access_allowed: delete access to
"uid=fbar,ou=people,dc=company,dc=com" "pwdAccountLockedTime" requested
585947a5 => dn: [2]
585947a5 => acl_get: [3] attr pwdAccountLockedTime
585947a5 => acl_mask: access to entry
"uid=fbar,ou=people,dc=company,dc=com", attr "pwdAccountLockedTime"
requested
585947a5 => acl_mask: to all values by "", (=0)
585947a5 <= check a_dn_pat: uid=mcerda,ou=people,dc=company,dc=com
585947a5 <= check a_dn_pat: users
585947a5 <= check a_dn_pat: anonymous
585947a5 <= acl_mask: [3] applying read(=rscxd) (stop)
585947a5 <= acl_mask: [3] mask: read(=rscxd)
585947a5 => slap_access_allowed: delete access denied by read(=rscxd)
585947a5 => access_allowed: no more rules
585947a5 mdb_modify: modify failed (50)
585947a5 send_ldap_result: conn=1000 op=0 p=3
585947a5 send_ldap_result: err=50 matched="" text=""
585947a5 slap_graduate_commit_csn: removing 0x6569601047f0
20161220150053.705334Z#00#000#00
585947a5 send_ldap_response: msgid=1 tag=97 err=49
---8<---
I can't see a reason why the update gets denied. Setting the global ACL
to:
---8<---
access to *
by dn="uid=mcerda,ou=people,dc=company,dc=com" write
by * write
---8<---
fixes the issue (but I obviously not want an open bar slapd).
The documentation (http://www.openldap.org/doc/admin24/overlays.html)
advises nothing about ACLs.
Is this and issue or a misconfiguration ?
Thanks in advance,
--
Matthieu Cerda
