Bug 1043667 - [GSS] (6.3) LDAP Group Loading - Should Not Fail for Non-existent User
Summary: [GSS] (6.3) LDAP Group Loading - Should Not Fail for Non-existent User
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Domain Management
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ER2
: EAP 6.3.0
Assignee: Darran Lofthouse
QA Contact: Petr Kremensky
Russell Dickenson
URL:
Whiteboard:
Depends On:
Blocks: 1051240
TreeView+ depends on / blocked
 
Reported: 2013-12-16 21:02 UTC by Derek Horton
Modified: 2018-12-04 16:41 UTC (History)
8 users (show)

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.
Clone Of:
Environment:
Last Closed: 2014-06-28 15:38:13 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
JBoss Issue Tracker WFLY-2660 Critical Resolved LDAP Group Loading - Should Not Fail for Non-existent User. 2014-06-30 10:03:02 UTC
JBoss Issue Tracker WFLY-3048 Major Resolved "Local" authentication fails when LDAP is used for ManagementRealm 2014-06-30 10:03:02 UTC

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.


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