Bug 26029

Summary:	pam_unix.so prevents pam_ldap.so from enforcing group membership
Product:	[Retired] Red Hat Linux	Reporter:	Christopher Barton <cpbarton>
Component:	authconfig	Assignee:	Nalin Dahyabhai <nalin>
Status:	CLOSED RAWHIDE	QA Contact:	Aaron Brown <abrown>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.1
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:	Florence RC-1
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-02-12 03:01:49 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:

Description Christopher Barton 2001-02-05 01:38:13 UTC

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)


When using "pam_groupdn" in /etc/ldap.conf for pam_ldap.so (from 
nss_ldap), group membership is not enforced.

This is being caused by 'account sufficient pam_unix.so' 
in /etc/pam.d/system-auth.  LDAP group membership enforcement works when i 
comment this line out of system-auth.

Reproducible: Always
Steps to Reproduce:
1. Setup nss_ldap to enforce group membership.
2. Pick an account whose dn is not a member of the required group.
3. Login with account from 2 above on an LDAP client machine.

	

Actual Results:  Login succeeds.

Expected Results:  Login should fail with with the following notice:

You must be a <attr> of <group> to login.

where attr is an ldap attribute & group is a posixGroup

This works just fine if I comment account sufficient pam_unix.so out 
of /etc/pam.d/system-auth.

This functionality is critical for deploying cool, centralized LDAP 
authentication.

Comment 1 Christopher Barton 2001-02-05 01:47:36 UTC

This doesn't work in Guinness either.

Comment 2 Nalin Dahyabhai 2001-02-05 06:19:04 UTC

Nice catch.  The account management supplied by pam_unix amounts to verifying
that the user's shadow information (if there is any) can be read.

To verify, if you change the pam_unix account line from 'sufficient' to
'required', does it work as expected?

Comment 3 Christopher Barton 2001-02-05 18:04:56 UTC

Yes, changing sufficient to required fixes it.  Thanks!

Comment 4 Glen Foster 2001-02-05 22:51:24 UTC

We (Red Hat) should really try hard to fix this before next release.

Comment 5 Nalin Dahyabhai 2001-02-06 02:03:21 UTC

Caveat: changing it to required also breaks local a local root user.  Try this:

account     required      /lib/security/pam_unix.so
account     [default=ok user_unknown=ignore] /lib/security/pam_ldap.so

The syntax looks a little strange, but it appears to work slightly better on my
test machine.  Since the system-auth file is generated by authconfig, I'm going
to reclassify this as an authconfig bug.  It'll be fixed in authconfig 4.1.1.

Thanks!

Comment 6 Christopher Barton 2001-02-08 20:51:45 UTC

Am using: Fisher plus authconfig-4.1.1-1 & pam-0.74-5

From my testing, authentication now works in the following way: 1) LDAP users
can authenticate against ldap, 2) root can authenticate against local files.

However, if I stop slapd, root can no longer authenticate.  Commenting out
pam_ldap.so fixes it.

Comment 7 Christopher Barton 2001-02-08 20:59:05 UTC

If slapd is stopped, logging in via login as root produces the message: "Error
in service module".

Comment 8 Nalin Dahyabhai 2001-02-09 21:54:20 UTC

Try authconfig-4.1.3, which until it shows up in Raw Hide is up in
http://people.redhat.com/nalin/test/.  It should also set pam_ldap to ignore
server errors.  One of our developers tripped over this problem when he
misspelled the server's name, so I think we've got it fixed.

Comment 9 Christopher Barton 2001-02-12 03:01:46 UTC

Nope.  New info.  Am using: Stock Fisher plus authconfig-4.1.3-1,
nss_ldap-142-2, & pam-0.74-5

slapd is stopped, root's login info is in /etc/passwd, /etc/group, & /etc/shadow

If /etc/ldap.conf is pointed at 127.0.0.1 with TLS on, root can login.  With TLS
off, login still produces an "Error in service module" error.  

(I'm assuming TLS off is safe for localhost, if not then I guess I don't really
care about this bug).

Thanks as always!

Comment 10 Nalin Dahyabhai 2001-02-13 02:14:52 UTC

Try adding "service_err=ignore" to the list of flags within the '[' and ']'. 
This will keep the module from having an effect if the server is down.  I'm a
little uncomfortable with having it allow the user access if the server is
unreachable, so even though I've made the change to authconfig's CVS tree (it'll
pop up in 4.1.5), it may get reverted before the final release.