Understanding Audit Logs

Audit logs capture records of system administration activities, including records of system configuration events, changes to roles, rules, and content ownership, user administration activities, and sign-in and sign-out events. For security purposes, audit logs are always enabled.

The audit log file is located in the drive:\ibi\WebFOCUS82\logs directory, and all events captured by the loggers assigned to it are logged to this single file.

The list of loggers that contribute records of events to the audit file appears next to the audit log name entry at the top of the Log Files page of the Administration Console Diagnostics tab, as shown in the following image. Specialized loggers that contribute events to this log, such as com.ibi.uoa.roles, capture routine events at the INFO level. The main logger com.ibi.uoa captures other non-specialized events at the ERROR level.

The log4j2.xml file, which is located at drive:\ibi\WebFOCUS_WFI\WebFOCUS\webapps\webfocus\WEB-INF\classes, contains the default configuration of loggers and appenders that define the format and scope of log records captured for each log. The display of log names and loggers on the Log File page is based on the configuration in this file.

Audit logs remain available for the number of days defined in the Days Until Logs Are Deleted (IBI_LOG_RETAIN_DAYS) setting on the Application Directories page of the Administration Console Configuration tab. By default, audit logs are saved for ten days. You can customize the amount of time that logs are saved by changing the number of days defined in this setting. Keep in mind, however, that any changes you make to this setting will affect the number of days that all logs, not just the Audit log, remain available.

Customizing the Audit Log Configuration

The default configuration of log files defined in the log4j2.xml file is designed to support most product installations. Administrators can change this configuration to redirect events captured by one or more of the audit file loggers to a separate log file or database table not defined in the default configuration to conform to the requirements of their organization.

For example, you might want to redirect sign-in events and user security events to a separate database table, by capturing the following information:

• Sign-in attempts and sign-out attempts.
• User creation, modification, and deletion.
• User assignments to or removals from groups.

Note that any changes made to the log4j2.xml file itself will clear the configuration of log file names and their associated loggers displayed on the Log File page in the Administration Console. Therefore, we strongly recommend that you make a backup copy of the log4j2.xml file before you make any changes to the file so that you can restore this display when necessary. For more information, see Create a Copy of the log4j2.xml File.

Once you establish this backup copy, you can redirect records of sign-in events to a separate log file by adding a dedicated appender and logger to a copy of the log 4j2.xml configuration file. For more information, see Redirect Audit Log Events to a Separate Log File.

If you want to redirect records to a database table, you must create a dedicated table to capture them within the targeted database along with the addition of a dedicated appender and logger to the copy of the log4j2.xml file. For more information, see Redirect Audit Log Events to a Separate Database Table.

As an alternative to the display of loggers on the Log Files page, you can develop database reports to replace the display and connect directly to the log files stored in the drive:\ibi\WebFOCUS_WFI\WebFOCUS\logs directory, as shown in the following image.

Redirect Audit Log Events to a Separate Database Table

