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
