Account Name Generation Logic in SaviyntApp in SNOW

[ravikumarghr]

We have complex queries to generate unique account name for AD and other applications(Account name rule in endpoint).

When requesting using Saviynt ARS it works fine and generates unique account name as per the logic/code.

When requesting account from SaviyntApp in ServiceNow it simply copies the username of the user not really the account name rule as per the rule logic.

Is this can be configured in SaviyntApp in ServiceNow?

[saikanumuri]

Hi @ravikumarghr 

Thanks for reaching out. I am checking internally on this scenario and will get back to you asap.

[saikanumuri]

Hi @ravikumarghr 

Apologies for the delay. Once the request is submitted on ServiceNowApp, the account name gets generated as per the logic defined in your Account Name Rule under the corresponding endpoint.  

Please let me know incase if you are seeing a different behavior and I can assist you in resolving the issue.

[Jari_K]

Hi @saikanumuri 

We are seeing this same unexpected behavior also on other customer environment when requesting access from ServiceNow app to child endpoint which doesn't have account for the user.

New access task is created with new account task as well instead of using the account from the parent endpoint. Which I believe is caused by this issue that account name doesn't match to the one on parent because it uses username instead of the name defined by account name rule.

[Jari_K]

Here is example how it looks like when requests are made using ARS and SaviyntApp for ServiceNow. Testuser arska.azure made request from ARS and reetta.requestor from SNOW app.

Account name rule works when request is made from Saviynt ARS but doesn't when request is made from ServiceNow.

[rushikeshvartak]

Can you try

[Jari_K]

Yes, Parent Account Name Pattern has been "select" all the time.

Only other option is GLDAP which doesn't make sense when account name should be email format in our case. Don't know about original poster's issue. Tried with that as well but no luck.

Did some additional testing and created new request using Saviynt's createrequest API. When calling this API with Postman I can reproduce the issue. So it seems that for requests from API the account name rule is not applied and username is copied as account name.

Tested with v23.5 and v23.11 with request body:

{

    "requesttype": "add",

    "username": "demo.requestor",

    "endpoint" : "ChildEndpoint",

    "createnewaccounttaskifnotexist" : "TRUE",

    "roles": [

        {

            "rolename": "Test application rolename",

            "businessjustification": "Created by postman using createrequest API"

        }

    ],

    "comments": "Request from postman"

}

Tested also with different endpoint that had simple account name rule to use just users email and same behavior with API. 

 

[Jari_K]

Ok, did again more testing... with createrequest API it is possible to give parameter: accountnamefromrule - true/false to API call, when set to true account name rule is applied and request is created with correct name.

Seems that ServiceNow is generating the API call without that parameter. In SaviyntAccessRequestHelper script include there is a function addAppRolesRequest which creates the body for API call:

var body = {
"requesttype": "add",
"username": saviyntUserID,
"endpoint" : endpointName,
"createnewaccounttaskifnotexist" : "TRUE",
"roles" : requestRole,
"requestor": requesterUserID,
"comments": comments
};

And since that script cannot be modified the account name rule is not applied.

@saikanumuri Please advise how this can be worked around when requesting application roles? This will prevent us from using Saviynt App for requesting access and will postpone our go-live.

[flucas]

Hi @rushikeshvartak and @saikanumuri , could you review the comments? This is tagged as blocker by our customer in order to implement this release of SNow integration with EIC. Thanks in advance for checking it.

[saikanumuri]

Hi @Jari_K ,

Thanks for the analysis. The script cannot be modified and I would recommend raising a request in the ideas portal.
https://ideas.saviynt.com/

However, as a workaround, you can import the ApplicationRoles as Enterprise roles using CSV upload or Sav4Sav and expose them to users to request from SnowApp so that the AccountName rule gets evaluated during the Enterprise role request.

[Jari_K]

Hi,

Thanks for looking into the issue. But I really don't get it. There is a bug in Saviynt app for ServiceNow which you can reproduce and you still want us to raise an idea to possibly fix it somewhere in the future?

What comes to workaround, yes technically that is possible but not very user friendly. Enterprise roles are used as work roles and bringing in all application roles would drown the that single dropdown menu with too many options to be easy to use for end users.

[rushikeshvartak]

As per current product design its working as expected hence it will be idea ticket. You can contact CSM to prioritize the idea. 

[Jari_K]

So it is not a bug but a feature that one of the ServiceNow forms does not apply account name rule of endpoint but other out of the box ServiceNow forms do when requesting access without existing account to the same endpoint?

For child endpoints this causes Saviynt to mismatch account with account in parent endpoint. Which in turn causes either creation of another account or failure of the provisioning task. For example, Azure AD with endpoint filters being used to create logical applications as child endpoints should use the same account as in parent endpoint. Now if the account name rule is not applied those accounts are not connected. Is that also intended?

Would really like to see that design also documented if that is intentional behavior. As it is now, there is no documentation what so ever about ServiceNow app not using account name rule which lets us think that account name should be used and if not the system is not working as expected.

[Darshanjain]

Hi @Jari_K 

This has been taken as enhancement from our internal product team.

Thanks

Darshan