Existing roles SOD violations appeared for non-violating access while modifying the service account.

[ssingh16]

Hi Team,

We create a new service account and add SOD-violating roles. When we modify the newly created service account and try to add a non-violating role, it shows the SOD violations that appeared for already-assigned roles (currently existing roles in the account). After approving the request at risk owner 2, it gets assigned to admin instead of risk owner 1 (without using the recalculate SOD option). We have two levels of approval: risk owner 2 and risk owner 1. If these violations are expected, then we expect them to show up after recalculations as well.

PFA evidence of this issue Could you please share your insights on this?

Regards,

Satyam

[Dhruv_S]

Hi @ssingh16 

Could you please provide more information about the issue/scenario. Please share the screenshot/information about the workflow.

Regards,

Dhruv Sharma 

[ssingh16]

Hi Dhruv,

Part A: We raise one service account and add voilating roles to them due to this voilation occurring.

Part B: When we try to modify the same service account by adding non-violating roles, even though violation appears for already-assigned roles, that is an unexpected behavior.

PFA screenshot and workflow details.

Regards,

Satyam

[Dhruv_S]

Hi @ssingh16 

1. Have you enabled Recalculate SOD from the Global Configuration-Request? 

2. Why are you using 2 Grant access in the workflow? Can you link both the links to same.

Regards,

Dhruv Sharma

[ssingh16]

Hi Dhruv,

Yes, recalculate SOD is turned on.

Initially, we are using two levels of approval. To link both levels of grant access to the same, you mean that when a request goes for approval, it requires only one level of approval. If it is, we can't use the same configuration. We are in non-prod, where we have not seen this issue.

Regards,

Satyam

[rushikeshvartak]

Can you turn off recalculate Sod and check behaviour 

[ssingh16]

Hi Rushikesh,

Our concern is that whenever we request a non-violating role, violations should not appear on the request or approval page. The issue seems to be with the preventative SOD check, which is not working as expected.

Disabling the recalculate SOD button is a secondary matter or step. We must first ascertain the reason behind the appearance of violations for roles that actually do not violate.

Regards,

Satyam

[rushikeshvartak]

Recalculate sod is beta feature and might not work as expected 

[Dhruv_S]

Hi @ssingh16 

Could you please confirm on which version are you facing this issue?

Have you opened a Fresh service ticket for this issue? Can you share the Ticket number if there is an existing ticket.  Can you please confirm on which version you are facing this issue.

Regards,

Dhruv Sharma

[ssingh16]

Hi Dhruv,

Currently, we are running on version Saviynt v2020.1

FD number: 2007991

Regards,

Satyam

[ssingh16]

Could you please provide an update on the above issue reported?

Regards,

Satyam

[Dhruv_S]

Hi @ssingh16 

As I can see from the FD comments, the product is behaving as expected.

When a Preventative SOD check occurs in the process or requesting access, the scan will include all the Entitlements on the target Account for which the Request is being made.  Even if the requested Entitlement/Role is not a cause of a new SOD Violation all existing open SOD Violations will still be raised in that scan. 

Regards,

Dhruv Sharma

[ssingh16]

Hello Dhruv,

If preventative SOD works in such a way that it will cross-verify all the entities of the user, and if violation exists for any assigned role, then it will reflect on the approval page if we raise a non-violating access request. After the first level of approval, it went to the 'Admin' for approval instead of the role owner, and that is not an expected behavior, I guess. It seems like workflow breaks in the middle of the request.

Could you please explain why it is stuck at admin?

Regards,

Satyam

[Dhruv_S]

Hi @ssingh16 

From the workflow, I can see that there is a two-level workflow with Risk owner1 and Risk owner2 when the request is having SOD violating entitlements. It is going to level 1 approval and post the level 1 approval; it is going to admin instead of level 2 approver. 

Here the issue seems to in the workflow and not the SOD. Now please confirm if you are using a user group in the level 2 approval (Risk owner 1), Are there valid and active users in that group with Rank 1 ownership?

Could you please try with a user instead of user group in Risk owner 1 approval and see if it works? 

Regards,

Dhruv Sharma

[rushikeshvartak]

Please share workflow

[ssingh16]

PFA document for Service Account.

[rushikeshvartak]

This blocks does not works in service account hence use custom query block and rank validation in query

Query :

select u.userkey
from request_exceptions RE INNER JOIN riskowners RO ON RO.RISKID=RE.EXCEPTIONKEY
INNER JOIN Users U ON U.userkey=RO.OWNERUSERKEY and ro.rank=1
where RE.REQUESTKEY=${ARSREQUEST.id}

[ssingh16]

In this block, what do you mean by Risk Owner 2 or Risk Owner 1? At this place, we need to test by placing a custom assignment task block. Correct me if I misunderstood something.

[rushikeshvartak]

• Change workflow type to parrllel 
• change sod approval block to custom assignment - custom query