We accessed the RES Console using the following URL: -
and logged in as the resAdmin user ( this user is in Active Directory, which is federated into the WAS cell ) and corresponding password.
However, when we clicked on the Diagnostics tab, and clicked the Run Diagnostics button: -
we saw exceptions against the XU MBean and Rule Session Second Execution processes: -
, with the following errors in SystemOut.log: -
javax.management.JMRuntimeException: ADMN0022E: Access is denied for the notifyRulesetArchiveChanged operation on IlrXUManagement MBean because of insufficient or empty credentials.
and: -
Caused by: javax.management.JMRuntimeException: ADMN0022E: Access is denied for the getAdapterVersion operation on IlrXUManagement MBean because of insufficient or empty credentials.
We found a number of IBM Technotes and discussion forum posts on the problem, including this advice: -
<snip>
The application server security is enabled but the Rule Execution Server users do not have the required administrative roles:
If working with WebSphere Application Server or WebLogic, you must provide some level of administrative role to the Rule Execution Server admin user so that that user can access MBeans.
If working with WebSphere Application Server or WebLogic, you must provide some level of administrative role to the Rule Execution Server admin user so that that user can access MBeans.
</snip>
and this: -
<snip>
This error indicates that security is enabled on the server and that the required roles have not been defined for the application.
Indeed, when security is enabled, DVS require all groups or users who are allowed to access it to be mapped to one of the two mandatory roles: resAdministrators or resDeployers.
For Rule Execution Server, those roles are: resAdministrators, resDeployers, and resMonitors.
For RTS: rtsAdministrator, rtsConfigManager, rtsInstaller, and rtsUser.
Indeed, when security is enabled, DVS require all groups or users who are allowed to access it to be mapped to one of the two mandatory roles: resAdministrators or resDeployers.
For Rule Execution Server, those roles are: resAdministrators, resDeployers, and resMonitors.
For RTS: rtsAdministrator, rtsConfigManager, rtsInstaller, and rtsUser.
</snip>
and this: -
<snip>
Map your administrator group (resAdministrators by default) to the Monitor role in the WebSphere Application Server administration console.
</snip>
This led us to believe that the user ( resAdmin ) wasn't in the right groups, so we spent time adding it to the resMonitors group, but to no avail. We started to think that the problem might be related to WAS <-> LDAP interactions, including group search base and filters.
Then we found this forum post: -
which said, in part: -
Did you map the resAdministrators group to the Monitor role?
To access the MBeans of the Rule Execution Server model, an application must have sufficient security credentials, restricted to the Monitor role in the WebSphere authentication system.
Rule Execution Server users can be given access to the MBeans of the model by configuring a mapping between the resAdministrators group declared in the custom registry and the Monitor role.
To map users to the Monitor role:
1. In the Integrated Solutions Console open Users and Groups > Administrative group roles.
2. Click Add. For Role(s) select Monitor, then click Search and move the entry beginning with resAdministrators from the Available column to the Mapped to role column.
Click OK.
3. Click the Save directly to the master configuration.
4. Open Users and Groups > Administrative user roles.
5. Click Add. For Role(s) select Monitor, then click Search. Move resAdmin from the Available column to the Mapped to role column.
Click OK.
6. Click the Save directly to the master configuration.
7. Restart your application server or your deployment manage
It then dawned on us.
As this is a clustered environment, the RES application needs to talk, via JMX, to the Deployment Manager and, therefore, the resAdmin user needs to be able to access the WAS administration MBeans.
Once we added the resAdministrators and resDeployers groups ( these are in LDAP ) into the WAS Administrative Group monitor role: -
and restarted the application server on which he RES Console runs, all was well :-)
