Identify users by using the Application User Translation

Selective Audit Trail and Application User Translation

Application user aliases

Each alias is a colon-separated string in the format AppUserName : Responsibility. Responsibility can be empty. For example, the alias for APPLICATION USER is created by querying the Oracle Database server to get the App User Name. The Oracle Database server is defined in the GUI as either SERVER IP or Connect to Server IP if it is not empty. The Responsibility is based on the ID of the Value column (the DB_VALUE of the ALIAS table in the format APPS_CODE : ID).

Oracle EBS with multiple interfaces

Guardium does not have specific pre-defined reports for Oracle EBS Application User Translation. Use the APP_USER_NAME in the Access domain to create your own reports.

When you add an interface for an Oracle EBS server that is already defined, add another data source using the Connect to Server IP field. See step 13.

Configure Application User Detection

1. Click Protect > Database Intrusion Detection > Application User Translation. The details for existing application user translation configurations are displayed.
2. Type a code in the Application Code box.
   Remember: Central Management has one set of aliases that is shared by all managed units. So, under Central Management, you must use different application codes on different managed units to prevent aliases that are generated for the users from conflicting with each other.
3. From the Application Type list, select the application type:
   • BO-WI - Business Objects / Web Intelligence
   • EBS - Oracle E-Business Suite
   • PeopleSoft
   • SAP Observed
   • SAP DB
   • SIEBEL Observed
   • SIEBEL DB
4. In the Application Version box, enter the application version number (11, for example).
5. From the Database Type list, select the database type. Only the types that are available for the selected Application Type and Version are displayed.
   Note: When the Application Type is set to EBS, SIEBEL DB, or SAP DB, you can select from preexisting data sources by clicking Add Datasource. The data source must match one of the supported database types for the application type that is being configured.
6. In the Server IP box, type the IP address the application uses to connect to the database.
7. In the Port box, type the port number the application uses to connect to the database.
8. In the Instance Name box, type the instance name the application uses to connect to the database.
9. In the DB Name box, type the database name for the application. (Required for some applications, not used for others.)
10. Check the Active box to enable user translation. Nothing is translated until after the first import of user definitions.
11. Enter a User Name for Guardium to use when accessing the database. Enter a password for Guardium to use when accessing the database.
12. Select the Responsibility checkbox if you want to associate responsibilities (Administration, for example) with user names. Or clear the Responsibility checkbox to record user names. When the box is cleared, all activities of a user are grouped, regardless of the responsibility at the time the activity occurred.
13. If the Application Type is EBS (Database Type is Oracle), two additional choices appear: Connect to Server IP and Connect to User Name.  If populated, the system connects by using that IP and username to retrieve the Responsibility and User Names. To support an Oracle Cluster Database that has multiple private, virtual, or both interfaces for EBS connections and one public interface for the Guradium connection, create multiple "Application User Translation" configurations. For each configuration, enter one of the Virtual/Private interface IP addresses in the Server IP field and enter the public connected interface IP address to the Connect to Server IP field. Make sure that this IP is connectable with Guardium and is able to retrieve the Responsibility and Application User Name.
14. Click Add to save the Application User Translation definition.
15. Continue to the procedure Populate Pre-defined Application Groups
16. Click Manage > Activity Monitoring > Inspection Engines and click Restart Inspection Engines in the Inspection Engine Configuration window.
17. Return to the Application User Translation page and click Run Once Now to import the user definitions for this application (and any others defined).
18. The data import of Application User Translation can be confirmed by looking at predefined reports, for example SAP Application Access. Click Reports > Report Configuration Tools > Query-Report Builder and choose the report SAP Application Access. Regenerate this report and add to a pane, and then set the date range to rather large (for example, go back a year for data).
19. In the Application User Translation page, click Modify Schedule to define an import operation to run regularly. Schedule the importing of user definition data at whatever interval is suitable for your environment. The maximum time that a new application username is not available is the time between executions of the import operation. For instructions on how to use the scheduler, see Scheduling

Populate Pre-defined Application Groups

When Application User Translation has been configured, you must populate at least two pre-defined groups with information that is specific to your environment. This table identifies the groups that must be populated for each application type. For instructions on how to populate a group, see Groups overview.

Unwilling to give DB_USER PASSWORD for EBS application

Sometimes, you do not want to use the Oracle EBS DB_USER for translating EBS traffic. In this scenario, when you set up Oracle EBS and want to translate traffic with Application User Translation, you have two options to make it work:  

