Actually, numerous things are slow (including logins), but the sudo example is quite easy to reproduce. Am new to SSSD so I'm assuming this is something I've misconfigured.
Here's my config:
[sssd] config_file_version = 2 domains = domain.com services = nss, pam debug_level = 0 override_space = _
[nss] debug_level = 0 override_shell = /bin/bash allowed_shells = /bin/bash, /bin/tcsh vetoed_shells = /bin/csh shell_fallback = /bin/bash
[pam] debug_level = 0
[domain/domain.com] debug_level = 0 id_provider = ad ; access_provider = ad ; ad_access_filter = memberOf=CN=ISTUnix,DC=domain,DC=com access_provider = simple simple_allow_groups = istunix krb5_realm = DOMAIN.COM override_homedir = /home/%u ldap_referrals = false
sudoers is fairly simple -- just defaults save for the following:
%istunix ALL=(ALL) NOPASSWD: ALL
However, when I run 'sudo su -' as a test, it can take 20+ seconds for it to succeed. Debug logs seem to show SSSD querying many groups. I can post debug logs if someone thinks they'll be useful -- but am hoping there's some obvious best practice I'm missing.
Side note that I kind of prefer using access_provider = ad above in tandem with ad_access_filter as it's 'faster' for most logins (once the info is cached it's faster). It seems that via the simple access provider, logins are slower (I think it queries all groups?). However, doesn't seem that ad_access_filter handles nested groups at all....
Thanks! Ray
On Tue, Jul 28, 2015 at 09:07:51PM -0700, Ray Van Dolson wrote:
Actually, numerous things are slow (including logins), but the sudo example is quite easy to reproduce. Am new to SSSD so I'm assuming this is something I've misconfigured.
Here's my config:
[sssd] config_file_version = 2 domains = domain.com services = nss, pam debug_level = 0 override_space = _
[nss] debug_level = 0 override_shell = /bin/bash allowed_shells = /bin/bash, /bin/tcsh vetoed_shells = /bin/csh shell_fallback = /bin/bash
[pam] debug_level = 0
[domain/domain.com] debug_level = 0 id_provider = ad ; access_provider = ad ; ad_access_filter = memberOf=CN=ISTUnix,DC=domain,DC=com access_provider = simple simple_allow_groups = istunix krb5_realm = DOMAIN.COM override_homedir = /home/%u ldap_referrals = false
sudoers is fairly simple -- just defaults save for the following:
%istunix ALL=(ALL) NOPASSWD: ALL
However, when I run 'sudo su -' as a test, it can take 20+ seconds for it to succeed. Debug logs seem to show SSSD querying many groups. I can post debug logs if someone thinks they'll be useful -- but am hoping there's some obvious best practice I'm missing.
Side note that I kind of prefer using access_provider = ad above in tandem with ad_access_filter as it's 'faster' for most logins (once the info is cached it's faster). It seems that via the simple access provider, logins are slower (I think it queries all groups?). However, doesn't seem that ad_access_filter handles nested groups at all....
Thanks! Ray
Follow-up on my last paragraph. Found I can enable nested group support with access_provider=ad via this syntax:
ad_access_filter = DOM:domain.com:(memberOf:1.2.840.113556.1.4.1941:=CN=ISTUnix,DC=domain,DC=com)
Fugly, but fast.
Ray
On Tue, Jul 28, 2015 at 09:07:51PM -0700, Ray Van Dolson wrote:
Actually, numerous things are slow (including logins), but the sudo example is quite easy to reproduce. Am new to SSSD so I'm assuming this is something I've misconfigured.
Here's my config:
[sssd] config_file_version = 2 domains = domain.com services = nss, pam debug_level = 0 override_space = _
[nss] debug_level = 0 override_shell = /bin/bash allowed_shells = /bin/bash, /bin/tcsh vetoed_shells = /bin/csh shell_fallback = /bin/bash
[pam] debug_level = 0
[domain/domain.com] debug_level = 0 id_provider = ad ; access_provider = ad ; ad_access_filter = memberOf=CN=ISTUnix,DC=domain,DC=com access_provider = simple simple_allow_groups = istunix krb5_realm = DOMAIN.COM override_homedir = /home/%u ldap_referrals = false
sudoers is fairly simple -- just defaults save for the following:
%istunix ALL=(ALL) NOPASSWD: ALL
However, when I run 'sudo su -' as a test, it can take 20+ seconds for it to succeed. Debug logs seem to show SSSD querying many groups. I can post debug logs if someone thinks they'll be useful -- but am hoping there's some obvious best practice I'm missing.
Found that I can solve this by using ignore_group_members = true. Not sure what other impacts this might have, though. More reading...
Ray
Hi!
with ignore_group_members = true, i have sudo su - ~13sec (user with +300 nested groups). It's long...
Вторник, 28 июля 2015, 21:46 -07:00 от Ray Van Dolson rvandolson@esri.com:
On Tue, Jul 28, 2015 at 09:07:51PM -0700, Ray Van Dolson wrote:
Actually, numerous things are slow (including logins), but the sudo example is quite easy to reproduce. Am new to SSSD so I'm assuming this is something I've misconfigured.
Here's my config:
[sssd] config_file_version = 2 domains = domain.com services = nss, pam debug_level = 0 override_space = _
[nss] debug_level = 0 override_shell = /bin/bash allowed_shells = /bin/bash, /bin/tcsh vetoed_shells = /bin/csh shell_fallback = /bin/bash
[pam] debug_level = 0
[domain/domain.com] debug_level = 0 id_provider = ad ; access_provider = ad ; ad_access_filter = memberOf=CN=ISTUnix,DC=domain,DC=com access_provider = simple simple_allow_groups = istunix krb5_realm = DOMAIN.COM override_homedir = /home/%u ldap_referrals = false
sudoers is fairly simple -- just defaults save for the following:
%istunix ALL=(ALL) NOPASSWD: ALL
However, when I run 'sudo su -' as a test, it can take 20+ seconds for it to succeed. Debug logs seem to show SSSD querying many groups. I can post debug logs if someone thinks they'll be useful -- but am hoping there's some obvious best practice I'm missing.
Found that I can solve this by using ignore_group_members = true. Not sure what other impacts this might have, though. More reading...
Ray _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users@lists.fedorahosted.org