UNAUTHENTICATED message after enabling JMX collection data.

Products

• APP PERF MANAGEMENT
• CA Application Performance Management Agent (APM / Wily / Introscope)
• CUSTOMER EXPERIENCE MANAGER
• INTROSCOPE

Issue/Introduction

 Issue:

 After enabling JMX collection data under Java Agent, the application server starts showing the below message in the log:

 Trace: 2015/05/20 13:38:19.917 01 t=9C24D8 c=UNK key=S2 (13007002)
   ThreadId: 00000026
   FunctionName: com.ibm.ws.security.role.RoleBasedAuthorizerImpl
   SourceId: com.ibm.ws.security.role.RoleBasedAuthorizerImpl
   Category: AUDIT
   ExtendedMessage: BBOO0222I: SECJ0305I: The role-based authorization check failed for admin-authz operation J2CConnectionFactory:getName.  The user

   UNAUTHENTICATED (unique ID: unauthenticated) was not granted any of the following required roles: deployer, operator, configurator, monitor, administrator,

   adminsecuritymanager, auditor.
   

 

Environment:  

Introscope 9.7.0
WebSphere 7.0.21 under Z/OS 1.12
Java Agent 9.7.0

 

Workaround:

 

For Z/OS system:

1. Make sure that the '<agent-home>/common/WebAppSupport.jar' file is present in the agent directory. Where <agent-home> is the root of the APM Agent installation. If not, then restore it from the Agent installation archive.

2. Go into the configuration for the previously defined Introscope Custom Service in WAS. (Servers > <server-name> > Administration > Custom Services > <service-name>).

3. Configure the Classpath setting to '<agent-home>/common/WebAppSupport.jar' if it was not already. Make sure this is the exact path and not for example '<agent-home>/core/ext/WebAppSupport.jar'.

4. Remove the '<agent-home>/core/ext/WebAppSupport.jar' file from the agent directory.

5. Restart the WAS server.

 

 For Other Operation Systems:

1. Add two custom properties to the custom service: jmxusername and jmxpassword.

2. The custom service configuration page in WAS 6.1 has a link for "Custom properties" on the Custome Service screen. Clicking that link brings up the properties

    configuration screen, where you can configure the keys (jmxusername, jmxpassword) and their corresponding values. (You can use the same username and      

    password you use to login to the admin console if you want.)

    For example, the WAS Admin console username and password can be used, "Admin" and "Admin":

    -jmxusername in the "name" field and "Admin" under the "value" field
    -jmxpassword in the "name" field and "Admin" under the "value" field

3. Save the configuration.

4. Restart the server.

 

Additional Information:  

-  This additional step above applied only for Z/OS. For other Operations Systems, see: 

    How to configure Agent 9.5 with Weblogic 11g and Enable Remote JMX collection    http://www.ca.com/us/support/ca-support-online/product-content/knowledgebase-articles/tec605262.aspx

 

    Not seeing JMX metrics after following the correct configuration steps.

    http://www.ca.com/us/support/ca-support-online/product-content/knowledgebase-articles/tec1057201.aspx

 

 - The core of the issue is the presence of a copy of WebAppSupport.jar in the core/ext directory. For any plugin that has a type defined as 'service' in the manifest in core/ext,  the agent will load it up and start the service. So what is happenning is  WAS launches the JMX service based on the custom service definition with the correct jmxusername/jmxpassword, but at the same time the Agent launches a copy of the service without then additional jmx* attributes.

 

   The authentication data is kept as a static class variable, which means that there is a race condition between the two 'instances' of the JMX service - one setting the correct authentication data, one clearing it. Depending on the order you will either get a finite amount of the 'UNAUTHENTICATED' messages (if the custom service instance comes up second) or a continuous stream of these messages (if the instance started by the Agent comes up second).

    Based on the notes in the issue,  I am concluding that the user has a copy of the WebAppSupport.jar file in the core/ext directory. Thus, it is likely that what we observed in our environment is the same thing the customer is seeing.

 

Environment

Release:
Component: APMAGT