How to enable the JBoss EAP 7 management audit log

This article explains how to enable and use the management audit log in Red Hat JBoss Enterprise Application Platform (JBoss EAP) 7.

The management audit log is used to register admin functions and it is created in the $JBOSS_HOME/standalone/data/ $JBOSS_HOME/domain/data/ directory. It logs all operations performed using the management console, command-line interface (CLI), or custom application using the Management API, as described in the JBoss EAP 7.4 configuration guide. Consult the JBoss EAP security configuration documentation to learn about the security audit logging logs authentication success and failures.

Management audit log versus security audit log

The security audit log (or the Elytron audit log in WildFly) is used for security operations. Elytron's audit log is created in $JBOSS_HOME/standalone/logs.

The management audit log is used to register admin functions; this log is created in the $JBOSS_HOME/standalone/data/ directory.

How to set the management log

The following JBoss CLI commands enable management logging:

/core-service=management/access=audit/logger=audit-log:write-attribute(name=enabled,value=true)
/core-service=management/access=audit/logger=audit-log:write-attribute(name=log-boot,value=true)
/core-service=management/access=audit/logger=audit-log:write-attribute(name=log-read-only,value=true)

For the XML configuration file, you can use the following format (you will find the file audit-log.log in the data directory):

<audit-log>
            <formatters>
                <json-formatter name="json-formatter"/>
            </formatters>
            <handlers>
                <file-handler name="file" formatter="json-formatter" relative-to="jboss.server.data.dir" path="audit-log.log"/>
            </handlers>
            <logger log-boot="true" log-read-only="false" enabled="true">
                <handlers>
                    <handler name="file"/>
                </handlers>
            </logger>
        </audit-log>

The audit logs are inside the management context, essentially inside the core-management subsystem:

    <management> <!--- biggest context -->
        <security-realms>
            <security-realm name="ManagementRealm">
               ....
            </security-realm>
            <security-realm name="ApplicationRealm">
            ...
        </security-realms>
        <audit-log> <!--- audit log -->
            ...
        </audit-log>

The configuration above has the following properties: enabled, log-boot, and log-read-only. These audit log operations are defined as follows:

• enabled: If true, the management operations will be recorded in the log.
• log-boot: Use true to log the management operations when booting the server, false otherwise.
• log-read-only: If enabled, all operations will be added to the audit log.

Use cases and usage

A user can get the audit logs, view the operation and the corresponding timestamp, and respond accordingly. Here are a few real-world use case examples:

• Which user deployed and undeployed a specific application, what was the timestamp, and on which host?
• Someone disabled HTTP/2 (HTTP upgrade) in JBoss EAP by mistake, and now the Enterprise Java Beans (EJB) remote communication is not working—which user was that and what time did it occur?
• What are the realms and endpoints configured in the server?
• What time was a certain property/subsystem changed?

However, audit log isn't typically used for the exact order of deployment (starting) of the subsystems, given that the EAP 7 subsystem start order is not defined, except for specific dependencies; thus, that would not be useful.

Of course, as you can see, a management audit log can be very useful for several scenarios, but it gets complex because during boot, some initialization operations will happen, like here:

"operation" : "add",
"address" : [{"subsystem" : "undertow"},
    {"server" : "default-server"},
    {"host" : "default-host"},
    {"setting" : "http-invoker"}], "security-realm" : "ApplicationRealm"},

Here is an example of removing one deployment:

   2021-11-04 21:02:03 - {
       "type" : "core",
       "r/o" : false,
       "booting" : false, <----- wasn't done in boot time
       "version" : "7.4.1.GA", <----- version
       "user" : "celine", <----- user, yes, the user is celine
       "domainUUID" : null,
       "access" : "HTTP", <----- http access
       "remote-address" : "/127.0.0.1",<----- url
       "success" : true,  <----- succeed
       "ops" : [{
           "operation" : "remove",
           "address" : [{
               "deployment" : "jboss-helloworld-singleton.war" <----- deployment
           }],
           "operation-headers" : {
               "access-mechanism" : "HTTP",
               "caller-type" : "user"
           }
       }]
   }

How do we properly parse JSON blocks to capture relevant security events showing date/time, user, and type of change? The capture data is written in the audit logs via the file handler; you can use any tool you think is necessary. The server deployment part of this is to feed the audit.log with information.

What are some of the keywords that you can search to identify security-related changes? Searching relevant terms directly on the audit.log. Also, the user can create scripts and use log aggregators to make it easy for you to find any terms you think is necessary.

There are several relevant terms; the user, ops, timestamp, etc., will depend on what your needs. You can parse with any tool you use to view the logs, like a log aggregator, to see any piece of information your team think is relevant.

The EAP management audit system is highly customizable, and the logs can record events on the EAP side. (Note that developing aggregators or custom scripts is beyond the scope of the support team; this would require engaging consulting services.)

I've summarized the output details below. They are also are explained in the latest WildFly documentation and referenced in Enabling JBoss EAP Management Audit Log and increasing its level.

• timestamp: The timestamp that the operation happened.
• type: This can have the values core, meaning it is a management operation, or jmx, meaning it comes from the JMX subsystem (see the JMX subsystem to configure the JMX subsystem's audit logging).
• r/o: true if the operation does not change the management model, false otherwise.
• booting: true if the operation was executed during the bootup process, false if it was executed once the server is up and running.
• version: The version number of the WildFly/EAP instance.
• user: The username of the authenticated user. In this case, the operation has been logged via the CLI on the same machine as the running server, so the special $local user is used.
• domainUUID: An ID to link together all operations as they are propagated from the Domain Controller to IT servers, Host Controllers, and Host Controller servers.
• remote-address: The address of the client executing this operation.
• success: true if the operation succeeded, false if it was rolled back.
• ops: The operations being executed; this is a list of the operations serialized to JSON. At boot, this will be all the operations resulting from parsing the XML. Once booted, the list will typically just contain a single entry.

JBoss EAP 7 audit logs

The JBoss EAP 7 audit logs can register admin functions and later verify them. In other words, the audit.log file will register all operations performed with the management console, management CLI, or custom application that uses the Management API.

Additional resources

For any other specific inquiries about working with audit logs, please open a case with Red Hat support. Our global team of experts can help you with any issues.