How To Audit An Oracle Applications' User? in R12
How To Audit An Oracle Applications' User?
Sign-On:Audit Level allows you to select a level at which to audit users who sign on to Oracle Applications.
Four audit levels increase in functionality: None, User, Responsibility, and Form.
None is the default value, and means do not audit any users who sign on to Oracle Applications.
Auditing at the User level tracks:
Who signs on to the system
The times users log on and off
Auditing at the Responsibility level performs the User level audit functions and tracks:
- The responsibilities users choose
- How much time users spend using each responsibility
Auditing at the Form level performs the Responsibility level audit functions and tracks:
The forms users choose
How long users spend using each form
System Administrator visible, revisable at all levels.
One can monitor users in the System Administrator responsibility by navigating to:
Security -> User-> Monitor form. This is the Monitor Users Window. Use this window to monitor what the application users are currently doing.
As well as seeing which users are signed on, one can see:
Which responsibilities, forms (windows), and terminals they are using
How long they have been logged in;
What Oracle database processes they are using.
In addition there are 5 reports that one can run that will provide user audited information:
Signon Audit Concurrent Requests - Use this report to view information about who is requesting what concurrent requests and from which responsibilities and forms.
Signon Audit Forms - Use this report to view who is navigating to what form and when they do it.
Signon Audit Responsibilities - Use this report to view who is selecting what responsibility and when they do it.
Signon Audit Unsuccessful Logins - Use this report to view who unsuccessfully attempted to sign on to Oracle Applications as another user. An unsuccessful login occurs when a user enters a correct username but an incorrect password. You can generate Signon Audit Unsuccessful Logins Reports for any users, regardless of whom one is auditing.
Signon Audit Users - Use this report to view who signs on and for how long.
With System Administrator responsibility navigate to:
Profile => System
Query for profile: "Sign-On:Audit Level"
Set the site level value to "FORM" // if User Lever "USER"
Sign-On:Audit Level = FORM // USER
Save the record.
Logout and login again.
Retest the issue.
Note: The concurrent program "Purge Signon Audit Data" should be used regularly to purge old sign on data.
395849.1,1359749.1,104282.1
+++++++++++++++++++++++++
For user sessions since auditing was enabled, run the "Signon Audit Users" concurrent request.
The following query should help in finding out previous login times:
1. Log into sqlplus as the apps user.
2. Perform the following select:
SQL> select to_char(creation_date,'DD-MON-YY HH:MI:SS'), disabled_flag
from icx_sessions
where user_id=(select user_id from fnd_user where user_name = 'OPERATIONS');
/
Notes:
1. The disabled_flag = N means the session is still active.
2. The sessions shown are from the time the icx_sessions table was last purged.
3. This query gives all the login times, not just logins that happened prior to enabling sign-on audit. Add a date filter to the where clause if you only want sessions prior to the date when sign-on audit was enabled.
1364259.1
++++++++++++++++++++=
Note:
First of all, auditing at the responsibility level is enabled as a system profile option called Sign-On:Audit Level. Sign-On:Audit Level can be done for the site, responsibility and user and can be done at the form, responsibility and the user level. In other words, it works like a matrix. If you decide to audit a responsibility, then you need to decide at what level: form, responsibility or user. If you audit the responsibility at the form level, then you will get the most details about who used the responsibility, what forms they accessed using this responsibility, when they accessed the responsibility and when they left the responsibility. If auditing the responsibility is done at the responsibility level, you will not get the forms that the responsibility accessed but you will get everything else. If you audit the responsibility at the user level, you will get the user that accessed the responsibility, when they started and when they stopped. Very limited data.
The second level of auditing is for the data itself. This auditing is called AuditTrail and is more involved in setup. You need to identify the data that you want to audit and then translate that to the specific table and column that you want tracked. Audit groups are then created from the identified columns and tables (note that you can audit different tables and different columns within those tables). It is not common place to audit all of the columns for all of the HR or Payroll tables given the amount of resource that will be required to create and store information in the shadow tables that are created specifically for auditing.
The reports for the Sign-On:Audit Level can be found using the System Administrator responsibility and they are:
Signon Audit Concurrent Requests
Signon Audit Forms
Signon Audit Responsibilities
Signon Audit Unsuccessful Logins
Signon Audit Users
=====================================
What Tables Are Involved In Using The System Profile 'Sign-On:Audit Level'? [ID 368260.1]
Sign-On: Audit Level can be set at 4 different levels. The level you specify will determine which Change Tracking information Integra Apps will capture.
The four levels (from lowest to highest level of audit) and the information that they capture are:
1. None
Tracks no additional info.
2. User
Tracks:
who signs on to Oracle Apps
the time users log on and off
the terminals in use
3. Responsibility
Tracks:
User Info
the responsibilities user choose
how much time users spend using each responsibility
4. Form
Tracks:
User Info
Responsibility Info
the forms users choose
how long users spend using each form
Based on the level chosen, the information captured gets stored in the following tables:
FND_LOGINS
FND_LOGIN_RESPONSIBILITIES
FND_LOGIN_RESP_FORMS
1. Least detailed level: User.
When the profile is set to User, the only table that gets updated is the table FND_LOGINS and only one record per user session.
2. Next level: Responsibility.
When the profile is set to Responsbility both FND_LOGINS and FND_LOGIN_RESPONSIBILITIES will be updated.
FND_LOGINS gets only one record per user session.
FND_LOGIN_RESPONSIBILITIES will be updated with one record for each
responsibility selected during the session.
3. Most detailed level: Form.
When the profile is set to Form all three tables are involved.
FND_LOGINS gets only one record per user session.
FND_LOGIN_RESPONSIBILITIES will be updated with one record for each
responsibility selected during the session.
FND_LOGIN_RESP_FORMS will be updated with one record for each form selected during the session.
No comments:
Post a Comment