Note that an unauthorized access is given to a user without a change request; which means that these access can't be stored in the PV_CHANGE_REQUEST_DETAIL table. That table only store anything item that were part of an access request on the system.

In my dev environment I tested this rule and got some hits and the email sent, however, there is nothing in the rule violations section nor any data in the V_AVR_ALL_VIOLATIONS table. I looked in the help section and it says that rule violations are only created for two rule types: Should I have rule violation date for unauthorized change detection rules?

Working withRule Violations

RSA Identity Governance and Lifecyclegenerates rule violations whenever it detects that users have access to entitlements they should not have as specified by the following rule types:

Just a note that if you were to write a query in the report module against pv_change_request_detail, you would need to say 'select * from avuser.pv_change_request_detail' because that view is owned by 'avuser' and the report module is connected to the database as the 'avdwuser' schema and not 'avuser'. Note you could rewrite the query as 'select * from change_request_detail' which is a public schema table. RSA recommends using the public schema tables in reports so that they will work from version to version (i.e. any underlying schema changes between versions should not effect queries that use the public schema tables.)

Attachments

In my dev environment I tested this rule and got some hits and the email sent, however, there is nothing in the rule violations section nor any data in the V_AVR_ALL_VIOLATIONS table. I looked in the help section and it says that rule violations are only created for two rule types: Should I have rule violation date for unauthorized change detection rules?

Working withRule Violations

RSA Identity Governance and Lifecyclegenerates rule violations whenever it detects that users have access to entitlements they should not have as specified by the following rule types: