password policy is not working well.

prakashk · 12-05-2015, 06:02 AM

Hi All,

I have implemented password policy on RHEL 6.5 64 bit. I have attached the configuration files which used on sever side.

Quote:

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_fprintd.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so

account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account required pam_permit.so

#password requisite pam_cracklib.so try_first_pass retry=3 type=
#password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password requisite pam_cracklib.so try_first_pass retry=3 type= minlen=7 dcredit=-2 ucredit=-1 lcredit=-2 ocredit=-2
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok remember=5

password required pam_deny.so

session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so

Quote:

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so

account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account required pam_permit.so

#password requisite pam_cracklib.so try_first_pass retry=3 type=
#password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok

password requisite pam_cracklib.so try_first_pass retry=3 type= minlen=7 dcredit=-2 ucredit=-1 lcredit=-2 ocredit=-2
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok remember=5
password required pam_deny.so

session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so

scenario:-

When first time the user password expire then it will go with password policy well or working.

When user itself to change password from his own console if password doesn't expire then password can not implemented as per password policy.

Do anyone have an idea. please help.

Appreciate your help!!!

Thanks,
Prakash

berndbausch · 12-06-2015, 03:01 AM

1- Which files are these?
2- What do you want to achieve?
3- I don't quite understand the problem. Can you restate it in different words, or elaborate? What can not be implemented?

prakashk · 12-08-2015, 01:58 AM

Quote:

Originally Posted by berndbausch

1- Which files are these?
2- What do you want to achieve?
3- I don't quite understand the problem. Can you restate it in different words, or elaborate? What can not be implemented?

Hi Berndbausch,

Appreciate your help.

1-
These files are -
ls -ltrh /etc/pam.d/system-auth
ls -ltrh /etc/pam.d/password-auth

2. Above are the configuration files, these works well. but the scenario is -
First time the client user set his own password as per defined password policy.

Now the queries begins here.

The user is able to change his own password and it takes a dictionary word. why he doesn't set his own password as per the defined policy rules.

Thanks,
PrakashK

berndbausch · 12-08-2015, 03:43 AM

Quote:

Originally Posted by prakashk

The user is able to change his own password and it takes a dictionary word. why he doesn't set his own password as per the defined policy rules.

You mean that your configuration allows dictionary words? And you want to know why?

Your configuration is minimally different from the default config. You just set up some rules about minimal length and number of digits, upper case, lower case and other characters, and remember the last 5 passwords.

So, if users can enter dictionary words, I don't understand why. Perhaps the dictionary on your system is broken.

prakashk · 12-08-2015, 05:01 AM

Quote:

if users can enter dictionary words, I don't understand why. Perhaps the dictionary on your system is broken.

I need to check whether dictionary broken on configured system. Am I right?

berndbausch · 12-08-2015, 05:40 AM

That's my suggestion. Admittedly, I'm guessing.
EDIT: Or reinstall cracklib-dicts?

Do you have examples for the unexpected behaviour?
Does passwd behave differently if you use the original pam files?

prakashk · 12-14-2015, 01:14 AM

Hi Berndbausch,

Sorry for late reply. I have cross-checked with RHEL and centos distribution, as well as implemneted the cracklib installation.

Now, it is working fine.

Thanks,
Prakashk