Bug 1404697

Summary:	SSSD does not skip GPO if no gpcFunctionalityVersion present
Product:	Red Hat Enterprise Linux 6	Reporter:	Andrey Bondarenko <abondare>
Component:	sssd	Assignee:	Michal Zidek <mzidek>
Status:	CLOSED ERRATA	QA Contact:	Steeve Goveas <sgoveas>
Severity:	high	Docs Contact:
Priority:	high
Version:	6.8	CC:	dlavu, ealcaniz, grajaiya, jhrozek, lslebodn, mkosek, mzidek, pbrezina, tlavigne
Target Milestone:	rc
Target Release:	6.8
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	sssd-1.13.3-56.el6	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1404725 (view as bug list)		Environment:
Last Closed:	2017-03-21 09:58:43 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:	1404725

Description Andrey Bondarenko 2016-12-14 12:57:15 UTC

Description of problem:

If the  groupPolicyContainer created by some tool (for example the https://www.quest.com/products/password-manager/) does not conatin gpcFunctionalityVersion attribute and sssd stumbles upon such container, it stops the processing and just quit with the default decision (wich is usually deny).

To avoid this problem, the SSSD should skip any GPO that does not contain the gpcFunctionalityVersion because this is the behavior specified by the MS-GPOL, see 3.2.5.1.6:

-----
3.2.5.1.6 GPO Filter Evaluation
In this step, the client MUST process the GPO as follows:
 1. Check for the functionality version of the GPO. If the gPCFunctionalityVersion
    field of the Group Policy Object Search message (as defined in [MS-ADA1]
    section 2.278) is not set to 2, the GPO MUST NOT be included in the rest
    of the protocol sequence. The GPO MUST be considered denied.
-----

given that the GPO itself does not have access control rules, you filter
it out. 


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

sssd-1.14.0-43.el7.x86_64                


Steps to Reproduce:
1. create GPO with https://www.quest.com/products/password-manager/
2. try to log in with such user 

Actual results:

login fails

Expected results:


should log in

Comment 1 Andrey Bondarenko 2016-12-14 13:48:48 UTC

Correct versions for the 6.8 related bug:

sssd-1.13.3-22.el6_8.4.x86_64                               Sun Oct 30 11:19:34 2016
sssd-ad-1.13.3-22.el6_8.4.x86_64                            Sun Oct 30 11:19:32 2016
sssd-client-1.13.3-22.el6_8.4.x86_64                        Sun Oct 30 11:19:30 2016
sssd-common-1.13.3-22.el6_8.4.x86_64                        Sun Oct 30 11:19:31 2016

Comment 4 Jakub Hrozek 2016-12-15 15:24:55 UTC

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

Comment 8 Lukas Slebodnik 2017-01-26 13:43:48 UTC

master:
* 47680083e7e4bf5c433657171bf84cceacc83339
* 6a490b312075d2588ad87bbb8a63466f1ac6a106

sssd-1-14:
* 9bf6c4b5afb5054282f7b8c4c5f7bed26a259f5a
* 94903da8a3723094948b4b99b30f6449fed809da

sssd-1-13:
* 627edf70ab2571d504bc23fdf3b15ce7983d4388
* 0ee20e9ece0d24c335f604b20e1ba7c8ea1d669d

Comment 11 Dan Lavu 2017-02-16 01:28:43 UTC

Manually verified against sssd-1.13.3-56.el6.x86_64

Added a denied user, and the user properly denied. 

ssh user1.176.119
user1.176.119's password: 
Connection closed by UNKNOWN

(Wed Feb 15 20:26:08 2017) [sssd[be[shrd.org]]] [ad_gpo_access_check] (0x0400): CURRENT USER:
(Wed Feb 15 20:26:08 2017) [sssd[be[shrd.org]]] [ad_gpo_access_check] (0x0400):        user_sid = S-1-5-21-343696347-2574225464-2087024737-1109
(Wed Feb 15 20:26:08 2017) [sssd[be[shrd.org]]] [ad_gpo_access_check] (0x0400):   group_sids[0] = S-1-5-21-343696347-2574225464-2087024737-513
(Wed Feb 15 20:26:08 2017) [sssd[be[shrd.org]]] [ad_gpo_access_check] (0x0400):   group_sids[1] = S-1-5-11
(Wed Feb 15 20:26:08 2017) [sssd[be[shrd.org]]] [ad_gpo_access_check] (0x0400): POLICY DECISION:
(Wed Feb 15 20:26:08 2017) [sssd[be[shrd.org]]] [ad_gpo_access_check] (0x0400):  access_granted = 1
(Wed Feb 15 20:26:08 2017) [sssd[be[shrd.org]]] [ad_gpo_access_check] (0x0400):   access_denied = 1
(Wed Feb 15 20:26:08 2017) [sssd[be[shrd.org]]] [ad_gpo_perform_hbac_processing] (0x0040): GPO access check failed: [1432158228](Host Access Denied)
(Wed Feb 15 20:26:08 2017) [sssd[be[shrd.org]]] [ad_gpo_cse_done] (0x0040): HBAC processing failed: [1432158228](Host Access Denied}
(Wed Feb 15 20:26:08 2017) [sssd[be[shrd.org]]] [ad_gpo_access_done] (0x0040): GPO-based access control failed.
(Wed Feb 15 20:26:08 2017) [sssd[be[shrd.org]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 6, <NULL>) [Success]

Comment 13 errata-xmlrpc 2017-03-21 09:58:43 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-2017-0632.html