Error in Role level SoD violations Dashboard

Hi All,
We are running on GRC V10 SP06.
When role level SoD violations dashboard is opened there is no relation between Number of role analyzed (X) in system and Number of roles with violations(Y).
In our case Y is far greater than actual X.
Even the percentage of roles with and without violatons together doesnt constitute 100 % ...
Please help what may be a solution to fix it.
-Thanks

Similar Messages

GRC CUP 5.3 SP16, detour path not working for SOD violations

Hi,
Something bazaar is going on in our requests processing and not sure if that's the way SAP has set it up.
We configured a detour path for requests with SOD violations to go to the additional stage of 'SOX Approver' but the first stage (manager) does the risk analysis and Mitigation assignment and then it goes to Role owner approver that approves the roles access. Once the role owner approves the roles , if the request had SOD violations, even if the mitigation was selected and approved by the manager stage, it needs to go to the SOX approver stage to approve the mitigation assignment before the request can be auto provisioned for any requests that had sod violations.
But it seems to skip the sox approver detour path stage after the role owner approval and go directly to auto provisioing. I thought that any requests that had sod violations inspite of having mitigation assignment in a previous stage can be detoured to the next path for SOX approval and then auto provisioned. Since SAP doesn't give different approval option to approve mitigation vs. approve roles, wherever you make the risk analysis mandatory, that's where the mitigation controls have to be assigned. But we want the option to detour the path to SOX approver to approve those mitigation controls b4 auto provisioning the request.
Any idea of how to fix this?
Is the detour only going to work if the mitigation wasn't assigned? But then how can you get approval for the mitigation on a different stage if the same person has to assign and approve that?
Will appreciate any feedback in this.
Thanks,
Alley

I was actually able to resolve the issue by adding the role approver stage first to the sox approver detour path.. this way..if the manager has roles with sod violations and updates mitigations for it, it goes to the role approver via detour path as well first and then to the sox approver stage b4 auto provisioining. So, that solved our problem. And if the request doesn't have SOD violations then it just goes to the next stage without detour which also has the role approver as the last stage.
Since I couldn't get the sox approver stage to show up after the role approver as originally anticipated since the request already had mitigation assigned at the manager level, we did the above scenario to fix the issue.
Requestor>Manager->Role Approver-->auto provisioning (without SOD violations)
Requestor>Manager> Detour (Role Approver>SOX Approver)->Auto Provisioning (with SOD violations)

CUP 5.3 SP16, detour path for SOD violations doesn't exclude critical risks

Hello,
Has anyone else had this issue:
If you set your configuration to not require mitigation of critical risks, but only SOD risks, the workflow detour path condition 'SOD violations' still triggers to go to the detour path even if the request only has critical risks. This is a bug in the workflow detour logic. First of all, CUP doesn't differentiate between SOD violations vs Critical Risks violations. If we only want the mitigation approver detour to happen for SOD risks, the detour seems to happen even if the request only has critical risks issue which doesn't require mitigation.
Since our Approver determinator for SOX approval is the RAR Mitigation Control approver, the workflow detours to SOD violations path but doesn't find any mitigation approvers on critical risks and so goes to the administrator inbox as a approver not found issue escape route.
If SAP gives the option to not require to mitigate critical risks under config>mitigation>uncheck mark mitigation of critical risks not required, then the logic for detour also shouldn't happen for critical risks under 'SOD violations' condition. This doesn't make any sense why SAP has both in the same condition when one is clearly not SOD risks. Now our workflows keep failing bc of this bc we have several roles that might have a critical transaction or so, but we can't stop it from detouring even when we do not want them mitigated or approved for SOX stage. But we still need this detour path for additional approval for the actual SOD Risks.
Will greatly appreciate any1's feedback on what they have done to resolve this.
Thanks,
A.

I was actually able to resolve the issue by adding the role approver stage first to the sox approver detour path.. this way..if the manager has roles with sod violations and updates mitigations for it, it goes to the role approver via detour path as well first and then to the sox approver stage b4 auto provisioining. So, that solved our problem. And if the request doesn't have SOD violations then it just goes to the next stage without detour which also has the role approver as the last stage.
Since I couldn't get the sox approver stage to show up after the role approver as originally anticipated since the request already had mitigation assigned at the manager level, we did the above scenario to fix the issue.
Requestor>Manager->Role Approver-->auto provisioning (without SOD violations)
Requestor>Manager> Detour (Role Approver>SOX Approver)->Auto Provisioning (with SOD violations)

