Two common steps when migrating a new source into production is to understand the impacts that new Roles will have as well as what attributes to enable for Attribute Sync. By leveraging the extensibility of SailPoint’s APIs, we can stage our changes and run two independent scripts to make sure our Role Membership and Transforms are correctly configured. The Role Membership report will show what entitlements will be added if a particular role is enabled. This helps identify if the role has too many users compared to existing users with those entitlements. The Attribute Sync report will show all attributes in the Provisioning Policy that are configured as Identity Attributes, and highlight which are already Synced, and which differ when compared to the Account Attribute. This report can be reviewed if updates to the Transforms are needed or if sync can be enabled with confidence.
How would you use this tool, if you are updating an existing dynamic role? Also, with roles can’t you directly assign an entitlement without an access profile?
@faye_jacobs1 I have not tested more than 20K users, but I assume there would need to be some modifications made to refreshing the token, retry logic, and maybe others, but I have not tested that.
@dpetebrown This was made prior to dynamic roles so it would not be compatible to my knowledge.
While you can directly attach entitlements, this method allows for the role to be enabled and access profile disabled. That way the assignment logic can be evaluated without provisioning to users.
@ethompson Thanks for the information. I may give it a try and see what happens. I will create a duplicate role with version in the name with disable access profile just to see what happens. If it still generates the query that can be used in search, it still may give me the information we need. Misconfigured Roles has caused us no end of headache and uncomfortable conversion with management. Simple mistake of using an or statement instead of an and statement has unforgiving consequences
For anyone encountering an out-of-memory exception or generally long run times I would recommend updating both of the $body objects in the Search-IDN function to include the includeNested parameter as follows:
This will exclude the “accounts” and “access” arrays from the returned identities, drastically reducing the size of the result/responses objects. The later parts of the script do not reference these nested objects, so they are safe to remove.