Procedure
1. Create the database table that will be used to store the audit log information. The table must contain appropriate columns for the information captured by the log.

   For example, you can create a table that captures the user IDs, date and time stamps, logger names, and audit events for sign-in, sign-out, and session termination events, with the following code prepared for a PostgreSQL © database.

   CREATE TABLE public.wf_log
   
   (
   
       eventdate timestamp with time zone,
   
       logger character varying(128) COLLATE pg_catalog."default",
   
       level character varying(12) COLLATE pg_catalog."default",
   
       logid character varying(128) COLLATE pg_catalog."default",
   
       message character varying(255) COLLATE pg_catalog."default",
   
       exception text COLLATE pg_catalog."default"
   
   
   
   GRANT UPDATE, INSERT, SELECT ON TABLE public.wf_log TO webfocus;
   
   

2. Navigate to drive:/ibi/WebFOCUS93/webapps/webfocus/WEB-INF/classes/.
3. Open the log4j2.xml file, and go to the <RollingFile name="LOGuoa"> block in the <Appenders> section.
4. Add the JDBC Appender to the log4j2.xml file using one of the following code snippets.
   1. If you want to transfer control of the connection to the external database, include a description of the ConnectionFactory class, as shown in the second line of the following example.

      <JDBC name="LOGevent" tableName="public.wf_log">
      
        <ConnectionFactory
      
          class="com.ibi.log4j2.ConnectionFactory"
      
          method="getConnection" />
      
        <Column name="eventdate" isEventTimestamp="true" />
      
        <Column name="logger" pattern="%logger" isUnicode="false" />
      
        <Column name="level" pattern="%level" isUnicode="false" />
      
        <Column name="logid" pattern="%X{userId}" isUnicode="false" />
      
        <Column name="message" pattern="%message" isUnicode="false" />
      
        <Column name="exception" pattern="%ex{full}" isUnicode="false" />
      
      </JDBC>

      Where:

      LOGevent

      Is the name of the JDBC appender that redirects events captured by this logger to the external database table. For example, LOGuoa.

      logger

      Is the name of the existing logger that captures messages typically assigned to the audit log. For example, com.ibi.uoa.signin.
   2. If you want to retain control of the connection within WebFOCUS, include a DriverManager tag, as shown in the second line of the following example.

      <JDBC name="LOGevent" tableName="public.wf_log">
      
        <DriverManager
      
          connectionString="jdbc:postgresql://localhost:5432/WebFOCUS82" 
      
          driverClassName="org.postgresql.Driver"
      
          username="webfocus" 
      
          password="webfocus" />
      
        <Column name="eventdate" isEventTimestamp="true" />
      
        <Column name="logger" pattern="%logger" isUnicode="false" />
      
        <Column name="level" pattern="%level" isUnicode="false" />
      
        <Column name="logid" pattern="%X{userId}" isUnicode="false" />
      
        <Column name="message" pattern="%message" isUnicode="false" />
      
        <Column name="exception" pattern="%ex{full}" isUnicode="false" />
      
      </JDBC>
      
      

      Where:

      LOGevent

      Is the name of the JDBC appender that redirects events captured by this logger to the external database table. For example, LOGuoa.

      logger

      Is the name of the existing logger that captures messages typically assigned to the audit log. For example, com.ibi.uoa.signin.
5. Determine where the information is logged and add an appender reference to the name of each existing logger you wish to include.
   • To log information solely in the external database, use the following code:

     <Logger name="logger" level="info" additivity="false">
     
        <AppenderRef ref="LOGevent"/> 
     
     </Logger>
     
     

     Where:

     logger

     Is the name of the existing logger that captures messages typically assigned to the audit log. For example, com.ibi.uoa.signin.

     LOGevent

     Is the name of the JDBC appender that redirects events captured by this logger to the external database table. For example, LOGuoa.

   • To log information both in WebFOCUS and in the external database, use the following code:

     <Logger name="logger" level="info" additivity="false">
     
       <AppenderRef ref="LOGevent"/> 
     
       <AppenderRef ref="LOGdb"/>
     
     </Logger>

     Where:

     logger

     Is the name of the existing logger that captures messages typically assigned to the audit log. For example, com.ibi.uoa.signin.

     LOGevent

     Is the name of the JDBC appender that redirects events captured by this logger to the external database table. For example, LOGuoa.

     LOGdb

     Is the name of the JDBC appender that redirects events captured by this logger to the external database table.
6. If the drive:/ibi/WebFOCUS93/webapps/webfocus/webfocus.war file is deployed on the Application server, update and redeploy the webfocus.war file.
7. If the drive:/ibi/ WebFOCUS93/webapps/webfocus expanded directory is deployed, recycle the WebFOCUS Application server.

   The database table captures each security event in a separate row, as shown in the following image.

   

Save Sign-in Events in a Separate Log File

Procedure
1. Navigate to drive:/ibi/WebFOCUS93/webapps/webfocus/WEB-INF/classes/.
2. Open the log4j2.xml file, and go to the <RollingFile name="LOGuoa"> block in the <Appenders> section.
3. Beneath the closing tag for the LOGuoa block, insert the following new RollingFile tag, which saves the sign-in events to a file named signinout.log, as shown in the following code example.

   <RollingFile name="LOGuoaSignInOut">
   
     <FileName>C:/ibi/WebFOCUS_WFI/WebFOCUS/logs/signinout.log</FileName>
   
     <FilePattern>C:/ibi/WebFOCUS_WFI/WebFOCUS/logs/signinout-%d{yyyy-MM-dd}-%i.log</FilePattern>
   
       <PatternLayout>
   
         <Pattern>[%d] %-5p %-16.16c{1} %-16.16X{monitorID} %X{userId} %m%n</Pattern>
   
       </PatternLayout>
   
       <Policies>
   
         <TimeBasedTriggeringPolicy />
   
         <SizeBasedTriggeringPolicy size="20 MB" />
   
       </Policies>
   
   </RollingFile>

4. Search within the file for the logger name="com.ibi.uoa.signin", and update the entry to identify the new LOGuoaSignInOut appender block as the target of the appender reference, as shown in the following example.

   <logger name="com.ibi.uoa.signin" level value="info” additivity="false">
   
     <AppenderRef ref="LOGuoaSignInOut"/>
   
   </logger>
   
   

5. Save the file.

   Sign-in events are now recorded in the signinout.log file, which will appear in the All Clients list of traces.

Save Sign-in Events in a Separate Database Table

Procedure
1. Create a new table in your database to capture the sign-in event records, as shown in the following example prepared for a PostgreSQL © database.

   CREATE TABLE public.wf_log
   
   (
   
       eventdate timestamp with time zone,
   
       logger character varying(128) COLLATE pg_catalog."default",
   
       level character varying(12) COLLATE pg_catalog."default",
   
       logid character varying(128) COLLATE pg_catalog."default",
   
       message character varying(255) COLLATE pg_catalog."default",
   
       exception text COLLATE pg_catalog."default"
   
   
   
   GRANT UPDATE, INSERT, SELECT ON TABLE public.wf_log TO webfocus;
   
   

2. Navigate to drive:/ibi/WebFOCUS93/webapps/webfocus/WEB-INF/classes/.
3. Open the copy of the drive:/ibi/WebFOCUS93/webapps/webfocus/WEB-INF/classes/log4j2.xml file with a text editor.
4. Go to the <RollingFile name="LOGuoa"> block in the <Appenders> section.
5. Beneath the closing tag for the LOGuoa block, insert a new JDBC tag, which saves the sign-in events to the database table using one of the following examples.

   To transfer control of the connection to the external database, include a description of the ConnectionFactory class, as shown in the second line of the following example.

   <JDBC name="LOGuoaSignInOut" tableName="public.wf_log">
   
     <ConnectionFactory
   
        class="com.ibi.log4j2.ConnectionFactory"
   
        method="getConnection" />
   
     <Column name="eventdate" isEventTimestamp="true" />
   
     <Column name="logger" pattern="%logger" isUnicode="false" />
   
     <Column name="level" pattern="%level" isUnicode="false" />
   
     <Column name="logid" pattern="%X{userId}" isUnicode="false" />
   
     <Column name="message" pattern="%message" isUnicode="false" />
   
     <Column name="exception" pattern="%ex{full}" isUnicode="false" />
   
   </JDBC>
   
   

   Or

   To retain control of the connection within WebFOCUS, include a DriverManager tag, as shown in the following example.

   <JDBC name="LOGuoaSignInOut" tableName="public.wf_log">
   
     <DriverManager
   
       connectionString="jdbc:postgresql://localhost:5432/WebFOCUS82" 
   
       driverClassName="org.postgresql.Driver"
   
       username="webfocus" 
   
       password="webfocus" />
   
     <Column name="eventdate" isEventTimestamp="true" />
   
     <Column name="logger" pattern="%logger" isUnicode="false" />
   
     <Column name="level" pattern="%level" isUnicode="false" />
   
     <Column name="logid" pattern="%X{userId}" isUnicode="false" />
   
     <Column name="message" pattern="%message" isUnicode="false" />
   
     <Column name="exception" pattern="%ex{full}" isUnicode="false" />
   
   </JDBC>
   
   

   Note: You can substitute the LOGuaoSignInOut name in these examples with another descriptive name of your own choosing. You must be sure to place the same name in the AppenderRef tag of the logger that will direct events to this new appender.
6. Search for the logger with the name="com.ibi.uoa.signin" tag, and update the entry to identify the new LOGevent JDBC class as the target of the appender reference, as shown in the following example.

   <Logger name="com.ibi.uoa.signin" level="info" additivity="false">
   
    <AppenderRef ref="LOGuoaSignInOut"/> 
   
   

   Note: You can substitute the LOGuaoSignInOut name in these examples with another descriptive name of your own choosing. You must be sure to place the same name in the name tag of the appender that will receive events from this logger.
7. Save the file.

   Sign-in events are now recorded in the public.wf_log database table.

Understanding Configuration Events

In the following table, each log entry is composed of the following elements:

• Timestamp, in the format of YYYY-MM-DD hh:mm:ss,sss.
• Log level, such as INFO.
• Type of event being logged, in this case, a configuration event indicated by config.
• Monitor ID of the user who performed the action.
• Specific event being logged, in this case, configUpdate, a configuration update.
• Whether the action succeeds or fails, indicated by SUCCESS or FAILURE.
• Name of the file affected, typically webfocus.cfg.
• Name of the user performing the action.
• New value of the changed property.
• Old value of the changed property.

[YYYY-MM-DD hh:mm:ss,sss] INFO config monitor_IDuser_ID 

updateConfig {SUCCESS|FAILURE} file:file_name user:user_ID 

parameterName:parameter_name newValue:new_value oldValue:old_value

[YYYY-MM-DD hh:mm:ss,sss] INFO config monitor_IDuser_ID 

updateConfig {SUCCESS|FAILURE} file:license_key_file user:user_ID 

parameterName:parameter_name newKey:new_value newSite:site_code

Understanding Content Events

In the following table, each log entry is composed of the following elements:

• Timestamp, in the format of YYYY-MM-DD hh:mm:ss,sss.
• Log level, such as INFO.
• Type of event being logged, in this case, a content event indicated by content.
• Monitor ID of the user who performed the action.
• Specific event, for example, createFolder or putItem.
• Whether the action succeeds or fails, indicated by SUCCESS or FAILURE.
• Name of the user performing the action.
• Location of the content affected by the action.
• Fields altered by the action.

[YYYY-MM-DD hh:mm:ss,sss]

INFO content monitor_IDuser_ID

createFolder

{SUCCESS|FAILURE} user:user_ID

folder:IBFS_address

[YYYY-MM-DD hh:mm:ss,sss]

INFO content monitor_IDuser_ID

putFolderProperties

{SUCCESS|FAILURE} user:user_ID

folder:IBFS_address

[YYYY-MM-DD hh:mm:ss,sss] INFO content monitor_IDuser_ID 

delete {SUCCESS|FAILURE} user:user_ID folder:IBFS_address

[YYYY-MM-DD hh:mm:ss,sss]

INFO content monitor_IDuser_ID

copyFolder

{SUCCESS|FAILURE} user:user_ID srcitem:

IBFS_address dstitem:IBFS_address_copy

[YYYY-MM-DD hh:mm:ss,sss]

INFO content monitor_IDuser_ID

putFolderProperties

{SUCCESS|FAILURE} user:user_ID  folder:IBFS_address

[YYYY-MM-DD hh:mm:ss,sss] INFO content monitor_IDuser_ID  

moveFolder {SUCCESS|FAILURE} user:user_ID  srcitem:old_IBFS_address dstitem:new_IBFS_address

[YYYY-MM-DD hh:mm:ss,sss] INFO content monitor_IDuser_ID 

putFolderProperties {SUCCESS|FAILURE} user:user_ID 

folder:new_IBFS_address

[YYYY-MM-DD hh:mm:ss,sss] INFO content monitor_IDuser_ID 

createItem {SUCCESS|FAILURE} user:user_ID folder:IBFS_address

[YYYY-MM-DD hh:mm:ss,sss] INFO content monitor_IDuser_ID 

putItem {SUCCESS|FAILURE} user:user_ID item:IBFS_address

[YYYY-MM-DD hh:mm:ss,sss] INFO content monitor_IDuser_ID 

delete {SUCCESS|FAILURE} user:user_ID item:IBFS_address

[YYYY-MM-DD hh:mm:ss,sss]

INFO content monitor_IDuser_ID

copyItem

{SUCCESS|FAILURE} user:user_ID srcitem:old_IBFS_address 

dstitem:new_IBFS_address

[YYYY-MM-DD hh:mm:ss,sss]

INFO content monitor_ID user_ID 

putItemProperties

{SUCCESS|FAILURE} user:user_ID  folder:IBFS_address

Understanding Group Events

In the following table, each log entry is composed of the following elements:

• Timestamp, in the format of YYYY-MM-DD hh:mm:ss,sss.
• Log level, such as INFO.
• Type of event being logged, in this case, a group event indicated by groups.
• Monitor ID of the user who performed the action.
• Description of the action, for example, createGroup or putGroup.
• Whether the action succeeds or fails, indicated by SUCCESS or FAILURE.
• Name and unique numeric ID of the group affected by the action.
• Fields altered by the action.

Each user and group is identified by a unique numerical ID, as well as by name.

[YYYY-MM-DD hh:mm:ss,sss] INFO groups monitor_IDuser_ID 

createGroup {SUCCESS|FAILURE} name:group_name (group_ID) 

parent:group_parent (parent_group_ID) 

desc:group_description extGrp:external_group_mappings

[YYYY-MM-DD hh:mm:ss,sss] INFO groups monitor_IDuser_ID 

deleteGroup {SUCCESS|FAILURE} group:IBFS_address (group_ID) 

users-autoremoved:number_of_group_members

[YYYY-MM-DD hh:mm:ss,sss] INFO groups monitor_IDuser_ID 

putGroup {SUCCESS|FAILURE} groupPath:IBFS_address (group_ID) 

newdesc:new_description olddesc:old_description 

externalGroups:external_group_mappings

[YYYY-MM-DD hh:mm:ss,sss] INFO groups monitor_IDuser_ID 

renameGroup {SUCCESS|FAILURE} name:group_name (group_ID) 

parent:parent_group oldName:old_group_name

[[YYYY-MM-DD hh:mm:ss,sss] INFO groups monitor_IDuser_ID  

addUserToGroup {SUCCESS|FAILURE} user:user_IDgroup:group_name 

(group_ID)								

[YYYY-MM-DD hh:mm:ss,sss] INFO groups monitor_IDuser_ID 

removeUserFromGroup {SUCCESS|FAILURE} user:user_ID 

group:group_name (group_ID)

Understanding Library Access Events

In the following table, each log entry is composed of the following elements:

• Timestamp noting when the Library report was accessed, in the format of YYYY-MM-DD hh:mm:ss,sss.
• Log level, such as INFO.
• Thread Identifier, in the format of http-connector-port_number-exec-ID_number:libaccess.
• User ID of the user accessing the Library report.
• The full IBFS path of the Library report.
• The title of the Library report.
• The Version number of a Library report.

[YYYY-MM-DD hh:mm:ss,sss]

INFO [Thread Identifier]

User_ID – FullPath:

IBFS_address ; 

Description: 

Library_Report_Title;

Version Number: 

Library_Report_Version_Number

Understanding Magnify Console Events

The audit log records changes to values, index items, and options in the Magnify Console. For more information, see the Magnify Search Security and Administration technical content.

In the following table, each log entry is composed of the following elements:

• Timestamp, in the format of YYYY-MM-DD hh:mm:ss,sss.
• Log level, such as INFO.
• Type of event being logged, indicated by magnify.
• Monitor ID of the user who performed the action.
• User ID of the user who performed the action.
• IP Address of the user who performed the action.
• A unique description of the specific Magnify Console event. This description may span several lines depending on the amount of actions performed by the user.

[YYYY-MM-DD hh:mm:ss,sss] INFO magnify Monitor_IDUser_ID User [User_ID] and IP address [IP address] tried to reset [timer option] timer to [new time setting] on the Magnify Timers console page.

[YYYY-MM-DD hh:mm:ss,sss] INFO magnify Monitor_IDUser_ID User [User_ID] and IP address [IP address] tried to reset Reading Refresh Rate Enabled attribute to [true/false] on the Magnify Timers console page.

[YYYY-MM-DD hh:mm:ss,sss] INFO magnify Monitor_IDUser_ID User [User_ID] and IP address [IP address] tried to create or update spell check dictionary for index [index] on Spell Check Setup console page.

[YYYY-MM-DD hh:mm:ss,sss] INFO magnify Monitor_IDUser_ID User [User_ID] and IP address [IP address] tried to create or update spell check dictionary for collections [collection] on Spell Check Setup console page.

[YYYY-MM-DD hh:mm:ss,sss] INFO magnify Monitor_IDUser_ID User [User_ID] and IP address [IP address] tried to close dictionaries (for backup or removal) on Spell Check Setup console page.

[YYYY-MM-DD hh:mm:ss,sss] INFO magnify Monitor_IDUser_ID User [User_ID] and IP address [IP address] tried to analyze [text] with analyzer [analyzer] on Analyzer Review console page.

[YYYY-MM-DD hh:mm:ss,sss] INFO magnify Monitor_IDUser_ID User [User_ID] and IP address [IP address] added a new daily refresh time on Collections Refresh console page.

[YYYY-MM-DD hh:mm:ss,sss] INFO magnify Monitor_IDUser_ID User [User_ID] New refresh time is: [hour:minute]

[YYYY-MM-DD hh:mm:ss,sss] INFO magnify Monitor_IDUser_ID User [User_ID] New refresh time comment is: [comment]

[YYYY-MM-DD hh:mm:ss,sss] INFO magnify Monitor_IDUser_ID User [User_ID] and IP address [IP Address] just refreshed collections file on Collections Refresh console page.

[YYYY-MM-DD hh:mm:ss,sss] INFO magnify Monitor_IDUser_ID User [User_ID] and IP address [IP Address] removed an existing daily refresh time on Collections Refresh console page.

[YYYY-MM-DD hh:mm:ss,sss] INFO magnify Monitor_IDUser_ID The removed refresh time is: [hour:minute]

[YYYY-MM-DD hh:mm:ss,sss] INFO magnify Monitor_IDUser_ID User [User_ID] and IP address [IP Address] modified the Feed Security Setup Console data to the following:

[YYYY-MM-DD hh:mm:ss,sss] INFO magnify Monitor_IDUser_ID==============================================

[YYYY-MM-DD hh:mm:ss,sss] INFO magnify Monitor_IDUser_ID|Feed Security enable was set to: [true/false]

[YYYY-MM-DD hh:mm:ss,sss] INFO magnify Monitor_IDUser_ID|List of Host Names were set to:

[YYYY-MM-DD hh:mm:ss,sss] INFO magnify Monitor_IDUser_ID|[List of Host Names]

[YYYY-MM-DD hh:mm:ss,sss] INFO magnify Monitor_IDUser_ID|List of IPv4 Addresses were set to:

[YYYY-MM-DD hh:mm:ss,sss] INFO magnify Monitor_IDUser_ID|[List of IPv4 Addresses]

[YYYY-MM-DD hh:mm:ss,sss] INFO magnify Monitor_IDUser_ID| List of IPv6 Addresses were set to: 

[YYYY-MM-DD hh:mm:ss,sss] INFO magnify Monitor_IDUser_ID|[List of IPv6 Addresses]

[YYYY-MM-DD hh:mm:ss,sss] INFO magnify Monitor_IDUser_ID==============================================

[YYYY-MM-DD hh:mm:ss,sss] INFO magnify Monitor_IDUser_ID User [User_ID] and IP address [IP Address] tried to delete the following indexes:

[YYYY-MM-DD hh:mm:ss,sss] INFO magnify Monitor_IDUser_ID ======================================

[YYYY-MM-DD hh:mm:ss,sss] INFO magnify Monitor_IDUser_ID|[index](index file path)

[YYYY-MM-DD hh:mm:ss,sss] INFO magnify Monitor_IDUser_ID======================================

[YYYY-MM-DD hh:mm:ss,sss] INFO magnify Monitor_IDUser_ID User [User_ID] and IP address [IP Address] tried to close searcher for [search file path]

[YYYY-MM-DD hh:mm:ss,sss] INFO magnify Monitor_IDUser_ID User [User_ID] and IP address [IP Address] tried to close index reader for [datasource file path].

[YYYY-MM-DD hh:mm:ss,sss] INFO magnify Monitor_IDUser_ID User [User_ID] and IP address [IP Address] tried to commit on index writer [index writer file path].

[YYYY-MM-DD hh:mm:ss,sss] INFO magnify User [User_ID] and IP address [IP Address] successfully loaded a record to index [index] from the Servlet Form page in the Magnify Console.

[YYYY-MM-DD hh:mm:ss,sss] INFO magnify Monitor_IDUser_ID User [User_ID] and IP address [IP Address] tried to verify a record with datasource [datasource] and WF_INDEX_QUNIQUE_KEY [a_unique_value]

Understanding Ownership Events

In the following table, each log entry is composed of the following elements:

• Timestamp, in the format of YYYY-MM-DD hh:mm:ss,sss.
• Log level, such as INFO.
• Type of event being logged, in this case, an ownership event indicated by ownership.
• The action taken, such as a change of ownership, indicated by changeOwner, or the publication of an item, indicated by makePublic.
• Whether the action succeeds or fails, indicated by SUCCESS or FAILURE.
• Whether the resource inherits its privacy from its parent.
• The full IBFS path of the resource.
• User ID of the new resource owner.
• Type of owner, G for a group or U for a user.

[YYYY-MM-DD hh:mm:ss,sss] INFO ownership monitor_IDuser_ID 

makeManaged {SUCCESS|FAILURE} inherited:{TRUE|FALSE} strPath:IBFS_address ownerName:owner_group_name ownerType:G

[YYYY-MM-DD hh:mm:ss,sss] INFO ownership monitor_IDuser_ID 

changeOwner {SUCCESS|FAILURE} inherited:{TRUE|FALSE} 

strPath:IBFS_address ownerName:owner_user_ID ownerType:U

[YYYY-MM-DD hh:mm:ss,sss] INFO 

ownership monitor_IDuser_ID 

makePrivate

{SUCCESS|FAILURE} strPath:IBFS_address 

ownerName:new_owner ownerType:U

[YYYY-MM-DD hh:mm:ss,sss] INFO

ownership monitor_IDuser_ID makePrivate {SUCCESS|FAILURE}

strPath:IBFS_address ownerName:new_owner ownerType:U								

[YYYY-MM-DD hh:mm:ss,sss] INFO ownership monitor_IDuser_ID 

isPublishable {SUCCESS|FAILURE} inherited:{TRUE|FALSE} 

ownerName:parent_folder

Understanding ReportCaster Configuration Events

In the following table, each log entry is composed of the following elements:

• Timestamp, in the format of YYYY-MM-DD hh:mm:ss,sss.
• Log level, such as INFO.
• Type of event being logged, in this case, a ReportCaster Configuration event indicated by caster_config.
• Monitor ID of the user who performed the action.
• Name of the user who performed the action.
• Name of the file affected, typically, the old CasterConfig file.

[YYYY-MM-DD hh:mm:ss,sss]

INFO caster_config monitor_IDuser_ID 

updated ReportCaster 

configuration, 

old CasterConfig file: 

dserver_file_ID.xml

User_IDdatabase table namevariable nameold valuenew valueThread Identifier

Understanding Role Events

In the following table, each log entry is composed of the following elements:

• Timestamp, in the format of YYYY-MM-DD hh:mm:ss,sss.
• Log level, such as INFO.
• Type of event being logged, in this case, a role event indicated by roles.
• Monitor ID of the user who performed the action.
• User ID of the user who performed the action.
• Specific event, for example, createRole.
• Whether the action succeeds or fails, indicated by SUCCESS or FAILURE.
• Name of the role affected by the action.
• Policy for the role.

[YYYY-MM-DD hh:mm:ss,sss] INFO roles monitor_IDuser_ID 

createRole {SUCCESS|FAILURE} role:role_name (role_ID) 

desc:description policy:privilege_name:OPERATION;

[YYYY-MM-DD hh:mm:ss,sss] INFO roles monitor_IDuser_ID  

putRole {SUCCESS|FAILURE} role:role_name (role_ID)   

desc:description policy:privilege_name:OPERATION;

[YYYY-MM-DD hh:mm:ss,sss] INFO roles monitor_IDuser_ID 

deleteRole {SUCCESS|FAILURE} role:role_name (role_ID) 

rules-autoremoved:number_rules_using_this_role 

policy:privilege_name:OPERATION;

[YYYY-MM-DD hh:mm:ss,sss] INFO roles monitor_IDuser_ID  

createRole {SUCCESS|FAILURE} role:role_name_copy (role_ID) 

desc:description_copy policy:privilege_name:OPERATION;

Understanding Rule Events

In the following table, each log entry is composed of the following elements:

• Timestamp, in the format of YYYY-MM-DD hh:mm:ss,sss.
• Log level, such as INFO.
• Type of event being logged, in this case, a rule event indicated by rules.
• Monitor ID of the user who performed the action.
• User ID of the user who performed the action.
• Specific event, for example, addGroupRule or addUserRule.
• Whether the action succeeds or fails, indicated by SUCCESS or FAILURE.
• Location of the resource to which the rule applies.
• Access policy of the rule.
• Whether the rule applies to this location only, the children of this location only, or to this location and its children.

[YYYY-MM-DD hh:mm:ss,sss]

INFO rules monitor_IDuser_IDaddGroupRule {SUCCESS|FAILURE} group_name (group_ID)role:IBFS_address (role_ID) resource:resource_location (resource_ID)verb:operation applyTo:scope

[YYYY-MM-DD hh:mm:ss,sss]

INFO rules monitor_IDuser_IDaddUserRule {SUCCESS|FAILURE} user_ID (numeric_user_ID)role:IBFS_address (role_ID) resource:resource_location (resource_ID)verb:operation applyTo:scope

Understanding Sharing Events

• Timestamp, in the format of YYYY-MM-DD hh:mm:ss,sss.
• Log level, such as INFO.
• Type of event being logged, in this case, a sharing event indicated by shares.
• Monitor ID of the user who performed the action.
• User ID of the user who performed the action.
• Specific event, for example, clearShares.
• Whether the action succeeds or fails, indicated by SUCCESS or FAILURE.
• Whether the owner of the resource is a group or an individual user, G or U.
• The owner ID.

[YYYY-MM-DD hh:mm:ss,sss] INFO shares monitor_IDuser_ID  

{SUCCESS|FAILURE} setShares resource:IBFS_address 

count:number_of_parties_shared_with ownerType:{G|U} ownerID:owner_ID

[YYYY-MM-DD hh:mm:ss,sss] INFO shares monitor_IDuser_ID 

clearShares {SUCCESS|FAILURE} resource:IBFS_address 

count:number_of_parties_shared_with ownerType:{G|U} ownerID:owner_ID

Understanding Sign-in Events

In the following table, each log entry is composed of the following elements:

• Timestamp, in the format of YYYY-MM-DD hh:mm:ss,sss.
• Log level, such as INFO.
• Type of event being logged, in this case, a sign-in event indicated by signin.
• Monitor ID of the user who performed the action.
• User ID of the user who performed the action.
• Description of the action, for example, signIn.
• Whether the action succeeds or fails, indicated by SUCCESS or FAILURE.
• Name and monitor ID of the user who signed in.
• The IP address and user agent or type of browser, if available.

Each user is identified by a unique numerical ID, as well as by name.

[YYYY-MM-DD hh:mm:ss,sss] INFO signin monitor_IDuser_ID 

signIn {SUCCESS|FAILURE} user:user_ID monitorId:monitor_ID 

IPaddr:IP_address userAgent:user_agent 

userDescription:user_description sessionType:session_type

[YYYY-MM-DD hh:mm:ss,sss] INFO signin monitor_IDuser_ID 

signOut {SUCCESS|FAILURE} user:user_ID monitorId:monitor_ID

[YYYY-MM-DD hh:mm:ss,sss] INFO signin monitor_IDuser_ID 

signOut {SUCCESS|FAILURE} user:user_ID monitorId:monitor_ID

Understanding WebFOCUS Reporting Server Authentication Failure Messages

ERROR_AUTHENTICATION_FAILURE(5003)

ERROR_AUTHENTICATION_FAILURE_ID_INACTIVE(5006)

ERROR_AUTHENTICATION_MUST_CHANGE_PASSWORD(5007)

ERROR_AUTHENTICATION_PASSWORD_EXPIRED(5008)

ERROR_AUTHENTICATION_USER_LOCKED(5009)

ERROR_AUTHENTICATION_USER_ALREADY_LOGGED_IN(5020)

Understanding User Sign-in Error Messages

signIn Failure-unregistered_user User:xyzabc

signIn Failure-EDA-RC User:admin RC:32033

EDANODE:EDASERVE

signIn Failure-EDA-RC User:bn01618 RC:32034 

EDANODE:EDASERVE

signIn Failure-Unknown User:cssadmin RC:32063 

EDANODE:EDASERVE

signIn Failure-EDA-RC User:cssadmin RC:32034 

EDANODE:EDASERVE

Troubleshoot a Database Connection Failure

Procedure
1. Check that your database is running.

   If you have installed Derby, check that it is listening on the default port of 1527 and determine its network interface. You can use the netstat --an command. Possible results are listed below.

   Local Address	Description
   0.0.0.0	Port is listening on all network interfaces.
   127.0.0.1	Port is listening only for connections from your computer.
   Your IP address	Port is listening only for connections on that interface.

2. Check the audit.log file for errors.
3. If the audit.log file indicates that the administrative user is unregistered, but this is a new installation with the default administrative user, consult the event log file for specific errors regarding the registration of this user.

   The event log file contains specific database connectivity errors. It will show the following relevant information:

   • Whether Managed Reporting can connect to the database at all.
   • Whether the database tables have been created.
   • Whether the database tables have been populated with data.

Understanding User Events

In the following table, each log entry is composed of the following elements:

• Timestamp, in the format of YYYY-MM-DD hh:mm:ss,sss.
• Log level, such as INFO.
• Type of event being logged, in this case, a user event indicated by users.
• Monitor ID of the user who performed the action.
• Description of the action, for example, createUser or putUser.
• Whether the action succeeds or fails, indicated by SUCCESS or FAILURE.
• User ID and unique numeric ID of the user affected by the action.
• Fields altered by the action.

Each user and group are identified by unique numerical IDs, as well as by name.

[YYYY-MM-DD hh:mm:ss,sss] INFO users monitor_IDuser_ID 

createUser {SUCCESS|FAILURE} user:user_ID (user_number)

status:{ACTIVE|INACTIVE} email:email_address desc:description

[YYYY-MM-DD hh:mm:ss,sss] INFO users monitor_IDuser_ID 

putUser {SUCCESS|FAILURE} userName:user_name Seat-Type-Property:property

[YYYY-MM-DD hh:mm:ss,sss] INFO users monitor_IDuser_ID 

putUser {SUCCESS|FAILURE} user:user_ID (user_number) status:INACTIVE

email:email_address desc:description

[YYYY-MM-DD hh:mm:ss,sss] 

INFO groups monitor_IDuser_ID 

removeUserFromGroup {SUCCESS|FAILURE} user:user_ID (user_number) 

group:group_name (group_ID) 

[YYYY-MM-DD hh:mm:ss,sss] 

INFO deleteUser monitor_IDuser_ID 

status:{ACTIVE|INACTIVE} 

email:email_address desc:description

[YYYY-MM-DD hh:mm:ss,sss] INFO users changePassword {SUCCESS|FAILURE}

user:user_whose_password_is_changed (user_number) 

status:{ACTIVE|INACTIVE} email:email_address desc:description