Thanks, Jishnu. I agree that showing counts would be ideal. We’ll support result counts in the future.
Thanks @kirby_fitch for the response. Looking forward to this.
Hi @kirby_fitch, thanks for your answers.
Good to know! We still need to click on each account to get more details from it, and link them to an identity from that screen, but better than downloading all accounts from the source to get the details of the uncorrelated accounts to fix.
That would be awesome, I’ve been playing around the feature in Sandbox and although the test data skews the uncorrelated numbers, I still see several accounts that will definitively need to “ignore” when working on uncorrelated accounts in Prod.
I’d like to suggest 2 more things:
-
Jump to given page from the navigation menu at the bottom.
We have sources with thousands of uncorrelated accounts and as I mentioned some we’d like to ignore (e.g. external humans, computers, service accounts), but until that feature is available, we would still like to have a way to jump to a page instead of clicking on “Next” several times to reach the point in the list where we left off.
-
Select all rows in the page for bulk action.
(I guess it would become more relevant when “non-human”/“ignore” features are released).
I know, our sources aren’t the cleanest (who has perfect sources anyway?), so when processing those sources with thousands of uncorrelated accounts I mentioned earlier, I’ve navigated entire pages of accounts that I would mark as “non-human” and with current UI I would need to repeat the process one by one. Also if I happen to accumulate enough external humans that can’t be correlated to our identities, I would love to bulk “ignore” them too (at least until we’re able to work on rules for our external human beings).
Both components are available in Search UI and other pages, so I hope it’s not too much to ask
I hope you can consider them for your future roadmap if you aren’t already working on them!
Thank you!!
Hi Elisa,
What things do you really need to know about an account to make that manual correlation decision? I think I read email
was one of them. What else?
We’ve got some work to do before we can allow discrete paging. Discrete paging when you’re working with hundreds of thousands of accounts can slow the UI down a bit. We optimized for very fast page loading to ensure admins correlate the maximum number of accounts.
We’ve seen customers with tens of thousands of service accounts. You’d be there for a couple years if you had to mark those one-by-one. We’re going to offer something very slick to solve this problem in bulk, with automation.
With regards to the “ignore” feature, we’d design it to do at least 250 accounts (or a single page of accounts) at a time.
Thanks for the input. Hope this helped!
Hi Kirby,
Today I finally got the feature in Prod, so I had my first exploration in there. Although email would be a good indicator to identify whether the account belongs to an employee, client or provider, as you mention, I can still dig into the details by clicking on the account name, so this is still much better than working with spreadsheets.
The account status was also useful (Disabled accounts represent a lower risk, so I just “ignored” them for now).
Looking forward to it!
I understand this is early in the release, so I’ll watch the space
Thank you!
I did not get a chance to review the new Accounts page, but got the notification that it was in productions so I decided to check it out. Overall I think this is a good view, particularly for the Uncorrelated accounts.
Feedback:
-
Having the left menu option of “Human Accounts” without a corresponding option for “Non-Human Accounts” or “Service Accounts” or something similar opens this up to the questions “When will Non-human be coming?”, “How can we mark service accounts?”, etc that I see have already been asked here. As a Roll-out strategy, labeling this “Identity Accounts” for the initial launch may have caused fewer questions. Granted, you are getting some good feedback for what people would like to see.
-
I agree with the previous person that a “Jump To Page” option would be good to have. To expand on that, a “Total # of Pages” label would be helpful to know the scope of what you are looking at, and where you can jump to. All other grids seem to list the total rows returned, so this one diverges from the standard.
-
I agree with others that having a way to export the data from here into a CSV would be helpful, however I am not sure this would be the best place for this improvement. Due to the unstructured nature of accounts on different source systems, this option would likely need to only be available when 1 source is selected, or you would need to come up with a way to define exportable fields per source to allow the admin to select which fields are important.
I think a better solution, assuming the account details are needed, would be to update the Uncorrelated Accounts export CSV on the Source Screen. The Uncorrelated Report from the Source Screen only outputs 4 fields, “Account”, “displayName”, “userName”, and “type”, which are not helpful in reviewing the data. The Accounts CSV Export on the Source Screen outputs the account details that one would want, but it does not output Correlated/Uncorrelated, so someone still needs to merge the data from those 2 manually to get something to review. If the Uncorremated Export on the Source Screen could include the data from the Accounts CSV Export for only the Uncorrelated accounts, it would be much more useful.
- The Search box is very limiting, especially when looking at Uncorrelated accounts, since it is only searching the “Name” field as a “Starts With”. I think the suggestion of changing it to “Contains” is a good start here, however I think that some improvements could be made:
- Allow searching through other columns: Native Identity and Status specifically
- Allow searching based on attributes in the accounts like “attributes.FIRST_NAME:Tom”. In many instances the Account Name and Native Identity do not contain easily recognizable information (ID: , Name: CC091239923) so searching on the name is not useful, nor is opening up each record to see the FIRST_NAME field. If you do allow this type of search, it would be good to return the column searched for in the grid.
-
For the Uncorrelated accounts, the Identity column is unnecessary and should be hidden by default, since the identity can not be clicked on, and it can not be looked up through Identity Management → Identities. It also is just the “Name” field with “(Uncorrelated)” added, so it is not providing additional information. This would allow more room for the other columns which are important.
-
There is a UI Error when you change the number of results viewable from 25 to 50 or 100. When you scroll down, the white header bar with the column selector stays above the column name header until row 25 comes up, then it moves up and leaves the column name header “floating” over the rows.
.
- Reading through the discussions, it would be great is we could categorize, and then filter the uncorrelated accounts based on that categorizations. The following categories/status are what I have come up with based on the feedback here:
- Admin
- Service
- Non-Human
- Reviewed
- Ignored
- Terminated (If a user is no longer with the company, and does not meet the aggregation requirements, there may be no Identity to correlate this to.)
Overall this is a great addition, and will be useful going forward, especially for looking at the Uncorrelated Accounts in the UI, and managing the manual correlations. Looking
Hi @gmilunich,
Thanks for the comprehensive feedback! I’ll respond in-line on each.
We knew some users would have this reaction. Almost all tenants regard accounts that have been correlated to an identity as accounts that are correlated to human identities or Human Accounts
.
We’re preparing our users for what’s coming next. Look for a filter to present service accounts, bots, etc. in the future. I’m not able define timelines yet.
We’ve got some work to do before we can allow discrete paging. Discrete paging when you’re working with hundreds of thousands of accounts can slow the UI down a bit. We optimized for very fast page loading to ensure admins correlate the maximum number of accounts.
This account grid is a component that can be re-used throughout Identity Security Cloud. For example, head to an identity’s details and check out their accounts. It’s the same component there too. The Source > Accounts UI will be updated in the near future to also use this component. We think that will be the appropriate place to provide more access to source-specific attributes and exports. I’m not able define timelines yet.
We’re taking a wait-and-see approach on further changes to Uncorrelated Accounts UI. We’re not sure how often (and how) it will be used now that you can correlate accounts via the UI.
We’ll be adding more filters in the future. We hope that will help some. Although we hear you that Search-style querying could be helpful.
We’ll eventually let you click that column. It was clickable in an earlier iteration but we had some trouble with that. It’s particularly helpful if the uncorrelated identity you’re working with was previously a correlated identity. These uncorrelated identities often end up holding the accounts that had been correlated prior to the authoritative accounts deletion. It’s helpful to access their account list for cleanup purposes.
Thanks for letting us know about this. It’s being tracked as a ticket and we’ll resolve it.
We’re focused on a way to categornize service accouts, bots, etc. to start. We’ll consider how to handle orphaned human accounts in the future. Our goal is to bring you to zero uncorrelated accounts.
Thanks!
@kirby_fitch Thank you for the responses.
For our use case, #3 and #4 are barriers to start using it more wide spread.
For our use case, in regards to #3, having a way to export the data that includes the account details in 1 step would allow the process to move forward. Currently the team that goes through and updates these is provided with the spreadsheet of the uncorrelated accounts that they then update their Source system to have the correct linking ID. This then allows IDN to correlate them on the next aggregation of the source (the preferred method.) If they had to be given admin access to the IDN system, then had to click into and open each individual record to see the details on the account, this would cause the process to take significantly longer and be more frustrating to them. As you mentioned, it is a lot of data do each page load takes time.
In regards to #4, we currently have many accounts that are uncorrelated and the Name is like “DD092342139” and the Native Identity is either a GUID, or Numeric value like “9234929392”. Neither of these values quickly identifies who the user would be to correlate, and would require clicking into each record to see these values.
And another issue found with the page, when you Filter the page based on a source, then click on an account to view the data. When you click back to the accounts using the link at the top, it takes you back to the Accounts screen, but all of the Filters are removed.
Have you considered using the Source Sub-Admin user level? Source Sub-Admin narrows the list of accounts one see just to the sources where that person is on the source’s governance group. This would enable these users to see their uncorrelated account lists and take you (or whomever is sharing the files) out of the loop.
Are there some specific attributes on AD we could show front-and-center to make this easier?
We’ve got a ticket to add some memory in here so that filters are preserved. Should filters also be preserved when switching between human accounts and uncorrelated accounts?
I agree with this… as a workaround, I started to open accounts in a separate tab that I close after I finish the correlation or determine it’s an account to ignore.
The Source sub-admin was not considered because aside from this process, those individuals do not need to access the IDN system, and are not considered admins of their system. Additionally, the Source Sub-admin does not truly limit the user to seeing data from ONLY the source they are added for. Per the documentation and testing, granting a user “Source Sub-Admin” still allows the user to see ALL sources from the Dashboard, Reporting and Search. This allows those users to access data that we would not want them to otherwise.
So this is not the restrictive, configured-source only secure level that it is touted to be.
As for your response to #4, I am not referencing AD. As mentioned in my first response as part of #3, there is no good way to get attributes from all the different sources in a manageable way. This is why I suggested that this move into the Uncorrelated Account Report on each source, since the data is going to be Source-Specific.
If you wanted to try and make the search work here for attributes, you’re still not going to get consistency. You could either provide a mechanism per source to define the top 3-5 attributes that you would want searchable from accounts, then search all those. Or you would need to have the search work similar to the main search, except you’d need to allow free-form searching: ie, I might search “attributes.LAST_NAME” and it would return any accounts on sources that had a “LAST_NAME” attribute, but not, for instance, AD with it’s “SN” field.
As for the Identity Column, it would be good if this could be Disabled by default until you have the clickability working since at this time it is just taking up space.
I look forward to seeing some of the categorization methods implemented. I think anything will be helpful. Even if you implemented a Tagging system like you have with other objects that allowed users to add free-form categories would be good. I think your goal of zero uncorrelated accounts is a lofty one until there is a good, financially feasable way to maintain disabled identities and/or exclude disabled accounts in ISC.
@kirby_fitch There appears to be an error when going to this page if the user does not have access to any sources through Governance Groups. I documented what I found here: Account Management: Error when user is a Source Sub-Admin, but not in Governance Groups
@gmilunich Hi! Thank you for this report. After looking further into this issue, it actually appears this may be a new bug. I’d like to ask that you please submit a support ticket to have this reviewed instead. Please let me know any questions. Thanks, Tori
@kirby_fitch @tozinga
There appears to be an error affecting our Production tenant only, where if you have the Human Accounts page filtered by a single source, and try to then filter by the “Identity State” if causes a single, partial result to be returned and the font changes. It seems like the system is erroring, then swallowing the error and not notifying the user. I detailed it here: Accounts Page: Sorting by Identity State causes the system to display 1 record/change font