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 Mon, 07 Aug 2017 21:29:35 GMT
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 honoring the 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 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: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


Mime
View raw message