In previous versions of JBoss EAP, LDAP group loading could fail if an authenticated user could not be mapped to an LDAP account. This issue could arise because the authentication process using security realms first negotiates a mechanism between the client and the server, then loads the group information for the user. Because the local authentication system represents the user with an artificial username, the second part of this process could fail if the LDAP server could not map the username to a user.
In this release of the product, a new attribute; 'skip-group-loading', has been added to the <local /> element that is used for local authentication. When this attribute is set to `true` group loading is skipped after local authentication has occurred, thus avoiding the error. If a different mechanism is used, however, group loading proceeds as normal.
When RBAC is not enabled, a security realm in the management section allows the use of the "<local />" login mechanism to work fine in conjunction with an LDAP user store.
When RBAC is enabled, the "<local />" login mechanism can still be configured but will not work.
The request is to allow this to work even when RBAC is enabled.
Why does the customer need this?
automated local scripts should use the "local" mechanisme, while actual management users need to use LDAP authentication/authorization
Is the $local user mapped to any role, e.g. what we have in our standard configs?
I don't believe this is RBAC, just an issue loading groups where the local mechanism is also in play so investigating further on that basis.
Verified on EAP 6.3.0.ER2. Using parameter skip-group-loading resolved this issue.
Changed <literal></literal> tags in Doc Text to ticks (`) to fix Bug 1096865