GRC AC 10: Issue in User SOD Cleanup

[Former Member]

Hello Gurus,

We have implemented GRC AC 10 & using role violation report @ permission level found 66 roles to be SOD conflicting roles.

Now we started cleanup & removed the conflicting transactions or in GRC terms , if we had a ROLE A and it had two functions e.g. GL01 & AP02 which were conflicting , we simply removed all the transactions related to AP02 and formed a clean role ROLE B . Hence with this approach we cleaned all the roles and hence we had two clean roles ROLE A(all Tx for function GL01) & ROLE B(all Tx for function AP02).

When we ran the "User Risk Violation report" we found that there were risk like F001, F002 etc.

The report revealed that ROLE A had a transaction F-41 which was conflicting with some other transaction in ROLE B transaction ABZON .

But when we checked in "MENU" of role A , there is no F-41 transaction in role A.

There is Transaction ABZON in Role B.

So we are wondering how can a transaction which is not present in ROLE A (menu under PFCG) , create a SOD conflict with ROLE B.

Has anyone come across such an issue ?? Or is is that i am understanding the concept wrong ??

How can we resolve this or proceed with user cleanup ?

Please help!!

Thank You.

Regards,

Victor

[kevin_tucholke1 · Accepted solution]

Victor:  You stated you looked at the MENU of role A, but did you look at S_TCODE permission to see if there may be a Range or Wildcard in that role that may have been manually placed?

Hope this helps.

Kevin Tucholke

[Former Member · Accepted solution]

Hello Kevin,

I searched for the T-code F-41 in object S_TCODE and found that the object was not manually changed and is still with name "STANDARD".

What else could be the reason why this transaction is available in this role ??

Thank You.

Regards.

Victor

[kevin_tucholke1 · Accepted solution]

Victor

I really don't have any other 'logical' cause.  Have you tried to just re-generate that risk in the rule set, has this role been synched recently....

Beyond my first suggestion, it will just be a trial/error find as you need to figure out why the role is showing up.

Sorry could not be more help.

Kevin Tucholke

[Former Member · Accepted solution]

Hello Kevin,

Thank you for the reply !!

I would like to know from your experience , if the approach that we used to make the role"SOD" free was correct or wrong ??

i.e. We ran report at "permission level", then if role A contained following conflicting functions

e.g.) GL01 , GL02 , AP02

Then in this case all the transactions of each functions were removed and placed in separate role.

i.e Role A with only GL01 functions

Role B with GL02 Functions & it's corresponding transactions & so on.

We did not perform any clean up the "conflicting objects" , but simply removed the transactions.

Was it a correct approach ??

Back to my original question , Is it due to "Implicit" objects from other transaction code causing access to some other transaction.

e.g.) Role A has  Transaction T1 has Object 1,Object 2 & value 1,2,3 

T2 , with obj 2 & value 3,4

T3 with object 1, Object 2, Object 3 ,Object 4 & values  2,3 ,5

So even if i have removed the transaction T1 from the "Menu" & also have not manually added it under S_TCODE object . is it possible that because transaction T3 which still exist in role & it's corresponding auth objects ,  "IMPLICITLY" forming  the authorization for transaction T1 ??

Please correct me if i am wrong ??

Thank You.

Regards,

Victor

[kevin_tucholke1 · Accepted solution]

Victor:

If you just remove the transactions, and do not validate the underlying permissions, what you could possibly end up with is a role that has 'unused' permissions, which is not recommended practice.  I would think that you would find that you will run into issues that may be able to be averted when you start provisioning role to users.

As you know, security is cumulative and permissions are shared across actions in SAP security.  For example, if you removed FB60 (Vendor Invoice Posting) from a role and made that role just FB50 (General Ledger Posting), then you may not need F_BKPF_BEK any longer as the vendor authorization is not valid for GL Postings.

As to your earlier question regarding F-41, if the transaction is not in S_TCODE, even if the permissions are still there, you should not be able to execute any STANDARD SAP transaction.  What I would do is to rule out that the role cannot do F-41 via a test user.  Also, make sure that the role is properly generated on the sytem you are running the analysis on.

Does that help more?

Kevin Tucholke