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=com
accessControlSubentries: 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=com
accessControlSubentries: 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=com
createTimestamp: 20170802133738.851Z
creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
entryCSN: 20170808045939.984000Z#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=manager,2.5.4.11=system *-*
modifyTimestamp: 20170808045939.335Z
nbChildren: 0
nbSubordinates: 0
pwdChangedTime: 20170808045939.331Z
pwdHistory:: MjAxNzA4MDgwMzU3MDguODU5WiMxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4
0MCM1NiNlMk55ZVhCMGZTUXhKRmxIZFM1TU5uYzJKRWxoZVhOS1QyODFZMjB4ZGxGemJUUlhXa0
00ZWpFPQ==
pwdHistory:: MjAxNzA4MDgwNDUyNTguNDA5WiMxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4
0MCM2NCNlMU5UU0VGOVNqWTRkMnBKVWxSNGJTOVVlREZTYzBabWRUSnRibVZ3UTBsa1dXaHBXRm
hJYlcxRlZVRTlQUT09
pwdHistory:: MjAxNzA4MDgwNDUzMjMuNTA4WiMxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4
0MCM1NiNlMk55ZVhCMGZTUXhKRWhxYzJGdFVqWXdKR0pDU0ZaNGFYRTNWbk5oYTNkb1ZEQk5hVE
5ETURFPQ==
pwdHistory:: MjAxNzA4MDgwNDUzNDIuMDA5WiMxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4
0MCM4I01USXpORFUy
pwdHistory:: MjAxNzA4MDgwNDUzNTcuNzM1WiMxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4
0MCM1NiNlMk55ZVhCMGZTUXhKR295U1RKNGJHVnhKRzFaZVZOemIySnhkMWxFU2tGYVQwaGlhMk
ZvVlM4PQ==
pwdHistory:: MjAxNzA4MDgwNDU5MzkuMzMxWiMxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4
0MCM1NiNlMk55ZVhCMGZTUXhKRWswY2xoVE9EQjRKSFJRU1dWRE9WUmFRMUJ1VUVsVmIxRlJia2
g2UXpFPQ==
subschemaSubentry: cn=schema
I experimented and modified/cnfigured the precriptiveACL for a test manager
user 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 enforce
is the pwdminage, I get this:
userPassword: 0x7B 0x63 0x72 0x79 0x70 0x74 0x7D 0x24 0x31 0x24 0x79 0x78
0x43 0x73 0x51 0x64
...org.apache.directory.api.ldap.model.message.ModifyRequestImpl@ed3df1c2:
password is too young to update
passwd: Permission denied
passwd: password unchanged.
Which is great, but it doesn't solve my problem.
Any further thoughts?
I appreciate the help.
Cheers
-Sam
On 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 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
> >>
> >
> >
>
> --
> Emmanuel Lecharny
>
> Symas.com
> directory.apache.org
>
>
--
Cheers
-Sam
