Hi, Mike.
I'd tried this before and just set it to strict, again to illustrate what
happens. It seems it's not able to validate the password because it's not
stored clear-test and rejects the change.
That seems to be consistent with this explanation of the Quality Check
Policy:
"2: The password is checked, and if it's hashed or in a form that does not
allow the checks to be done, then the changes are rejected."
Here's what happens:
testuser@kudu-dev:~$ passwd
Enter login(LDAP) password:
New password:
Re-enter new password:
LDAP password information update failed: Constraint violation
CONSTRAINT_VIOLATION: failed for MessageType : MODIFY_REQUEST
Message ID : 9
Modify Request
Object : 'cn=redact,ou=users,dc=redact,dc=cloud,dc=myorg,dc=com'
Modification[0]
Operation : replace
Modification
userPassword: 0x7B 0x63 0x72 0x79 0x70 0x74 0x7D 0x24 0x31 0x24 0x75 0x35
0x47 0x74 0x4B 0x54
...org.apache.directory.api.ldap.model.message.ModifyRequestImpl@9990075:
cannot verify the quality of the non-cleartext passwords
passwd: Permission denied
passwd: password unchanged
On Tue, Aug 8, 2017 at 11:53 AM, Mike Davis <mda...@rez1.com> wrote:
> Hey, shot in the dark here, but I think it's this value in your password
> policy configuration.
>
> ads-pwdcheckquality: 1
>
> On my system, I have that set to 2. I believe 1 means relaxed, and if you
> send an already hashed password, it can't unhash it to validate it, and
> just
> assumes it's valid.
>
> See the "Password checks and strength enforcement" section here:
> http://directory.apache.org/apacheds/advanced-ug/4.3-password-policy.html
>
>
>
> -----Original Message-----
> From: Sambedi Fahted [mailto:sfah...@gmail.com]
> Sent: Tuesday, August 08, 2017 11:17 AM
> To: users@directory.apache.org
> Subject: Re: [ApacheDS] Password Policy not being enforced
>
> Hey, Mike.
> That's correct. MinAge *is* being enforced, but minLength is *not*.
>
> After changing the password on my Ubuntu machine (test ldap client), logged
> in as "testuser", the modifiersName shows up as:
> "0.9.2342.19200300.100.1.1=
> manager,2.5.4.11=system".
>
> Funny, the min/maxAge gets enforced for uid=manager,ou=system, as well. So
> it started to fail as the binddn, and logins to the linux machine stopped
> working. :-p
>
>
>
> On Tue, Aug 8, 2017 at 10:16 AM, Mike Davis <mda...@rez1.com> wrote:
>
> > Sam,
> >
> > Just to be clear, you're saying minAge IS being enforced, but
> > minLength is NOT?
> >
> > Who shows up as modifiersName on the record after you change the
> password?
> >
> > // Mike
> >
> > -----Original Message-----
> > From: Sambedi Fahted [mailto:sfah...@gmail.com]
> > Sent: Tuesday, August 08, 2017 1:21 AM
> > To: users@directory.apache.org
> > Subject: Re: [ApacheDS] Password Policy not being enforced
> >
> > Hi, Mike & Emmanuel.
> > Sorry, in advance, for the long message.
> >
> > So.. I'm not out of the woods yet, for some reason.
> >
> > I created the precriptiveACL:
> > {
> > identificationTag "enablEditForManager",
> > precedence 15,
> > authenticationLevel simple,
> > itemOrUserFirst userFirst:
> > {
> > userClasses
> > {
> > name { "uid=manager,ou=system" }
> > }
> > ,
> > userPermissions
> > {
> > {
> > protectedItems { allUserAttributeTypesAndValues },
> > grantsAndDenials
> > {
> > grantModify,
> > grantRename,
> > grantRead,
> > grantCompare,
> > grantReturnDN,
> > grantAdd,
> > grantBrowse,
> > grantFilterMatch,
> > grantRemove
> > }
> > }
> > ,
> > {
> > protectedItems { entry },
> > grantsAndDenials
> > {
> > grantModify,
> > grantRename,
> > grantRead,
> > grantCompare,
> > grantReturnDN,
> > grantAdd,
> > grantBrowse,
> > grantFilterMatch,
> > grantRemove
> > }
> > }
> > }
> > }
> > }
> >
> > I changed my /etc/ldap.conf to use the uid=manager,ou=system as binddn
> > and I'm able to change passwords, but it's still not enforcing the
> > minlength policy.
> >
> > Here's what the testuser ldif looks like now. As you can see the
> > modifier's name now reflects the manager user:
> >
> > dn: cn=testuser,ou=users,dc=redact,dc=cloud,dc=myorg,dc=com
> > objectClass: organizationalPerson
> > objectClass: person
> > objectClass: inetOrgPerson
> > objectClass: top
> > objectClass: posixAccount
> > cn: testuser
> > gidNumber: 500
> > homeDirectory: /home/users/testuser
> > sn: USer
> > uid: testuser
> > uidNumber: 1049
> > givenName: Test
> > loginShell: /bin/bash
> > mail: t...@myorg.com
> > userPassword::
> > e2NyeXB0fSQxJEk0clhTODB4JHRQSWVDOVRaQ1BuUElVb1FRbkh6QzE=
> > accessControlSubentries: 2.5.4.3=enableeditforself,0.9.
> > 2342.19200300.100.1.2
> >
> > 5=redact,0.9.2342.19200300.100.1.25=cloud,0.9.2342.19200300.100.1.25=m
> > yorg,0
> > .9.2342.19200300.100.1.25=comaccessControlSubentries:
> > 2.5.4.3=enableeditformanager,0.9.2342.19200300.100.
> > 1.25=redact,0.9.2342.19200300.100.1.25=cloud,0.9.2342.19200300.100.1.2
> > 5=fulcr
> > m,0.9.2342.19200300.100.1.25=comaccessControlSubentries:
> > 2.5.4.3=enableadminformanager,0.9.2342.19200300.100
> > .1.25=redact,0.9.2342.19200300.100.1.25=cloud,0.9.2342.19200300.100.1.
> > 25=fulc
> > rm,0.9.2342.19200300.100.1.25=comcreateTimestamp:
> > 20170802133738.851ZcreatorsName:
> > 0.9.2342.19200300.100.1.1=admin,2.5.4.11=systementryCSN:
> > 20170808045939.984000Z#000000#001#000000entryDN:
> > cn=testuser,ou=users,dc=redact,dc=cloud,dc=myorg,dc=comentryParentId:
> > b97b014f-2c00-4266-b578-1aa21053c437entryUUID::
> > YmFmNDI4YjQtYzMyYy00NGM0LThkNTUtNDM2OGZkMjU1N2I3*-* modifiersName:
> > 0.9.2342.19200300.100.1.1=manager,2.5.4.11=system *-*modifyTimestamp:
> > 20170808045939.335ZnbChildren: 0nbSubordinates: 0pwdChangedTime:
> > 20170808045939.331ZpwdHistory:: MjAxNzA4MDgwMzU3MDguODU5WiMxLj
> > MuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4 0MCM1NiNlMk55ZVhCMGZTUXhKRmxIZ
> > FM1TU5uYzJKRWxoZVhOS1QyODFZMjB4ZGxGemJUUlhXa0 00ZWpFPQ==pwdHistory::
> > MjAxNzA4MDgwNDUyNTguNDA5WiMxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4
> > 0MCM2NCNlMU5UU0VGOVNqWTRkMnBKVWxSNGJTOVVlREZTYzBabWRUSnRibVZ3UTBsa1dXa
> > HBXRm
> > hJYlcxRlZVRTlQUT09pwdHistory:: MjAxNzA4MDgwNDUzMjMuNTA4WiMxLj
> > MuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4 0MCM1NiNlMk55ZVhCMGZTUXhKRWhxY
> > zJGdFVqWXdKR0pDU0ZaNGFYRTNWbk5oYTNkb1ZEQk5hVE 5ETURFPQ==pwdHistory::
> > MjAxNzA4MDgwNDUzNDIuMDA5WiMxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4
> > 0MCM4I01USXpORFUypwdHistory:: MjAxNzA4MDgwNDUzNTcuNzM1WiMxLj
> > MuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4 0MCM1NiNlMk55ZVhCMGZTUXhKR295U
> > 1RKNGJHVnhKRzFaZVZOemIySnhkMWxFU2tGYVQwaGlhMk ZvVlM4PQ==pwdHistory::
> > MjAxNzA4MDgwNDU5MzkuMzMxWiMxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4
> > 0MCM1NiNlMk55ZVhCMGZTUXhKRWswY2xoVE9EQjRKSFJRU1dWRE9WUmFRMUJ1VUVsVmIxR
> > lJia2
> > g2UXpFPQ==subschemaSubentry: cn=schemaI experimented and
> > modified/cnfigured the precriptiveACL for a test manageruser I'd
> > created within the directory
> > structure,cn=manager,dc=redact,dc=cloud,dc=myorg,dc=com and I had the
> > same result:minlength and complexity not being enforced. The one thing
> > it does enforceis the pwdminage, I get this:userPassword: 0x7B 0x63
> > 0x72 0x79
> > 0x70 0x74 0x7D 0x24 0x31 0x24 0x79 0x780x43 0x73 0x51
> > 0x64...org.apache.directory.api.ldap.model.message.ModifyReq
> > uestImpl@ed3df1c2:password is too young to updatepasswd: Permission
> > deniedpasswd: password unchanged.Which is great, but it doesn't solve
> > my problem.Any further thoughts?I appreciate the help.Cheers-SamOn
> > Mon, Aug 7,
> > 2017 at 5:29 PM, Mike Davis <mda...@rez1.com> wrote:> Glad to be of
> > help.>> -----Original Message-----> From: Emmanuel Lécharny [mailto:
> > elecha...@gmail.com]> Sent: Monday, August 07, 2017 5:22 PM> To:
> > users@directory.apache.org> Subject: Re: [ApacheDS] Password Policy
> > not being enforced>> Many thanks Mike for having replied to this
> > question, it
> > totally> slipped under my view :/>>> And yes, I conform that the admin
> > totally> user
> > will bypass any passwordPolicy> controls, simply because this is the
> > only user able to rectify a bad> passwordPolicy configuration (well,
> > there are workarounds, but not on> a running server).>>> Le 07/08/2017
> > à 22:26, Sambedi Fahted a écrit :> > Thanks, Mike.> > I'll give this a
> > shot.> >> > On Mon, Aug 7, 2017 at 4:01 PM, Mike Davis
> > <mda...@rez1.com> wrote:> >>
> > >> Hi Sam.> >>> >> I started with this> >>
> > >> http://directory.apache.org/ap
> > acheds/advanced-ug/4.2.7.1-> >>
> > enable-authenticated-users-to-browse-and-read-entries.html>
> > >>> >> And this> >> http://directory.apache.org/ap
> > acheds/advanced-ug/4.2.7.2-> >> allow-self-password-modify.html> >>>
> > >> From there, I built my own accessControlSubentry with a new> >>
> > prescriptiveACI that looks something like this, scoped to> >>
> > ou=users,ou=system.> >>> >> {> >> identificationTag
> > "allowEditByApplicationAdmin",> >> precedence 15,> >>
> > authenticationLevel simple,> >> itemOrUserFirst userFirst:> >>
> {>
> > >> userClasses> >> {> >> name {
> > "uid=applicationAdmin,ou=system" }> >> }> >> ,> >>
> > userPermissions> >> {> >> {> >>
> > protectedItems { entry },> >> grantsAndDenials> >>
> > {> >> grantRemove,> >>
> > grantModify,> >> grantBrowse,> >>
> > grantFilterMatch,> >> grantRead,> >>
> > grantRename,> >> grantCompare,> >>
> > grantAdd,> >> grantReturnDN> >> }>
> > >> }> >> ,> >> {> >>
> > protectedItems { allUserAttributeTypesAndValues },> >>
> > grantsAndDenials> >> {> >>
> > grantRemove,> >> grantModify,> >>
> > grantBrowse,> >> grantFilterMatch,> >>
> > grantRead,> >> grantRename,> >>
> > grantCompare,> >> grantAdd,> >>
> > grantReturnDN> >> }> >> }> >> }> >>
> > }> >> }> >>> >> Be aware that there is a bug in ApacheDS that causes
> > some
> > issues> >> with doing this. Right now, once the user's password is
> > expired,> >> the password can't be changed (except by
> > uid=admin,ou=system),> >> because it tries to authenticate the user
> > before changing the> >> password, and that authentication fails. I
> > worked around that,> >> based on a conversation on this this group, by
> > using grace logins,> >> and coding to treat a grace login like an
> > expired, rather than honoringthe grace logins.> >>> >> // Mike> >>>
> > >>> >> -----Original
> > Message-----> >> From: Sambedi Fahted [mailto:sfah...@gmail.com]> >>
> > Sent: Monday, August 07, 2017 2:16 PM> >> To:
> > users@directory.apache.org>
> > >> Subject: Re: [ApacheDS] Password Policy not being enforced> >>> >>
> > >> Hi,
> > Mike.> >> Thanks for the quick response. Yes. my (ubuntu) system is
> > using
> > the> >> uid=admin,ou=system account in /etc/ldap.conf.> >>> >> What's
> > the> >> the
> > best way to create a user that would work for this?> >> Would I create
> > an account like ou=manager,ou=system, as an example?> >> Or would it
> > need to reside in the org's hierarchy, i.e.,> >>
> > cn=manager,ou=users,dc=redac,dc=cloud,dc=myorg,dc=com?>
> > >>> >> Thanks, again!> >>> >> Cheers> >> -Sam> >>> >> On Mon, Aug 7,
> > >>> >> 2017
> > at 1:57 PM, Mike Davis <mda...@rez1.com> wrote:> >>> >>> Hi Sam,> >>>>
> > >>> What credentials are you using to log in to the LDAP server? If>
> > >>> >>>
> > you are using uid=admin,ou=system, that user, from everything I've>
> > >>> been able to tell, can ignore the password policies. What I've>
> > >>> done is create a separate user that my applications use to log in
> > toLDAP.> >>> That user gets special rights to be able to change
> > passwords. In> >>> that case, the policies are enforced.> >>>> >>> //
> > Mike> >>>> >>> -----Original
> > Message-----> >>> From: Sambedi Fahted [mailto:sfah...@gmail.com]> >>>
> > Sent: Monday, August 07, 2017 1:44 PM> >>> To:
> > users@directory.apache.org>
> > >>> Subject: [ApacheDS] Password Policy not being enforced> >>>> >>>
> > >>> Sorry
> > if this creates a duplicate entry. I just read the> >>> instructions
> > for list etiquette and I want to honor that.> >>>> >>> Somewhat
> > reopening an old thread that went cold without a> >>> resolution, or
> > at least not one that works for me.> >>> I've created a password
> > policy and some test users and ApacheDS> >>> isn't enforcing the
> > password policies.> >>> I have the policy set to not allow passwords
> > longer than 9> >>> characters and from the linux host that's
> > configured to use the> >>> ApacheDS server, I can create a password
> > that's 6 characters long,> >>> that's as simple as "123456"> >>>> >>>
> > I'm using: Apacheds-2.0.0-M24> >>>> >>> I created the following
> > password policy:> >>> dn: ads-pwdid=default,ou=passwordPolicies,ads->
> > >>> interceptorId=authenticationIn> >>>> >>>
> > terceptor,ou=interceptors,ads-directoryServiceId=default,ou=config>
> > >>>
> > objectclass: ads-passwordPolicy> >>> objectclass: ads-base> >>>
> > objectclass: top> >>> ads-pwdattribute: userPassword> >>> ads-pwdid:
> > default> >>> ads-enabled: TRUE> >>> ads-pwdcheckquality: 1> >>>
> > ads-pwdexpirewarning: 600> >>> ads-pwdfailurecountinterval: 30> >>>
> > ads-pwdgraceauthnlimit: 3> >>> ads-pwdinhistory: 4> >>> ads-pwdlockout:
> > TRUE> >>> ads-pwdmaxage: 3600> >>> ads-pwdmaxfailure: 2> >>>
> > ads-pwdmaxlength: 10> >>> ads-pwdminage: 1800> >>> ads-pwdmindelay:
> > 600>
> > >>> ads-pwdminlength: 9> >>> ads-pwdvalidator:
> > org.apache.directory.server.> >>> core.api.authn.ppolicy.Default> >>>
> > PasswordValidator> >>>> >>> Here's the ldif export of a test user I
> > created. The operational> >>> attributes are created, as you can see,
> > but in addition to the min> >>> password length, the pwdmaxage isn't
> > enforced, either.> >>>> >>> dn:
> > cn=testuser,ou=users,dc=redac,dc=cloud,dc=myorg,dc=com>
> > >>> objectClass: organizationalPerson> >>> objectClass: person> >>>
> > objectClass: inetOrgPerson> >>> objectClass: top> >>> objectClass:
> > posixAccount> >>> cn: testuser> >>> gidNumber: 500> >>> homeDirectory:
> > /home/users/testuser> >>> sn: User> >>> uid: testuser> >>> uidNumber:
> > 1049>
> > >>> givenName: Test> >>> loginShell: /bin/bash> >>> mail:
> > >>> t...@myorg.com> userPassword::> >>>
> > >>> e2NyeXB0fSQxJG9UYWNpSUF3JDV2c0dqLnVHeUtpL0RpMXNMQVFTMDA=>
> > >>> createTimestamp: 20170802133738.851Z> >>> creatorsName:
> > 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system> >>> entryCSN:
> > 20170804213220.210000Z#000000#001#000000> >>> entryDN:
> > cn=testuser,ou=users,dc=redac,dc=cloud,dc=myorg,dc=com> >>>
> > entryParentId: b97b014f-2c00-4266-b578-1aa21053c437> >>> entryUUID::
> > YmFmNDI4YjQtYzMyYy00NGM0LThkNTUtNDM2OGZkMjU1N2I3> >>> modifiersName:
> > 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system> >>> modifyTimestamp:
> > 20170804203344.706Z> >>> nbChildren: 0> >>> nbSubordinates: 0> >>>
> > pwdChangedTime: 20170804203344.705Z> >>> pwdFailureTime:
> > 20170804213220.200Z> >>> pwdHistory::> >>>
> > MjAxNzA4MDQwNTM4NTQuNjA0WiMxLj
> > MuNi4xLjQuMS4xNDY2LjExNS4xMjEu> >>> MS4> >>>
> > 0MCM1NiNlMk55ZVhCMGZTUXhKRVZHTUM5Wk9VUmtKRTlwWWtkbWVXaEJSbk4> >>>
> > zZURkUVNWaEtRMF> >>> JNZFRFPQ==> >>> pwdHistory::> >>>
> > MjAxNzA4MDQxOTMwMzQuMDIxWiMxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEu> >>> MS4>
> > >>> 0MCM1NiNlMk55ZVhCMGZTUXhKSEkxTUU1RVJtNXhKR1F3ZVdaQlEwOU9Wa1Y> >>>
> > xUWxSeVR6RlBiam> >>> xJUXk4PQ==> >>> pwdHistory::> >>>
> > MjAxNzA4MDQyMDI4NDguODA2WiMxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEu> >>> MS4>
> > >>> 0MCM1NiNlMk55ZVhCMGZTUXhKRkpGTkRCSmQwcGxKRlIxVVU1MWFtRjZkaTl> >>>
> > zTVd3dkxqQk1kaT> >>> h4ZUM4PQ==> >>> pwdHistory::> >>>
> > MjAxNzA4MDQyMDMzNDQuNzA1WiMxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEu> >>> MS4>
> > >>> 0MCM1NiNlMk55ZVhCMGZTUXhKRzlVWVdOcFNVRjNKRFYyYzBkcUxuVkhlVXR> >>>
> > wTDBScE1YTk1RVk> >>> ZUTURBPQ==> >>> subschemaSubentry: cn=schema>
> > wTDBScE1YTk1RVk> >>> >>>>
> > >>> I think I'm missing one thing to make this work but I can't find>
> > >>> >>>
> > what that one thing.> >>> Can anyone please provide some insight?>
> > >>>> >>> ~~Incidentally.~~> >>>> >>> Even the pwdAccountLockedTime
> > operational attribute gets created> >>> after the allotted number of
> > bad login attempts, but despite that> >>> I am still able to log in
> > with the account with the correct password.> >>>> >>> dn:
> > cn=testuser,ou=users,dc=redact,dc=cloud,dc=myorg,dc=com>
> > >>> objectClass: organizationalPerson> >>> objectClass: person> >>>
> > objectClass: inetOrgPerson> >>> objectClass: top> >>> objectClass:
> > posixAccount> >>> cn: testuser> >>> gidNumber: 500> >>> homeDirectory:
> > /home/users/testuser> >>> sn: User> >>> uid: testuser> >>> uidNumber:
> > 1049>
> > >>> givenName: Test> >>> loginShell: /bin/bash> >>> mail:
> > >>> t...@myorg.com> userPassword::> >>>
> > >>> e2NyeXB0fSQxJG9UYWNpSUF3JDV2c0dqLnVHeUtpL0RpMXNMQVFTMDA=>
> > >>> createTimestamp: 20170802133738.851Z> >>> creatorsName:
> > 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system> >>> entryCSN:
> > 20170807173256.649000Z#000000#001#000000> >>> entryDN:
> > cn=testuser,ou=users,dc=redact,dc=cloud,dc=myorg,dc=com> >>>
> > entryParentId: b97b014f-2c00-4266-b578-1aa21053c437> >>> entryUUID::
> > YmFmNDI4YjQtYzMyYy00NGM0LThkNTUtNDM2OGZkMjU1N2I3> >>> modifiersName:
> > 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system> >>> modifyTimestamp:
> > 20170804203344.706Z> >>> nbChildren: 0> >>> nbSubordinates: 0> >>>
> > pwdAccountLockedTime: 20170807173256.648Z> >>> pwdChangedTime:
> > 20170804203344.705Z> >>> pwdFailureTime: 20170807173236.454Z> >>>
> > pwdFailureTime: 20170807173239.031Z> >>> pwdFailureTime:
> > 20170807173243.325Z> >>> pwdFailureTime: 20170807173249.384Z> >>>
> > pwdFailureTime: 20170807173252.878Z> >>> pwdFailureTime:
> > 20170807173256.648Z> >>>> >>> Thanks, again.> >>>> >>> -Sam> >>>> >>>
> > >>>
> > >> --> >> Cheers> >> -Sam> >>> >> >>> --> Emmanuel Lecharny>>
> > >> --> >> Cheers> >> -Sam> >>> >> >>> --> Symas.com>
> > directory.apache.org>>--Cheers-Sam
> >
>
>
>
> --
> Cheers
> -Sam
>
--
Cheers
-Sam
