[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sssd-users
Subject:    =?utf-8?q?=5BSSSD-users=5D?= Re: Realm permit with bogus AD domain disallows any subsequent legal lo
From:       Sumit Bose <sbose () redhat ! com>
Date:       2020-01-10 16:20:23
Message-ID: 20200110162023.GC22557 () p50 ! Speedport_W_724V_Typ_A_05011603_05_020
[Download RAW message or body]

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.org
_______________________________________________
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.org

[prev in list] [next in list] [prev in thread] [next in thread]