Bug 26029 - pam_unix.so prevents pam_ldap.so from enforcing group membership
Summary: pam_unix.so prevents pam_ldap.so from enforcing group membership
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: authconfig   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: Aaron Brown
Whiteboard: Florence RC-1
Depends On:
TreeView+ depends on / blocked
Reported: 2001-02-05 01:38 UTC by Christopher Barton
Modified: 2007-04-18 16:31 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-02-12 03:01:49 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

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 

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.


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 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.

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