Am Tue, Nov 30, 2021 at 09:57:24AM -0600 schrieb Spike White:
> Sumit,
> 
> Good day!  I'm curious about your statement "during authentication".  I
> seek clarification.  It's when you said:
> 
>      ... until recently SSSD unconditionally updated the group-memberships
> of the user *during authentication*.
> 
> We do a lot of GSSAPI-based ssh logins.  That is, we acquire a Kerberos
> credential up front and then ssh to the Linux server.  The ssh client
> (putty or equiv) passes the kerberos credentials and ssh daemon
> automatically logs us in.  No passwords.  It's secure because ssh daemon is
> verifying the Kerberos identity with KDC (AD controllers).
> 
> So effectively, sshd is bypassing the pam "auth" phase for these Kerberized
> logins.    it is doing the "account" and "session" phase for these logins
> only.
> 
> Also, we have set up some sudo privs with "NOPASSWD:" flag like so:
> 
>     %<priv group> ALL=NOPASSWD: /bin/su
> 
> then it appears that sudo is by passing the PAM "auth" phase when these
> engineers issue "sudo su -l oracle".   Again, doing the "account" and
> "session" phases only.
> 
> In these cases, does that mean that sssd is bypassing updating
> group-memberships?

Hi,

thanks for asking with *during authentication* I meant any PAM related
operation which typically happens at login/authentication time. So
'account' and 'session' phase will trigger an update of the group
memberships as well. But SSSD has a cache (option pam_id_timeout) to
avoid that the group memberships are updated at every step.

It's a bit tricky to find the right level of technical details. I'm not
sure if every reader here knows about PAM and what it does, so I used
the vague term 'authentication'.

bye,
Sumit

> 
> Spike
> 
> On Tue, Nov 30, 2021 at 9:36 AM Sumit Bose <[email protected]> wrote:
> 
> > Am Tue, Nov 30, 2021 at 02:24:34PM -0000 schrieb Robert Wagensveld:
> > > Hi all,
> > >
> > > We've been using SSSD for a while successfully in our Kerberos over
> > > LDAP enterprise environment. However, our SSSD online query time,
> > > especially over VPN, is very poor, usually each login request or sudo
> > > requests takes about 1 minute. There does not seem to be a way around
> > > it, not even forcing SSSD to use the cache for a while even when
> > > online again.  entry_cache_timeout does not help. Is there anything
> > > I'm missing? Some configuration options I do not know about yet?
> >
> > Hi,
> >
> > until recently SSSD unconditionally updated the group-memberships of the
> > user during authentication. With recent versions of SSSD there is the new
> > option pam_initgroups_scheme and SSSD does not update the
> > group-memberships if the related user is already logged in. This should
> > already help for sudo. To speed up the login as well if the user is not
> > already logged in you can set 'pam_initgroups_scheme = never' and SSSD
> > will used cached data as long as the cached data is valid.
> >
> > HTH
> >
> > bye,
> > Sumit
> >
> > >
> > > [sssd]
> > > config_file_version = 2
> > > services = nss, pam, ifp
> > > domains = company.nl
> > > debug_level = 9
> > > [nss]
> > > entry_cache_nowait_percentage = 5
> > > filter_groups = root
> > > filter_users = root
> > > debug_level = 9
> > > [pam]
> > > offline_failed_login_attempts = 3
> > > offline_failed_login_delay = 30
> > > debug_level = 9
> > > [domain/company.nl]
> > > debug_level = 9
> > > id_provider = ldap
> > > ignore_group_members = true
> > > auth_provider = krb5
> > > chpass_provider = krb5
> > > access_provider = permit
> > > cache_credentials = true
> > > min_id = 1000
> > > entry_cache_timeout = 28800
> > > krb5_realm = COMPANY.NL
> > > krb5_canonicalize = false
> > > krb5_renewable_lifetime = 24h
> > > krb5_renew_interval = 6h
> > > krb5_server = dc03.company.nl
> > > krb5_store_password_if_offline = true
> > > krb5_ccname_template = FILE:%d/krb5cc_%U
> > > ldap_uri = ldap://dc03.company.nl
> > > ldap_search_base = DC=Company,DC=nl
> > > ldap_user_search_base = OU=CompanyCompany,DC=nl
> > > ldap_group_search_base = OU=Company,DC=Company,DC=nl??
> > > ldap_referrals = false
> > > enumerate = false
> > > ldap_force_upper_case_realm = true
> > > ldap_schema = rfc2307bis
> > > ldap_id_use_start_tls = false
> > > ldap_tls_reqcert = demand
> > > ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt
> > > ldap_sasl_canonicalize = true
> > > ldap_sasl_mech = GSSAPI
> > > ldap_user_object_class = user
> > > ldap_user_name = sAMAccountName
> > > ldap_user_uid_number = uidNumber
> > > ldap_user_gid_number = gidNumber
> > > ldap_user_gecos = gecos
> > > ldap_user_shell = loginShell
> > > ldap_user_home_directory = unixHomeDirectory
> > > ldap_user_principal = nonExistingAttribute
> > > ldap_group_object_class = group
> > > ldap_group_name = cn
> > > ldap_group_gid_number = gidNumber
> > > ldap_group_member = member
> > > _______________________________________________
> > > sssd-users mailing list -- [email protected]
> > > To unsubscribe send an email to [email protected]
> > > 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/[email protected]
> > > Do not reply to spam on the list, report it:
> > https://pagure.io/fedora-infrastructure
> > _______________________________________________
> > sssd-users mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
> > 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/[email protected]
> > Do not reply to spam on the list, report it:
> > https://pagure.io/fedora-infrastructure
> >

> _______________________________________________
> sssd-users mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> 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/[email protected]
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Reply via email to