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 = [email protected], > [email protected], [email protected], > [email protected], [email protected], > [email protected], [email protected], > [email protected], [email protected], > [email protected], [email protected], > [email protected], [email protected], > [email protected], [email protected] > > simple_allow_users = [email protected], > [email protected], [email protected], > [email protected], [email protected], > [email protected], [email protected] > <[email protected]> > > 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 [email protected] > <[email protected]> > > realm permit -g [email protected] <[email protected]> >
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 [email protected] > <[email protected]> > > realm permit -g -x [email protected] <[email protected]> > > > > 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 -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
