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:[email protected]] Sent: Tuesday, August 08, 2017 1:21 AM To: [email protected] 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: [email protected] 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:: MjAxNzA4MDgwMzU3MDguODU5WiMxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4 0MCM1NiNlMk55ZVhCMGZTUXhKRmxIZFM1TU5uYzJKRWxoZVhOS1QyODFZMjB4ZGxGemJUUlhXa0 00ZWpFPQ==pwdHistory:: MjAxNzA4MDgwNDUyNTguNDA5WiMxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4 0MCM2NCNlMU5UU0VGOVNqWTRkMnBKVWxSNGJTOVVlREZTYzBabWRUSnRibVZ3UTBsa1dXaHBXRm hJYlcxRlZVRTlQUT09pwdHistory:: MjAxNzA4MDgwNDUzMjMuNTA4WiMxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4 0MCM1NiNlMk55ZVhCMGZTUXhKRWhxYzJGdFVqWXdKR0pDU0ZaNGFYRTNWbk5oYTNkb1ZEQk5hVE 5ETURFPQ==pwdHistory:: MjAxNzA4MDgwNDUzNDIuMDA5WiMxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4 0MCM4I01USXpORFUypwdHistory:: MjAxNzA4MDgwNDUzNTcuNzM1WiMxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4 0MCM1NiNlMk55ZVhCMGZTUXhKR295U1RKNGJHVnhKRzFaZVZOemIySnhkMWxFU2tGYVQwaGlhMk 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.ModifyRequestImpl@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 <[email protected]> wrote:> Glad to be of help.>> -----Original Message-----> From: Emmanuel Lécharny [mailto:[email protected]]> Sent: Monday, August 07, 2017 5:22 PM> To: [email protected]> 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 <[email protected]> wrote:> >> >> Hi Sam.> >>> >> I started with this> >> http://directory.apache.org/apacheds/advanced-ug/4.2.7.1-> >> enable-authenticated-users-to-browse-and-read-entries.html> >>> >> And this> >> http://directory.apache.org/apacheds/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:[email protected]]> >> Sent: Monday, August 07, 2017 2:16 PM> >> To: [email protected]> >> 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 <[email protected]> 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:[email protected]]> >>> Sent: Monday, August 07, 2017 1:44 PM> >>> To: [email protected]> >>> 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: [email protected]> >>> 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::> >>> MjAxNzA4MDQwNTM4NTQuNjA0WiMxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEu> >>> 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: [email protected]> >>> 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
