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