So far we preferred to perform all of these decisions on the server side (sssd daemon) and not on the client side (pam_sss). I would like recommend to add configuration options to sssd.conf like e.g. allowed_pam_services for the domain sections.

coverity: =>
description: https://bugzilla.redhat.com/show_bug.cgi?id=727466

{{{

1. What is the nature and description of the request?
   Add the ability for pam_sss to override the default 'domains=' option that is
   specified in /etc/sssd/sssd.conf.

2. Why does the customer need this? (List the business requirements here)
   Under RHEL-5 (and RHEL-4), the customer was able to provide authentication
   separate from the OS login authentication. This was performed via the
   application specific /etc/pam.d script. In the script, an alternate ldap.conf
   was specified to the pam_ldap.so module to specify the applications specific
   authentication details. This provides systems where general users are able to
   connect/login to applications, but not have login rights on the system itself.
   It also allows for pass-through authentication for application like SAS. Using
   sssd, it appears that the separate authentication details could be specified in
   an application specific domain in /etc/sssd/sssd.conf, but there is no way to
   tell pam_sss.so which domain to use.

3. How would the customer like to achieve this? (List the functional >
   requirements here)
   Add a "domains=" option to the pam_sss module that overrides the "domains="
   option in the /etc/sssd/sssd.conf file and utilizes the same configuration file
   for the shared parameters. That way multiple domains could still be specified
   and all the sssd configuration could be maintained in one place/file.

4. For each functional requirement listed in question 4, specify how Red Hat
   and the customer can test to confirm the requirement is successfully
   implemented.

5. add a service configuration that utilizes the domains= option to override
   the default domains= configuration in sssd.conf

6. verify that users without login rights on the system itself are able to
   authenticate to the service configured in (1)

7. Is there already an existing RFE upstream or in Red Hat bugzilla?
   I was not able to find an existing RFE, although some of the discussion in
   https://fedorahosted.org/sssd/ticket/149 looks similar.

8. How quickly does this need resolved? (desired target release)
   RHEL 6.3

9. Does this request meet the RHEL Bug and Feature Inclusion Criteria (please
   review)
   yes

10. List the affected packages
    sssd-client

11. Would the customer be able to assist in testing this functionality if
    implemented?
    yes
    }}}
    => https://bugzilla.redhat.com/show_bug.cgi?id=727466

{{{

1. What is the nature and description of the request?
   Add the ability for pam_sss to override the default 'domains=' option that is
   specified in /etc/sssd/sssd.conf.

2. Why does the customer need this? (List the business requirements here)
   Under RHEL-5 (and RHEL-4), the customer was able to provide authentication
   separate from the OS login authentication. This was performed via the
   application specific /etc/pam.d script. In the script, an alternate ldap.conf
   was specified to the pam_ldap.so module to specify the applications specific
   authentication details. This provides systems where general users are able to
   connect/login to applications, but not have login rights on the system itself.
   It also allows for pass-through authentication for application like SAS. Using
   sssd, it appears that the separate authentication details could be specified in
   an application specific domain in /etc/sssd/sssd.conf, but there is no way to
   tell pam_sss.so which domain to use.

3. How would the customer like to achieve this? (List the functional >
   requirements here)
   Add a "domains=" option to the pam_sss module that overrides the "domains="
   option in the /etc/sssd/sssd.conf file and utilizes the same configuration file
   for the shared parameters. That way multiple domains could still be specified
   and all the sssd configuration could be maintained in one place/file.

4. For each functional requirement listed in question 4, specify how Red Hat
   and the customer can test to confirm the requirement is successfully
   implemented.

5. add a service configuration that utilizes the domains= option to override
   the default domains= configuration in sssd.conf

6. verify that users without login rights on the system itself are able to
   authenticate to the service configured in (1)

7. Is there already an existing RFE upstream or in Red Hat bugzilla?
   I was not able to find an existing RFE, although some of the discussion in
   https://fedorahosted.org/sssd/ticket/149 looks similar.

8. How quickly does this need resolved? (desired target release)
   RHEL 6.3

9. Does this request meet the RHEL Bug and Feature Inclusion Criteria (please
   review)
   yes

10. List the affected packages
    sssd-client

11. Would the customer be able to assist in testing this functionality if
    implemented?
    yes
    }}}

patch: => 0
rhbz: =>
tests: => 0
testsupdated: => 0
upgrade: => 0

This will be solved by InfoPipe.

milestone: NEEDS_TRIAGE => SSSD 1.9.0

