sssd-devel June 2017

sssd-devel@lists.fedorahosted.org

5 participants
68 discussions

[sssd PR#314][opened] SDAP: Add sdap_domain_copy_search_bases
by mzidek-rh 11 Jul '17

11 Jul '17

URL: https://github.com/SSSD/sssd/pull/314 Author: mzidek-rh Title: #314: SDAP: Add sdap_domain_copy_search_bases Action: opened PR body: """ Add function to copy search bases from one sdap_domain to another. Resolves: https://pagure.io/SSSD/sssd/issue/3435 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/314/head:pr314 git checkout pr314

3 8

[sssd PR#300][opened] LDAP: Fix nesting level comparison
by justin-stephenson 11 Jul '17

11 Jul '17

URL: https://github.com/SSSD/sssd/pull/300 Author: justin-stephenson Title: #300: LDAP: Fix nesting level comparison Action: opened PR body: """ Very(very) basic fix to correct an issue with nesting level comparison of option `ldap_group_nesting_level` to ensure that setting nesting level 0 will avoid parent group of group searches. This was tested and confirmed as fixed downstream, but if needed can be tested with the LDAP provider and `ldap_schema = rfc2307bis` with nesting level set to 0. Resolves: https://pagure.io/SSSD/sssd/issue/3425 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/300/head:pr300 git checkout pr300

5 22

Evaluating HBAC rules for other hosts
by Howard Johnson 28 Jun '17

28 Jun '17

In Ipsilon, we recently (OK, about a year ago) added an authorisation stack. This allows us to control, Ipsilon-side, which users are permitted to log into which service providers. Our authorisation plugin functions are currently fairly limited, basically using user group membership to control which service providers a user has access to. One of the things we'd like to support is using FreeIPA's HBAC rules rather than user attributes directly. In my opinion, this makes it much more obvious what's going on and fits in better with FreeIPA's architecture. There're a few options that have come up in discussions around this on #ipsilon and #sssd: 1) Treat each service provider as a new service in FreeIPA. The most basic HBAC rule would then be "<user> can log into <ipsilon server> via service <service provider>". Ipsilon can easily do a PAM_ACCT_MGMT PAM call (either using a PAM library, or by talking to SSSD directly using the PAM socket) with the appropriate service name. SSSD will then permit or deny the check based on the HBAC rules. This is nice and simple, but the permitted length / characters of service names could have a potential limit on what service providers can be authorised this way. 2) Ipsilon fetches HBAC rules from FreeIPA and processes them itself. This requires duplication of the HBAC processing logic in Ipsilon (although I believe the python bindings for libipa_hbac deal with most of the heavy lifting there), and LDAP connectivity to the FreeIPA server(s), along with the appropriate login credentials. Ipsilon would need to have any appropriate retry / failover logic. With this method, we can create service providers as hosts in FreeIPA, and HBAC rules would be "<user> can log into <service provider> via service saml2" (or openidc, etc). 3) Ipsilon uses the FreeIPA JSON-RPC API to call the hbactest API. This moves the HBAC check to the FreeIPA server, where the logic already exists. This requires Ipsilon to have access to the FreeIPA API and the appropriate login credentials. Moving the HBAC checks into FreeIPA itself has load implications for the IPA servers. Again, this would permit HBAC rules of the style "<user> can log into <service provider> via saml2". 4) Add support to SSSD for performing HBAC checks for arbitrary FreeIPA hosts. This lets SSSD deal with connections to FreeIPA, including authentication and failover, which it's already doing. Some mechanism would be needed for Ipsilon to pass the "destination host" to SSSD for use in the HBAC check rather than the local IPA hostname. All of these options assume that there's an HBAC rule to permit the user to log in to the Ipsilon server itself via the "ipsilon" service, which we require now. Considering I'm writing this mail, it'll come as no surprise that I'm most interested in option 4. SSSD only fetches HBAC rules from FreeIPA that affect the local host (unless the legacy src host option is enabled), so there'd need to be an option to enable fetching all rules instead. I'm not clear if there's a PAM attribute that could be used to pass the remote host name to SSSD for the check, so my thought was to add HBAC functionality to the infopipe (Ipsilon can already use the Infopipe for fetching user attributes). My first thought is something like an org.freedesktop.sssd.infopipe.HBAC DBus interface with an Evaluate method that takes hostname, username, and service name, and returns a boolean. So, basically, if I were to work up patches to implement this option, would they have a chance of being accepted into SSSD? In the meantime we'll probably look at implementing one of option 2 or 3, but the SSSD option is appealing to me in the longer term. Cheers. -- HJ

3 6

[sssd PR#315][opened] tests: update expired certificate
by sumit-bose 26 Jun '17

26 Jun '17

URL: https://github.com/SSSD/sssd/pull/315 Author: sumit-bose Title: #315: tests: update expired certificate Action: opened PR body: """ This is a short term fix to un-break the unit tests. The proper fix would be to create the certificates at runtime during the tests. Related to https://pagure.io/SSSD/sssd/issue/3436 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/315/head:pr315 git checkout pr315

2 3

[sssd PR#313][opened] SDAP: Update parent sdap_list
by mzidek-rh 21 Jun '17

21 Jun '17

URL: https://github.com/SSSD/sssd/pull/313 Author: mzidek-rh Title: #313: SDAP: Update parent sdap_list Action: opened PR body: """ Update parent sdap_list with newly created subdomain sdap domain. Preiously, we inherited the parent sdap_list and used it also in the subdomain's context (this was introduced recently with commit c4ddb9ccab670f9c0d0377680237b62f9f91c496), but it caused problems that were difficult to debug (we somewhere rewrite part of the list incorrectly). This patch reverses to the previous bahavior, where every subdomain has it's own sdap_list, however this time the parrent domain's sdap_list is updated so that it has correct information about search bases of the child domains. We should ideally have just one sdap_list to avoid the updating completely, but this would require more refactoring in the sdap code. Resolves: https://pagure.io/SSSD/sssd/issue/3421 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/313/head:pr313 git checkout pr313

3 17

[sssd PR#311][opened] RESPONDER: Use fqnames as output when needed
by fidencio 21 Jun '17

21 Jun '17

URL: https://github.com/SSSD/sssd/pull/311 Author: fidencio Title: #311: RESPONDER: Use fqnames as output when needed Action: opened PR body: """ As some regressions have been caused by not handling properly naming conflicts when using shortnames, last explicitly use fully qualified names as output in the following situations: - domain resolution order is set; - a trusted domain has been using `use_fully_qualified_name = false` In both cases we want to ensure that even handling shortnames as input, the output will always be fully qualified. Resolves: https://pagure.io/SSSD/sssd/issue/3403 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/311/head:pr311 git checkout pr311

2 19

[sssd PR#312][opened] Master valgrind
by lslebodn 19 Jun '17

19 Jun '17

URL: https://github.com/SSSD/sssd/pull/312 Author: lslebodn Title: #312: Master valgrind Action: opened PR body: """ There was a bug in valgrind < 3.13 which override some log files and therefore there was missing errors for shell wrappers generated by libtool for dummy-child. https://bugs.kde.org/show_bug.cgi?id=162848 We could add more suppressions for errors/leaks in bash to our suppression file but dummy child is built just for test purposes. Another possible solution would to avoid linking dummy-child with internal libraries; So libtool would not generate shell wrapper for dummy-child. But the simplest think is to ignore all errors for dummy-child. current master: http://sssd-ci.duckdns.org/logs/job/71/50/summary.html This patchset: http://sssd-ci.duckdns.org/logs/job/71/51/summary.html """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/312/head:pr312 git checkout pr312

2 5

[sssd PR#289][opened] Check the timestamp cache during the users/groups cleanup
by fidencio 15 Jun '17

15 Jun '17

URL: https://github.com/SSSD/sssd/pull/289 Author: fidencio Title: #289: Check the timestamp cache during the users/groups cleanup Action: opened PR body: """ This patch set basically changes the behaviour of the cleanup_user() and cleanup_groups() functions used by ldap_id_cleanup(). With the current behaviour the searches for the users/groups to be cleaned up are always done in the cache, while the up to date information about their expiration is kept in the timestamp cache. So, in order to fix [3389](https://pagure.io/SSSD/sssd/issue/3369), let's perform the search in the timestamp cache whenever it's possible. I'm really not sure whether the dn_filter I'm building is totally correct, so I'd like to ask whoever review this patchset to take a careful look that the last patch, specially in the cleanup_dn_filter() function. The way I'm testing this issue is: - I have a LDAP server with a few users and have the following options configured on sssd.conf: ``` enumerate = true ldap_enumeration_refresh_timeout = 35 ldap_purge_cache_timeout = 60 entry_cache_timeout = 20 ``` """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/289/head:pr289 git checkout pr289

3 31

[sssd PR#305][+Pushed] krb5: use plain principal if password is expired
by jhrozek 15 Jun '17

15 Jun '17

URL: https://github.com/SSSD/sssd/pull/305 Title: #305: krb5: use plain principal if password is expired Label: +Pushed

1 0

[sssd PR#305][closed] krb5: use plain principal if password is expired
by jhrozek 15 Jun '17

15 Jun '17

URL: https://github.com/SSSD/sssd/pull/305 Author: sumit-bose Title: #305: krb5: use plain principal if password is expired Action: closed To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/305/head:pr305 git checkout pr305

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel June 2017