Bug 1170910

Summary:	SSSD should not fail authentication when only allow rules are used
Product:	Red Hat Enterprise Linux 6	Reporter:	Arpit Tolani <atolani>
Component:	sssd	Assignee:	Pavel Reichl <preichl>
Status:	CLOSED ERRATA	QA Contact:	Kaushik Banerjee <kbanerje>
Severity:	low	Docs Contact:
Priority:	low
Version:	6.6	CC:	atolani, grajaiya, jhrozek, kbanerje, lslebodn, mkosek, mzidek, pbrezina, preichl, sssd-maint, viggiani
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	sssd-1.12.4-34.el6	Doc Type:	Bug Fix
Doc Text:	* When the simple_allow_groups and simple_allow_users options contained non-existent and existing entries, SSSD denied access to the existing users or groups. Now, SSSD logs and skips the non-existent entries and correctly handles the existing ones. (BZ#1170910)	Story Points:	---
Clone Of:
Clones:	1175408 1274322 (view as bug list)		Environment:
Last Closed:	2015-07-22 06:42:37 UTC	Type:	Bug
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:	1175408

Description Arpit Tolani 2014-12-05 05:12:32 UTC

Description of problem:
SSSD should not fail when only allow rules are used

In case of GID to name resolve failure, SSSD should not deny user auth when only allow rules are used.

Version-Release number of selected component (if applicable):
1.11.x

Comment 1 Jakub Hrozek 2014-12-05 07:21:35 UTC

Assigning to pavel, b/c he already has a patch.

Comment 2 Jakub Hrozek 2014-12-05 07:22:56 UTC

Upstream ticket:
https://fedorahosted.org/sssd/ticket/2519

Comment 4 Jakub Hrozek 2014-12-11 10:00:11 UTC

QA:

to test, add an existing and a nonexisting group name to the simple_allow_groups lines. Before the fix, even the valid group was denied access. With the fix, sssd should skip the nonexisting group name.

simple_deny_groups should always fail with a non existing group name.

To make sure the parser hits the faulty code, the nonexisting group name should come first in the list.

Comment 8 Mimmus 2015-03-16 17:17:59 UTC

Do duplicate gidNumber(s) could give same problems?

Comment 9 Lukas Slebodnik 2015-03-16 17:44:13 UTC

(In reply to Mimmus from comment #8)
> Do duplicate gidNumber(s) could give same problems?

I'm not sure why do you reply to this BZ? If you think your question is related to this BZ then please elaborate otherwise please ask on upstream mailing list sssd-users.org.

Comment 10 Jakub Hrozek 2015-03-16 21:30:49 UTC

Duplicate GIDs can lead to unpredictable behaviour and are not supported by SSSD. I would suggest to fix your server..

Comment 11 Mimmus 2015-03-17 09:59:48 UTC

Sorry Lukas, I found this BZ searching for access denied due to GID to name resolve failure. I will follow correct channels

Comment 12 Kaushik Banerjee 2015-04-20 12:31:33 UTC

Re-opening. Tested with sssd-1.12.4-31.el6

Steps to test:

1. On AD Server, create a user and it's group under "CN=Users,DC=sssdad2012r2,DC=com"
i.e. "CN=kau1,CN=Users,DC=sssdad2012r2,DC=com" and "CN=kaugrp1,CN=Users,DC=sssdad2012r2,DC=com"

2. Create another group in another search base. i.e. "CN=kaugrp2,CN=Computers,DC=sssdad2012r2,DC=com"

3. kau1 is a member to kaugrp1 and kaugrp2

4. Restrict sssd to ldap_group_search_base = cn=Users,dc=sssdad2012r2,dc=com
[domain/sssdad2012r2.com]
debug_level = 0xFFF0
id_provider = ad
ad_domain = sssdad2012r2.com
cache_credentials = True
krb5_store_password_if_offline = True
use_fully_qualified_names = True
fallback_homedir = /home/%d/%u
ldap_group_search_base = cn=Users,dc=sssdad2012r2,dc=com
access_provider = simple
simple_allow_groups = kaugrp2, kaugrp1

5. Auth as kau1:
# ssh -l kau1 localhost
kau1@localhost's password: 
Connection closed by ::1

/var/log/secure shows:
Apr 20 17:56:29 dhcp207-169 sshd[28773]: pam_sss(sshd:account): Access denied for user kau1: 4 (System error)

Domain log shows:
(Mon Apr 20 17:56:29 2015) [sssd[be[sssdad2012r2.com]]] [simple_check_get_groups_next] (0x0040): Could not resolve name of group with GID 599012886
(Mon Apr 20 17:56:29 2015) [sssd[be[sssdad2012r2.com]]] [simple_access_check_done] (0x0040): Could not collect groups of user kau1
(Mon Apr 20 17:56:29 2015) [sssd[be[sssdad2012r2.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 4, <NULL>) [Success]

Comment 16 Kaushik Banerjee 2015-04-30 11:06:47 UTC

Verified with sssd-1.12.4-34.el6.x86_64

# ssh -l kau1 localhost
kau1@localhost's password: 
Last login: Thu Apr 30 16:32:54 2015 from localhost
-sh-4.1$

Comment 18 errata-xmlrpc 2015-07-22 06:42:37 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.

https://rhn.redhat.com/errata/RHBA-2015-1448.html