Dear all,
I referred some SAP notes,KBA's,threads which are answered by alessandr0 and Madhu Babu,found some standard behavior(As we know) of GRC access controls product.
Thought to share with you all,hope its helpful.
1.Transaction description is not available in consolidated log report in EAM.
Ans: The transaction description is not available in the consolidated report due to performance issue. As in 10.0 there are multiple systems and logs come from multiple systems of different basis release. Now for showing transaction description RFC calls have to be made for each system. So it was found that fetching the transaction description for each system is degrading the performance of the log report, hence the per the design the transaction description has not been supported in EAM reports
2. Results mismatch in risk analysis in Reports and Analytics and risk analysis in Access Management
Ans: The risk analysis in Reports and Analytics tab is always offline analysis and hence you should have run the Batch Risk Analysis to populate the violations data.
The risk analysis in Access Management is real time analysis.
Both the results are same only when the batch risk analysis ran and completed successfully.
3.If any role from the User Account has been rejected or removed, UAR notifications are not sent to the User for whom the access review.
Ans: As per the standard functionality, notifications to users are not supported
If you want to send notification to user, then go for customization
Note: 2138427
4.Removal of direct and indirect role assignments using User Access review
Ans: 1.An indirectly assigned role, particularly through HR, (Position based), cannot be removed from SU01 directly.
2.GRC requires a system call from HR trigger, (Position change), to remove the indirectly assigned roles.
(Indirect role can be removed from PO13,but cannot be removed in SU01.)
3.From GRC product functionality, a UAR request will only remove the direct assignments
Note: 2066401
5.We cannot use functional area as attribute for role in BRF+ rule,as Functional area is a table. It is possible to maintain multiple
functional areas in roles,so it is not possible to directly use functional area as attribute for roles in decision table.
Instead we can use business process or create a table operation to read functional area of the roles using BRF+ procedure.
Note: 1890452
6.While updating the user assignment from Business Role Management (BRM), the change document in plugin system shows that the updated user-id is,the user who executed the update assignment from BRM and not SM59 user.
The change document in plugin system would show that the updated user as logged in user, who executed the update assignment and not SM59 user-id.
This is to track that who actually executed the provisioning.
7.Change log reports does not give any results for user id search
The User ID filter in the Change Log Report is intended to search for the changes made by the specific user in the USER ID field,on any particular
object within GRC NWBC.
The Audit logs shown for the Access Request would not be captured in this report.
This is only intended to capture the changes made to the objects within GRC. Check for the Configuration Settings in IMG for Access Control, it contains the parameters to enable the logging for various GRC objects like Risks/Functions (within ARA functionality), Roles (from within BRM) and similar.Objects under Param Group "Change Log" in GRC are under the scope of this report. (Available in IMG - Maintain Configuration Settings for Access Control).
8.Changing Mitigation control ID for an assignment, creates a duplicate mitigation assignment rather than updating old assignment.
It is a standard behavior of system to create a new assignment based on control ID entered. If any change is done to control ID, it will trigger a new assignment. We can do a mass change with the help of program GRAC_UPLOAD_MIT_ASSIGNMENTS and GRAC_DOWNLOAD_MIT_ASSIGNMENTS.
Note: 2026425
9.An error message 'Mitigating ID is not unique' appears when the approver tries to approve the control id workflow request second time wherein Control Id is same as in the first workflow.
If the workflow is ENABLED - the error happens only while approving the work item.If the workflow is NOT enabled - the error is shown at the time of creation, when you press SAVE.
This is as per the Mitigation Control Workflow functionality - it allows to submit 2 Control IDs with same name,
but does not allow approval. (This scenario can be very business specific, should avoid creating controls with same name/IDs).
We cannot show any error message during control creation in case of workflow, because Control Id will not be generated till the time it is completed.
Once the workflow for Mitigation Control has been initiated and sent to the Approver's Inbox, it will not show this error message until
this first workflow is completed and Control Id is created.
When the two Mitigation Control Workflows are created and sent to the same approver, the approver will be able approve only one workflow. Second time, when he will attempt to approve the second workflow which has same control name, it will display the error message saying 'Mitigating ID is not unique', because there is already a Control Id with same name existing in the system.
IMPORTANT: If the control is created WITHOUT WORKFLOW, this error message appears at very beginning and therefore, system will restrict the duplicate, the second time.
Note: 2130931
10.Mitigation Controls change History
Mitigation controls are integrated with Process Control, and whenever a new mitigation control is created, the entry is saved in tables starting with HRP*,example: HRP1000 holds the mitigation control object ids.
These object ids are converted from Process Control ID to Access Control ID, to be displayed in the Access Control screens.
There is no change history available for it.
Mitigation control changes can be tracked by having the "Mitigation Assignment" and "Mitigating Control Maintenance" workflow requests.
In order to have the control changes and assignments to generate workflow requests, configuration parameters 1061 and 1062 should be set to YES.
Mitigation assignments for Roles and Users are stored in below tables
User: GRACMITUSER
Role: GRACMITROLE
Profile: GRACMITPROF
User Org: GRACMITUSERORG
Role Org: GRACMITUSERORG
Note: 2027376
11.When a user request is created for a user who already has mitigation control assigned, the SOD detour path does not get initiated.
As per the design, if a mitigation control is assigned to a risk then the SOD detour is not initiated.
If a user access is altered and new risks arise then detour would be initiated.
But for existing risks where the Mitigation control is already assigned, the request will not take the SOD detour.
Note: 2073883
12.Difference in the results displayed for "Access Risk Analysis" and "Access Risk Assessment".
Check the "Permission Level" check box before running the "Access risk Analysis".This is required because "Access Risk Assessment" always runs at Permission Level by default and to keep the results in sync with "Access Risk Analysis", it should also be run at "Permission Level".
Note: 1689067
13.HR Triggers not works multiple positions for an employee.
HR Triggers functionality currently does not support fetching roles for multiple positions.
SAP HR storing only one position in PA0001, the GRC code is prepared to receive only one job position from this table.This means there is not such a LOOP to go through the found entries in PA0001, the code only reads from it expecting only one entry.
Note: 1990364
14.Behavior of user sync if two different systems are having same User ID with different user name
As per Application behavior, user sync depends on the User Data Source
CASE 1:
Say you are having 2 systems X and system Y. If none of them are listed in the user data source then the latest
connector sync will have the data in GRACUSER table.
System X: User ID ABC: User Name: ABCX
System Y: User ID ABC: User Name: ABCY.
Run user sync for system X.
ABCX gets updated in GRACUSER table.
Run user sync for system Y
ABCY gets updated in GRACUSER table. In this case, the older value ABCX would be overwritten by ABCY as none of the system is
listed as a Detail Data Source.
CASE 2:
If connector X is maintained in detail data source connector.
Then on running user sync for connector X, ABCX will be updated in GRCAUSER table
On running user sync for Y, ABCX will remain as it is as its connector X is maintained as a User detail data source in IMG.
Note: 2041653
15.When the firefighter tries to use firefighter logon pad from web interface (NWBC/GRC Portal) then Firefighter ID logon is not happening
Firefighter ID session is supported from SAP GUI. One can login into GRC box via SAP GUI and then use GRAC_SPM/GRAC_EAM transactions for firefighter ID logon AND NOT via Web interface.
Note: 2059142
16.When request for Risk or Function changes (using Risk workflow / Function Workflow) reaches to the approver, the changes done in the risk/function is not being highlighted to the approver.
Means the approver is not able to check what changes have been done to the Risk / Function
As per the product design, all the change history is not visible for an approver. If Approver would like to check the changes made for Risk or Function, he/she can check it's change history by opening that particular Risk or Function in Access Risk.
Note: 1907345
Looking forward to add more into this page so that its easy to refer and helpful for others.feel free to add if you have any such information.
Regards
Baithi
1 Comment
