Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 746642 - [RFE] define pam_passthru service per subtree
[RFE] define pam_passthru service per subtree
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: 389-ds-base (Show other bugs)
6.3
Unspecified Unspecified
high Severity unspecified
: rc
: 6.4
Assigned To: Rich Megginson
Sankar Ramalingam
: FutureFeature
: 863415 (view as bug list)
Depends On:
Blocks: 690319
  Show dependency treegraph
 
Reported: 2011-10-17 07:17 EDT by Jim Minter
Modified: 2013-02-21 03:16 EST (History)
4 users (show)

See Also:
Fixed In Version: 389-ds-base-1.2.11.12-1.el6
Doc Type: Enhancement
Doc Text:
Feature: Allow PAM Pass Through to pass through authentication to different PAM stacks, based on domain membership and/or some property of the user entry. Reason: Allow users whose entries are in dc=domainA to pass through the authentication to the AD server for domainA, and allow users whose entries are in dc=domainB to pass through the authentication to the AD server for domainB. Result (if any): A user can login to RHDS using the account and credentials from the correct AD server based on domain membership.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-21 03:16:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:0503 normal SHIPPED_LIVE Moderate: 389-ds-base security, bug fix, and enhancement update 2013-02-21 03:18:44 EST

  None (edit)
Description Jim Minter 2011-10-17 07:17:38 EDT
In RHDS 8.2 (and 9.0 AFAIK), only one global PAM service file can be defined per RHDS instance for use by the pam_passthru plugin.

In the example use case that >1 AD domains are synchronised into RHDS, it would be nice to be able to define binds against one AD domain/RHDS subtree to use one PAM service file (to passthru authentication to the relevant AD DC) and binds to a different AD domain/RHDS subtree to use a different PAM service file.

At the moment, this can be worked around with pam_regex from http://puszcza.gnu.org.ua/software/pam-modules/ and the following example service file, but it's ugly and pam_regex is not part of RHEL so not supported.

=== 8< ===
#%PAM-1.0
auth     [default=2 success=ignore] pam_regex.so regex=^[^@]+@domain1.com$
auth     optional   pam_regex.so transform=s/@domain1.com$//
auth     required   pam_ldap_static.so config=/etc/ldap-domain1.conf
auth     [default=2 success=ignore] pam_regex.so regex=^[^@]+@domain2.com$
auth     optional   pam_regex.so transform=s/@domain2.com$//
auth     required   pam_ldap_static.so config=/etc/ldap-domain2.conf
account  sufficient pam_permit.so
=== 8< ===
Comment 3 Dmitri Pal 2011-12-11 12:27:26 EST
Can this be accomplished with SSSD domains?
It would be nice if in case of the SSSD integration DS would be able to expand the user name into the full user name like this user@domain and pass to SSSD. That would allow to configure multiple domains and have one simple pam file at the same time.
Comment 4 Rich Megginson 2011-12-12 10:48:10 EST
Is the domain passed to the DS?  That is, does the user login with the username + domain name like "rmeggins@DOMAIN"?
Comment 5 Dmitri Pal 2011-12-12 11:23:46 EST
No, here is how I see it.

* DS has 3 different domains configured in one instance: A, B and C.
* User 'foo' tries to log in. 
* DS would do a search across A, B and C. If the user is found in domain A his name is expanded into foo@A, if in B then foo@B and if in C then foo@C. If the result set is empty the user is not found and can't log in. If there are more than one entry returned in the search then this is a duplicate name and the access should be denied and corresponding message should be sent to the log.
* The expanded full name is then passed to PAM passthrough.
* SSSD is configured with the same domains but by looking at the full name it would be able to see which domain to use.

This solves the problem of passsync. With this one can setup the DS without need to reset passwords.
Comment 6 Jim Minter 2012-01-04 05:48:06 EST
In principal, using SSSD for this would be fine as far as I'm concerned; testing and documenting it would be good.

I think the foo@A / foo@B search idea won't fly with a lot of customers as it's often a legitimate case that there are two different physical users who happen to have identical usernames in two separate domains.  It's necessary to allow the login to be fully specified, i.e. the user logs in specifying the domain to use as well as the domain name.  As far as I can see bz746643 or equivalent is a pre-requisite for this to work.
Comment 7 Rich Megginson 2012-01-09 11:21:36 EST
Upstream ticket:
https://fedorahosted.org/389/ticket/181
Comment 8 Nathan Kinder 2012-02-28 16:11:14 EST
This was recently fixed upstream in 389 Directory Server.  See the ticket in comment#7 above for details.
Comment 10 Ján Rusnačko 2012-11-19 07:31:22 EST
This is automated in pam_pta testsuite.
Comment 11 Nathan Kinder 2013-01-31 12:57:29 EST
*** Bug 863415 has been marked as a duplicate of this bug. ***
Comment 13 errata-xmlrpc 2013-02-21 03:16:45 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-0503.html

Note You need to log in before you can comment on or make changes to this bug.