Hello Community experts,
Quick sanity check from others in the field and anyone else who might have been in a similar situation.
System Manager rights were removed from IdM developer to establish SoD on production deployments, which I'm familiar with, but what I'm not familiar with is being denied read-only access to users, roles and tasks visible by system manager.What I'm thinking would be beneficial is a system manager read only role, but is there such a thing or an example that could be provided? I'm thinking having a system manager (read-only) support role would help for anyone tasked with troubleshooting the environment, whether it be account provisioning, synchronization issues of user attributes (bulk load and reverse sync used). Also perhaps it could be used to limit making exceptions and allowing certain IdM developers system manager access to production deployment. Does anyone agree with me that it's difficult to thoroughly document user on-boarding process in an environment where you see errors from inbound on attribute data that is being populated from bulk feed and pulled in through E/C's with reverse sync and the mappings are different depending if the data is flowing down or up and where it was created first (ad endpoint or CA directory)? Wouldn't you consider a user fully on-boarded once the entire attribute set is established, whether or not it came in from feeder file, IdM task execution, or from an E/C against AD which is being manipulated outside of IdM?
Furthermore, has there ever been a reason to limit IdM engineers from querying production data on the database? I'm concerned because I've seen far too many times garbage collection of VST not being implemented properly and the only real way to address the problem is at the database level, but without the ability to query the prod db, it's difficult to gauge the type of data that needs to be cleaned or how much of it is there. For instance, perhaps there's a lot of stuck in progress transactions which need to be updated to complete since they're no longer needed and can be cleaned. Looking for strategies on how best to help in situations like these where SoD has become a disabler preventing thorough analysis and identification of issues which could be negatively impacting the current implementation.
Thanks,
Chris.