I have a working LDAP server. Next added password policy to LDAP server. My password ldif looks like this:
dn: cn=MyPolicy,ou=Policies,dc=XXX,dc=XXXX
cn: MyPolicy
objectClass: pwdPolicy
#objectClass: pwdPolicyChecker
objectClass: device
objectClass: top
pwdAttribute: 2.5.4.35
#pwdAttribute: userPassword
pwdMaxAge: 7862400
pwdExpireWarning: 6048000
pwdInHistory: 3
pwdCheckQuality: 2
pwdMinLength: 7
pwdMaxFailure: 3
pwdLockout: TRUE
pwdLockoutDuration: 300
pwdGraceAuthNLimit: 0
pwdFailureCountInterval: 0
pwdMustChange: TRUE
pwdAllowUserChange: TRUE
pwdSafeModify: FALSE
pwdReset: FALSE
it is successfully added to my LDAP server. But only Lock out and Lock out duration is working. Password minimum length is not working.
pam configuration
Server side configuration
pam.d/common-auth
auth [success=1 default=ignore] pam_ldap.so nullok_secure try_first_pass
auth requisite pam_deny.so
auth required pam_permit.so
pam.d/common-account
account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so
account requisite pam_deny.so
account required pam_permit.so
pam.d/common-password
password [success=1 default=ignore] pam_unix.so obscure sha512 minlen=8
password requisite pam_deny.so
password required pam_permit.so
Client side configuration
pam.d/common-auth
auth [success=2 default=ignore] pam_unix.so null_secure try_first_pass
auth [success=1 default=ignore] pam_ldap.so use_first_pass
auth requisite pam_deny.so
auth required pam_permit.so
pam.d/common-account
account [success=2 new_authtok_reqd=done default=ignore] pam_ldap.so
account [success=1 default=ignore] pam_unix.so
account needs pam_deny.so
account required pam_permit.so
pam.d/common-password
password [success=2 default=ignore] pam_unix.so obscure sha512
password [success=1 user_unknown=ignore default=die] pam_ldap.so try_first_pass
password requisite pam_deny.so
password required pam_permit.so
ldap.conf
pam_lookup_policy yes
Can you please let me know where I am gone wrong.
pwdLockout: TRUE
pwdLockoutDuration: 300
These attributes are used on failed bind attempts to lock an account
pwdMinLength: 7
This attribute is only checked when a user (except manager DN) performs a modify password operation on his userPassword attribute. It will not lock already created accounts which do not satisfy this rule.
EDIT :
Considering your different comments, try to modify the line in your file /etc/ldap.conf :
From :
pam_password crypt
To :
pam_password exop
It will modify the password using the extended operation modifypassword and so should trigger the password policy.
If you're using OpenLDAP, the password policy overlay is completely bypassed by the ManagerDN. You should never use this yourself: it is only for the OpenLDAP server itself. You need to use another, less privileged but sufficiently priviledged, LDAP account for performing password modifications: preferably, the user's own account.
Related
why the log say pam_unix(sshd:auth): authentication failure but the login works fine? or can anyone tell me how can I fix this.
Jun 27 09:46:31 [localhost] sshd[16341]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.56.1 user=ope_fptsoft01
Jun 27 09:46:31 [localhost] sshd[16341]: Accepted password for ope_fptsoft01 from 192.168.56.1 port 55087 ssh2
Jun 27 09:46:31 [localhost] sshd[16341]: pam_unix(sshd:session): session opened for user ope_fptsoft01 by (uid=0)
My system-auth:
#%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 required pam_faildelay.so delay=2000000
auth sufficient pam_unix.so
auth sufficient pam_ldap.so minimum_uid=1000 use_first_pass
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth required pam_deny.so
account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 1000 quiet
account [default=bad success=ok user_unknown=ignore] pam_ldap.so
account required pam_permit.so
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password sufficient pam_unix.so sha512 shadow nullok use_authtok
password sufficient pam_ldap.so minimum_uid=1000 try_first_pass
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
-session optional pam_systemd.so
session optional pam_mkhomedir.so umask=0077
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_ldap.so minimum_uid=1000
Your PAM stack configuration lists two different modules to be sufficient for authentication:
auth sufficient pam_unix.so
auth sufficient pam_ldap.so minimum_uid=1000 use_first_pass
So first the user is tried via pam_unix.so which fails because it's likely a remote user in a LDAP user management. So the user probably was successfully authenticated via pam_ldap.so.
Normally one would set option try_first_pass:
auth sufficient pam_unix.so try_first_pass
auth sufficient pam_ldap.so minimum_uid=1000 use_first_pass
See also: pam_unix(8)
My solution is:
auth sufficient pam_unix.so try_first_pass
auth sufficient pam_ldap.so
I have configured OpenLDAP to store user information.
In Ping Federate, I have given the OpenLDAP connection information. LDAP connection has been established. I am using HTTP Basic adapter on the PF IDP side.
How to give search filter?I have given something like:
cn=$username.
The following is the User information in OpenLDAP directory server.
dn: cn=John Smith,ou=people,dc=highroads,dc=com
objectclass: inetOrgPerson
cn: John Smith
cn: John J Smith
sn: Smith
uid: jsmith
userpassword: jSmitH
ou: Sales
On single sign-on authentication, I gave:
Username : uid
Password : userpassword
from the user information in OpenLDAP directory. But I am not able to access SP resource.
Please let me know about the configuration information I should provide on the Ping Federate side.
Thanks,
Aswini J
You would manage this in your Password Credential Validator that you have assigned to the HTTP Basic Adapter. If the user is providing the attribute value stored in the "uid" attribute, then you would typically specify "uid=${username}" as the Search Filter and "dc=highroads,dc=com" as the Search Base for the PCV. You can make this more complex/specific as needed to ensure you only get a single user identity returned from your LDAP.
I am using openldap 2.4. I have configured it with following configuration.
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/HFSchema.schema
include /etc/ldap/schema/ppolicy.schema
pidfile /var/run/slapd/slapd.pid
modulepath /usr/lib/ldap
moduleload back_hdb.la
moduleload ppolicy.la
database hdb
suffix "dc=example,dc=com"
rootdn "cn=admin,dc=example,dc=com"
rootpw {SSHA}xzW0DfNFHahvm/C68ZR4YvbZGFQJjfz5
overlay ppolicy
ppolicy_default "cn=DefaultPwdPolicy,ou=Policies,dc=example,dc=com"
ppolicy_use_lockout
ppolicy_hash_cleartext
Also I added default password policy
# DefaultPwdPolicy, Policies, example.com
dn: cn=DefaultPwdPolicy,ou=Policies,dc=example,dc=com
cn: DefaultPwdPolicy
pwdAttribute: 2.5.4.35
objectClass: pwdPolicy
objectClass: top
objectClass: device
pwdAllowUserChange: TRUE
pwdMaxAge: 7776000
pwdInHistory: 5
pwdCheckQuality: 2
pwdMinLength: 8
pwdExpireWarning: 432000
pwdLockoutDuration: 900
pwdMaxFailure: 3
pwdMustChange: TRUE
pwdSafeModify: TRUE
pwdLockout: TRUE
But still admin is able to create users without these constraints. How will I confirm if my ppolicy overlay is working? How can I test if these constraint are actually been applied.?
The only user that is free from the password policy constraints is the internal rootdn user. You shouldn't use that yourself for anything. It is the user that slapd itself uses to update the DIT. You should define another admin user, in the DIT, with the necessary permissions. Using the rootdn user for admin tasks will bypass every constraint known to man.
To use the ppolicy fully, you have to use the password policy request control and check for the corresponding response control in your code so you can discover impending expiry, grace periods, etc.
You can test password policy with ldap* commands (OpenLDAP LDAP clients), which allow to use LDAP controls.
You must know a valid DN and a password (not rootdn, which override password policy).
For example:
clement#ader-xps:~$ ldapwhoami -x -H ldap://localhost -D uid=coudot,ou=users,dc=example,dc=com -W -e ppolicy
Enter LDAP Password:
ldap_bind: Invalid credentials (49); Account locked
Password History check in openldap not working when I am using SHA-256 password hashing in openldap.
So I am sending clear text password from my java application to openLDAP and it is storing as SHA-256 hashed form on its own.
whenever I am changing password, openLDAP is storing the previous password in pwdHistory.
There is no problem in that but when I am changing password with the same password previously used it is taking up without throwing any error.
I am struggling to make it work for few weeks. Please somebody help me.
My environment details:
OpenLDAP 2.4.38
RHEL 6
Following details also mentioned in slapd.conf
include ../etc/openldap/schema/ppolicy.schema
password-hash {SHA256}
overlay ppolicy
ppolicy_default "cn=default,ou=pwdpolicies,dc=my-domain,dc=com"
ppolicy_hash_cleartext
my password policy:
dn: cn=Default,ou=pwdpolicies,dc=my-domain,dc=com
objectClass: pwdPolicy
objectClass: person
objectClass: top
cn: Default
sn: Default
pwdAttribute: userPassword
pwdMinAge: 0
pwdInHistory: 5
pwdFailureCountInterval: 0
pwdLockout: TRUE
pwdLockoutDuration: 0
pwdAllowUserChange: TRUE
pwdExpireWarning: 0
pwdGraceAuthNLimit: 0
pwdMustChange: FALSE
pwdSafeModify: FALSE
Kindly let me know if I have to give me more information to nail down the issue. Please Please Please someone help me on this. I am badly need a solution on this.
I've setup a linux machine (debian 6.0.7) with ldap authentication with the following configurations:
/etc/nsswitch.conf
passwd: compat ldap [NOTFOUND=return UNAVAIL=continue] db
group: compat ldap [NOTFOUND=return UNAVAIL=continue] db
shadow: compat ldap
/etc/pam.d/common-account
# here are the per-package modules (the "Primary" block)
account [user_unknown=ignore authinfo_unavail=ignore default=ok] pam_unix.so
account [success=ok user_unknown=ignore authinfo_unavail=ignore default=ignore] pam_succeed_if.so uid < 1000 debug
account [success=done default=ignore authinfo_unavail=1] pam_ldap.so debug
# here's the fallback if no module succeeds
account requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
account required pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config
/etc/pam.d/common-auth
# here are the per-package modules (the "Primary" block)
auth [success=done default=ignore] pam_unix.so nullok_secure
auth requisite pam_succeed_if.so uid >= 1000 quiet
auth requisite pam_succeed_if.so gid >= 1000 quiet
auth requisite pam_succeed_if.so user notingroup root
auth requisite pam_succeed_if.so user notingroup wheel
auth [success=3 default=2 authinfo_unavail=ignore] pam_ldap.so use_first_pass
auth [success=2 default=ignore] pam_ccreds.so minimum_uid=1000 action=validate use_first_pass
auth [default=ignore] pam_ccreds.so minimum_uid=1000 action=update
# here's the fallback if no module succeeds
auth requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth required pam_permit.so
# and here are more per-package modules (the "Additional" block)
auth optional pam_ccreds.so minimum_uid=1000 action=store
# end of pam-auth-update config
/etc/pam.d/common-password
# here are the per-package modules (the "Primary" block)
password [success=2 default=ignore] pam_unix.so obscure sha512
password [success=1 user_unknown=ignore default=die authinfo_unavail=ignore] pam_ldap.so try_first_pass
# here's the fallback if no module succeeds
password requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
password required pam_permit.so
# and here are more per-package modules (the "Additional" block)
password optional pam_gnome_keyring.so
# end of pam-auth-update config
/etc/pam.d/common-session
# here are the per-package modules (the "Primary" block)
session [default=1] pam_permit.so
# here's the fallback if no module succeeds
session requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
session required pam_permit.so
# and here are more per-package modules (the "Additional" block)
session required pam_unix.so
session required pam_mkhomedir.so skel=/etc/skel umask=0022
session optional pam_ldap.so
# end of pam-auth-update config
in common-account I had to jump to pam_permit if ldap server is unavailable otherwise users with cached credentials can't authenticate, but I think this is not a good idea.
I'm also running nss_updatedb ldap to cache passwd and groups.
Everything is working fine, even offline authentication. The problem is when I disable a user on ldap (setting shadowexpire to 1). When the machine is online authentication system notify that the account is disabled but when the machine is offline a disabled user can login using cached credentials. I believe it's because shadow infos aren't cached.
Is it a way to cache shadow informations about disabled users so they can't log in even when the machine is offline?
pam_ccreds README says this isn't currently supported. You could reset the user's password instead of using shadowexpire.
Thank you for sharing your config! I changed /etc/pam.d/common-account from
account [user_unknown=ignore authinfo_unavail=ignore default=ok] pam_unix.so
to
account [success=done user_unknown=ignore authinfo_unavail=ignore default=ok] pam_unix.so
The problem was that when the LDAP server was not available a local user was turned down even with a good password. success=done terminates the chain once pam_unix.so says it is ok.