Trace and Log Files 

Log Information

Log information pertaining to Knowledge Management is stored by the system in the defaultTrace.trc file. This file is stored in the .../j2ee/cluster/server<n>/log directory. You use the log viewer to display and evaluate logged data.

 

Logging Configuration Changes

Changes to the Knowledge Management configuration are logged automatically and written to the config_audit.<n>.log file. This file is stored in the directory .../j2ee/cluster/server<n>/log.

You can use the Log Viewer or the SAP NetWeaver Administrator (NWA) to display and analyze the logged data. You cannot set a level of detail for the logging of configuration changes.

More information: Logging Configuration Changes.

 

Audit Log Service

The audit log service saves events (for example, file operations performed by users) that were triggered in selected repositories in the applications.log log file for the J2EE Engine. This is located in the .../j2ee/cluster/server<n>/log/ directory.

The log file is written in a format that can be read by administrators. The logs written by activity reporting are more suitable for machine analyses.

You cannot set a detail level in the audit log service. Program-internally, the system writes the log automatically using the INFO level of detail.

More information: Audit Log Service.

 

ACL Audit Logging

You can use ACL audit logging to log changes to ACLs and accesses to ACLs.

You activate audit logging for ACLs in the log configurator of the visual administrator of the J2EE engine by setting the required level of detail for the /System/Security/Audit/Access and /System/Security/Audit/Modify categories. If these categories do not yet exist, you have to create them first.

The system write the log information to the security.<n>.log file. This file is stored in the .../j2ee/cluster/server<n>/log/system directory.

 

Read ACL operations by service users are not recorded by ACL audit logging. Write operations are recorded for service users and for normal users depending on the settings.

 

Logging Changes to ACLs

To log changes to ACLs, set the /System/Security/Audit/Modify category to WARNING or INFO (default) depending on the required level of detail.

/System/Security/Audit/Modify
Severity  = INFO

 

Output for ACL Changes

Changes can be logged with the WARNING or INFO levels of detail.

●      If you use INFO, the system logs detailed information on the changes.

●      If you use WARNING, the system issues brief information (indicated with [aclDetails] in the following list).

 

When you create, delete, or remove ACLs, the following messages can occur:

Level of Detail	Output	Description
INFO / WARNING	<user ID> ACL.CREATE <path> owner: <owner ID>	A new ACL has been created.
INFO / WARNING	<user ID> ACL.CREATE <path> [aclDetails]	A new ACL has been created on the basis of an existing ACL.
INFO / WARNING	<user ID> ACL.DELETE <path>	An ACL has been deleted.
INFO / WARNING	<user ID> ACL.DELETE_ON_CHILDREN <path>	The ACLs for a hierarchy have been deleted. This can be triggered by the deletion of a folder and the items contained therein.
INFO / WARNING	<user ID> ACL.ADD_ENTRY <path> <member ID> <permission>	An ACE has been added to an ACL. *
INFO / WARNING	<user ID> ACL.REMOVE_ENTRY <path> <member ID> <permission>	An ACE has been deleted from an ACL. *
INFO / WARNING	<user ID> ACL.ADD_OWNER <path> <owner ID>	A new owner has been added to an ACL. *
INFO / WARNING	<user ID> ACL.REMOVE_OWNER <path> <owner ID>	An owner has been deleted from an ACL. *
INFO / WARNING	<user ID> ACL.MODIFY <path> [aclDetails]	An ACL has been changed. The output ACL details correspond to the ACL that is now valid.

*) ACL.MODIFY can appear in the log file instead of ACL.ADD_ENTRY,  ACL.REMOVE_ENTRY, ACL.ADD_OWNER and ACL.REMOVE_OWNER.

 

The following outputs are only relevant if new services define their own permissions:

Level of Detail	Output	Description
INFO / WARNING	<system> ACLPERM.CREATE <permission>	A new permission has been created.
INFO / WARNING	<system> ACLPERM.DELETE <permission>	A permission has been deleted.
INFO / WARNING	<system> ACLPERM.ADD <permission>	A permission has been identified as a supported permission.
INFO / WARNING	<system> ACLPERM.REMOVE <permission>	A permission has had the designation supported permission removed.

 

The following messages are only relevant if a user, group, role, or other UME item has been deleted from user administration:

Level of Detail	Output	Description
INFO / WARNING	<user ID> ACL.USER.DELETE <deleted user ID>	A user has been deleted from user administration. The user has also been deleted from the ACLs into which it was entered.
INFO / WARNING	<user ID> ACL.GROUP.DELETE <deleted user ID>	A group has been deleted from user administration. The group has also been deleted from the ACLs into which it was entered.
INFO / WARNING	<user ID> ACL.ROLE.DELETE <deleted user ID>	A role has been deleted from user administration. The role has also been deleted from the ACLs into which it was entered.
INFO / WARNING	<user ID> ACL.PRINCIPAL.DELETE <deleted user ID>	A UME item (user, group, role, and so on) has been deleted from user administration. The item has also been deleted from the ACLs into which it was entered.

 

Logging ACL Accesses

You use the  /System/Security/Audit/Access category to log ACL accesses. The INFO level of detail is set by default for logging rejected accesses to resources. You can also set the category to WARNING.

Set the category to PATH to log both rejected and permitted accesses.

/System/Security/Audit/Access
Severity  = PATH

 

Note that this can result in a very large number of log entries, especially if logging read accesses. This is particularly true in the case of permitted accesses. Use the PATH level of detail carefully.

 

Output for ACL Accesses

When checking permissions, the following messages can occur:

Level of Detail	Output	Description
WARNING	<user ID> ACCESS.ERROR <path> <permission>: not authenticated	User is not authenticated or logged on.
WARNING	<user ID> ACCESS.ERROR <path> <permission>	User does not have the specified permission because this is not assigned for the user according to the ACL.
WARNING	<user ID> ACCESS.ERROR <path> <permission>: unmapped	User does not have the specified permission because the permission is unknown.
PATH	<user ID> ACCESS.OK <path> <permission>: configured	User has the permission due to its configuration as a system user.
PATH	<user ID> ACCESS.OK <path> <permission>	User has the permission according to the ACL.