I did use difok to solve the issue. Thanks.
On Thu, May 29, 2014 at 1:42 PM, Jonathan Vaughn <jonathan@creatuity.com> wrote:
Probably the culprit is specifically pam_cracklib, which among other things checks if password are too similar.Looks like you can use the difok=N option to specify how many characters need to differ from old one for it not to be "too similar". You could set this to 1 or 2 to allow incremental changes at the end, or 0 probably to disable entirely.On Thu, May 29, 2014 at 7:10 AM, John Trump <trumpjk@gmail.com> wrote:
Agree about password security. What I provided was just an example of a password. Unfortunately forcing the use of a non similar is beyond my control. I guess one bright spot is the password being used meets all other complexity requirements, I just needed to allow subsequent passwords to be similar.
On May 29, 2014 6:08 AM, "Vincent Gerris" <vgerris@gmail.com> wrote:Well I just like to note that you SHOULD NOT want to use a password like that.
It's completely insecure and thus a very BAD idea from a security perspective.
As far as I know, you can override a directory wide password policy per account, so if the restrictions come from there, just change them there, there is a setting that defines how different a next password should be.
If it come from a module in between with similar rules and if you really want to do this, you should also modify it there.
If the module correctly handles LDAP responses regarding password policies, then you should be able to disable the checks there.On Wed, May 28, 2014 at 11:06 PM, John Trump <trumpjk@gmail.com> wrote:
The issue was being caused by the pam module on the linux systems. Not sure why I have to modify pam module to allow similar paswords when changing ldap passwords.On Wed, May 28, 2014 at 4:24 PM, Mark Reynolds <mareynol@redhat.com> wrote:How are you changing the password, are you using ldapmodify? Can you post access log(/var/log/dirsrv/slapd-INSTANCE/access) output showing the failed password attempt?
On 05/28/2014 04:21 PM, John Trump wrote:
Not using any other client app. User logged on to a linux system and trying to change password. If they choose a password to similar to the old one it will not allow it.
On Wed, May 28, 2014 at 4:14 PM, Mark Reynolds <mareynol@redhat.com> wrote:
I'm not aware of a setting in 389 that prohibits you from using secret01, then secret02, and then secret03, etc. These should all be allowed. Are you using some other client app(freeIPA?) to make these password updates?
On 05/28/2014 04:06 PM, John Trump wrote:
Haven't been able to come up with a solution yet. Hopefully someone on the list has a suggestion.
On Fri, May 23, 2014 at 12:42 PM, John Trump <trumpjk@gmail.com> wrote:
I would like to relax the password policy for specific users to allow them to modify passwords but use similar password to their old one. These are "group" accounts and would like to allow password to be set to: password01 then allow password to be changed to password02. Currently this is not allowed. I understand security risk etc in allowing this. I do want to keep other password complexity and history settings.
Suggestions?
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
No comments:
Post a Comment