Re: (ITS#8763) ACL scope warning
by ryan＠nardis.ca
Hi Claude,
Please use the openldap-technical(a)openldap.org mailing list for usage or
configuration questions. If you post your slapd.conf to the list I'm
sure someone will be able to point out the reason for the warning.
This ITS will be closed.
5 years, 11 months
(ITS#8763) ACL scope warning
by claude.dube＠muhc.mcgill.ca
Full_Name: Claude
Version: 2.4.45
OS: entOS Linux release 7.3.1611 (Core)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (198.168.152.20)
the slapd.conf openldap configuration file see below.
slapd daemon is issuing ACL scope warning for unknown reason that ACL is in the
slapd.conf
warning messages :
config_back_db_open: line 0: warning: cannot assess the validity of the ACL
scope within backend naming context
How that warning can be addressed?
Thanks
how to recreate warning messages based on slapd.conf below.
I'd like to get of rid of that ACL scope warning
Thanks, Claude
### - slapd is launched by this running command ###
/usr/sbin/slapd -d acl
#
# output of slapd daemon
#
59f51611 @(#) $OpenLDAP: slapd 2.4.45 (Sep 10 2017 16:37:12) $
root@templateldap:/a/admin/ldap/openldap-2.4.45/servers/slapd
59f51611 => access_allowed: search access to "cn=config" "objectClass"
requested
59f51611 <= root access granted
59f51611 => access_allowed: search access granted by manage(=mwrscxd)
59f51611 => access_allowed: search access to "cn=schema,cn=config" "objectClass"
requested
59f51611 <= root access granted
59f51611 => access_allowed: search access granted by manage(=mwrscxd)
59f51611 => access_allowed: search access to "cn={0}core,cn=schema,cn=config"
"objectClass" requested
59f51611 <= root access granted
59f51611 => access_allowed: search access granted by manage(=mwrscxd)
59f51611 => access_allowed: search access to "cn={1}cosine,cn=schema,cn=config"
"objectClass" requested
59f51611 <= root access granted
59f51611 => access_allowed: search access granted by manage(=mwrscxd)
59f51611 => access_allowed: search access to
"cn={2}inetorgperson,cn=schema,cn=config" "objectClass" requested
59f51611 <= root access granted
59f51611 => access_allowed: search access granted by manage(=mwrscxd)
59f51611 => access_allowed: search access to
"olcDatabase={-1}frontend,cn=config" "objectClass" requested
59f51611 <= root access granted
59f51611 => access_allowed: search access granted by manage(=mwrscxd)
Backend ACL: access to dn.base="dc=example,dc=com"
by * read
59f51611 => access_allowed: search access to "olcDatabase={0}config,cn=config"
"objectClass" requested
59f51611 <= root access granted
59f51611 => access_allowed: search access granted by manage(=mwrscxd)
Backend ACL: access to dn.base="cn=admin,cn=config"
by * none
59f51611 => access_allowed: search access to "olcDatabase={1}mdb,cn=config"
"objectClass" requested
59f51611 <= root access granted
59f51611 => access_allowed: search access granted by manage(=mwrscxd)
Backend ACL: access to dn.children="dc=example,dc=com"
by * search
Backend ACL: access to dn.base="dc=example,dc=com"
by * read
Backend ACL: access to *
by * none
59f51611 config_back_db_open: line 0: warning: cannot assess the validity of the
ACL scope within backend naming context
59f51611 slapd starting
#### - slapd.conf - #####
#
# NOTES: inetorgperson picks up attributes and objectclasses
# from all three schemas
#
# NB: RH Linux schemas in /etc/openldap
#
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
# NO REFERRALS
# DON'T bother with ARGS file
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
loglevel ACL
disallow bind_anon
#
#####################################
# frontend database
#####################################
#
access to dn.base="dc=example,dc=com" by * read
#######################################################################
# bdb database definitions
#
# replace example and com below with a suitable domain
#
# If you don't have a domain you can leave it since example.com
# is reserved for experimentation or change them to My and inc
#######################################################################
database mdb
#access to dn.base="dc=example,dc=com" by * read
access to dn.children="dc=example,dc=com" by * search
access to dn.base="dc=example,dc=com" by * read
suffix "dc=example, dc=com"
#
# superuser
rootdn "cn=jimbob, dc=example, dc=com"
rootpw dirtysecret
# The database directory MUST exist prior to running slapd AND
# change path as ncessary
directory /var/lib/ldap
# Indices to maintain for this directory
# required if searches will use
# unique id so equality match only
index uid eq
# allows general searching on commonname, givenname and email
index cn,gn,mail eq,sub
# allows multiple variants on surname searching
index sn eq,sub
# sub above includes subintial,subany,subfinal
# optimise department searches
index ou eq
# if searches will include objectClass uncomment following
# index objectClass eq
# shows use of default index parameter
index default eq,sub
# indices missing - uses default eq,sub
index telephonenumber
#
#####################################
# config database
#####################################
#
database config
access to dn.base="cn=admin,cn=config" by * none
rootdn "cn=admin,cn=config"
rootpw {SSHA}rZGfPJkJYWy036tqoQb9jZ4Tz36c7ddG
5 years, 11 months
RE: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailureTime
by mihai.munteanu＠thalesgroup.com
According to https://tools.ietf.org/html/draft-behera-ldap-password-policy-=
10 , chapter 5.2.13. pwdMaxFailure
This field is described as:
"This attribute specifies the number of consecutive failed bind attempts af=
ter which the password may not be used to authenticate."
In first case, when user is just created, for example, he can fail to login=
3 times and accounts get locked, which means the "password may not be used=
to authenticate", as stated above.
However, after admin unlocks the account, the user is still registered with=
3 failed bind attempts (the pwdFailureTime is not deleted) but now the use=
r can use the password to authenticate. This scenario contradicts the defin=
ition of pwdFailureTime.
Moreover, the pwdLockout attribute description says, on chapter 5.2.11 that=
" This attribute indicates, when its value is "TRUE", that the password ma=
y not be used to authenticate after a specified number of consecutive faile=
d bind attempts. The maximum number of consecutive failed bind attempts is=
specified in pwdMaxFailure."
In our password policy, pwdLockout is set to TRUE but after admin unlocks t=
est1 account, because pwdFailureTime is not cleared, it is considered that =
there are already 3 consecutive failed bind attempts, am I right?
However, in this case, the user is allowed to use the password for new auth=
entication which contradicts the definition of pwdLockout field.
Kind regards,
Mihai (+40213032732)=20
-----Original Message-----
From: Jon C Kidder [mailto:jckidder@aep.com]=20
Sent: Friday, October 27, 2017 2:46 PM
To: MUNTEANU Mihai-Adrian; openldap-its(a)OpenLDAP.org
Subject: RE: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdF=
ailureTime
This is not a bug.
pwdFailureTime is only cleared after the first successful bind. If you're =
manually unlocking the user's account it can be assumed that you've gone th=
rough the exercise of ensuring the user is using the proper password. Perh=
aps by setting a new temporary password? If you haven't gone through that =
exercise 1 attempt vs multiple attempts is not going to matter. The user i=
s going to lock their account again anyway.
We've just recently deployed a password self-service tool and have accounte=
d for this current behavior in our help desk procedures. Our cyber securit=
y team loves this behavior.
JON C KIDDER | MIDDLEWARE ADMINISTRATOR LEAD JCKIDDER(a)AEP.COM | D:614.716.4=
970
1 RIVERSIDE PLAZA, COLUMBUS, OH 43215
-----Original Message-----
From: openldap-bugs [mailto:openldap-bugs-bounces@openldap.org] On Behalf O=
f mihai.munteanu(a)thalesgroup.com
Sent: Friday, October 27, 2017 3:48 AM
To: openldap-its(a)OpenLDAP.org
Subject: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailu=
reTime
This is an EXTERNAL email. STOP. THINK before you CLICK links or OPEN attac=
hments. If suspicious please forward to incidents(a)aep.com for review.
**********************************************************************
Full_Name: Mihai Munteanu
Version: 2.4.44
OS: CentOS7 x64
URL: https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.openldap.org_=
incoming_&d=3DDwIBAg&c=3DgMbiD-Q9WoaRgoXZKCrSug&r=3DWacA_KdnzU1pvF8wEQ4v1A&=
m=3D3fgtnQphBlucWYzXakB6baAXEq2msUxFLlsMdi1aZQY&s=3DfE28OfhKUqMQkynWWNTkl9-=
sUN8henbPip3IgOunodI&e=3D
Submission from: (NULL) (86.12.190.162)
Scenario:=20
0. we have configured that after 3 login failed attempts, the account to be
locked.
1. user test1 fails to login 3 times -> account is locked
2. admin unlocks test1's account and notify test1 user
3. user test1 tries 1 time to login using a wrong password and gets his acc=
ount
locked again.
Expectation here: account should not be locked after first attempt of a wro=
ng
password, but after third attempt, as it was the case on step 1.=20
It turns out that it is locked again after first attempt due to the fact th=
at on
step 2, only pwdAccountLockedTime field is removed from LDAP, but not also
pwdFailureTime fields.
It seems pwdFailureTime is internally cleared only:
- when test1 successfully authenticate (having his account unlocked)
- admin changes test1's password
See below my details:
$>ldapsearch -x -b "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" +
...
pwdChangedTime: 20171027043554Z
pwdFailureTime: 20171027052019.225837Z
pwdFailureTime: 20171027052021.776604Z
pwdFailureTime: 20171027052024.436413Z
pwdAccountLockedTime: 20171027052024Z
entryCSN: 20171027055105.381686Z#000000#000#000000
...
$>cat unlock.ldif:
dn: cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom
changetype: modify
delete: pwdAccountLockedTime
-
delete: pwdFailureTime
$>ldapmodify -x -W -D "cn=3Dadmin,ou=3Dusers,dc=3Dthales,dc=3Dcom" -f unloc=
k.ldif
Enter LDAP Password:=20
modifying entry "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom"
ldap_modify: Constraint violation (19)
additional info: pwdFailureTime: no user modification allowed
$>cat unlock.ldif
dn: cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom
changetype: modify
delete: pwdAccountLockedTime
$>ldapmodify -x -W -D "cn=3Djamessmith,ou=3Dusers,dc=3Dthales,dc=3Dcom" -f =
unlock.ldif
Enter LDAP Password:=20
modifying entry "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom"
$>ldapsearch -x -b "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" +
...
pwdChangedTime: 20171027043554Z
pwdFailureTime: 20171027052019.225837Z
pwdFailureTime: 20171027052021.776604Z
pwdFailureTime: 20171027052024.436413Z
entryCSN: 20171027055105.381686Z#000000#000#000000
...
Result: pwdAccountLockedTime is removed but pwdFailureTime is not automatic=
ally
removed also.
Expected: since I'm not allowed to remove pwdFailureTime I would expect to =
be
automatically removed via removal of pwdAccountLockedTime.
5 years, 11 months
Re: (ITS#8762) Unlocking an account doesn't remove pwdFailureTime
by mihai.munteanu＠thalesgroup.com
--_000_73687a3a63cc4dd6950d893d7e7e73e9THSONEA01HUB06Ponegrp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
1. See below the contents of our password policy:
# Search scope: sub
# Search filter: (objectClass=3D*)
# Total entries: 1
#
# Generated by LDAP Account Manager
(http://www.ldap-account-manager.org) on October 27, 2017 10:48 am # Versio=
n: 5.5
version: 1
# Entry 1: cn=3DpasswordDefault,ou=3Dpolicies,dc=3Dthales,dc=3Dcom
dn: cn=3DpasswordDefault,ou=3Dpolicies,dc=3Dthales,dc=3Dcom
cn: passwordDefault
createtimestamp: 20171004124029Z
creatorsname: dc=3DManager,dc=3Dthales,dc=3Dcom
entrycsn: 20171004124029.795969Z#000000#000#000000
entrydn: cn=3DpasswordDefault,ou=3Dpolicies,dc=3Dthales,dc=3Dcom
entryuuid: f3031268-3d4c-1037-9198-453c4b052276
hassubordinates: FALSE
modifiersname: dc=3DManager,dc=3Dthales,dc=3Dcom
modifytimestamp: 20171004124029Z
objectclass: top
objectclass: device
objectclass: pwdPolicy
objectclass: pwdPolicyChecker
pwdallowuserchange: TRUE
pwdattribute: userPassword
pwdcheckmodule: check_password.so
pwdcheckquality: 2
pwdexpirewarning: 0
pwdfailurecountinterval: 0
pwdgraceauthnlimit: 0
pwdinhistory: 4
pwdlockout: TRUE
pwdlockoutduration: 0
pwdmaxage: 7776000
pwdmaxfailure: 3
pwdminage: 0
pwdminlength: 8
pwdmustchange: FALSE
pwdsafemodify: FALSE
structuralobjectclass: device
subschemasubentry: cn=3DSubschema
-----------------
2. we are using the lamcms from www.ldap-account-manager.org<http://www.lda=
p-account-manager.org>. In the web interface there is a "Unlock account" bu=
tton which we use. I suppose they are using the php ldap_modify() method in=
order to remove the 'pwdAccountLockedTime' field. Of course, temporary mod=
ifying their sources and trying to remove also the pwdFailureTime generates=
the following error:
"Was unable to remove attributes from DN: cn=3Dtest1,ou=3Dusers,dc=3Dthales=
,dc=3Dcom.
LDAP error, server says: Constraint violation - pwdFailureTime: no user mod=
ification allowed"
We've contact also guys from ldap-account-manager.org but they said they ca=
n't do anything on their side and suggested to contact you.
Kind regards,
Mihai
--_000_73687a3a63cc4dd6950d893d7e7e73e9THSONEA01HUB06Ponegrp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Arial","sans-serif";}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Arial","sans-serif";
color:windowtext;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Arial","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoPlainText>1. See below =
the contents of our password policy:<o:p></o:p></p><p class=3DMsoPlainText>=
# Search scope: sub<o:p></o:p></p><p class=3DMsoPlainText># Search filter: =
(objectClass=3D*)<o:p></o:p></p><p class=3DMsoPlainText># Total entries: 1<=
o:p></o:p></p><p class=3DMsoPlainText>#<o:p></o:p></p><p class=3DMsoPlainTe=
xt># Generated by LDAP Account Manager<o:p></o:p></p><p class=3DMsoPlainTex=
t>(<a href=3D"http://www.ldap-account-manager.org">http://www.ldap-account-=
manager.org</a>) on October 27, 2017 10:48 am # Version: 5.5<o:p></o:p></p>=
<p class=3DMsoPlainText><o:p> </o:p></p><p class=3DMsoPlainText>versio=
n: 1<o:p></o:p></p><p class=3DMsoPlainText><o:p> </o:p></p><p class=3D=
MsoPlainText># Entry 1: cn=3DpasswordDefault,ou=3Dpolicies,dc=3Dthales,dc=
=3Dcom<o:p></o:p></p><p class=3DMsoPlainText>dn: cn=3DpasswordDefault,ou=3D=
policies,dc=3Dthales,dc=3Dcom<o:p></o:p></p><p class=3DMsoPlainText>cn: pas=
swordDefault<o:p></o:p></p><p class=3DMsoPlainText>createtimestamp: 2017100=
4124029Z<o:p></o:p></p><p class=3DMsoPlainText>creatorsname: dc=3DManager,d=
c=3Dthales,dc=3Dcom<o:p></o:p></p><p class=3DMsoPlainText>entrycsn: 2017100=
4124029.795969Z#000000#000#000000<o:p></o:p></p><p class=3DMsoPlainText>ent=
rydn: cn=3DpasswordDefault,ou=3Dpolicies,dc=3Dthales,dc=3Dcom<o:p></o:p></p=
><p class=3DMsoPlainText>entryuuid: f3031268-3d4c-1037-9198-453c4b052276<o:=
p></o:p></p><p class=3DMsoPlainText>hassubordinates: FALSE<o:p></o:p></p><p=
class=3DMsoPlainText>modifiersname: dc=3DManager,dc=3Dthales,dc=3Dcom<o:p>=
</o:p></p><p class=3DMsoPlainText>modifytimestamp: 20171004124029Z<o:p></o:=
p></p><p class=3DMsoPlainText>objectclass: top<o:p></o:p></p><p class=3DMso=
PlainText>objectclass: device<o:p></o:p></p><p class=3DMsoPlainText>objectc=
lass: pwdPolicy<o:p></o:p></p><p class=3DMsoPlainText>objectclass: pwdPolic=
yChecker<o:p></o:p></p><p class=3DMsoPlainText>pwdallowuserchange: TRUE<o:p=
></o:p></p><p class=3DMsoPlainText>pwdattribute: userPassword<o:p></o:p></p=
><p class=3DMsoPlainText>pwdcheckmodule: check_password.so<o:p></o:p></p><p=
class=3DMsoPlainText>pwdcheckquality: 2<o:p></o:p></p><p class=3DMsoPlainT=
ext>pwdexpirewarning: 0<o:p></o:p></p><p class=3DMsoPlainText>pwdfailurecou=
ntinterval: 0<o:p></o:p></p><p class=3DMsoPlainText>pwdgraceauthnlimit: 0<o=
:p></o:p></p><p class=3DMsoPlainText>pwdinhistory: 4<o:p></o:p></p><p class=
=3DMsoPlainText>pwdlockout: TRUE<o:p></o:p></p><p class=3DMsoPlainText>pwdl=
ockoutduration: 0<o:p></o:p></p><p class=3DMsoPlainText>pwdmaxage: 7776000<=
o:p></o:p></p><p class=3DMsoPlainText>pwdmaxfailure: 3<o:p></o:p></p><p cla=
ss=3DMsoPlainText>pwdminage: 0<o:p></o:p></p><p class=3DMsoPlainText>pwdmin=
length: 8<o:p></o:p></p><p class=3DMsoPlainText>pwdmustchange: FALSE<o:p></=
o:p></p><p class=3DMsoPlainText>pwdsafemodify: FALSE<o:p></o:p></p><p class=
=3DMsoPlainText>structuralobjectclass: device<o:p></o:p></p><p class=3DMsoP=
lainText>subschemasubentry: cn=3DSubschema<o:p></o:p></p><p class=3DMsoPlai=
nText><o:p> </o:p></p><p class=3DMsoPlainText>-----------------<o:p></=
o:p></p><p class=3DMsoPlainText>2. we are using the lamcms from <a href=3D"=
http://www.ldap-account-manager.org">www.ldap-account-manager.org</a>. In t=
he web interface there is a "Unlock account" button which we use.=
I suppose they are using the php ldap_modify() method in order to remove t=
he 'pwdAccountLockedTime' field. Of course, temporary modifying their sourc=
es and trying to remove also the pwdFailureTime generates the following err=
or: <o:p></o:p></p><p class=3DMsoPlainText>"Was unable to remove attri=
butes from DN: cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom.<o:p></o:p></p><p=
class=3DMsoPlainText>LDAP error, server says: Constraint violation - pwdFa=
ilureTime: no user modification allowed"<o:p></o:p></p><p class=3DMsoP=
lainText>We've contact also guys from ldap-account-manager.org but they sai=
d they can't do anything on their side and suggested to contact you.<o:p></=
o:p></p><p class=3DMsoNormal><span style=3D'font-family:"Arial","sans-serif=
"'><o:p> </o:p></span></p><p class=3DMsoNormal><span style=3D'font-fam=
ily:"Arial","sans-serif"'><o:p> </o:p></span></p><p class=3DMsoNormal>=
Kind regards,<o:p></o:p></p><p class=3DMsoNormal>Mihai<o:p></o:p></p><p cla=
ss=3DMsoNormal><o:p> </o:p></p></div></body></html>=
--_000_73687a3a63cc4dd6950d893d7e7e73e9THSONEA01HUB06Ponegrp_--
5 years, 11 months
RE: (ITS#8762) Unlocking an account doesn't remove pwdFailureTime
by mihai.munteanu＠thalesgroup.com
--_002_D204E7513BE6154188ADA82EFFA18AC69B58B3FFFFTHSONEA01CMS0_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
DQoNCjEuIFNlZSBhdHRhY2hlZCBhbmQgYmVsb3cgdGhlIGNvbnRlbnRzIG9mIG91ciBwYXNzd29y
ZCBwb2xpY3k6DQojIFNlYXJjaCBzY29wZTogc3ViDQojIFNlYXJjaCBmaWx0ZXI6IChvYmplY3RD
bGFzcz0qKQ0KIyBUb3RhbCBlbnRyaWVzOiAxDQojDQojIEdlbmVyYXRlZCBieSBMREFQIEFjY291
bnQgTWFuYWdlcg0KKGh0dHA6Ly93d3cubGRhcC1hY2NvdW50LW1hbmFnZXIub3JnKSBvbiBPY3Rv
YmVyIDI3LCAyMDE3IDEwOjQ4IGFtICMgVmVyc2lvbjogNS41DQoNCnZlcnNpb246IDENCg0KIyBF
bnRyeSAxOiBjbj1wYXNzd29yZERlZmF1bHQsb3U9cG9saWNpZXMsZGM9dGhhbGVzLGRjPWNvbQ0K
ZG46IGNuPXBhc3N3b3JkRGVmYXVsdCxvdT1wb2xpY2llcyxkYz10aGFsZXMsZGM9Y29tDQpjbjog
cGFzc3dvcmREZWZhdWx0DQpjcmVhdGV0aW1lc3RhbXA6IDIwMTcxMDA0MTI0MDI5Wg0KY3JlYXRv
cnNuYW1lOiBkYz1NYW5hZ2VyLGRjPXRoYWxlcyxkYz1jb20NCmVudHJ5Y3NuOiAyMDE3MTAwNDEy
NDAyOS43OTU5NjlaIzAwMDAwMCMwMDAjMDAwMDAwDQplbnRyeWRuOiBjbj1wYXNzd29yZERlZmF1
bHQsb3U9cG9saWNpZXMsZGM9dGhhbGVzLGRjPWNvbQ0KZW50cnl1dWlkOiBmMzAzMTI2OC0zZDRj
LTEwMzctOTE5OC00NTNjNGIwNTIyNzYNCmhhc3N1Ym9yZGluYXRlczogRkFMU0UNCm1vZGlmaWVy
c25hbWU6IGRjPU1hbmFnZXIsZGM9dGhhbGVzLGRjPWNvbQ0KbW9kaWZ5dGltZXN0YW1wOiAyMDE3
MTAwNDEyNDAyOVoNCm9iamVjdGNsYXNzOiB0b3ANCm9iamVjdGNsYXNzOiBkZXZpY2UNCm9iamVj
dGNsYXNzOiBwd2RQb2xpY3kNCm9iamVjdGNsYXNzOiBwd2RQb2xpY3lDaGVja2VyDQpwd2RhbGxv
d3VzZXJjaGFuZ2U6IFRSVUUNCnB3ZGF0dHJpYnV0ZTogdXNlclBhc3N3b3JkDQpwd2RjaGVja21v
ZHVsZTogY2hlY2tfcGFzc3dvcmQuc28NCnB3ZGNoZWNrcXVhbGl0eTogMg0KcHdkZXhwaXJld2Fy
bmluZzogMA0KcHdkZmFpbHVyZWNvdW50aW50ZXJ2YWw6IDANCnB3ZGdyYWNlYXV0aG5saW1pdDog
MA0KcHdkaW5oaXN0b3J5OiA0DQpwd2Rsb2Nrb3V0OiBUUlVFDQpwd2Rsb2Nrb3V0ZHVyYXRpb246
IDANCnB3ZG1heGFnZTogNzc3NjAwMA0KcHdkbWF4ZmFpbHVyZTogMw0KcHdkbWluYWdlOiAwDQpw
d2RtaW5sZW5ndGg6IDgNCnB3ZG11c3RjaGFuZ2U6IEZBTFNFDQpwd2RzYWZlbW9kaWZ5OiBGQUxT
RQ0Kc3RydWN0dXJhbG9iamVjdGNsYXNzOiBkZXZpY2UNCnN1YnNjaGVtYXN1YmVudHJ5OiBjbj1T
dWJzY2hlbWENCg0KLS0tLS0tLS0tLS0tLS0tLS0NCjIuIHdlIGFyZSB1c2luZyB0aGUgbGFtY21z
IGZyb20gd3d3LmxkYXAtYWNjb3VudC1tYW5hZ2VyLm9yZy4gSW4gdGhlIHdlYiBpbnRlcmZhY2Ug
dGhlcmUgaXMgYSAiVW5sb2NrIGFjY291bnQiIGJ1dHRvbiB3aGljaCB3ZSB1c2UuIEkgc3VwcG9z
ZSB0aGV5IGFyZSB1c2luZyB0aGUgcGhwIGxkYXBfbW9kaWZ5KCkgbWV0aG9kIGluIG9yZGVyIHRv
IHJlbW92ZSB0aGUgJ3B3ZEFjY291bnRMb2NrZWRUaW1lJyBmaWVsZC4gT2YgY291cnNlLCB0ZW1w
b3JhcnkgbW9kaWZ5aW5nIHRoZWlyIHNvdXJjZXMgYW5kIHRyeWluZyB0byByZW1vdmUgYWxzbyB0
aGUgcHdkRmFpbHVyZVRpbWUgZ2VuZXJhdGVzIHRoZSBmb2xsb3dpbmcgZXJyb3I6IA0KIldhcyB1
bmFibGUgdG8gcmVtb3ZlIGF0dHJpYnV0ZXMgZnJvbSBETjogY249dGVzdDEsb3U9dXNlcnMsZGM9
dGhhbGVzLGRjPWNvbS4NCkxEQVAgZXJyb3IsIHNlcnZlciBzYXlzOiBDb25zdHJhaW50IHZpb2xh
dGlvbiAtIHB3ZEZhaWx1cmVUaW1lOiBubyB1c2VyIG1vZGlmaWNhdGlvbiBhbGxvd2VkIg0KV2Un
dmUgY29udGFjdCBhbHNvIGd1eXMgZnJvbSBsZGFwLWFjY291bnQtbWFuYWdlci5vcmcgYnV0IHRo
ZXkgc2FpZCB0aGV5IGNhbid0IGRvIGFueXRoaW5nIG9uIHRoZWlyIHNpZGUgYW5kIHN1Z2dlc3Rl
ZCB0byBjb250YWN0IHlvdS4NCg0KDQpLaW5kIHJlZ2FyZHMsDQpNaWhhaSAoKzQwMjEzMDMyNzMy
KSANCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWljaGFlbCBTdHLDtmRl
ciBbbWFpbHRvOm1pY2hhZWxAc3Ryb2VkZXIuY29tXSANClNlbnQ6IEZyaWRheSwgT2N0b2JlciAy
NywgMjAxNyAxMTo1MyBBTQ0KVG86IE1VTlRFQU5VIE1paGFpLUFkcmlhbjsgb3BlbmxkYXAtaXRz
QE9wZW5MREFQLm9yZw0KU3ViamVjdDogUmU6IChJVFMjODc2MikgVW5sb2NraW5nIGFuIGFjY291
bnQgZG9lc24ndCByZW1vdmUgcHdkRmFpbHVyZVRpbWUNCg0KbWloYWkubXVudGVhbnVAdGhhbGVz
Z3JvdXAuY29tIHdyb3RlOg0KPiBTY2VuYXJpbzogDQo+IDAuIHdlIGhhdmUgY29uZmlndXJlZCB0
aGF0IGFmdGVyIDMgbG9naW4gZmFpbGVkIGF0dGVtcHRzLCB0aGUgYWNjb3VudCANCj4gdG8gYmUg
bG9ja2VkLg0KPiAxLiB1c2VyIHRlc3QxIGZhaWxzIHRvIGxvZ2luIDMgdGltZXMgLT4gYWNjb3Vu
dCBpcyBsb2NrZWQNCg0KUGxlYXNlIHByb3ZpZGUgdGhlIHBhc3N3b3JkIHBvbGljeSBhcyBMRElG
Lg0KDQo+IDIuIGFkbWluIHVubG9ja3MgdGVzdDEncyBhY2NvdW50IGFuZCBub3RpZnkgdGVzdDEg
dXNlcg0KDQpXaGljaCBleGFjdCBMREFQIG9wZXJhdGlvbiBpcyBkb25lIHdoZW4gImFkbWluIHVu
bG9ja3MgdGVzdDEncyBhY2NvdW50Ii4NCkFyZSB5b3UganVzdCByZW1vdmluZyAncHdkQWNjb3Vu
dExvY2tlZFRpbWUnPw0KDQpJJ20gYXNraW5nIGJlY2F1c2UgdGhlcmUgbWlnaHQgYmUgYSBtaXN1
bmRlcnN0YW5kaW5nIGhvdyB0aGF0IGlzIHN1cHBvc2VkIHRvIHdvcmsuIEluIHRoaXMgY2FzZSBp
dCdzIGFuIHVzYWdlIHF1ZXN0aW9uIGJldHRlciB0byBiZSBkaXNjdXNzZWQgb24gb3BlbmxkYXAt
dGVjaG5pY2FsIG1haWxpbmcgbGlzdC4NCg0KQ2lhbywgTWljaGFlbC4NCg==
--_002_D204E7513BE6154188ADA82EFFA18AC69B58B3FFFFTHSONEA01CMS0_
Content-Type: application/octet-stream; name="pwdPolicy.ldif"
Content-Description: pwdPolicy.ldif
Content-Disposition: attachment; filename="pwdPolicy.ldif"; size=1196;
creation-date="Fri, 27 Oct 2017 12:49:45 GMT";
modification-date="Fri, 27 Oct 2017 12:50:00 GMT"
Content-Transfer-Encoding: base64
IyBTZWFyY2ggc2NvcGU6IHN1Yg0KIyBTZWFyY2ggZmlsdGVyOiAob2JqZWN0Q2xhc3M9KikNCiMg
VG90YWwgZW50cmllczogMQ0KIw0KIyBHZW5lcmF0ZWQgYnkgTERBUCBBY2NvdW50IE1hbmFnZXIN
CihodHRwOi8vd3d3LmxkYXAtYWNjb3VudC1tYW5hZ2VyLm9yZykgb24gT2N0b2JlciAyNywgMjAx
NyAxMDo0OCBhbSAjIFZlcnNpb246IDUuNQ0KDQp2ZXJzaW9uOiAxDQoNCiMgRW50cnkgMTogY249
cGFzc3dvcmREZWZhdWx0LG91PXBvbGljaWVzLGRjPXRoYWxlcyxkYz1jb20NCmRuOiBjbj1wYXNz
d29yZERlZmF1bHQsb3U9cG9saWNpZXMsZGM9dGhhbGVzLGRjPWNvbQ0KY246IHBhc3N3b3JkRGVm
YXVsdA0KY3JlYXRldGltZXN0YW1wOiAyMDE3MTAwNDEyNDAyOVoNCmNyZWF0b3JzbmFtZTogZGM9
TWFuYWdlcixkYz10aGFsZXMsZGM9Y29tDQplbnRyeWNzbjogMjAxNzEwMDQxMjQwMjkuNzk1OTY5
WiMwMDAwMDAjMDAwIzAwMDAwMA0KZW50cnlkbjogY249cGFzc3dvcmREZWZhdWx0LG91PXBvbGlj
aWVzLGRjPXRoYWxlcyxkYz1jb20NCmVudHJ5dXVpZDogZjMwMzEyNjgtM2Q0Yy0xMDM3LTkxOTgt
NDUzYzRiMDUyMjc2DQpoYXNzdWJvcmRpbmF0ZXM6IEZBTFNFDQptb2RpZmllcnNuYW1lOiBkYz1N
YW5hZ2VyLGRjPXRoYWxlcyxkYz1jb20NCm1vZGlmeXRpbWVzdGFtcDogMjAxNzEwMDQxMjQwMjla
DQpvYmplY3RjbGFzczogdG9wDQpvYmplY3RjbGFzczogZGV2aWNlDQpvYmplY3RjbGFzczogcHdk
UG9saWN5DQpvYmplY3RjbGFzczogcHdkUG9saWN5Q2hlY2tlcg0KcHdkYWxsb3d1c2VyY2hhbmdl
OiBUUlVFDQpwd2RhdHRyaWJ1dGU6IHVzZXJQYXNzd29yZA0KcHdkY2hlY2ttb2R1bGU6IGNoZWNr
X3Bhc3N3b3JkLnNvDQpwd2RjaGVja3F1YWxpdHk6IDINCnB3ZGV4cGlyZXdhcm5pbmc6IDANCnB3
ZGZhaWx1cmVjb3VudGludGVydmFsOiAwDQpwd2RncmFjZWF1dGhubGltaXQ6IDANCnB3ZGluaGlz
dG9yeTogNA0KcHdkbG9ja291dDogVFJVRQ0KcHdkbG9ja291dGR1cmF0aW9uOiAwDQpwd2RtYXhh
Z2U6IDc3NzYwMDANCnB3ZG1heGZhaWx1cmU6IDMNCnB3ZG1pbmFnZTogMA0KcHdkbWlubGVuZ3Ro
OiA4DQpwd2RtdXN0Y2hhbmdlOiBGQUxTRQ0KcHdkc2FmZW1vZGlmeTogRkFMU0UNCnN0cnVjdHVy
YWxvYmplY3RjbGFzczogZGV2aWNlDQpzdWJzY2hlbWFzdWJlbnRyeTogY249U3Vic2NoZW1hDQo=
--_002_D204E7513BE6154188ADA82EFFA18AC69B58B3FFFFTHSONEA01CMS0_--
5 years, 11 months
RE: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailureTime
by jckidder＠aep.com
This is not a bug.
pwdFailureTime is only cleared after the first successful bind. If you're =
manually unlocking the user's account it can be assumed that you've gone th=
rough the exercise of ensuring the user is using the proper password. Perh=
aps by setting a new temporary password? If you haven't gone through that =
exercise 1 attempt vs multiple attempts is not going to matter. The user i=
s going to lock their account again anyway.
We've just recently deployed a password self-service tool and have accounte=
d for this current behavior in our help desk procedures. Our cyber securit=
y team loves this behavior.
JON C KIDDER | MIDDLEWARE ADMINISTRATOR LEAD
JCKIDDER(a)AEP.COM | D:614.716.4970
1 RIVERSIDE PLAZA, COLUMBUS, OH 43215
-----Original Message-----
From: openldap-bugs [mailto:openldap-bugs-bounces@openldap.org] On Behalf O=
f mihai.munteanu(a)thalesgroup.com
Sent: Friday, October 27, 2017 3:48 AM
To: openldap-its(a)OpenLDAP.org
Subject: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailu=
reTime
This is an EXTERNAL email. STOP. THINK before you CLICK links or OPEN attac=
hments. If suspicious please forward to incidents(a)aep.com for review.
**********************************************************************
Full_Name: Mihai Munteanu
Version: 2.4.44
OS: CentOS7 x64
URL: https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.openldap.org_=
incoming_&d=3DDwIBAg&c=3DgMbiD-Q9WoaRgoXZKCrSug&r=3DWacA_KdnzU1pvF8wEQ4v1A&=
m=3D3fgtnQphBlucWYzXakB6baAXEq2msUxFLlsMdi1aZQY&s=3DfE28OfhKUqMQkynWWNTkl9-=
sUN8henbPip3IgOunodI&e=3D=20
Submission from: (NULL) (86.12.190.162)
Scenario:=20
0. we have configured that after 3 login failed attempts, the account to be
locked.
1. user test1 fails to login 3 times -> account is locked
2. admin unlocks test1's account and notify test1 user
3. user test1 tries 1 time to login using a wrong password and gets his acc=
ount
locked again.
Expectation here: account should not be locked after first attempt of a wro=
ng
password, but after third attempt, as it was the case on step 1.=20
It turns out that it is locked again after first attempt due to the fact th=
at on
step 2, only pwdAccountLockedTime field is removed from LDAP, but not also
pwdFailureTime fields.
It seems pwdFailureTime is internally cleared only:
- when test1 successfully authenticate (having his account unlocked)
- admin changes test1's password
See below my details:
$>ldapsearch -x -b "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" +
...
pwdChangedTime: 20171027043554Z
pwdFailureTime: 20171027052019.225837Z
pwdFailureTime: 20171027052021.776604Z
pwdFailureTime: 20171027052024.436413Z
pwdAccountLockedTime: 20171027052024Z
entryCSN: 20171027055105.381686Z#000000#000#000000
...
$>cat unlock.ldif:
dn: cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom
changetype: modify
delete: pwdAccountLockedTime
-
delete: pwdFailureTime
$>ldapmodify -x -W -D "cn=3Dadmin,ou=3Dusers,dc=3Dthales,dc=3Dcom" -f unloc=
k.ldif
Enter LDAP Password:=20
modifying entry "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom"
ldap_modify: Constraint violation (19)
additional info: pwdFailureTime: no user modification allowed
$>cat unlock.ldif
dn: cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom
changetype: modify
delete: pwdAccountLockedTime
$>ldapmodify -x -W -D "cn=3Djamessmith,ou=3Dusers,dc=3Dthales,dc=3Dcom" -f =
unlock.ldif
Enter LDAP Password:=20
modifying entry "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom"
$>ldapsearch -x -b "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" +
...
pwdChangedTime: 20171027043554Z
pwdFailureTime: 20171027052019.225837Z
pwdFailureTime: 20171027052021.776604Z
pwdFailureTime: 20171027052024.436413Z
entryCSN: 20171027055105.381686Z#000000#000#000000
...
Result: pwdAccountLockedTime is removed but pwdFailureTime is not automatic=
ally
removed also.
Expected: since I'm not allowed to remove pwdFailureTime I would expect to =
be
automatically removed via removal of pwdAccountLockedTime.
5 years, 11 months
Re: (ITS#8762) Unlocking an account doesn't remove pwdFailureTime
by michael＠stroeder.com
mihai.munteanu(a)thalesgroup.com wrote:
> Scenario:
> 0. we have configured that after 3 login failed attempts, the account to be
> locked.
> 1. user test1 fails to login 3 times -> account is locked
Please provide the password policy as LDIF.
> 2. admin unlocks test1's account and notify test1 user
Which exact LDAP operation is done when "admin unlocks test1's account".
Are you just removing 'pwdAccountLockedTime'?
I'm asking because there might be a misunderstanding how that is
supposed to work. In this case it's an usage question better to be
discussed on openldap-technical mailing list.
Ciao, Michael.
5 years, 11 months
(ITS#8762) Unlocking an account doesn't remove pwdFailureTime
by mihai.munteanu＠thalesgroup.com
Full_Name: Mihai Munteanu
Version: 2.4.44
OS: CentOS7 x64
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (86.12.190.162)
Scenario:
0. we have configured that after 3 login failed attempts, the account to be
locked.
1. user test1 fails to login 3 times -> account is locked
2. admin unlocks test1's account and notify test1 user
3. user test1 tries 1 time to login using a wrong password and gets his account
locked again.
Expectation here: account should not be locked after first attempt of a wrong
password, but after third attempt, as it was the case on step 1.
It turns out that it is locked again after first attempt due to the fact that on
step 2, only pwdAccountLockedTime field is removed from LDAP, but not also
pwdFailureTime fields.
It seems pwdFailureTime is internally cleared only:
- when test1 successfully authenticate (having his account unlocked)
- admin changes test1's password
See below my details:
$>ldapsearch -x -b "cn=test1,ou=users,dc=thales,dc=com" +
...
pwdChangedTime: 20171027043554Z
pwdFailureTime: 20171027052019.225837Z
pwdFailureTime: 20171027052021.776604Z
pwdFailureTime: 20171027052024.436413Z
pwdAccountLockedTime: 20171027052024Z
entryCSN: 20171027055105.381686Z#000000#000#000000
...
$>cat unlock.ldif:
dn: cn=test1,ou=users,dc=thales,dc=com
changetype: modify
delete: pwdAccountLockedTime
-
delete: pwdFailureTime
$>ldapmodify -x -W -D "cn=admin,ou=users,dc=thales,dc=com" -f unlock.ldif
Enter LDAP Password:
modifying entry "cn=test1,ou=users,dc=thales,dc=com"
ldap_modify: Constraint violation (19)
additional info: pwdFailureTime: no user modification allowed
$>cat unlock.ldif
dn: cn=test1,ou=users,dc=thales,dc=com
changetype: modify
delete: pwdAccountLockedTime
$>ldapmodify -x -W -D "cn=jamessmith,ou=users,dc=thales,dc=com" -f unlock.ldif
Enter LDAP Password:
modifying entry "cn=test1,ou=users,dc=thales,dc=com"
$>ldapsearch -x -b "cn=test1,ou=users,dc=thales,dc=com" +
...
pwdChangedTime: 20171027043554Z
pwdFailureTime: 20171027052019.225837Z
pwdFailureTime: 20171027052021.776604Z
pwdFailureTime: 20171027052024.436413Z
entryCSN: 20171027055105.381686Z#000000#000#000000
...
Result: pwdAccountLockedTime is removed but pwdFailureTime is not automatically
removed also.
Expected: since I'm not allowed to remove pwdFailureTime I would expect to be
automatically removed via removal of pwdAccountLockedTime.
5 years, 11 months
(ITS#8761) Comment for SLAPD_OVER_RETCODE define in portable.h is incorrect
by metzen＠gmail.com
Full_Name: Matt McDonald
Version:
OS:
URL:
Submission from: (NULL) (2601:282:b01:175b:359:7f8e:53e6:7341)
The comment for the SLAPD_OVER_RETCODE entry in include/portable.hin incorrectly
describes it as the "Referential Integrity" overlay, when it should indicate the
"return code" overlay.
diff --git a/include/portable.hin b/include/portable.hin
index 3b17ccf04..3e340b6c7 100644
--- a/include/portable.hin
+++ b/include/portable.hin
@@ -1020,7 +1020,7 @@
/* define for Referential Integrity overlay */
#undef SLAPD_OVER_REFINT
-/* define for Referential Integrity overlay */
+/* define for return code overlay */
#undef SLAPD_OVER_RETCODE
/* define for Rewrite/Remap overlay */
5 years, 11 months
