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.
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
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.o...
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.
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 jhrozek@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-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.o... _______________________________________________ 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.o...
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 jhrozek@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-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.o... _______________________________________________ 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.o...
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.o...
sssd-users@lists.fedorahosted.org
-
Jakub Hrozek -
Spike White -
Sumit Bose