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]>



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]

Reply via email to