Role level mitigating controls not affecting position level reports

Hi,
Here's the problem we're having with mitigating controls:
When I assign a mitigating control to a role, it correctly mitigates the risk when we perform a role level SoD analysis. However, when we perform a position level analysis, the same role shows up again in the report as not mitigated. Anyone else running into this issue? We are on CC5.2 with SP4. Is this fixed in later SPs?
Simple Example:
Role ABC has conflicting tcodes FBV0 and FBVB. We applied a mitigating control to this role and it doesn't show up anymore on the role level reports.
When running the position level SoD analysis, position number 50010000 contains role ABC and the same conflict shows up again even though the conflict is entirely within Role ABC and not with other roles that are in position 50010000.
Thanks,
Robert

All,
I opened a customer message with SAP and it seems that this issue is a limitation with CC 5.2 Mitigating at the role level will will not follow through to the position level reports. However, it seems that it will follow through to the user level as long as you have configured it under the Configuration->Additional Options tab. There is a setting there that will allow rule level mitigating controls to take affect at the user level.
Thanks,
Robert

No violations at user/role level

Hi All,
We are using GRC 10.1 SP04
While running the risk analysis reports on user/role level, I don't see any violations. Post running the reports, I can only see that "No rules were selected" under Action field.
Recently we added a few more systems/landscapes so created a few more connector groups and added the corresponding connectors. Strage part is that, for a few D-systems I can see the violations as expected but for the respectice Q-clients I don't see any eventhough there are violations.
Please refer to the attached screen shots for clarity.
Kindly help me with the solutions.
Thanks,
Ameet
P.S: Rule-set is successfully generated and MIME repository is maintained with the appropriate extensions.

Hi Ameet,
How were you able to resolve the issue?
Even I am now stuck with similar issue after I replaced the connector because of change of SRM sys IDs. I followed all the necessary steps after setting up the new connector. Steps like rescheduling all of the background jobs for these new connector. I also regenerated Rules and ran SOD analysis program. But still the nos of Risks differs between past and current report.
Thanks,
Kishore

SOD Violations at R/3 Backend

Hi all,
we are using GRC 5.2 version,and Backend R/3 is ECC6.0,wen i am changing at user level i.e in su01 if i add any role it is showing that
Checking SOD Violations at Object Level with Time stamp at Status bar.
But when i am changing any thing in PFCG it is not showing violations.
Really it shows SOD Violations at R/3 Backend.
Kindly clarify my Query

Hi,
When I executed * /n/VIRSA/ZRTCNFG*, I got the following options:
Stop generation if violations exist
Comments are required in case of violations
Send notification in case of violations
Default analysis level
I did not get anything like PFCG Plug in value
Could you please tell me actually what is the use of these?
Regards,
Faisal

SOD violation as per sizing guide

Hi All,
I have a query regarding sizing for GRC server. As per sizing guide, there are few inputs like total roles and total users in system landscape, which are to be connected to GRC and total violations during per peak hour etc.
I want to know what violation count means in this context -
Is it SOD violation before GRC implementation occuring in system?
Or is it SOD voilation count when GRC is established and we assume that either most of the risks are mitigated and / or remediations are done.
Does this count SATs as well?
Thanks & Regards,
Sabita

