All,
Another engineer fat-fingered a ‘realm permit’ invocation and discovered this problem. Brought this to my attention. (This is on RHEL7).
We are using the simple access provider in sssd.conf. So we have simple_allow_groups and simple_allow_users lines in sssd.conf:
Example allow lines:
simple_allow_groups = amerlinuxeng@amer.company.com, amerlinuxengtfssupt@amer.company.com, amerlinuxsup@amer.company.com, amerlnxsvcdelauttfs@amer.company.com, fnms_ops@amer.company.com, gbllinuxsuppw@amer.company.com, pptsupportpac@amer.company.com, scheduling_global@amer.company.com, unv_legato_admins@amer.company.com, zabbix-support@amer.company.com, apaclinuxeng@apac.company.com, apaclinuxsup@apac.company.com, emealinuxeng@emea.company.com, emealinuxsup@emea.company.com, vra_users@amer.company.com
simple_allow_users = processdaceaccount@amer.company.com, processdisco05@amer.company.com, processdisco06a@amer.company.com, processehcprofiler@amer.company.com, processfoglight@amer.company.com, svc_prdprofoglight01@amer.company.com, john2_nolan@emea.company.com john2_nolan@emea.dell.com
amer.company.com and emea.company.com are legal AD child domains.
If we mistakenly do a ‘realm permit’ for any bogus AD domain, it breaks any subsequent legal logins.
Examples:
realm permit processdaceaccount@us.company.com processdaceaccount@us.dell.com
realm permit -g vra_users@us.company.com vra_users@us.dell.com
If I attempt to log in now, the authentication fails. (& my login is legal – I’m a member of a couple of these permitted AD groups.)
Here’s the log lines from /var/log/secure:
Jan 9 11:21:54 spikev2stest01 sshd[68160]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost= spikev2stest01.us.company.com user=admspike_white
Jan 9 11:21:54 spikev2stest01 sshd[68160]: Accepted password for admspike_white from 10.179.253.197 port 47334 ssh2
Jan 9 11:21:54 spikev2stest01 sshd[68160]: pam_sss(sshd:account): Access denied for user admspike_white: 6 (Permission denied)
Jan 9 11:21:54 spikev2stest01 sshd[68160]: fatal: Access denied for user admspike_white by PAM account configuration
So the PAM auth phase still succeeds, but now the access phase fails. This is for a legal login.
If I remove the bogus entries, access of legal logins again succeeds.
realm permit -x processdaceaccount@us.company.com processdaceaccount@us.dell.com
realm permit -g -x vra_users@us.company.com vra_users@us.dell.com
Now my legal login again succeeds.
Here’s the auth and access section of the /etc/pam.d/system-auth file:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
# OL7 version. Per Company I/T's stated policy for service & process accounts, lock-out time = 30 mins
auth required pam_tally2.so deny=5 onerr=fail unlock_time=1800
auth sufficient pam_sss.so forward_pass
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth required pam_deny.so
account [default=ignore success=ok perm_denied=bad user_unknown=ignore] pam_sss.so
account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 1000 quiet
account required pam_permit.so
Spike
On Fri, Jan 10, 2020 at 09:53:23AM -0600, Spike White wrote:
All,
Another engineer fat-fingered a ‘realm permit’ invocation and discovered this problem. Brought this to my attention. (This is on RHEL7).
We are using the simple access provider in sssd.conf. So we have simple_allow_groups and simple_allow_users lines in sssd.conf:
Example allow lines:
simple_allow_groups = amerlinuxeng@amer.company.com, amerlinuxengtfssupt@amer.company.com, amerlinuxsup@amer.company.com, amerlnxsvcdelauttfs@amer.company.com, fnms_ops@amer.company.com, gbllinuxsuppw@amer.company.com, pptsupportpac@amer.company.com, scheduling_global@amer.company.com, unv_legato_admins@amer.company.com, zabbix-support@amer.company.com, apaclinuxeng@apac.company.com, apaclinuxsup@apac.company.com, emealinuxeng@emea.company.com, emealinuxsup@emea.company.com, vra_users@amer.company.com
simple_allow_users = processdaceaccount@amer.company.com, processdisco05@amer.company.com, processdisco06a@amer.company.com, processehcprofiler@amer.company.com, processfoglight@amer.company.com, svc_prdprofoglight01@amer.company.com, john2_nolan@emea.company.com john2_nolan@emea.dell.com
amer.company.com and emea.company.com are legal AD child domains.
If we mistakenly do a ‘realm permit’ for any bogus AD domain, it breaks any subsequent legal logins.
Examples:
realm permit processdaceaccount@us.company.com processdaceaccount@us.dell.com
realm permit -g vra_users@us.company.com vra_users@us.dell.com
Hi,
unknown user or groups in _allow_ lists should be ignored only in _deny_ lists they should cause an error. Can you send logs with 'debug_level=9' in the [domain/...] section of sssd.conf.
bye, Sumit
If I attempt to log in now, the authentication fails. (& my login is legal – I’m a member of a couple of these permitted AD groups.)
Here’s the log lines from /var/log/secure:
Jan 9 11:21:54 spikev2stest01 sshd[68160]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost= spikev2stest01.us.company.com user=admspike_white
Jan 9 11:21:54 spikev2stest01 sshd[68160]: Accepted password for admspike_white from 10.179.253.197 port 47334 ssh2
Jan 9 11:21:54 spikev2stest01 sshd[68160]: pam_sss(sshd:account): Access denied for user admspike_white: 6 (Permission denied)
Jan 9 11:21:54 spikev2stest01 sshd[68160]: fatal: Access denied for user admspike_white by PAM account configuration
So the PAM auth phase still succeeds, but now the access phase fails. This is for a legal login.
If I remove the bogus entries, access of legal logins again succeeds.
realm permit -x processdaceaccount@us.company.com processdaceaccount@us.dell.com
realm permit -g -x vra_users@us.company.com vra_users@us.dell.com
Now my legal login again succeeds.
Here’s the auth and access section of the /etc/pam.d/system-auth file:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
# OL7 version. Per Company I/T's stated policy for service & process accounts, lock-out time = 30 mins
auth required pam_tally2.so deny=5 onerr=fail unlock_time=1800
auth sufficient pam_sss.so forward_pass
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth required pam_deny.so
account [default=ignore success=ok perm_denied=bad user_unknown=ignore] pam_sss.so
account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 1000 quiet
account required pam_permit.so
Spike
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
sssd-users@lists.fedorahosted.org