sssd-devel May 2018

sssd-devel@lists.fedorahosted.org

9 participants
76 discussions

[sssd PR#413][opened] mmap_cache: add SID and type to struct sss_mc_rec
by sumit-bose 16 Oct '18

16 Oct '18

URL: https://github.com/SSSD/sssd/pull/413 Author: sumit-bose Title: #413: mmap_cache: add SID and type to struct sss_mc_rec Action: opened PR body: """ This patchset updates the memory cache by adding some new members to struct sss_mc_rec. One is the addition of a hash value for SID based lookup which will be added in later patches. The other is a new record type and a member indicating the type. The new type is a link record which links an alias name, e.g. an UPN, to the original record of the related user or group object. Besides aliases this link record will be used in case in-sensitive setups. E.g. if getpwnam() returns the name of an AD users as Administrator(a)ad.domain bit some applications or users use administrator(a)ad.domain for lookups the memory cache is currently never used because there is no entry with the hash of 'administrator(a)ad.domain'. With this patch the original data record is created as before with the hash for 'Administrator(a)ad.domain' and a link record is create with the hash of 'administrator(a)ad.domain'. Now both lookups can be handled by the memory cache. If now another application uses ADMINISTRATOR(a)AD.DOMAIN for lookups the first request will go to the NSS responder but upcoming requests can use the memory cache as well because a link record for ADMINISTRATOR(a)AD.DOMAIN is created. The last patch in this series adds some additional data to the user and group lookup requests, the short name, the domain name, the short domain name and the SID. Those are needed to be able to support SID based lookups in the memory cache and allow applications to not depend on the name format returned by getpw{nam|uid}. Upcoming patches for libsss_nss_idmap will make those additional values available to applications I added them already here to keep the memory cache related changes in one PR. Application which will benefit here are the interfaces SSSD provides e.g. to Samba related applications like SSSD's version of libwbclient but also IPA plugins like extdom and slapi-nis. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/413/head:pr413 git checkout pr413

3 5

[sssd PR#397][opened] cleanup: Remove CONFDB_DOMAIN_LEGACY_PASS
by amitkumar50 13 Aug '18

13 Aug '18

URL: https://github.com/SSSD/sssd/pull/397 Author: amitkumar50 Title: #397: cleanup: Remove CONFDB_DOMAIN_LEGACY_PASS Action: opened PR body: """ Since CONFDB_DOMAIN_LEGACY_PASS is legacy parameter that is rooted in pre-1.0 SSSD. We should just nuke it as we remove other legacy code. Resolves: https://pagure.io/SSSD/sssd/issue/3530 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/397/head:pr397 git checkout pr397

5 24

[sssd PR#568][opened] Strip whitespaces in netgroup triple.
by malyzelenyhnus 31 Jul '18

31 Jul '18

URL: https://github.com/SSSD/sssd/pull/568 Author: malyzelenyhnus Title: #568: Strip whitespaces in netgroup triple. Action: opened PR body: """ Strip leading and trailing whitespaces from netgroup three-tuple strings to be compatible with nss_ldap. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/568/head:pr568 git checkout pr568

4 17

[sssd PR#522][opened] Prepare SSSD to support IPA in trust to Samba AD
by abbra 19 Jul '18

19 Jul '18

URL: https://github.com/SSSD/sssd/pull/522 Author: abbra Title: #522: Prepare SSSD to support IPA in trust to Samba AD Action: opened PR body: """ This pull request prepares SSSD ipa provider to support IPA in trust to Samba AD but the same changes are needed for a properly working bi-directional trust against Microsoft AD as well. To make everything fully working, one needs patches against FreeIPA too but SSSD changes are isolated. @sumit-bose @jhrozek please review. 1. When IPA establishes a trust to an Active Directory forest, a number of special objects is created in a subtree of `cn=trusts,$SUFFIX`. These objects represent Kerberos principals for trusted domain objects (TDOs) used for both incoming and outgoing trusts. For bi-directional trust there is a requirement that one of them (`<REMOTE FLAT NAME>$@<OUR REALM>`) must have a POSIX identity because a remote domain controller will use it to authenticate against smbd running on IPA master. SSSD only looks for user accounts in `cn=accounts,$SUFFIX`, so an attempt by smbd to resolve this principal name as a POSIX user via `getpwnam()` will fail. And the reason why smbd behaves this way is due to the fact that a Kerberos ticket used for authentication contains no MS-PAC record, thus not allowing Samba to build a local security token it needs. This is expected for the authentication using TDO account as it is used for bootstrapping reasons (AD DC couldn't create and sign MS-PAC record for an account in IPA realm) but the side effect is that TDO object must be known as a POSIX account on IPA master. Thus, we extend user search base in IPA provider to search in both `cn=accounts,$SUFFIX` and `cn=trusts,$SUFFIX`. Changes on FreeIPA side will handle access controls and generation of the POSIX information for the TDO accounts. 2. For long time we relied on using cross-realm TGTs to talk to Active Directory domain controllers (LDAP and GC services) in case of bi-directional trust. Unfortunately, this is not something we can continue using as there are multiple reasons such access can be denied by a trusted AD side, including SID filtering and other security measurements. It also happens that right now Samba AD in Fedora has a bug in handling a cross-realm TGT generated by the FreeIPA KDC. As result, while technically IPA could establish a bi-directional trust to Samba AD, it does not work as any SSSD attempt to connect to AD DCs via LDAP with GSSAPI will fail (Samba AD DC answers error with PROCESS_TGS message on Kerberos level and authentication fails). For this reason, we should remove any distinction when using bi-directional trust and simply always use a special keytab with a TDO object as we do in uni-directional trust case. While a more generic Kerberos authentication will not work in the outbound direction, SSSD will be able to resolve users/groups. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/522/head:pr522 git checkout pr522

4 17

[sssd PR#586][opened] SSH: Do not exit abruptly if SSHD closes its end of the pipe before reading all the SSH keys
by jhrozek 22 Jun '18

22 Jun '18

URL: https://github.com/SSSD/sssd/pull/586 Author: jhrozek Title: #586: SSH: Do not exit abruptly if SSHD closes its end of the pipe before reading all the SSH keys Action: opened PR body: """ Resolves: https://pagure.io/SSSD/sssd/issue/3747 Before writing the keys to sshd, ignore SIGPIPE so that if the pipe towards the authorizedkeys helper is closed, the sss_ssh_authorizedkeys helper is not terminated with SIGPIPE, but instead proceeds and then the write(2) calls would non-terminally fail with EPIPE. The other patch in this PR is not meant to be pushed. It is an easy way to reproduce the bug. I would also like to write an integration test, but I'm not sure if I can do that very soon and given that we try to release in about a week I prefer to send the fix first. In order to reproduce, load many SSH keys to a user object. I found it was easiest to cheat during reproducing and do this: - first, set a long cache expire so that the cache doesn't expire and overwrite your local changes - ldbedit the cache - copy the ssh public key attribute and each time, change one character in the attribute (ldb would otherwise detect the duplicates) - save the ldbedit window - run the program from the second patch. With the sss_ssh_authorizedkeys patch in, the sss_ssh_authorizedkeys binary should finish gracefully, without the patch, it would fail with SIGPIPE. In my testing, I needed about 30 ssh keys to reproduce the bug. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/586/head:pr586 git checkout pr586

3 14

[sssd PR#579][opened] krb5 locator: add support for multiple addresses and sub-domains
by sumit-bose 14 Jun '18

14 Jun '18

URL: https://github.com/SSSD/sssd/pull/579 Author: sumit-bose Title: #579: krb5 locator: add support for multiple addresses and sub-domains Action: opened PR body: """ Related to https://pagure.io/SSSD/sssd/issue/3652 and https://pagure.io/SSSD/sssd/issue/941. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/579/head:pr579 git checkout pr579

3 22

[sssd PR#585][opened] tcurl: do not log the payload
by fidencio 08 Jun '18

08 Jun '18

URL: https://github.com/SSSD/sssd/pull/585 Author: fidencio Title: #585: tcurl: do not log the payload Action: opened PR body: """ We should never ever log the payload. In order to avoid doing this, let's parse the data and replace the payload content for "...". One example of the log before the patch is: (Wed May 30 21:43:49 2018) [sssd[kcm]] [tcurl_write_data] (0x2000): ---> begin libcurl data (Wed May 30 21:43:49 2018) [sssd[kcm]] [tcurl_write_data] (0x2000): { "version": 1, "kdc_offset": 0, "principal": { "type": 0, "realm": "DOMAIN.TEST", "components": [ "admin" ] }, "creds": [ "uuid": "f87d2975-fc14-4cb8-8275-f0e474f82403", "payload": "AAAAAAAAAAEAAAAPS05PV05IT1NUUy5URVNUAAAABWFkbWluAAAAAAAAAAMAAAAMWC1DQUNIRUNPTkY6AAAAFWtyYjVfY2NhY2hlX2NvbmZfZGF0YQAAAApmYXN0X2F2YWlsAAAAJmtyYnRndC9LTk9XTkhPU1RTLlRFU1RAS05PV05IT1NUUy5URVNUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADeWVzAAAAAA==" } ] } (Wed May 30 21:43:49 2018) [sssd[kcm]] [tcurl_write_data] (0x2000): <--- end libcurl data And after the patch: (Wed May 30 21:45:19 2018) [sssd[kcm]] [tcurl_print_sanitized_data] (0x2000): ---> begin libcurl data (Wed May 30 21:45:19 2018) [sssd[kcm]] [tcurl_print_sanitized_data] (0x2000): { "version": 1, "kdc_offset": 0, "principal": { "type": 0, "realm": "DOMAIN.TEST", "components": [ "admin" ] }, "creds": [ { "uuid": "727b7a15-eba7-4d44-aebe-dc6d1ecaf5f4", "payload": "..." } ] } (Wed May 30 21:45:19 2018) [sssd[kcm]] [tcurl_print_sanitized_data] (0x2000): <--- end libcurl data Resolves: https://pagure.io/SSSD/sssd/issue/3674 Signed-off-by: Fabiano Fidêncio <fidencio(a)redhat.com> """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/585/head:pr585 git checkout pr585

2 12

[sssd PR#582][opened] ipa: MPG realted fixes for lookups by GID
by sumit-bose 08 Jun '18

08 Jun '18

URL: https://github.com/SSSD/sssd/pull/582 Author: sumit-bose Title: #582: ipa: MPG realted fixes for lookups by GID Action: opened PR body: """ There are a few issues when a trusted AD user with an expired cache entry is indirectly looked up be a GID lookup for the primary user private group (mpg). One if the issues was that sysdb_search_group_by_gid() is not aware of MPGs in contrast to sysdb_search_group_by_name(). Since sysdb_search_group_by_gid() is used at other places as well I added sysdb_getgrgid_attrs() to replace sysdb_search_group_by_gid() in get_object_from_cache() instead of modifying to avoid regressions in the other callers. Maybe it would be worth a ticket to check if MPG support can be added safely to sysdb_search_group_by_gid(). Related to https://pagure.io/SSSD/sssd/issue/3748 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/582/head:pr582 git checkout pr582

2 8

[sssd PR#588][opened] nss-imap: add sss_nss_getsidbyuid() and sss_nss_getsidbygid()
by sumit-bose 08 Jun '18

08 Jun '18

URL: https://github.com/SSSD/sssd/pull/588 Author: sumit-bose Title: #588: nss-imap: add sss_nss_getsidbyuid() and sss_nss_getsidbygid() Action: opened PR body: """ Two new calls are added to allow the caller to specify if the given POSIX ID is a UID or a GID and the expected result is a user or a group respectively. This is needed because on POSIX a user and a group may share numerically the same ID value but might have different SIDs assigned. Related to https://pagure.io/SSSD/sssd/issue/3629 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/588/head:pr588 git checkout pr588

2 7

[sssd PR#553][opened] Use p11_child to verify certificates for the ssh responder
by sumit-bose 04 Jun '18

04 Jun '18

URL: https://github.com/SSSD/sssd/pull/553 Author: sumit-bose Title: #553: Use p11_child to verify certificates for the ssh responder Action: opened PR body: """ This patch set is another step to solve https://pagure.io/SSSD/sssd/issue/3489, i.e to remove the NSS dependency and allow all Smartcard and certificate related features to be build with OpenSSL as well. To have all the code related to certificate verification in one place the verification code is removed from the ssh responder and the ssh responder will now call p11_child to verify a certificate before extracting the public key as ssh key. Another benefit is that the ssh responder is not blocked anymore during OCSP check since they now run in p11_child and the ssh responder can process other requests in parallel. In this context I also added a patch which improves the documentation of the feature in the sss_ssh_authorizedkeys man page as requested in https://pagure.io/SSSD/sssd/issue/3688. Besides adding unit tests for the new calls I added an unit test for the ssh responder, similar to the ones for the nss and pam responder. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/553/head:pr553 git checkout pr553

2 10

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel May 2018