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

Similar Messages

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

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

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

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

GRC 10.1 - Routing at Request Submission in case of SOD violations

I am trying to configure MSMP workflow or risks analysis while creating userid
1. No Risks >> User created and access assigned automatically
2. Risks found >> forward to security team to review and approve
I have checked the standard functional module - GRAC_MSMP_DETOUR_SODVIOL cannot be used in AC 10.0 . This is only be used as Routing Rule after first stage approval and at subsequent stages as per Note - 1783157 - Routing at Request Submission in case of SOD violations
Can anyone advise the standard SAP delivered rule / functional module we can use in GRC AC 10.1 to achieve the outcome at the time of request submission ??

Hi Anil,
You have enable riak analysis at submission buy setting parameter and the need to have a first stage as dummy where risk analysis result can be analysed and have a detour at this dummy stage so that in case of risk request is forwarded to next stage.
Hope that helps..
Regards
Ashish

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)

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

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)

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

SPM "SoD Violation Report"

Hi all,
We are trying to find details documentation for user SPM report "SoD Violation Report" but there is any in 5.3 configuration and user guide.
What is the purpose of such report? Which is the expected result? Are they the SoD conflicts within FF authorizations? OR SoD conflicts of transactions executed by FF?
Many thanks in advance. Best regards,
Imanol

Yes, Imanol. it will show the SoD conflicts of transactions executed by FF
The Segregation of Duties (SoD) Conflicts Report captures the data from the selected system for
each designated firefighter ID. The data is grouped by firefighter and by violated risk. The report
lists the SoD Conflicts that arise for each login event.
The report displays the following information for each firefighter ID:
· Name of the firefighter using the firefighter ID.
· The Risk ID associated with the conflict.
· The name of the transaction.
· The date that the conflict occurred.

SPM SOD Violations Report

Should the SPM SOD Violations Report populate if you don't have Risk Terminator enabled?
If so, I'm not sure I have the correct configurations in place. Whenever I click the report in SPM I get the following message: "No match nor conflict found". I have other reports that are function correctly, which makes me belive this is not a connector issue. Am I supposed to run some background job?
Please advise.
Thanks,
Kunal

Kunal
did you imported the default rules and risks before connecting the system? And than did the sync job?
The sequence has to be followed as per the config guide
Nesimi

SoD Error in Back system

Hello,
While changing the user in SU01 the following error occured:
SAP Adapter has a problem, SOD violations will not be checked !!!
Please check with your system Administrator
Technical Info:
Bean VIRSA/RT_JAVA_RISK_ANALYSISnot found on host ulldev, ProgId =GRCRTTOCC5X
I searched and found a thread with the same error but the OSS mentioned in that thread was not opening in the service marketplace (Error was Requested OSS Notes was either in reworking mode or it is released internally)
Can you please help me on this error?
Can you please paste the content of the OSS Note: 1145048
Regards,
Kumar Rayudu

Hello Kumar,
Please check SAP Note 1225960 which has the same issue mentioned and is available for download.
The content of note 1145048 is also pasted below.
1. Go to Backend system where Risk Terminator is giving this error.
2. Go to SM59 and delete all (old and new) TCP/IP connections created
for Risk Terminator per note 1060673.
3. Now go to Visual Admin -> Server<number> -> Services -> JCo RFC
provider.
Here if you see any entries related to TCP/IP connector you created for
Risk Terminator, delete them all, by clicking 'Remo..' (Remove) button.
4. Then go to Backend system (where RTA is installed) and follow below
steps:
a. SM59 -> click on TCP/IP and click 'Create'.
b. Give 'RFC Destination' name and it should be EXACTLY 10 character
long. Apart from that first three characters should be System Id. Say
'PRDGRCCONN' (This is precautionary step).
c. Now select 'Connection Type' as T.
d. Give Description.
e. Under 'Technical Settings' tab select radio button 'Registered
Server Program' and enter 'Program ID' EXACTLY 10 character (This is
compulsary step). And the important thing you have to take care while
giving name is that no character in this program id name should be part
of 'RFC Destination' name given in step 'b.' above. Per above 'RFC
Destination' name, Program ID should be like 'ABEFHIJKLM' (This is
precautionary step).
f. Avoid entering value for 'Gateway Host' while creating TCP/IP
connection.
g. However 'Gateway service' entry is MUST. Use transaction 'RSGWLST'
to check the same.
h. Go to transaction /VIRSA/ZRTCNFG and maintain option 'RFC
destination for release CC5.X' same as 'RFC Destination' given above in
step 'b.' say 'PRDGRCCONN' and 'Save'.
5. Now go to Frontend Compliance Calibrator 5.2 and follow below steps:
a. Go to 'Configuration' -> 'Connector' -> 'Search' -> 'Search' ->
select the relevant connector and click 'Change'.
b. Now change 'Report Name' to be same as Program ID given while
creating TCP/IP connection and per above example it should be
'ABEFHIJKLM' and 'Save'.
c. Now 'Logoff' from Compliance Calibrator.
d. 'Login' again into Compliance Calibrator 5.2 and go to
'Configuration' -> 'SAP Adapter' and click on the grey diamond for the
relevant SAP system.
e. If it don't become Green and gives error, then restart J2EE. Else
test Risk Terminator in the Backend system by creating or changing one
conflicting Role.
Regards,
Varun
Edited by: Thakur Varun on Jul 20, 2009 11:22 AM

SOD Risk P003 and transaction F-44

In the use of our version of SOD Rule P003, we are encountering SOD violations caused by access to F-44 from the AP01-AP Payment Processing functional group and various AP02-Process Vendor Invoice functional group transactions (such as F-42, FB60, FBVO and MR8M).
Can someone explain the risk of having F-44 as well as Process Vendor Invoice transactions?
We also need to mitigate this risk. Is there a standard SAP report which lists vendor invoices/items entered and cleared by the same person? Or can someone suggest an alternate monitoring report?
Thanks.

Laks,
Thank you for the reply.
Regarding F-44 specifically, I understand that it only allows you to clear items already existing in a single vendor's account that are equal in amount and would offset each other. The net impact to the vendor balance and to the financial statements appears to be $0.00. I believe the risk comes from having the ability to create a credit memo or something like it to offset a vendor invoivce and F-44 would allow you to clear the credit memo against an invoice. I am not sure what the real risk is because the amount is still owed to the vendor who will still expect to be paid.
Regarding the FBL1N report for cleared vendor items, is there a way to limit the report to the users who need to be mitigated aby a control due to a F-44 SOD violation? When we run the report for our company which is global, the report is very lenghty and does not show the name of the user executing F-44 to clear the vendor balances?
Thanks again for your help.
John

SOD's are not shown in the Report

We have created the connector in Compliance Calibrator for MQA system
We ran the user Full Synch and Incremental Synch.
But the Sod Report doesn't show any SOD's.
SOD's are shown for the different system's the user has same Roles in
the two systems.
Is something we are missing?

Venkat,
You need to run 1) Full User Sync, 2) Full Role Sync, 3) Full Profile sync if you are using profiles, 4) Full Risk Analysis and 5) Management Reports to see SoD violations.
I did not understand meaning of this statmenet:
"SOD's are shown for the different system's the user has same Roles in the two systems."
What do you mean by this?
Regards,
Alpesh

SOD Violations at R/3 Backend

Similar Messages

Maybe you are looking for