sssd-devel June 2019

sssd-devel@lists.fedorahosted.org

3 participants
53 discussions

[sssd PR#823][opened] CI: use python3-pep8 on Fedora 31 and later
by sumit-bose 11 Jun '19

11 Jun '19

URL: https://github.com/SSSD/sssd/pull/823 Author: sumit-bose Title: #823: CI: use python3-pep8 on Fedora 31 and later Action: opened PR body: """ None """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/823/head:pr823 git checkout pr823

2 4

[sssd PR#822][opened] tests: fix enctypes in test_copy_keytab
by sumit-bose 11 Jun '19

11 Jun '19

URL: https://github.com/SSSD/sssd/pull/822 Author: sumit-bose Title: #822: tests: fix enctypes in test_copy_keytab Action: opened PR body: """ Currently test_copy_keytab uses legacy encryption types to mock up keytab entries. New versions of libkrb5 might not support them anymore. With this patch only supported encryption types should be used. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/822/head:pr822 git checkout pr822

2 7

Identity information not cached for login?
by manuel.nuno.melo＠gmail.com 04 Jun '19

04 Jun '19

Hello, I am using SSSD with NIS via the proxy id_provider and auth_provider (full conf below). I hoped that SSSD's cache would work around the sandboxing of systemd's logind that won't, by default, allow outgoing connections to the provider (see https://github.com/systemd/systemd/issues/7074). User and credential lookup works fine and I can log in remotely via ssh. However, immediately after auth, at session setup-time, pam_systemd.so calls logind, which calls getpwuid(), which in turn causes a NIS lookup that hangs because of the sandbox. Failure of pam_systemd.so also means I can't login via the GUI. I was hoping that SSSD's cache, which is up-to-date because of the immediately preceding auth, would be used instead of the NIS lookup. My alternative right now is to specifically disable that sandbox, as described in the link above, but I'd rather understand this completely and perhaps avoid that. I'm on Ubuntu 18.04, with sssd 1.16.1. sssd.conf: [sssd] services = nss, pam config_file_version = 2 domains = my.domain.name [nss] filter_groups = root filter_users = root reconnection_retries = 3 cache_first = true [pam] reconnection_retries = 3 pam_verbosity = 3 offline_failed_login_attempts = 3 offline_failed_login_delay = 1 # increased this in hopes of fixing the issue. Nope... pam_id_timeout = 35 cache_first = true [domain/my.domain.name] id_provider = proxy auth_provider = proxy proxy_lib_name = nis proxy_pam_target = none cache_credentials = true # increased this in hopes of fixing the issue. Nope... cached_auth_timeout = 30 # Tried with and without enumeration. No difference. enumerate = true The relevant PAM file -- /etc/pam.d/common-session. In my tests via ssh was included via /etc/pam.d/sshd: session [default=1] pam_permit.so session requisite pam_deny.so session required pam_permit.so session optional pam_umask.so session required pam_unix.so session optional pam_sss.so # if I comment or skip the next line I get clean ssh logins, but still failing GUI logins. session optional pam_systemd.so nsswitch.conf: passwd: compat systemd sss group: compat systemd sss shadow: compat sss gshadow: files hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname networks: files protocols: db files services: db files ethers: db files rpc: db files sudoers: files getent output getent passwd testuser: testuser:$6$salted_hashed_password.:1100:100::/home/testuser:/bin/bash getent -s sss passwd testuser: testuser:*:1100:100::/home/testuser:/bin/bash getent -s sss shadow testuser: <no output>

1 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel June 2019