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:: 
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 <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/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: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::> >>> 
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: 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

Reply via email to