SSSD does not honor openldap account lock policy when using ssh keys for authentication
Environment
- Red Hat Enterprise Linux 9
- Red Hat Enterprise Linux 8
- Red Hat Enterprise Linux 7
- Red Hat Enterprise Linux 6
- sssd
- OpenLDAP
Issue
- When using sssd to authenticate against an openldap server, an ldap
user that has the pwdAccountLockedTime value set to TRUE can still
log into a system if they use a known valid ssh key - How to deny login with SSH keys for LDAP user which has
pwdAccountLockedTime: 000001010000Z
set in OpenLDAP
server.
Resolution
1. Add the following parameter in sssd.conf file
:
# /etc/sssd/sssd.conf
ldap_access_order = ppolicy
ldap_pwdlockout_dn = cn=default,ou=policies,dc=example,dc=com
access_provider = ldap
ldap_access_order
can also be set to lockout
instead of ppolicy
.
- Restart SSSD service.
Root Cause
- Earlier ppolicy ldap schema overlay was not used to invoke when
using SSH keys but only for passwords..
Diagnostic Steps
1. Collect 'ldapsearch' output for the LDAP user.
Example of ldapsearch command with "pwdAccountLockedTime" policy
[root@example ~]# ldapsearch -x -D "cn=admin,dc=ldap,dc=test" -W -H ldaps://test-server -b "ou=People,dc=ldap,dc=test" "(cn=testuser)" +
Enter LDAP Password:
dn: uid=testuser,ou=People,dc=ldap,dc=test
structuralObjectClass: account
entryUUID:
creatorsName: cn=admin,dc=ldap,dc=test
createTimestamp: 20191128083648Z
pwdChangedTime: 20200115125255Z
pwdAccountLockedTime: 000001010000Z
entryCSN: 20200427070553.656135Z#000000#000#000000
modifiersName: cn=admin,dc=ldap,dc=test
modifyTimestamp: 20200427070553Z
entryDN: uid=testuser,ou=People,dc=ldap,dc=test
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
2. Check /var/log/secure
:
Apr 10 13:56:18 rhel9 sshd[79578]: pam_sss(sshd:account): Access denied for user ldapuser: 4 (System error) Apr 10 13:56:18 rhel9 sshd[79578]: fatal: Access denied for user ldapuser by PAM account configuration [preauth]
3. Collect sssd debug logs with debug_level = 9
set in [domain]
section:
(Thu Apr 10 11:54:48 2020) [sssd[be[default]]] [sdap_access_ppolicy_send] (0x0400): Performing access ppolicy check for user [ldapuser@default] (Thu Apr 10 11:54:48 2020) [sssd[be[default]]] [sdap_access_ppolicy_send] (0x0400): Checking ppolicy against LDAP (Thu Apr 10 11:54:48 2020) [sssd[be[default]]] [sdap_access_ppolicy_get_lockout_step] (0x0100): Trying to find out if ppolicy is enabled using the DN: "cn=default,ou=policies,dc=example,dc=com" (Thu Apr 10 11:54:48 2020) [sssd[be[default]]] [sdap_print_server] (0x2000): Searching 172.x.x.x:636 (Thu Apr 10 11:54:48 2020) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [no filter]["cn=default,ou=policies,dc=example,dc=com"]. (Thu Apr 10 11:54:48 2020) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [pwdLockout] (Thu Apr 10 11:54:48 2020) [sssd[be[default]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Thu Apr 10 11:54:48 2020) [sssd[be[default]]]
According to sssd debug logs, it seems that it couldn't retrieve the ppolicy from the LDAP server and in that case "access denied" is an expected error message.
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.
Comments