Bug 1043667

Summary:	[GSS] (6.3) LDAP Group Loading - Should Not Fail for Non-existent User
Product:	[JBoss] JBoss Enterprise Application Platform 6	Reporter:	Derek Horton <dehort>
Component:	Domain Management	Assignee:	Darran Lofthouse <darran.lofthouse>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Petr Kremensky <pkremens>
Severity:	high	Docs Contact:	Russell Dickenson <rdickens>
Priority:	unspecified
Version:	6.2.0	CC:	brian.stansberry, darran.lofthouse, emuckenh, kkhan, myarboro, olukas, smumford, tfonteyn
Target Milestone:	ER2
Target Release:	EAP 6.3.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:	Cause: The authentication process using security realms occurs in two steps, first authentication is performed based on the client and server negotiating a mechanism and then the group information for the authenticated user is loaded in a second step. Consequence: The local authentication mechanism authenticates the user using a file challenge and represents the user using an artificially specified username, if this user can not be mapped to a user in LDAP then any group loading using LDAP fails. Fix: An attribute 'skip-group-loading' has been added to the <local /> element used to enable local authentication. Result: When 'skip-group-loading' is set to true after local authentication has occurred group loading is skipped and the error avoided, if a different mechanism is used then group loading proceeds as normal.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-06-28 15:38:13 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:	1051240

Description Derek Horton 2013-12-16 21:02:38 UTC

Description of problem:
Where a security realm is configured to load groups from LDAP it should not cause an authentication failure if the user is not found in LDAP.
One example is local authentication where the user may not exist.
Another is domain mode servers where the servers have a custom name and generated password that they use to connect back to the local host controller.

Comment 1 Derek Horton 2014-01-09 22:04:26 UTC

6.x PR:
https://github.com/jbossas/jboss-eap/pull/780

Comment 2 Rostislav Svoboda 2014-01-10 06:46:24 UTC

QA is OK with forced qa_ack.

Comment 4 Ondrej Lukas 2014-03-06 11:11:26 UTC

Verification on EAP 6.3.0.DR1 failed. It seems it still fails. I've added authorization through LDAP (for load groups from LDAP, see below) and then in case I defined $local user in ldif for LDAP I can connect to jboss-cli but in case I comment out $local user from ldif it fails, but according to right behavior it still should allow me access to jboss-cli.

I used following authorization for ManagementRealm:
    <authorization map-groups-to-roles="false">
	<ldap connection="ldapConnection">
	    <username-to-dn force="false">
		<username-filter base-dn="ou=People,dc=jboss,dc=org" user-dn-attribute="dn" attribute="uid" />
	    </username-to-dn>
	    <group-search group-name="SIMPLE" group-dn-attribute="dn" group-name-attribute="cn">
		<group-to-principal base-dn="ou=Groups,dc=jboss,dc=org" search-by="DISTINGUISHED_NAME">
		    <membership-filter principal-attribute="member"/>
		</group-to-principal>
	    </group-search>
	</ldap>
    </authorization>

Comment 7 Ondrej Lukas 2014-04-30 08:46:10 UTC

Verified on EAP 6.3.0.ER2. Using parameter skip-group-loading resolved this issue.

Comment 8 Scott Mumford 2014-05-05 01:13:53 UTC

Is this issue the same as the one Tom raised in bug 1069127? If so, which should carry the release notes text into the final document?

Comment 9 Darran Lofthouse 2014-05-07 18:11:47 UTC

Yes that is correct, both are the same issue - the initial description was just described differently.

Comment 10 Scott Mumford 2014-05-07 22:23:28 UTC

Thanks Darran.
Marking for exclusion from 6.3.0 Release Notes as the issue is already noted in 1069127.