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 751291 - sssd-ldap: "getent shadow" returns only local users
Summary: sssd-ldap: "getent shadow" returns only local users
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd
Version: 6.1
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: rc
: ---
Assignee: Stephen Gallagher
QA Contact: IDM QE LIST
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-11-04 08:40 UTC by dfrise
Modified: 2011-11-04 12:05 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-11-04 12:05:25 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description dfrise 2011-11-04 08:40:56 UTC 
Description of problem:
System was configured with system-config-authentication to use an LDAP server for authentication with TLS.
"enumerate = True" was set in /etc/sssd/sssd.conf to be able to list local and LDAP users with getent.
Users are able to login without problem.
"getent passwd" work as expected but not "getent shadow" which returns only local users.


Version-Release number of selected component (if applicable):
Red Hat Enterprise Linux Server release 6.1 (Santiago)
kernel-2.6.32-131.12.1.el6.x86_64
sssd-1.5.1-34.el6_1.3.x86_64
sssd-client-1.5.1-34.el6_1.3.x86_64



How reproducible: always


Steps to Reproduce:
1. Configure system to use LDAP for authentication with TLS
2. Add "enumerate = True" in /etc/sssd/sssd.conf
3. Restart sssd
  
Actual results:
"getent shadow" lists only local users
"getent shadow" <ldapuser> returns nothing


Expected results:
"getent shadow" should list local and ldap users
"getent shadow" <ldapuser> should list ldapuser's line

Additional info:
Extract of sssd running in debug mode (5) when launching "getent passwd dfrise": and "getent shadow dfrise":

(Fri Nov  4 08:52:19 2011) [sssd[nss]] [accept_fd_handler] (4): Client connected!
(Fri Nov  4 08:52:19 2011) [sssd[nss]] [sss_cmd_get_version] (5): Received client version [1].
(Fri Nov  4 08:52:19 2011) [sssd[nss]] [sss_cmd_get_version] (5): Offered version [1].
(Fri Nov  4 08:52:19 2011) [sssd[nss]] [nss_cmd_getpwnam] (4): Requesting info for [dfrise] from [<ALL>]
(Fri Nov  4 08:52:19 2011) [sssd[nss]] [nss_cmd_getpwnam_search] (4): Requesting info for [dfrise@default]
(Fri Nov  4 08:52:19 2011) [sssd[nss]] [client_recv] (5): Client disconnected!

Same for "getent shadow dfrise":
Comment 2 Jakub Hrozek 2011-11-04 09:11:18 UTC 
That's expected. We don't handle the shadow map and currently have no plans to
do so.
Comment 3 dfrise 2011-11-04 10:18:03 UTC 
(In reply to comment #2)
> That's expected. We don't handle the shadow map and currently have no plans to
> do so.

Why?
This was supported and documented in RHEL5.
This is true that I asked myself why there is no man page for getent under RHEL6.
Are you gonna remove this useful command from the distribution?
Comment 4 Stephen Gallagher 2011-11-04 12:02:29 UTC 
(In reply to comment #3)
> (In reply to comment #2)
> > That's expected. We don't handle the shadow map and currently have no plans to
> > do so.
> 
> Why?
> This was supported and documented in RHEL5.
> This is true that I asked myself why there is no man page for getent under
> RHEL6.
> Are you gonna remove this useful command from the distribution?

There are several good reasons not to support the shadow map at this time.

1) Most LDAP servers do not maintain the shadow map themselves. nss_ldap/pam_ldap hid this behind the scenes, but updates to the shadow map (except the password) were performed with the user's credentials. This means that if the user wanted to do so, they had privilege to extend their password expiration, etc. without admin intervention.

2) The shadow map has a long and vile history of exposing users' password hashes. This is something we want to discourage.

3) Most LDAP servers maintain their own server-side password policy controls (which are usually more robust and are ALWAYS more secure than shadow's client side policy controls). Because of 1), in many cases the server-side policy will not agree with the shadow entries (things can get out of sync over time since it's the clients that update these entries; the server doesn't keep them in sync).

So to sum up, the shadow information is always insecure and often completely wrong. As such, we have no plans in the immediate future to enable this misfeature.
Comment 5 RHEL Program Management 2011-11-04 12:05:25 UTC 
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.
Note You need to log in before you can comment on or make changes to this bug.