Fields changed

rhbz: => [https://bugzilla.redhat.com/show_bug.cgi?id=727466 727466]

Fields changed

blockedby: =>
blocking: =>
milestone: SSSD 1.9.0 => SSSD Infopipe

Fields changed

owner: somebody => nalin

Fields changed

feature_milestone: =>
milestone: SSSD Infopipe Feature => NEEDS_TRIAGE

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.11 beta
type: defect => enhancement

Fields changed

proposed_priority: => Optional

This ticket has been evaluated for inclusion into SSSD 1.10 release and was decided to be excluded since it does not match the main goals and themes of the release. It might be considered for later releases.

Fields changed

milestone: SSSD 1.11 beta => SSSD 1.12 beta

I think we have misinterpreted the ticket.
What we need to be able to do is to pass the PAM parameter from pam_sss to pam responder that would only allow authentication to happen against the specific domains that are allowed in pam configuration.

Say sssd.conf would define domains A and B.
There are two applications with two different PAM configurations one would have A as a PAM parameter and another would have B as parameter. Then PAM responder would filter out the domains other than listed in the parameter and thus prevent people from wrong domains to use the other application.

This would require extra field to go over the wire from pam_sss to sssd. I do not know how hard it is to implement.

changelog: =>
design: =>
design_review: => 0
fedora_test_page: =>
milestone: SSSD 1.13 beta => NEEDS_TRIAGE
review: => 0
selected: =>

The idea is to actually add an option to sssd.conf to define allowed services. This is similar to what is proposed but would allow single file for the configuration.

milestone: NEEDS_TRIAGE => Interim Bucket

Fields changed

milestone: Interim Bucket => SSSD 1.12 beta

Fields changed

priority: major => critical

Fields changed

cc: => jpazdziora@redhat.com

Fields changed

cc: jpazdziora@redhat.com => jpazdziora@redhat.com, mark.nejedlo@tdstelecom.com

I would like to encourage this to be solved via the domain= in PAM rather than by specifying the service in sssd.conf.

First, I would argue that the PAM config file is where users will look first for auth config, so putting it on the pam_sss line makes it obvious, while an allowed_services statement buried inside the domain definition in sssd.conf is easy to miss.

Second, for the problem I'm trying to solve I will be running two ssh daemons which need to have different configs, including different domains inside sssd. If the PAM service name was passed into sssd I would be able to use that, but if a predefined list of services was used by sssd, as is done elsewhere in sssd.conf, I would not be able to differentiate the two ssh daemons which need different domains.

The issue OTOH is that you can allow to trust those options only if the peer sending them is root.
This means we need an eforced set of options also in sssd.coinf (probably in the [pam] section) that instead enforces whatever domains for user applications using pam.

Replying to [comment:18 simo]:

The issue OTOH is that you can allow to trust those options only if the peer sending them is root.
This means we need an eforced set of options also in sssd.coinf (probably in the [pam] section) that instead enforces whatever domains for user applications using pam.

Yes; if my memory serves me right, this is pretty much what Sumit said when we talked about this issue a while ago.

Replying to [comment:18 simo]:

The issue OTOH is that you can allow to trust those options only if the peer sending them is root.
This means we need an eforced set of options also in sssd.coinf (probably in the [pam] section) that instead enforces whatever domains for user applications using pam.

What is the harm of trusting the pam.conf file?
I understand that for NSS part we would have to do it differently and not trust someone to pass info to us but the pam configs can be trusted. And application can't win much but specifying a wrong domain, this attack does not have any benefit. [[BR]]
We can for example have a setting in the sssd.conf to trust pam.conf to pass domain argument to SSSD. If set we will respect the setting but the scope is authentication only.

Fields changed

milestone: SSSD 1.12 beta => SSSD 1.12.1

A patch was contributed to the list (thanks!!)

patch: 0 => 1

Fields changed

cc: jpazdziora@redhat.com, mark.nejedlo@tdstelecom.com => jpazdziora@redhat.com, mark.nejedlo@tdstelecom.com, dgollub@brocade.com

Mass-moving all tickets that didn't make 1.12.1 into 1.12.2

milestone: SSSD 1.12.1 => SSSD 1.12.2

Fields changed

design: => https://fedorahosted.org/sssd/wiki/DesignDocs/RestrictDomainsInPAM

• master:
  • 830ded2
  • 663fd9b

mark: => 0
resolution: => fixed
status: new => closed

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/2063

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.