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 honoring the 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 to LDAP. > 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
