Bug 1170910 - SSSD should not fail authentication when only allow rules are used
Summary: SSSD should not fail authentication when only allow rules are used
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd
Version: 6.6
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: rc
: ---
Assignee: Pavel Reichl
QA Contact: Kaushik Banerjee
URL:
Whiteboard:
Depends On:
Blocks: 1175408
TreeView+ depends on / blocked
 
Reported: 2014-12-05 05:12 UTC by Arpit Tolani
Modified: 2019-04-16 14:26 UTC (History)
11 users (show)

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)
Clone Of:
: 1175408 1274322 (view as bug list)
Environment:
Last Closed: 2015-07-22 06:42:37 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:1448 normal SHIPPED_LIVE sssd bug fix and enhancement update 2015-07-20 18:43:53 UTC

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@lists.fedorahosted.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@sssdad2012r2.com, kaugrp1@sssdad2012r2.com

5. Auth as kau1:
# ssh -l kau1@sssdad2012r2.com localhost
kau1@sssdad2012r2.com@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@sssdad2012r2.com: 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@sssdad2012r2.com localhost
kau1@sssdad2012r2.com@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


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