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

Reply via email to