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=myorg,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.25=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 > 0MCM2NCNlMU5UU0VGOVNqWTRkMnBKVWxSNGJTOVVlREZTYzBabWRUSnRibVZ3UTBsa1dXaHBXRm > hJYlcxRlZVRTlQUT09pwdHistory:: MjAxNzA4MDgwNDUzMjMuNTA4WiMxLj > MuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4 0MCM1NiNlMk55ZVhCMGZTUXhKRWhxY > zJGdFVqWXdKR0pDU0ZaNGFYRTNWbk5oYTNkb1ZEQk5hVE 5ETURFPQ==pwdHistory:: > MjAxNzA4MDgwNDUzNDIuMDA5WiMxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4 > 0MCM4I01USXpORFUypwdHistory:: MjAxNzA4MDgwNDUzNTcuNzM1WiMxLj > MuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4 0MCM1NiNlMk55ZVhCMGZTUXhKR295U > 1RKNGJHVnhKRzFaZVZOemIySnhkMWxFU2tGYVQwaGlhMk ZvVlM4PQ==pwdHistory:: > MjAxNzA4MDgwNDU5MzkuMzMxWiMxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4 > 0MCM1NiNlMk55ZVhCMGZTUXhKRWswY2xoVE9EQjRKSFJRU1dWRE9WUmFRMUJ1VUVsVmIxRlJia2 > 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 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 > 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> >>>> > >>> 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>> Symas.com> > directory.apache.org>>--Cheers-Sam > -- Cheers -Sam
