ChrisPope (Customer) asked a question.
We have been struggling with the issue where a Role is updated to add an Active Directory Group and some of the existing Members have multiple Accounts in the Domain, such as one being a non-privileged account and the other a privileged account. IGL does not present an option to choose to which account the AD Groups should be provisioned, instead it provisions the Group to all Accounts which belong to the Member. This causes access to be provisioned to the wrong account and violation of least-privileged access amongst other problems.
I opened Case 01652541 back on Sep 2, 2020, when we first started working with RBAC Roles. Jira ACM-107542 was opened but no solution was provided. Idea https://community.rsa.com/ideas/3818 was also opened and it appears that no longer exists.
I searched on this community and can find no other discussion around this subject.
Has anyone else experienced this and how are you handling this issue?
Thank you in advance for any and all help!
ACM-107542 was investigated by RSA Engineering and they have determined that this is not a use case that is currently implemented to work in the current/existing versions of the product and this jira has been modified to be a product improvement (AKA Enhancement request).
About the https://community.rsa.com/ideas/3818, since our recent upgrade of the communities customers no longer have access to the exiting Ideas.
If you have a business need to cover this particular scenario please contact your RSA sales account manager and ask help from them to bring more visibility and or prioritize this with RSA Product Management.
I'm really looking for an answer from someone who has a solution.
One approach I can think of, is to separate the regular accounts (and groups) and the admin accounts (and the associated "admin" groups) to a different directory/application.
This can work assuming a user has 1 regular account and 1 admin account.
If there are more than 1 admin accounts in the same directory (per user), then when applying a role, all admin accounts (which are in the same directory) for a specific user will be granted with the new group membership.
Additional approach is to cancel the change items which are associated to "regular" account during the workflow processing.
@TimWillemstein2 (Customer) @OverthinkerDave (Customer) - any creative suggestions?
Hi Boris,
The method you mentioned is one we've been using for years for this exact scenario. Efficient? not quite, does it work? 100% of the time.
In the past you could do some very nasty stuff with webservices from forms / workflows where you would call the deprecated Webservice call:
Add account to group
But the first mentioned solution is much more elegant for this scenario.
@Boris.Lekumovich (RSA) and @TimWillemstein2 (Customer), thank you both for your answers! I greatly appreciate your help! @Boris.Lekumovich (RSA) especially, you are always such a rock-star!
I had started to develop the first solution Boris mentioned, creating a "Privileged" Directory to contain the Privileged accounts...but not Groups. But as Boris mentioned, for users with multiple privileged Accounts...of which there are many examples...this sorta falls apart. Additionally, I cannot separate the Groups so cleanly. There are LARGE amounts of Groups which are commonly needed for both the non-Privileged Account and the Privileged Account(s). When one of these Groups is added to a Role with Members who have multiple Accounts, then it is provisioned to all Accounts. So that problem remains. We would have to duplicate these Groups to be in both Directories which would require them to be in multiple Apps. I am pretty sure people would come after me with pitchforks and torches if I proposed that! Although...maybe I could simply collect them into the Directory without putting them into an App. That might put extra work upon the Role Owners...which also will go over like a lead balloon.
I had also thought about creating a new Identity Collector for the Directory to create a Privileged Identity. I actually think this was a solution once proposed by RSA. The problem with this is during Terminations (Leavers) and even Transfers (Movers), ensuring that the Privileged Identity is included in the Term/Transfer processing.
I was also looking into the solution to modify the Workflow to cancel provisioning the Group to the Human-user vs. Privileged Account. It seems to require creating Privileged RBAC Roles and ensuring only Privileged Groups are processed. This may be the best solution, albeit it not very fun.
Thanks @ChrisPope (Customer) :)
As Tim mentioned, the first solution is more elegant, but most likely will require a significant amount of work to change the existing config and processes.
As far as I remember, you can't collect the same group in different applications. It will be rejected as duplicate.
I think the most practical solution to cancel the change items in a workflow, assuming you can easily identify the regular account vs a privileged account.
To add in here Boris, you can collect the same groups from the same directory as long as the directory/application is different.
Thanks Tim. You are right. Just one caveat.
Based on some testing I've done, if Collect ObjectSID is checked, the groups will be rejected with this error:
The ObjectSID value is already assigned to another active Account or Group in the environment