sssd-devel September 2014

sssd-devel@lists.fedorahosted.org

23 participants
95 discussions

[PATCH] AD: conflicting gpo policy settings not being resolved correctly
by Yassir Elley 02 Oct '14

02 Oct '14

Hi, The attached patch fixes ticket #2437 (conflicting gpo policy settings not being resolved correctly) https://fedorahosted.org/sssd/ticket/2437 Regards, Yassir.

3 8

[PATCH] MAN: Document the domains option of pam_sss
by Jakub Hrozek 01 Oct '14

01 Oct '14

I realized we forgot to add a description of the new pam_sss option to the man pages.

2 4

Releasing 1.12.2
by Jakub Hrozek 30 Sep '14

30 Sep '14

Hi, as requested by an important downstream, we need to do a release release. I created a Release Notes page: https://fedorahosted.org/sssd/wiki/Releases/Notes-1.12.2 and moved the rest of the tickets we're definitely not fix in time to a new milestone 1.12.3 We need to push Sumit's views patchset and my simple man page patch. It would be nice to push Pavel's reconnection patches, although 1.12.3 would be fine, too, I guess. I'll be glad for any corrections of the wiki page. Also, if there are any pending patches that need to make it to 1.12.2, please reply with a request for review.

1 0

[PATCH] IPA: add support for new extdom plugin version
by Sumit Bose 30 Sep '14

30 Sep '14

Hi, this patch adds support for the new extdom plugin version as described on http://www.freeipa.org/page/V4/Extdom_plugin_enhancement_grouplist . I will send the server side updates to the freeipa-devel list soon. Nevertheless it would be nice if these changes can already be tested against the old version to avoid regressions. bye, Sumit

2 6

Design Discussion: Restricting domains per PAM service
by Jakub Hrozek 29 Sep '14

29 Sep '14

