Bug 746642

Summary:	[RFE] define pam_passthru service per subtree
Product:	Red Hat Enterprise Linux 6	Reporter:	Jim Minter <jminter>
Component:	389-ds-base	Assignee:	Rich Megginson <rmeggins>
Status:	CLOSED ERRATA	QA Contact:	Sankar Ramalingam <sramling>
Severity:	unspecified	Docs Contact:
Priority:	high
Version:	6.3	CC:	dpal, jgalipea, jrusnack, nkinder
Target Milestone:	rc	Keywords:	FutureFeature
Target Release:	6.4
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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 08:16:45 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	690319

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