access_provider = ad,simple
(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
access_provider = ad, simple
(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
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-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