Hi, I have prepared a wiki page summarizing the discussion that happened previously on this list: https://lists.fedorahosted.org/pipermail/sssd-devel/2014-July/020867.html Here is the wiki page: https://fedorahosted.org/sssd/wiki/DesignDocs/RestrictDomainsInPAM For your convenience, I copied the design page text below verbatim. Does that reflect the discussion accurately? Provided it does... Daniel, based on the contents of the page, do you which parts of SSSD need to be touched? I was wondering if we could help with some of the three subtasks. For example adding a new option requires touching several places such as the man pages or the python configAPI. Could we maybe create a skeleton that just loads the option for you? Please note I'm not trying to take over the feature from you, your contribution is really welcome. It's just that some parts of the SSSD development process, such as adding a new option are not documented anywhere and might be difficult to find for a newcomer. And we would like to get this feature merged sooner rather than later.. See the full design page text below: = Restricting the domains a PAM service can auth against = Related ticket(s): * https://fedorahosted.org/sssd/ticket/2370 === Problem statement === Some environments require that different PAM applications can use a different set of SSSD domains. An example might be a system where, depending on which VPN PAM service you log with, you authenticate against a different set of remote servers. The legacy PAM modules were able to use a different configuration file altogether as a parameter for the PAM module. This wiki page describes a similar feature for the SSSD. === Overview of the solution === On the PAM client side, the PAM module should receive a new option that specifies the SSSD domains to authenticate against. However, the SSSD daemon can't fully trust all PAM services. We can't rely on the PAM service fields either, as the data the PAM client sends to the PAM application can be faked by the client, especially by users who posses shell access or can start custom applications. Instead, there needs to be a list of users who we trust. Typically, this would be a list of users who run the PAM aware applications we wish to restrict (such as `vsftpd` or `openvpn`). This list would default to `root` only. These trusted users would be allowed to authenticate against any domain and would also be able to restrict the domains further using a new pam_sss option. For the untrusted users, we need to keep a list of domains allowed to authenticate against, too. Since by default there are no restrictions on the allowed domains, this list would default to "all domains are allowed". === Implementation details === This section breaks down the Overview of the solution into consumable pieces. ==== Add a new option `pam_trusted_users` ==== A new option must be added to the PAM responder. This option will be a list of numerical UIDs or user names that are trusted. This list will be parsed during PAM responder initialization (`pam_process_init` call) using the `csv_string_to_uid_array` function and stored in the PAM responder context (`struct pam_ctx`). The PAC responder does pretty much the same in the `pac_process_init` function. In the responder, we already have the credentials of the client stored in the `cli_ctx` structure. When a new request comes into the `pam_forwarder` function, we will match the client UID against the list of trusted IDs and determine whether the client is trusted or not. ==== Add a option to limit the domains for untrusted users ==== Another option, called `pam_allowed_auth_domains` shall be added. This option will list the SSSD domains an untrusted client can authenticate against. The option will accept either a comma-separated list of SSSD domains or any of two special values "all" and "none". The default value will be "all" in order to keep the current behaviour where any client can authenticate against any domain. The option will be parsed during `pam_process_init` and stored in the `pam_ctx` structure. An untrusted client will only be allowed to send a request to a domain that matches the list of allowed domains. In order to keep the implementation simple, the `allow` keyword would copy all domain names into `pam_ctx` and the `none` keyword would set the variable holding the names to NULL. Then the check would be a simple loop for all cases. Care must be taken to ensure a sensible PAM error code for cases where the domain wouldn't match. ==== Add a new pam module option to limit the domains ==== The PAM module will gain a new option, called `domains` that will allow the administrator to use a list of domains to authenticate this PAM service against. In the PAM responder, this option will only be in effect for trusted clients. If the client is trusted, only domains listed in this PAM option will be considered for authentication. Please note that a patch implementing most of the functionality of this PAM module option was contributed to the sssd-devel mailing list by Daniel Gollub already. ==== Password Changes ==== Password changes should be allowed against all domains. === How To Test === 1. Prepare an SSSD installation with at least two domains A and B. 1. Pick a PAM service that is running by a trusted user. One example might be VPN service ran by the openvpn user or similar. Add this user as a value of `pam_trusted_users` option in the `[pam]` section. 1. Add one of the domains (domain A) as a `domain=` parameter into the `auth` section of your service's PAM config file 1. Edit `sssd.conf` and set `pam_allowed_auth_domains = none`. 1. Authenticate using the selected PAM service as a user from domain A. The authentication should succeed. 1. Authenticate using the same service as a user from domain B. The authentication should fail and there should be a reasonable (ie not System Error) return code returned to the application 1. Authenticate using a different PAM service. Make sure this service is ran by an untrusted user (not root!). Logins against both A and B should fail. 1. Change the value of `pam_allowed_auth_domains` to A. Login against A should succeed from a service running as untrusted user. 1. Change the value of `pam_allowed_auth_domains` to all. Login against both domains should succeed from a service running as untrusted user. 1. Remove the `domains=` option from the PAM config file. The trusted service should now be able to log in against both SSSD domains. === Authors === * Daniel Gollub <dgollub(a)brocade.com> * Jakub Hrozek <jhrozek(a)redhat.com> * Simo Sorce <simo(a)redhat.com>

4 13

[PATCH] LDAP: Do not require a dereference control to be retuned in a reply
by Jakub Hrozek 29 Sep '14

29 Sep '14

Ludwig suggested that we should be more permissive when parsing replies from a server.

2 2

[PATCH] PAM: new option pam_trusted_users
by Pavel Reichl 29 Sep '14

29 Sep '14

Hello, please see attached patch which adds first of two options proposed in https://fedorahosted.org/sssd/wiki/DesignDocs/RestrictDomainsInPAM Thanks!

3 7

[PATCH] some typos in debug messages
by Pavel Reichl 29 Sep '14

29 Sep '14

Please see attached trivial patch. Thanks!

3 2

[PATCH] AD GPO: Fix incorrect sAMAccountName selection
by Stephen Gallagher 29 Sep '14

29 Sep '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We were assuming that the ad_hostname value would match the sAMAccountName attribute, but in practice this was almost never the case on a properly-configured system. Microsoft's convention is that the sAMAccountName is always the portion of the FQDN before the first dot, so this patch makes that same assumption. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlQi3sgACgkQeiVVYja6o6OJDwCfRgV66Mp/oLWfNXXamXMC7S1i KYwAoK4H6eogurMto2oUVM6V9pVDbZ0C =1Nj3 -----END PGP SIGNATURE-----

2 6

[PATCH] AD: Add a missing break statement to the GPO code
by Jakub Hrozek 29 Sep '14

29 Sep '14

Found by Coverity. Moreover, I think the DEBUG message shouldn't be so loud.

2 2

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel September 2014