On Mon, Dec 16, 2019 at 10:47:12AM -0600, Spike White wrote:
Jakub and sssd experts,
I tested this stacking of sssd access_providers. Both on RHEL8.1 and RHEL
first I tried:
access_provider = ad,simple
sssd fails to restart. Error message in the sssd log file is:
(Mon Dec 16 09:58:21 2019) [sssd[be[amer.example.com]]]
[dp_module_open_lib] (0x0010): Unable to load module [ad,simple] with path
cannot open shared object file: No such file or directory
Changed to this:
access_provider = ad, simple
Error message in log file is now this:
(Mon Dec 16 10:00:24 2019) [sssd[be[amer.examplecom]]] [dp_module_open_lib]
(0x0010): Unable to load module [ad, simple] with path
[/usr/lib64/sssd/libsss_ad, simple.so]: /usr/lib64/sssd/libsss_ad,
simple.so: cannot open shared object file: No such file or directory
So it appears you cannot stack your access_providers. At least in the sssd
versions shipping with RHEL7 & 8.
Great idea -- just not implemented.
The original concern is that with a "simple" access provider, that
password-less methods of SSH login would allow AD accounts with locked
password or expired accounts in. Because the denial of these accounts
would be in the "auth" section of the PAM stack -- which gets bypassed by
password-less methods of SSH login?
By entering multiple incorrect password attempts, trivially I was able to
lock my AD account. But I still had a valid Kerberos credential on my
Linux server. I tested for GSSAPI-based SSH logins. It properly refused
to auto-login, instead it prompted for a password.
My speculation is that the SSH client is presenting the valid Kerberos
token to the SSH daemon. The daemon then consults the KDC (aka the AD
domain controller). That AD DC declines to authorize this Kerberos
principal, as he has a locked password.
I also attempted RSA pubkey based SSH login. Using that, I was able to
auto-login into the test server, even though my AD account had a locked
That could be remediated with access_provider = ad and
/etc/security/access.conf file entries to authorize users and groups, I'd
guess. access_provider=ad just to thwart locked or expired accounts;
access.conf for the granular (per-server) access control.
have you checked if 'ad_access_filter', see man sssd-ad for details,
BTW, for our use case -- conferring login via GPO's wouldn't work so well.
We have hundreds and hundreds of diverse projects, each with their own
authorized users. We are the Linux engineers; we do not managed AD. We
confer access per group and the group owner (project team manager) has
self-service ability to add or remove accounts to his or her AD groups.
Thus once server is initially provisioned, we don't have to do additional
maintenance. Our Linux team is not authorized in AD to create OUs or GPOs
associated with those OUs.
either simple access provide or using access.conf for access work well for
us, because we have full control over the per-server configuration of the
Incidentally, we do a ton of GSSAPI-based SSH SSO, but essentially no
pubkey-based SSH SSO. So the above situation is not so bad -- for our use
On Thu, Dec 5, 2019 at 10:42 AM Jakub Hrozek <jhrozek(a)redhat.com> wrote:
> On Wed, Dec 04, 2019 at 09:58:00AM -0600, Spike White wrote:
> > Sssd experts,
> > We have an AD-based sssd configuration that is working. For RHEL6, 7
> and 8.
> > We've done thorough lab testing + pilot projects. All good (with certain
> > RHEL6 restrictions).
> > Currently, we're using access_provider = simple, with the appropriate
> > simple_allow_groups and simple_allow_users lines in /etc/sssd/sssd.conf.
> > Works fine.
> > A reviewer mentioned we should be using access_provider = ad +
> > /etc/security/access.conf file to restrict access. (We have
> > in our pam stack already, to disallow direct root login and other limited
> > uses.)
> > Obviously that second approach would work too.
> > The claim is the first approach would allow in AD accounts with expired
> > passwords and locked accounts. Whereas the second approach would not.
> This is correct. If would be an issue if you had used a different auth
> method than passwords, like ssh keys, then locked accounts could log in.
> The best way would be if sssd implemented account provider stacking so
> that you could say:
> or such.
> btw since you are already using AD, wouldn't it be best to implement
> GPOs and use GPOs for access control, at least on RHEL-7 and 8?
> > I'm attempting to test this claim -- I have an account I can lock easily.
> > But does anyone have any best practices for access_provider?
> > The advantage of this first approach is that it's already coded and
> > thoroughly tested. The pilot projects use this.
> > The one advantage of the second approach that I'm certain of is that
> > does not have a realm permit command. So to permit a user or group in
> > RHEL6 using the first approach is different between RHEL6 and 7/8. (To
> > that's not huge.)
> > Spike
> > _______________________________________________
> > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> > Fedora Code of Conduct:
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)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