|
Dan and openldap tech community:
I’m using SSSD (pam_sss.so directives), the service is running and there are no issues there.
I can verify that users can reset their passwords, however when an account is set to expire, that user is allowed to login via SSH. SSSD should be able to honor account expirations.
I confirmed the SSH configuration is set to PasswordAuthentication YES and UsePAM YES.
This is part of the /var/log/secure log from the RHEL7 ldap client:
Sep 2 13:53:07 ***** sshd[2255]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=node22.cluster.sec312 user=real
Sep 2 13:53:08 ***** sshd[2255]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=node22.cluster.sec312 user=real
Sep 2 13:53:08 ***** sshd[2253]: Accepted keyboard-interactive/pam for real from 10.1.1.122 port 43950 ssh2
Sep 2 13:53:08 ***** sshd[2253]: pam_unix(sshd:session): session opened for user real by (uid=0)
Sep 2 13:53:08 ***** sshd[2269]: error: Failed to allocate internet-domain X11 display socket.
Any advise or suggestions will be greatly appreciated.
Thank you, Liz
From: Elizabeth Real Chavez <Elizabeth.Real@jpl.nasa.gov>
Date: Monday, August 31, 2015 at 4:10 PM To: Dan White <dwhite@olp.net> Cc: "openldap-technical@openldap.org" <openldap-technical@openldap.org> Subject: Re: RHEL7 OpenLDAP server is not enforcing password expirations
Dan,
I have RHEL5 ldap clients using pam_unix.so and pam_ldap.so directives and these do honor the ldap user password expiration, no issues at all.
The /var/log/secure file shows: error: PAM: User account has expired
However, the two RHEL7 ldap clients using the pam_unix.so and pam_sss.so directives do not even see/know that the user ldap password has expired. When I change the directive from pam_sss.so to pam_ldap.so, the client cannot communicate with the ldap server.
RHEL5 /ETC/PAM.D/system-auth file:
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_ldap.so use_first_pass
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 [default=bad success=ok user_unknown=ignore service_err=ignore system_err=ignore] pam_ldap.so
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 type=LINUX minlen=8 dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1
password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok md5 shadow remember=24
password sufficient pam_ldap.so use_authtok
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
session optional pam_ldap.so
RHEL7 CLIENTS /ETC/PAM.D/:
password-auth file:
auth sufficient pam_sss.so use_first_pass
account [default=bad success=ok user_unknown=ignore] pam_sss.so
password sufficient pam_sss.so use_authtok
session optional pam_sss.so
system-auth file:
auth sufficient pam_sss.so use_first_pass
account [default=bad success=ok user_unknown=ignore] pam_sss.so
password sufficient pam_sss.so use_authtok
session optional pam_sss.so
Thank you, Liz
From: Dan White <dwhite@olp.net>
Date: Friday, August 28, 2015 at 7:13 AM To: Elizabeth Real Chavez <Elizabeth.Real@jpl.nasa.gov> Cc: "openldap-technical@openldap.org" <openldap-technical@openldap.org> Subject: Re: RHEL7 OpenLDAP server is not enforcing password expirations On 08/27/15 22:56 +0000, Real, Elizabeth (392K) wrote:
That depends on your configuration. Consult the pam project's to determine
that:
pam_ldap is a 3rd party product, so you'll need to consult it's
documentation to see how expiration is handled, if at all. nssov, which is
distributed with OpenLDAP, explicitly supports it.
In the case you are using, or wish to use, pam_unix with an ldap nss
module, expiration might be represented as an attribute underneath the
user's DN. See its documentation for details.
--
Dan White
|