Bug 1105677

Summary:	[GSS] (6.4.0) Nonexistent ldap group causes authentication to fail in security-realm
Product:	[JBoss] JBoss Enterprise Application Platform 6	Reporter:	Derek Horton <dehort>
Component:	Domain Management	Assignee:	Darran Lofthouse <darran.lofthouse>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Pavel Slavicek <pslavice>
Severity:	urgent	Docs Contact:
Priority:	unspecified
Version:	6.3.0	CC:	dandread, darran.lofthouse, kkhan, nchaudha, pkremens
Target Milestone:	DR4
Target Release:	EAP 6.4.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:	In previous release of JBoss EAP 6, a user containing a reference to a non-existent group returned a failure in authentication while performing principal-to-group searches of LDAP to load a user's group membership information. The user's authentication was aborted. In JBoss EAP 6.4, this issue has been fixed by defining a skip-missing-groups attribute as "true" on the principal-to-group configuration, which allows missing groups to be ignored.	Story Points:	---
Clone Of:	1105619
Clones:	1128176 (view as bug list)		Environment:
Last Closed:		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:	1105619, 1127938, 1128176, 1143052

Description Derek Horton 2014-06-06 17:30:04 UTC

+++ This bug was initially created as a clone of Bug #1105619 +++

Description of problem:
The LdapGroupSearcher code will fail if it tries to lookup a group that 
does not exist on the local ldap server.

This can happen when the ldap systems are configured as trusted domains.  
Even though the security-realm is not configured to use the trusted domain
(it is configured to only look at a single ldap server), the 
user's entry on one ldap server could point at a group that exists on 
the other (trusted) ldap server.

The LdapGroupSearcher code attempts to lookup this role and it fails.  This 
failure is sent back to the http server which results in an HTTP 500 error
and leaves the user with no way to authenticate/login.

There is currently not a way to tell the group searcher code to ignore the 
group/role that cannot be found.


How reproducible:
Create a user in ldap that has a "bogus" group.  Log into the admin console as that user.  Once the LdapGroupSearcher code looks up the user, it will fail when it attempts to lookup the "bogus" group.

Comment 1 Derek Horton 2014-06-06 20:21:27 UTC

PR
https://github.com/jbossas/jboss-eap/pull/1436

Comment 2 Kabir Khan 2014-08-05 15:36:58 UTC

I closed the PR without merging it according to Darran's comments, there is some more info on https://bugzilla.redhat.com/show_bug.cgi?id=1105619

Comment 3 Derek Horton 2014-08-08 14:15:58 UTC

I created a one-off [1] for this issue because a customer is running into this issue when RBAC is enabled.  When they run into this, it is impossible for the users to log into the management console.

The pull request was denied because a system property is used to enable the "ignore nonexistent group" logic.  This option needs to be added to the ldap group searcher xml section of the config file.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1127938

Comment 5 Josef Cacek 2014-10-14 05:57:13 UTC

Verified in 6.4.0.DR4.