Bug 751291

Summary:	sssd-ldap: "getent shadow" returns only local users
Product:	Red Hat Enterprise Linux 6	Reporter:	dfrise
Component:	sssd	Assignee:	Stephen Gallagher <sgallagh>
Status:	CLOSED WONTFIX	QA Contact:	IDM QE LIST <seceng-idm-qe-list>
Severity:	urgent	Docs Contact:
Priority:	unspecified
Version:	6.1	CC:	grajaiya, jgalipea, jhrozek, prc
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-11-04 12:05:25 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 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.