Is there a date that access reviews will move from BETA? We will be using them in production in the coming months and purchased the enterprise version to get the Access Reviews feature, not knowing it was BETA.
it says beta like good mail had beta on gmail for years even when everything was perfectly functional - i think we miss one or two functionalities:
- manual vs. just automated trigger of reviews
- optional reviews (meaning not forcing someone to go to the portal, etc)
the ux on the portal will be upgraded in the coming months (as part of the migration of all portals) but that wont change the functionalities itself , is more like a clean up of the portal to use template 2.x html/javascript elements.
weāll remove the beta thing in a month or so , i guess that is my point here.
Thought Iād share my experience with the Beta so far, and a few outstanding items from my perspective:
Iāve been using it in production almost since it became available. I reached out to support with numerous issues that came up, which were all fixed in updates last year, and it has worked sufficiently for us so far. There may still be one or two lingering issues; one that comes to mind, on Exit reviews the Roles donāt come through properly (missing, misaligned), but I donāt usually care about Roles at that point so it hasnāt yet been a showstopper.
That said, I definitely want some improvements:
- Review Interface for Complex Role Sets: Due to the review interface, they can be hard for reviewers to compare across users to make sure all the same type of person on their team has the same set of Roles.
- Apps with Many Reviewers: For apps that need to go to lots of reviewers (e.g. I have one app with complex Roles that I have to break in to 80 individual reviews), I have to create each of those eramba reviews, including creating each Portal page, Starting each review, and ensuring all the Notifications are set up properly! Gets very tedious, and can make it hard to get across the finish line and keep track of the status for that one app and its 80 reviews. It would be helpful if the Portal page was a template or perhaps was auto generated on the fly based on input criteria. And a way to link to the numerous input files I have to associate to each review.
- Better Support for Narrower Computer Displays: The 1.x interface is not very good at handling narrower computer displays. Sometimes users canāt see what the Ok or Not drop-down boxes are for because they are so narrow no help text is shown. A quick way to see this issue isāas the review owner where you see extra buttons for blocking and adding findings, or as a regular reviewer with complex Roles which seem to make the Roles column extra wideāon that screen, make the browser window a little more narrow and see that the Ok or Not column is shrunk down to about a centimeter wide. Those buttons take up a LOT of real estate.
- Schedule Management: Finally, I really hope we can get better scheduling options because setting repeating review for x days is great, but when is that? I wonāt remember when I set 300 days as the interval, so I donāt know when it will trigger again, and therefore when I have to have the files updated and staged. Iāve not found any way to see or manage upcoming reviews, so I revert to Stopping the reviews until Iām ready to do them next time to avoid mistakes.
I havenāt upgrade to 2.x so maybe some of this is already easier to manage with the upgrade. All that said, itās MUCH better than the old way of using emails or chasing people down. Iāve been able to automate the collection of many users lists (outside of eramba) and created my own scripts to parse them in to eramba format, so gearing up to use the tool has been a useful exercise that will pay dividends every year.
Happy to clarify further if needed, and sorry for hijacking your Beta question. Hopefully, my experience gives confidence that even with that label it is useful.
Hi, thanks for the response. I look forward to the coming changes!
Hi JGLA,
It is always great to get insight into how other are using so thanks for the feedback.
We havenāt started using it in anger yet, we are in the process of configuring it and scripting feeds, however I see this drastically improving how we do access reviews going forward as they have been somewhat a bone of contention in the past.
I would be interested to learn more about how you are automating user list collections and the scripts you use to parse them into the Eramba format as this is something we are struggling with right now
This is probably more than youāre asking for, but while itās still rather fresh, and in case itās helpful to others, I thought Iād share more about how Iāve worked to develop the overall process, as well as some aspects of my scripts. Iām definitely open to easier approaches to this. My primary goal it to work toward automating as much of this as possible, so as youāll see I focused on scripting support for variations in the data Iāll get from each system.
Process Considerations
As I began working on this I ran across several considerations in designing a process. Most of it has nothing to do with eramba, but affects how I prepare the seed files (or whatever theyāre called now).
I started by defining who authorized users are for our company, and where I would obtain that list from. This is for my Exit reviews (I decided for now to just do Exits against a list of currently active authorized users). Turns out I need:
- HRās Employee list
- HRās contingent labor list (contractors, consultants, temp, outsourced, etc. Anyone not an employee, but recognized as an authorized user in some capacity.)
- Authorized ānon-humanā accounts (we often use the term āService Accountā, but it can also include things like Bots, core administrative or guest accounts, or any other authorized account on a system not tied to an identifiable individual. This list can vary from system to system, and there is overlap in naming (many systems have SA or Admin accounts, so I have to know what its called for each system).
Next, I need to know who is going to recertify a given systemās users and non-human accounts. Is it the individual managers of the users, is it a system or data owner, or some combination? Included in this is figuring out how to deal with company executives and board members, or other senior people. Can we establish a consistent policy that all Managing Directors and below must approve users, but levels above that may delegate? I have to program how will we manage that.
Finally, since each system has its own approach to UserIDs and account management, I need a way to reliably link a given system user ID to a known authorized user, and identify where they work and who their manager is. Weāre using Active Directory to do this ānormalizationā to a known person (and a spreadsheet to track non-system accounts for a given system).
Collecting User List Reports
For each system I need to review I work on how I will collect the user list. I need a CSV or XLSX format report, and Iām able to handle some minimal formatting. I need a header row and a minimum set of fields: UserID, UserName (fn and ln combined or separated), Roles, only active accounts or a field which indicates active/enabled status, last login date, and email address of the user. In some cases Iāll take additional details which may help with a particular review, such as product (some systems have sub-products), a license type, profile type, or other relevant fields. I prefer that each Role for a user be represented by a separate row/record, and that the overall report be minimally processed, as Iām going to handle the processing later when I prepare it for eramba.
If the collection of this data can be configured as an automated report or query I work with the appropriate teams to set that up. In my case, our reporting team has established a set of reports based on sql queries I collect from system owners. In other cases, it canāt be automated due to some system limitation, so I work with the owner to define what is needed so they can send it to me on request. (Maybe I can get those added to our RPA tool down the road!)
Preparing To Bring It Under Management
Youāll find that no two systems use the same field names. I developed a set of mapping tables to map the names provided to a standard set I could process automatically in a script. For each new system I add to my process I first define the mapping tables that will be used. Source and Target file prefix names and locations, and any special filtering or processing requirements (start on excel file row 3, filter on descriptions that regex match āInformation Technologyā, filter on accounts flagged as not checking in for over 65 days, etc.). For example, in my default mapping group, to get a UserID I accept āUserIDā, āUser IDā, āLogin IDā, āLoginIDā, āLogin Nameā, or āLoginNameā. If something other field name is used (such as an email address, or āNameā), I specify an additional mapping group so that the email address or Name field is read as the UserID.
As I start collecting user list files for each system I preparing my mapping table to support any variations and ābring it under supportā.
Scripting It All Out
As for scripting, Iām using PowerShell 5 which gives me direct access to SQL queries (assuming I have an authorized account), AD user information queries, and good data management capabilities. There are many other scripting language options which may be better suited for other environments. My script is continually growing and adapting, but the high-level outline Iām using is:
- Look for any updates to my authorized users lists and update the Exit Seed File.
- Read the list of App Reports files to be processed, remove any dated/prior files (all my report file names include the date in yyyymmdd format) or files not already under support.
- For each of the supported App Reports I:
- Read the headers and normalize to my standard field set per the mapping table, removing fields I donāt need to process.
- Using the updated headers I read in the App Report
- Match each App UserID against Active Directory by one solid criteria (Employee ID, userID match, email address match, first name/last name match (assuming there is only one match)
- If no match can be made, check the spreadsheet for a known service account to match with.
- If all else fails it drops to the No-Match list.
- For each App UserID I collect the matched users AD ID, AD DisplayName, Department, and Manager. For un-matched IDs I assign some default values so its clear these werenāt matched to a known person or ID.
- I consolidate all the Roles from the User report for each user.
- I assemble all this information for a user in to an eramba Seed File record: UserID (from AD if matched), Roles (consolidated previously), Description (a combination of the App UserID, App fields like Last Login, email address, user name, etc., and any matched AD fields that will help the reviewer such as Profile, Department, etc.
- Once Iāve processed all the App UserIDs and assembled my eramba Seed File report I output that to a CSV file, taking care to back up/archive any previous versions. I generally output one Seed File for each Manager/Reviewer, a Seed File of all users, my No-Manager list, my Service-Accounts list, and if called for, Seed Files based on special criteria for a given application. The No-Manager and Service-Accounts lists help me identify accounts that may need more research or documentation.
Iām not a developer in my day job, so this has taken some time and a lot of google/youtube searches, reading, and trial and error (Iāve got some good resources to bounce ideas off of internally as well). Happy to share more script details if PowerShell is relevant for others.
1 Like
Hi @JGLA
Our user access review process is very similar, and we have similar issues, for instance.
- Different applications have different usernames.
- We have system accounts or service accounts (CITO reviews these)
- Our review is done by userās respective managers. ( I have excel of staff and their managers, their email etc)
After looking at your process, I had few questions.
- I see you have mentioned you output one seed file for each manager.
- So you do create the user review for each manager manually on Eramba and then select the
respective seed file ?
- Or do you use some automated ways to select all seed files and create reviews ? - Is it possible you can share your scripts, this will be very useful.
- Each user might have multiple roles for the same app; currently I see in Eramba its piped and showed under roles, but during review, if the reviewer wants to indicate to remove only 1 role, how do you handle that ? Currently how we do it is have each row for respective roles (in separate application, and not Eramba)
Thanks in advance.
Hi @JGLA
Any help here will highly be appreciated. Or anyone else has similar use case as JGLA.
Kind Regards