RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 746642 - [RFE] define pam_passthru service per subtree
Summary: [RFE] define pam_passthru service per subtree
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: 389-ds-base
Version: 6.3
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: 6.4
Assignee: Rich Megginson
QA Contact: Sankar Ramalingam
URL:
Whiteboard:
: 863415 (view as bug list)
Depends On:
Blocks: 690319
TreeView+ depends on / blocked
 
Reported: 2011-10-17 11:17 UTC by Jim Minter
Modified: 2020-09-13 20:18 UTC (History)
4 users (show)

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.
Clone Of:
Environment:
Last Closed: 2013-02-21 08:16:45 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 181 0 None None None 2020-09-13 19:57:57 UTC
Github 389ds 389-ds-base issues 487 0 None None None 2020-09-13 20:18:34 UTC
Red Hat Product Errata RHSA-2013:0503 0 normal SHIPPED_LIVE Moderate: 389-ds-base security, bug fix, and enhancement update 2013-02-21 08:18:44 UTC

Description Jim Minter 2011-10-17 11:17:38 UTC 
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 17:27:26 UTC 
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 15:48:10 UTC 
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 16:23:46 UTC 
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 10:48:06 UTC 
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 16:21:36 UTC 
Upstream ticket:
https://fedorahosted.org/389/ticket/181
Comment 8 Nathan Kinder 2012-02-28 21:11:14 UTC 
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 12:31:22 UTC 
This is automated in pam_pta testsuite.
Comment 11 Nathan Kinder 2013-01-31 17:57:29 UTC 
*** Bug 863415 has been marked as a duplicate of this bug. ***
Comment 13 errata-xmlrpc 2013-02-21 08:16:45 UTC 
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.