[SSSD-users] Re: session management by sssd (when using LDAP as an authentication and authorization server)
I agree with Simo. UNIX was designed so that group membership is set only at session creation time. Linux mimicked that same approach. So if this is a problem, it's bigger than sssd. Consider a local user that's a member of a local group that confers additional privileges (like the 'wheel' group). If that user is removed from that local group, any active sessions still list his membership in that group. That indicates it's not an sssd-specific problem. BTW, if you totally delete that local group, the "id" command can no longer output the textual name for that GID in the active session. But it still insists the user is a member of that group -- even though the group technically no longer exists. Again, that's because group membership is set up at session creation time and then never changed thereafter. Until the session ends. Granted, this is a 50 yr old OS design -- back when companies had 3-4 computers max. Thus, it was easy for a sysadmin to jump on those 3-4 computers and terminate a user's sessions. Maybe this should be revisited. But that's a much bigger re-design than just sssd. Spike On Wed, Feb 19, 2020 at 8:45 AM wrote: > This is NOT an OUD issue, it's not really and issue for sssd either. > Look at your sssd.conf, are you caching? > What is the time to live? > What does your pam auth for session section look like is sss optional or > required? > > Can you post your sssd.conf, pam.d/system-auth? (strip out the sensitive > stuff) > > > > > On February 19, 2020 at 12:25 AM Hristina Marosevic < > hristina.marose...@gmail.com> wrote: > > > > > > Hello, > > > > I installed and configured SSSD with LDAP server OUD (Oracle Unified > Directory). Everything works fine so far, except for one thing which I > consider as a vulnerability. > > I just found out that there is a potential security hole which is the > old session of a user who lost his authorization. > > Generic example: > > User1 has to belong to the LDAP group sshUsers which is configured as an > access filter on the SSSD client in order to be authorized (after the > successfull authentication) for access to the remote linux machine, where > the SSSD client is installed. > > User1 is a member of the LDAP group sshUsers and logs in to the remote > linux machine. > > After the successfull login of the User1 to the remote linux machine, > its membership in the LDAP group sshUsers is removed i.e. User1 looses it > authorization to access the remote linux machine. > > What happens as a result is: > > 1. The active ssh connection od User1 to the remote linux machine which > was established before he lost his authorization is still active!! > > 2. User1 (after he lost his authorization) can not login to the remote > linux machine anymore - this is okay. > > > > Security hole - explained in 1. > > > > Can you please explain to me if there is a possiblity for SSSD to manage > the sessions, how to do that? If this is not possible (whn using OUD) > should it be proposed as a bug? > > Other than that, how is session managed on the OS layer? > > > > Thank you! > > BR, > > Hristina > > ___ > > 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] Re: Restricted access to MemberOf attribute in AD
On Thu, Feb 20, 2020, at 4:31 PM, Eugene Vilensky wrote: > > Greetings, > > My company restricts which AD entities have access to a Domain User's > MemberOf attribute. This is done precisely as described by this > institution here: > https://itconnect.uw.edu/wares/msinf/design/arch/group-member-privacy/ > > Self can read own MemberOf. > > We've never seen an impact on Windows clients. > > However for SSSD the effect is obvious: "Domain Users" is the only > Group returned. It appears to be that SSSD uses the permissions of the > Computer account for this operation. > > Is there any configurable alternative to use the User's own permissions > to resolve MemberOf on a user? > I think this info is also in the PAC. I wonder if enabling the pac responder would help... V/r, James Cassell ___ 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] Restricted access to MemberOf attribute in AD
Greetings, My company restricts which AD entities have access to a Domain User's MemberOf attribute. This is done precisely as described by this institution here: https://itconnect.uw.edu/wares/msinf/design/arch/group-member-privacy/ Self can read own MemberOf. We've never seen an impact on Windows clients. However for SSSD the effect is obvious: "Domain Users" is the only Group returned. It appears to be that SSSD uses the permissions of the Computer account for this operation. Is there any configurable alternative to use the User's own permissions to resolve MemberOf on a user? Regards, Eugene ___ 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] Re: session management by sssd (when using LDAP as an authentication and authorization server)
and here is the /etc/pam.d/system-auth file: (shoud I find the answer of the question "What does your pam auth for session section look like is sss optional or required?" here?) - I didn' change this file. Can you give me a quick explanation of its function? #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. authrequired pam_env.so authrequired pam_faildelay.so delay=200 auth[default=1 ignore=ignore success=ok] pam_succeed_if.so uid >= 1000 quiet auth[default=1 ignore=ignore success=ok] pam_localuser.so authsufficientpam_unix.so nullok try_first_pass authrequisite pam_succeed_if.so uid >= 1000 quiet_success authsufficientpam_sss.so forward_pass authrequired pam_deny.so account required pam_unix.so account sufficientpam_localuser.so account sufficientpam_succeed_if.so uid < 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so passwordrequisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= passwordsufficientpam_unix.so sha512 shadow nullok try_first_pass use_authtok passwordsufficientpam_sss.so use_authtok passwordrequired pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session optional pam_mkhomedir.so umask=0077 session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so ___ 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] Re: session management by sssd (when using LDAP as an authentication and authorization server)
Hello, "Look at your sssd.conf, are you caching?" Yes "What is the time to live?" It should be default, as I didn't change anything (I don't know the default value) "What does your pam auth for session section look like is sss optional or required?" Can you pls tell me where to search for this? Which conf file? [sssd] config_file_version = 2 domains = LDAP services = nss, pam, autofs, ssh reconnection_retries = 3 [nss] reconnection_retries = 3 debug_level = 2 filter_users = root, oracle filter_groups = root [pam] reconnection_retries = 3 debug_level = 2 [domain/LDAP] id_provider = ldap access_provider = ldap chpass_provider = ldap ldap_schema = rfc2307 ldap_uri = ldaps://hostname:LDAPs_port ldap_default_bind_dn = ldap_default_authtok = ldap_default_authtok_type = password ldap_search_base = ldap_user_search_base = cn=users, ldap_group_search_base = cn=groups, ldap_access_filter = isMemberOf=cn=linuxusers,cn=groups, cache_credentials = true enumerate = false debug_level = 9 ldap_id_use_start_tls = false ldap_tls_reqcert = demand ldap_tls_cacert = /etc/sssd/cacerts/.pem ldap_tls_cacertdir = /etc/sssd/cacerts ldap_user_name = employeeNumber ldap_user_ssh_public_key = userCertificate;binary ___ 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
