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 > 7.6. > > 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 > [/usr/lib64/sssd/libsss_ad,simple.so]: /usr/lib64/sssd/libsss_ad,simple.so: > 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 > password. > > 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.
Hi, have you checked if 'ad_access_filter', see man sssd-ad for details, might help? bye, Sumit > > 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 > Linux client. > > 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 > case. > > Spike > > On Thu, Dec 5, 2019 at 10:42 AM Jakub Hrozek <jhro...@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 > > pam_access.so > > > 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: > > access_provider=ad,simple > > 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 > > RHEL6 > > > 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 > > me, > > > that's not huge.) > > > > > > Spike > > > > > _______________________________________________ > > > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > > > To unsubscribe send an email to sssd-users-le...@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-le...@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-le...@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-le...@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
