Managing memberships assigned prior to EIC implementation

[dvillalta]

Hello all

Prior to the deployment of EIC in our environment we had several memberships (all location code based) that were assigned and maintained via Power Shell scripts that performed the assignment according to several conditions, these memberships are related to a door access platform not connected to EIC and that makes use of AD syncs to keep the system updated

Now that we have EIC implemented we need to move the functionality implemented in Power Shell to native functions in EIC, for this purpose we have implemented a set of Technical Rules (birthright, detective and remove birthright options selected on each), as well as a set of User Update Rules (one at user creation and other at user update both from import)

The issue we have found is the following: By applying the combo of user update/technical rules and making use of a detective job for the technical rules we can get the memberships correctly assigned in EIC and these are passed correctly to AD (this applies to new users and users updated via import), the issue arises when users that had the memberships assigned prior to the EIC implementation (which makes sense), on these users we can add the new memberships once the user is updated, but removing the previous membership (assigned via our script, not EIC) is not possible via the set of user update/technical rules we have implemented

For this effect we have tried also running a retrofit job for said technical rules, but the issue remains where memberships assigned via our script can't be removed by the set of user update/technical rules

Does EIC has any method for managing these memberships that were assigned via script prior to EIC being implemented? or do we have to remove all the memberships assigned via script and afterwards perform the needed updates into EIC via the retrofit job (run first) and detective job (run second)?

Thanks in advance

[rushikeshvartak]

Membership assigned prior EIC is not pulled in Saviynt ?

[dvillalta]

It appears it is being pulled, but if the user is updated the User Update Rule is not firing the tech rules to remove the membership, for example:

We have user A and user B

User A has location Livingroom assigned and thus had the Couch membership assigned by our script prior to EIC being implemented

User B has location Kitchen and membership Stove assigned by EIC

We have several Technical rules for each location:

• If user is active and has location Livingroom assigned, assign the Couch membership to it (Birthright, Detective and Remove Birthright if condition fails)
• If user is active and has location Kitchen assigned, assign the Stove membership to it (Birthright, Detective and Remove Birthright if condition fails)

We also have a set of User Update rules for when user was created (this is how user B got its membership assigned) or when user is updated

We update the users, now user B has location Livingroom and user A has location Kitchen, this fires the User Update Rule

• User B has the Stove membership removed since it does not comply with the Birthright condition anymore, and then has the Couch membership assigned by the rule
• User A has the Stove membership assigned by the rule, but the Couch membership is not removed despite not complying with the birthright condition

We suppose this is caused by the membership being assigned by our script and not by EIC, therefore a rule-user relation does not exist

Running a rule retrofit job for these rules, does not resolve the issue, and neither does running a Detective job for the rules (both the retro and the detective job have the Tech rules explicitly selected)

Hope the example helps clarify the issue

[rushikeshvartak]

what is flag set for User A for Couch memebership.

select ASSIGNEDFROMRULE from account_entitlements1 where accountkey =100

[dvillalta]

Running provided query for user A returns ASSIGNEDFROMRULE = 133, which corresponds to the ID of one of the Tech rules we have created

Running it for user B returns ASSIGNEDFROMRULE = 140, which also corresponds to one of the Tech rules we have defined for locations, user B had the new membership added by one of the rules, but the old membership was not removed by the other rule when the birthright condition stopped being valid probably due to the membership being assigned via our script and no rule-user relation existing

Situation that we have proven works on user A, we can change the location of A to comply with any of the Tech rules, and the membership gets removed once the condition stops being valid, and the new one is assigned by a different tech rule

Would it be possible to, for users that got the membership assigned via script and have the ASSIGNEDFROMRULE key empty, manually assign this value to kinda force the rule-user relation in regards to this membership?

[rushikeshvartak]

Ideally not but for testing purpose you can try

[dvillalta]

@rushikeshvartakwhich method would you recommend to perform the update of the ASSIGNEDFROMRULE field on the specific user?

[rushikeshvartak]

Using update query

[dvillalta]

Tried the following from a ROLE_ADMIN level account:

UPDATE account_entitlements1
SET ASSIGNEDFROMRULE = 137
WHERE accountkey=98429;

Getting the following: Error : Operation Not Allowed

[rushikeshvartak]

Query is correct share logs

[dvillalta]

I managed to run the query, looks like performing that process of forcing an update to the ASSIGNEDBYRULE field forces the rule-user relation, sadly performing this process for multiple users (up to +1500 each with multiple accounts managed in EIC (SN, Workday, etc)) would be extremely complex

Will probably default to a different method to perform this process

[rushikeshvartak]

You need to perform one time

[bala]

@ dvillalta

Any good solution found on this? we also have same issue. 

[dvillalta]

Hello @bala

None of the answers provided on this thread were useful for resolving our issue, at the end we performed the following:

• Stopped the script from further executions
• Removed all the location memberships from users by making use of a different script
• Performed an import into Saviynt
• Created a set of Technical Rules making use of the Birthright, Remove Birthright if condition fails and Detective options in order to assign the memberships
• Created a set of User Update Rules to manage different scenarios (location change, user creation, etc)
• Created a detective job that runs the created set of Technical Rules to be executed at the end of day to pick any assignments

After performing these processes the memberships are being managed by EIC, had a couple of hiccups, but these were fixed by creating a User Update Rule for manual fixing of users, here we set the rule to re run the set of Tech Rules once a custom property was updated from import, afterwards we did a manual user upload with the affected users and this seems to fix the issues