Hello,
If the Permission can not be requested/assigned more than once from the back-end system for the user then that is what Identity Governance enforces.

Is this permission from IDM, csv, or ?
Is it allowed to be assigned more than one (1) time by the back-end system?

Sincerely,
Steven Williams
Principal Enterprise Architect
OpenText Cybersecurity

Hi Steven

This is on Active Directory, so each service account can be assigned to the AD group that grants access to the folder. The issue is that once the user has requested the permission for 1 of the service accounts that he is the owner of, the option to assign that permission is not displayed anymore and he cannot assign it to another service accounts although AD supports it. In this case we have 2 service accounts in AD that need access to the same folder, but due to the fact that both service accounts are owned by the same user, IGA does not allow the user to request the permission for both.

Anyone has any idea on how this can be done ?

I think you've found a limitation in the interface.  The request policy infrastructure relies on relationships between permissions and identities (through account objects) and in my experience it behaves just as you've said - it doesn't matter which account you have rights on, it will prevent displaying it for request again.

I thought there was an attribute on permissions that was labeled "allow multiple requests" but I think I must have dreamed that!   If the request system could be tied into a boolean like this somehow, that might enable multiple assignments, but otherwise I think you'll need a very crafty workflow or custom interface to handle that.

--Jim

Hi,

If you can distinguish between the type of accounts in AD using the filter or search base I would recommend that you add multiple applications to the same AD. One for each type of account that you want to manage. 

I did a PoC for a customer asking if we could support the "Tier model" (now the "Enterprise Access Model"). I solved it by having multiple application sources where each layer was collected separately allowing the user to have multiple accounts. This will also make it possible to assign the same permission to multiple accounts assuming it is collected by the application collecting the account.

This will also make it possible to manage privileged account permissions using business roles and not only using the end user requests.

Other benefits are that risk, approvals, fulfillment and other compliance related policies can be separated between the applications and not managed as one application. 

Please let me know if you need more details but hopefully this will give you a starting point.

Best regards,
Tobias

I had a thought.  I like this idea of a separate App for alternative accounts, but 1 app per account doesn't quite work for requests, especially if you have dozens of service accounts that users want.   WHAT IF you were to create a second app config, and you configured it to NOT pull in permission assignments, only permissions.  Then in request policy, you only allow people to request against this second app.  For fulfillment, it would go set perm assignments as expected, but then it wouldn't be able to collect and confirm perms afterwards.  If we had a way to deal with the failed validation that would occur, this could setup a way for a user to request anything against an app (since it would never see that user having any rights) and they could always make requests for accounts.   You would use the original app config (that does pull in assignments) for reviews, so you could still see who has rights, but just for requests you might use the second app.   

I think there are some unintended consequences here with validation, but this might be a model that works?

* Note I haven't tried this at all.