directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Davis <mda...@rez1.com>
Subject RE: [ApacheDS] Password Policy not being enforced
Date Tue, 08 Aug 2017 14:16:28 GMT
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:sfahted@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: test@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 <mdavis@rez1.com> wrote:> Glad to be of help.>>
-----Original Message-----> From: Emmanuel Lécharny [mailto:elecharny@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 <mdavis@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:sfahted@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 <mdavis@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:sfahted@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: test@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:
test@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

Mime
View raw message