Hi Experts,
Please excuse me for re-opening this message. Our client wants clear understaning on sizing and I want confirmation before I can convince them.
Here are my queries-
1. When we do sizing for RAR, what activities are covered under " Daily Transactional Sizing per hour". We do incremental Sync and Batch risk Analysis, but they run in nights when system is less loaded. So what does it mean"during peak hour"? What else are under transactional sizing-do webservice calls from ERM or CUP are included in it and does Alert Monitor job also falls under it?
2. What does it mean voilations in context of Risk Analysis? Does it mean actual violations in daily backend transactions or it is only voilations based upon Role/User authorizations? What kind of voilation it includes-permission level all line items(like ME21N ACTVT 01, 02, 03 are 4 voilations or it is only one for one risk?
3. Under which criteria or parametr should we do sizing for Adhoc risk analysis ( run from Informer tab) .
4. There is parameter for "initial load" in RAR and CUP. We would like to know why there are two parameters for "initial load" and "daily transactional". They may overlap for sizing purpose because when we do initial it means system is not ready to perform daily tasks. And when we say " Transactional" it means initial load is done. So in this case, the SAPS used in initial load is released for daily transactional task.
Thanks in advace.
Regards,
Sabita

How to change the "Page Flow Error - Unsatisfied Role Restriction" page

When you try to access a page and are denied authorization to it, Weblogic automatically redirects you to a
"Page Flow Error - Unsatisfied Role Restriction" page, on the bottom of which tells you what roles you have to be in in order to access the resource. My question is how can I change this page to match the general look and feel of my application?

I know you asked this almost a month ago, so you may have already figured it out... but you just need to add a handler for com.bea.wlw.netui.pageflow.UnfulfilledRolesException. Something like this:
@jpf:catch type="com.bea.wlw.netui.pageflow.UnfulfilledRolesException" path="roles-error.jsp"
You can put it at the class level of a specific page flow, or at the class level of WEB-INF/src/Global.app, which will apply it to all page flows.
Hope this helps.
Rich

Can PID (Parameter ID) be set as a default by TCODE or Role Level

Hi, Any one has any idea if PID (Parameter ID) and its value can be set as a default at TCODE or at Role Level?
Thanks in advance.
Syd.
Addendum:
Re: Can PID (Parameter ID) be set as a default by TCODE or Role Level
Posted: Oct 17, 2006 9:38 AM Reply E-mail this post
Thanks for the reply, you have mentioned try creating a Transaction variant or a Transaction parameter.
Here is my question?
1. Can we set a default Parameter ID at TCODE level so, if any user execute a transaction who has access to execute it, he will have Parameter id and its value as a default?
2. Can PID be set as a default for SAP TCODE or Custom TCODE, or can be done for both, if it can be done then, How?
3. Can PID be set as a default for a particular Role or profile?
Message was edited by: Syed Alam
Message was edited by: Syed Alam

Hi JC,
Yes, I agree.
A small disclaimer however is that we dont know which transaction is being refered to.
Creating a transaction variant with the parameter set for it could enable the use to navigate further and back again and in doing so "shed" the screen which the transaction (initially with variant parameter and skip screen) originally gave them.
Using a user-exit to set the parameter can in some cases be closer to the functionality (irrespective of how the user gets there) and be more reliable. But in this case an adventurous user will be likely to trick it anyway if they want to.
If the decision is made to use PIDs in the coding, then it is a decision that the user can influence the value (in my view). If coding makes insecure use of PIDs, then it is a design error in the coding.
Cheers,
Julius

Does "Access Enforcer" only support "role" based SOD analyse?

Hi Expert,
In the demo script, when the user create the "Access Request Form", he can choose the "Role" he wanted from "Select roles" list, I'm just wondering whether each role here is corresponding to the role in the backend system? for example,
If I choose role "Z_AP_ACCOUNTANT" actualy at that time there is a role called "Z_AP_ACCOUNTANT" already in the backend system if the system is a SAP ECC system.
Another question is, if so, does that mean it can only support "Role" based SOD analyse? as you know, each role may contain several "authorization objects", can it be done from "authorization object" level?
Thanks and best regards.

Hi,
The Roles are normally determined based on the SOD.Using T/code:PFCG the roles are mapped to the system.These Roles are common to all the system,regardless of R3,Virsa etc.
The roles also can be determined without SOD [but this is not recommended.].
The SOD is only to ensure that there exist no internal control weaknesses while creating the Roles at an organizational level.Thus it is only an excercise outside the System,be it SAP,Virsa or else.
At the system level we map only the roles [ using :PFCG].We dont map SOD here.So,SOD or No SOD,the system supports the Roles.
Hope this helps.
Regards,
Ramesh.

SAP Adapter has a problem, SOD violations will not be checked

Hi,
In our ides server whenever i click save button in su01 i get the following error ,
"SAP Adapter has a problem, SOD violations will not be checked !
Please check with your system Administrator
Technical Info:
Error when opening an RFC connection "
we didn't have this problem before . can anybody help me to resolve the issue
Also I am getting this error only if I click save in su01. in other t code. I don't get this error
Thanks in Advance
Edited by: gajula jhansi on Apr 11, 2011 11:28 AM

You need to restart your sap adapter in GRC front end from configurations tab-->Sap adapter >choose the one for your back end system> if it's grayed out or even green still, click on it and let it restart and turn green again.
Then you go back to your backend ECC system and in SM59 , choose the RFC connection for the Risk Terminator (the one you have saved in the Risk Terminator transaction /VIRSA/ZRTCNFG in backend system).. and test the connection. It should pass the connection test if your adapter is working and set up correctly. Then when you do save in SU01 or make changes in PFCG and have Risk Terminator activated for the backend system, it will check the SOD violations against those transactions from RAR front end.
If you don't want Risk Terminator to check for SOD violations in front end RAR, then you need to set your settings to 'NO' for all in the Risk Terminator transaction. You can get all this info in the GRC config guide for RAR and SPM area.
Regards,
Alley

ERM: Exceeding SoD violations treshold

Hi all,
In ERM role definition, when exceeding the SoD violations treshold, it is not possible to continue the role definition since next stage doesn't get active.
Has anyone of you face this before? How do you tackle it?
Many thanks ion advance. Kind regards,
Imanol

this was known issue with SAP on older SP's...
not sure if it was resolved or not.
however why are you creating role with so many violations...
as workaround create two separate roles (with min conflicting tcodes...)
so two roles can be assigned to a user in end... and role will be created in ERM also
regards,
Surpreet

CUP 5.3: SOD violations detour to Super Access Owner

Hi GRC Experts
Is it possible for us to set-up SOD violations detour to a super access owner as an approver when violation is identified?
Has anyone done does this before?
Edited by: Donovan Mathews on Oct 6, 2009 2:47 PM

I'm fairly sure that you could configure the workflow to trigger an approval stage which is then approved by the SuperUser Owners.
However, you may need to be on patch level 08 to allow this approval mechanism to work correctly.
I've not had the chance to play with detours massively yet so cannot comment on that element but I'm sure others here have.
Simon

Inconsistency Data between Role Level & User Level Risk Analysis

Hi,
When we run Role Level Risk Analysis for a role (Ex: XYZ), there is no SOD conflicts. But when we try to run the user level analysis, this role shows SOD conflicts. I mean, XYZ is assigned with other roles. Combination of other roles access may bring SOD conflict, thats fine, but here the challenge is role XYZ itself has SOD conflicts. The same does not appear when we run Role Level Risk Analysis!!
How could this happen??
Thanks,
Karthik

Hi Karthik,
The role might be mitigated at role level.
In RAR Anayze tool, click -More options to expand the selection options
Chose "Exclude Mitigated Risks: No"

Firefighter - SoD Violations Report - not showing any data

We have ECC6 and GRC 5.3 with latest patch. Our RAR is working well also. We recently installed firefighter. All reports are working fine except following two reports,
1: SoD Violations Report
2: Critical Transactions
We want to use RAR critical table and SoD data, therefore In our configuration table we have following paramter set as:
Critical Transaction Table from Compliance Calibrator (VRAT) = YES
Could someone please direct in right direction how to get it fixed. Is there any SAP Note suggesting configuration setup etc.
Thanks in Advance
Masood Akhter

There are a number of settings to be made in order to get this working. The note is helpful but effectively you need the following:
In ECC
TCP/IP RFC Dest created with a unique report name.
This RFC mentioned in the /VIRSA/ZRTCNFG transaction
In RAR
The Report name entered into the RAR connector.
The SAP gateway mentioned in the RAR Connectior.
The RAR connector marked as outbound connection.
The SAP Adapter activated.
In SPM (ECC)
Set the "Connector ID for Risk Analysis" parameter to the name of the RAR Connector in the SPM configuration table.
You may also have to do a Java system Restart if you encounter error messages when activating the SAP adapter in RAR.
Simon

Error in Role level SoD violations Dashboard

Similar Messages

Maybe you are looking for