• Supply the username and password that EBS uses to talk to Oracle (often APPS/$passwd).
• If you don't want to provide the password the DB_USER EBS uses to access Oracle, you can still use Application User Translation, however the process is more complicated.  

1. Create a login for Oracle to access the database for gathering aliases/users/responsibilities.  That user needs access to the table [APPLSYS.]FND_USER and the view FND_RESPONSIBILITY_VL, which combines two tables: APPLSYS.FND_RESPONSIBILITY and APPLSYS.FND_RESPONSIBILITY_TL.

   (  CREATE VIEW FND_RESPONSIBILITY_VL AS SELECT /* $HEADER$ */ B.ROWID ROW_ID , B.WEB_HOST_NAME ,      
   B.WEB_AGENT_NAME , B.APPLICATION_ID , B.RESPONSIBILITY_ID ,      
   B.RESPONSIBILITY_KEY , B.LAST_UPDATE_DATE , B.LAST_UPDATED_BY , 
   B.CREATION_DATE , B.CREATED_BY , B.LAST_UPDATE_LOGIN ,      
   B.DATA_GROUP_APPLICATION_ID , B.DATA_GROUP_ID , B.MENU_ID ,      
   B.START_DATE , B.END_DATE , B.GROUP_APPLICATION_ID ,      
   B.REQUEST_GROUP_ID , B.VERSION , T.RESPONSIBILITY_NAME ,      
   T.DESCRIPTION FROM FND_RESPONSIBILITY_TL T, FND_RESPONSIBILITY B 
   WHERE B.RESPONSIBILITY_ID = T.RESPONSIBILITY_ID      
   AND B.APPLICATION_ID = T.APPLICATION_ID      
   AND T.LANGUAGE = USERENV('LANG')  )

2. Run the following SQL statements directly from the Oracle EBS system: select RESPONSIBILITY_ID, RESPONSIBILITY_NAME from FND_RESPONSIBILITY_VL order by RESPONSIBILITY_ID; and select USER_ID, USER_NAME from FND_USER order by USER_ID;

   After the user is set up so that those two statements successfully run, two different Application User Translation entries are needed. Both need to have the same server IP, port, and instance name, (and EBS and Oracle chosen for APP type and APP server type).

   Even if the Application Code is identical or not, one entry needs the username that EBS uses to connect to the database, usually APPS, but you can use a dummy password. The second entry needs the username and password that has been created to access those tables.

3. After both username and password are entered with Active and Responsibility, click Run Once Now, and start or restart EBS (assuming that there is an Inspection Engine (S-TAP or net) looking at the traffic). The collection of data and the assignment of APPS usernames to that data for the EBS traffic now takes place.   

Oracle privileges needed for the Oracle EBS App User

Translation:

1. Grant select on the following tables to Custom DB User:
   • APPLSYS.FND_USER
   • APPLSYS.FND_RESPONSIBILITY
   • APPLSYS.FND_RESPONSIBILITY_TL
2. Create a private synonym FND_USER on APPLSYS.FND_USER for Custom DB User.
3. Create a view called FND_RESPONSIBILITY_VL for Custom DB User.  You can find this view under the APPS user to use as your template.

Validate SAP Stack for Application User Translation

ABAP Stack

Traditional ECC (Enterprise Core Components) SAP systems are written in ABAP code and are predominantly accessed by using the SAP GUI, although web access is possible.

SAP ABAP systems have direct (read/write/update) access to traditional SAP databases. The databases are large and contain all the sensitive data. This is where IBM Guardium is best utilized.

1-SAP GUI (ABAP Stack)

To validate the ABAP Stack SAP Kernel module for Application User Translation, log in to SAP and click System > Status. Click Other Kernel Info to view the system kernel information.

SAP with a DB2® backend is also available for SAP kernel 640, but the user needs to set DB6_DBSL_ACCOUNTING=1 (in kernel 700 and up, this DB6_DBSL_ACCOUNTING value is 1 by default). SAP for Oracle backend requires a kernel of 710 or higher.

Data gets put into the app user field and the app event string.

Java Stack

SAP Portal systems are written in Java code and are the front end web applications that use pre-canned queries to display SAP related web pages.

Portal systems can be accessed only by using a web browser. Portal system databases are smaller with only a few table spaces.

To validate the Java Stack SAP Kernel module for Application User Translation, click System Information.

SAP for either Db2 or Oracle requires a kernel of 7.02 or higher. Make sure that the SAP Kernel version is 7.00 or higher.

SAP sets similar client properties in the Java stack as it did for ABAP Stack.