New Capability: Account Management

[kirby_fitch]

This is available in all sandbox and production tenants. Thanks for your feedback while this was in sandbox!

A new Account Management UI enables Org Admins, Source Admins, and Source Sub-Admins to manage accounts at a global level across sources. Admins can…

• Search and filter accounts across all sources.
• View uncorrelated accounts in detail.
• Manually correlate accounts via the UI.

You’ll know this is available in your tenant when you see an Accounts link in the navigation menu. Org Admins will find the Accounts link under Identity Management.

How do I use the feature?

Watch this short video for a step-by-step usage guide. Continue reading this post for additional detail.

You could also review the official documentation.

About Human Accounts

Human Accounts are accounts that are correlated to identities. This filter name choice leaves room for a forthcoming Non-Human Accounts filter item.

About Search and Filter

The search box searches based on Name. Filter menu changes are ANDed to the search box input. For example, you could search for accounts starting with Ann on sources named Active Directory.

About User Level Authorizations

Org Admins and Source Admins are able to view all accounts via the Account Management UI. Source Sub-Admins are able to view accounts on sources where that person is a member of the source’s governance group. We’ve detailed what actions each user level is authorized to use.

Action	Org Admin	Source Admin	Source Sub-Admin
Aggregate Account	Authorized	Authorized	Unauthorized
Disable Account	Authorized	Unauthorized	Unauthorized
Enable Account	Authorized	Unauthorized	Unauthorized
Remove Account	Authorized	Authorized	Unauthorized
Update Correlation	Authorized	Authorized	Unauthorized
Unlock Account	Authorized	Unauthorized	Unauthorized

About Update Correlation

Update Correlation could be used for several use cases.

Assign an uncorrelated account to an identity

This is the prime intended use case for this feature. First, improve your correlation configuration if you have a lot of uncorrelated accounts. Use Update Correlation to reduce your uncorrelated accounts to zero if you can!

Re-assign an account that was previously manually correlated

Use Update Correlation to correct previous manual correlation mistakes.

Re-assign an account that was auto-correlated via aggregation

Improve your correlation configuration if a lot of accounts are being incorrectly auto-correlated to the wrong identities. Use Update Correlation to clean up just a few.

Re-assign an account that was provisioned via access request, lifecycle state membership, or role membership.

We recommend against using Update Correlation for accounts that were provisioned. Let’s assume an identity received account A because it’s in a role. ISC would provision a new account B to that identity if Update Correlation moved account A to another identity.

Re-assign one identity’s authoritative account to another identity

Issues could arise when the same people are represented in multiple authoritative sources. Let’s assume there are separate FTE and contractor authoritative sources and…

• A contractor moves to FTE and then exists as two duplicate identities.
• A contractor moves to FTE but gets stuck as a contractor because the FTE authoritative source is prioritized.

Use Update Correlation to solve either issue by correlating the previous authoritative account to the new identity.

More About Navigation Bar Changes

We renamed the following navigation items:

1. Identities top-level nav renamed to Identity Management
2. Identity List sub-nav renamed to Identities
3. Access top-level nav renamed to Access Model

This was mentioned in a previous announcement but will be released with Account Management. Sorry for the confusion.

Bonus Enhancements for Identity > Accounts List

We heard that you would like to sort within the Identity > Accounts list (amongst other places). Thanks for providing feedback on our latest capabilities!

Now you can sort and filter!

New Capability: Identity Management

This is great, however, on the Accounts tab, you are no longer able to sort the accounts by the Source Name. Can that be added? For those that have lots of accounts, you now have to weed through the non-sorted sources to find what the user has.

Next on the Roadmap

• Tell you if new accounts were Aggregated or Provisioned (forthcoming Origin field) to help you make great manual correlation decisions.
• Expand this UI and all its actions to the following user levels: Org Admin, Source Admin, Source Sub-Admin, and Helpdesk.
• Add Identity > Accounts Source Name filter option to Helpdesk user level.

Submit Questions or Feedback

The goal of this project is to deliver a substantial upgrade to the account management experience. We are invested in addressing all concerns that are communicated to us.

Submit your questions or feedback as comment on this post!

[adunker (Alex Dunker)]

Love the bonus enhancement as well!

[eabedrapo1 (Elisa Abedrapo)]

Thanks @kirby_fitch, these features are a great improvement, especially the ability to manually correlate accounts from the UI. The former method via CSV wasn’t always easy to use when spotting issues with a few accounts, and the mapping exercise needed some dedicated effort which we never had time to do.

Looking forward to see what’s coming next!

[angelo_mekenkamp]

Hi Kirby,

Thank you for this new feature!
Some feedback from my side so far:

1: Based on the authorization matrix, source sub admins are not able to perform single account aggregation on accounts, even when the source sub admin is associated with the corresponding source through governance group membership. Is this indeed not allowed? If so, I would say this conflicts with the original idea of source sub admins, that says that a source sub-admin can do everything a source admin can do, unless it is related to a source they are not associated with.

2: Based on the User Level Matrix documentation, Helpdesk admins are able to go to the identities UI, view an identities accounts and through there choose to aggregate/disable/enable/unlock/remove any account. Why are they not allowed to see this page and perform exactly the same actions through here? I can imagine that this overview might sometimes be more suitable for certain activities.

3: How can we allow auditors to see these accounts without allowing them to make changes to them? How can we allow certain users to correlate accounts without also allowing them to delete the whole source? AKA, how can we ensure Separation of Duties on Identity Security Cloud itself?

4: If I want to correlated an account to an identity with displayName “Billy Bob Baker”, searching for “Bob Baker” does not show the result. Shouldn’t the search be done based on “contains” rather than “starts with” for more user friendly search? Same holds for when someone has a double lastname (maiden name?) and you search for the second one.

5: We can’t filter or sort the accounts on status. Why not? I can imagine it being used. either to get a clear overview or perhaps to get the number of results after filtering.

6: Why show us the identity state of the account by default rather than the identity lifecycle state? The latter gives more information than the former after all.

Kind regards,
Angelo

[vguleria (Vikas Guleria)]

Hi Kirby,

Looks like a great feature although i completely agree with @angelo_mekenkamp’s remarks.

In addition to that when i see the account management page, it also displays authoritative source accounts and for all accounts (authoritative or non-authoritative source ) i think remove account action button always pops up irrespective of the features associated to that source. So in case some one remove the account from authoritative source, that may result in deletion of the identity itself, so do not think that it will be ideal.

Also for authoritative source accounts too the update correlation button is appearing, i am just thinking what will be happen if admin or source admin try to correlate authoritative source’s account to another identity. And what happens when the aggregation happens for this authoritative source, something to be checked i believe ?

But in general this feature looks great and really handy when comes to correlating the non authoritative source accounts.

Thank You.
Regards
Vikas.

[kirby_fitch]

Hi @angelo_mekenkamp - thanks for the great questions! I’ll answer them inline.

@angelo_mekenkamp

1: Based on the authorization matrix, source sub admins are not able to perform single account aggregation on accounts, even when the source sub admin is associated with the corresponding source through governance group membership. Is this indeed not allowed? If so, I would say this conflicts with the original idea of source sub admins, that says that a source sub-admin can do everything a source admin can do, unless it is related to a source they are not associated with.

We didn’t have time to update authorization as I would have liked. We wanted to get this UI out to you to collect valuable feedback and then iterate. Do you think this would be an appropriate revised authorization matrix for this UI?

Action	Org Admin	Source Admin	Source Sub-Admin	Helpdesk
Aggregate Account	Authorized	Authorized	Authorized	Authorized
Disable Account	Authorized	Authorized	Authorized	Authorized
Enable Account	Authorized	Authorized	Authorized	Authorized
Remove Account	Authorized	Authorized	Authorized	Authorized
Update Correlation	Authorized	Authorized	Authorized	Authorized
Unlock Account	Authorized	Authorized	Authorized	Authorized

@angelo_mekenkamp

2: Based on the User Level Matrix documentation, Helpdesk admins are able to go to the identities UI, view an identities accounts and through there choose to aggregate/disable/enable/unlock/remove any account. Why are they not allowed to see this page and perform exactly the same actions through here? I can imagine that this overview might sometimes be more suitable for certain activities.

See #1 for revised user level matrix question.

@angelo_mekenkamp

3: How can we allow auditors to see these accounts without allowing them to make changes to them? How can we allow certain users to correlate accounts without also allowing them to delete the whole source? AKA, how can we ensure Separation of Duties on Identity Security Cloud itself?

We have an in-progress project for custom user levels that should enable you to create an elevated user level that can see this UI but take no action, or see this UI and ONLY use the Update Correlation action.

Let’s imagine we had an Account Correlation user level that was limited to that function.

• Who at your business would you designate to correlate accounts?
• How many people would be assigned to that user level?
• Would you want someone like the Source Owner to approve their correlation decisions?
• Is that the ONLY action you’d want them to do?

CC @grady_slane

@angelo_mekenkamp

4: If I want to correlated an account to an identity with displayName “Billy Bob Baker”, searching for “Bob Baker” does not show the result. Shouldn’t the search be done based on “contains” rather than “starts with” for more user friendly search? Same holds for when someone has a double lastname (maiden name?) and you search for the second one.

I agree that we should support contains searching on Identity Name. We were limited by time available to complete this first iteration. I expect us to get there in the long-term.

@angelo_mekenkamp

5: We can’t filter or sort the accounts on status. Why not? I can imagine it being used. either to get a clear overview or perhaps to get the number of results after filtering.

I agree that we should support sorting and filtering on on Status. We were limited by time available to complete this first iteration. I expect us to get there in the long-term.

@angelo_mekenkamp

6: Why show us the identity state of the account by default rather than the identity lifecycle state? The latter gives more information than the former after all.

Lifecycle State was prioritized as the default with Identity State available but hidden in our desired design. We then encountered a technical trade-off. We’re able to sort and filter on Identity State but not on Lifecycle State via the account list endpoint. I thought admins would find that it’s more useful to work with a column that can be sorted and filtered.

Identity State supports sorting now and will be added to filters soon.

Additionally, we have another project in progress to remember column selections. Then you’ll be able to decide what columns you want to see as the default!

CC @AndrewFerguson @ben_coble

Thanks for this great line of questioning, @angelo_mekenkamp !

[kirby_fitch]

@vguleria

Looks like a great feature although i completely agree with @angelo_mekenkamp’s remarks.

Thanks for this!

@angelo_mekenkamp asked a lot of the questions I had anticipated. Take a review through the answers and let me know your opinions!

@vguleria

In addition to that when i see the account management page, it also displays authoritative source accounts and for all accounts (authoritative or non-authoritative source ) i think remove account action button always pops up irrespective of the features associated to that source. So in case some one remove the account from authoritative source, that may result in deletion of the identity itself, so do not think that it will be ideal.

You’re correct that removing an authoritative account would result in identity deletion. This is something we’ve allowed in the Identity Management UI for years without negative feedback. Remove is a much-used feature and I anticipated administrators would want it available in Account Management.

@vguleria

Also for authoritative source accounts too the update correlation button is appearing, i am just thinking what will be happen if admin or source admin try to correlate authoritative source’s account to another identity. And what happens when the aggregation happens for this authoritative source, something to be checked i believe ?

I documented how this works in the main post. See the section on About Update Correlation.

@vguleria

But in general this feature looks great and really handy when comes to correlating the non authoritative source accounts.

Thank you. We’re open to enhancements and adjustments as people use it and determine what works and what doesn’t!

[kej01s (Kathryn Sanders)]

I like the new feature! It’s great that you can correlate an account with the UI, and I also like that you can disable uncorrelated accounts.

Will we be able to export a report from this page? The uncorrelated accounts report on the source screens does not contain enough information, and I would like to be able to bulk up the action items in the source.

[kirby_fitch]

@kej01s

Will we be able to export a report from this page? The uncorrelated accounts report on the source screens does not contain enough information, and I would like to be able to bulk up the action items in the source.

Thanks, @kej01s !

We’ve been considering putting accounts into Search so that you could run an export like that.

• How would you use that?
• What attributes would you export?

What do you mean by “bulk up the action items in the source”?

[kej01s (Kathryn Sanders)]

Let’s say I have 50 uncorrelated AD accounts. I want to be able to run a script against AD to disable them all instead of clicking each one individually in the UI.

I would like the account name, status, OU (for AD), description, and any other identifying attributes. It would also be nice to see any entitlements assigned to that uncorrelated account.

[kirby_fitch]

@kej01s — thanks for this. Would you use Disable / Enable in bulk on this UI if it were supported? Do you have enough filtering tools to narrow it down to the 50 you want to disable?

[kej01s (Kathryn Sanders)]

Could there be a checkbox and you could select the accounts you would want to disable?

AD is a little different because we move them to a different OU when we disable them, which isn’t a function I expect to see in this UI.

[kirby_fitch]

@kej01s

Could there be a checkbox and you could select the accounts you would want to disable?

We’d need to add support for disabling 1-250 accounts at a time to our endpoints but it’s feasible. If there are others in the community reading this that would desire bulk disables, please like this comment!

@kej01s

AD is a little different because we move them to a different OU when we disable them, which isn’t a function I expect to see in this UI.

If you could:

• Trigger a workflow when accounts are disabled.
• Move accounts into different OUs with workflow actions.

Do you think Workflow would be a suitable way to address this use case?

[kej01s (Kathryn Sanders)]

Typically, we do this as part of a Before Provisioning rule as part of the Lifecycle change to inactive. We could look into moving this to a Workflow.

[jroozeboom (Jill Roozeboom)]

Thanks for all of the great detail Kirby! I especially like that you added the ability to source by Source on the Identity > Account screens. This was a very missed feature of mine! I do have a couple of comments / questions:

1. Human Accounts - you mention that human accounts are accounts that are correlated to identities. We have clients who have non-human identities because of other functional reasons that I will not detail here.

   • Will there be a way to categorize authoritative sources as Human or Non-Human so their accounts are properly categorized / limit confusion?

   • Are there plans to update the request center in ISC to where Non-Human accounts do not need to be attached to an identity? If yes, will the ServiceNow integration support this? Currently you have to have a ServiceNow account correlated to an identity to be able to request for it via the ServiceNow integration.

2. Just to be certain, the Remove account option still just removes it from ISC and does not perform a Delete Account operation, correct? I know you were working on providing the Delete Account admin operation in the UI and I just wanted to be sure what Remove account does with the new interface. If this is all true, is the Delete Account admin feature still forthcoming?

3. I agree that exporting account details is valuable. We wrote a Postman script to do this for us, but it would be helpful to have this capability in the UI. What was missing for us on the csv extract of accounts on a source was whether an account was disabled or not, and the identity that it was tied to (or not tied to, if uncorrelated).

4. I could see the use case for doing bulk disable by an admin, especially for uncorrelated accounts.

5. If I remember correctly, are you also adding capability to mark an uncorrelated account as “reviewed” (or similar) so admins could quickly tell what hasn’t already been looked at?

6. This might be a little off topic, but has SP considered putting the filters under the header rows throughout the product so a person can always see what is being filtered on and easily modify the filter, instead of a pop-out window?

[eabedrapo1 (Elisa Abedrapo)]

@kirby_fitch

We’ve been considering putting accounts into Search so that you could run an export like that.

• How would you use that?
• What attributes would you export?

Hi Kirby,

Unfortunately for this case one size does NOT fit all. When we had to correlate accounts in the past, we downloaded the source CSV and using VLOOKUP in Excel we were able to correlate using custom attributes that our business implemented long time ago, so a fixed list of attributes that may work for one organization may not work for another one. Actually, different sources in the same org may have totally different schema as well.

I feel like having a dynamic column chooser based on the attributes from the displayed source(s) would be very helpful, so it’s up to the user to pick the attributes required to identify a proper correlation.

If a dynamic chooser is too complex to implement, maybe we could define “searchable” account attributes via API, similar to setting identity attributes via put-identity-attribute | SailPoint Developer Community and have those “searchable” account attributes available in the chooser for search and export.

[rauls (Raul Sabau)]

Hey @kirby_fitch ,
Love this new feature! We were actually struggling a bit with the correlation topic in general, and in particular with Uncorrelated accounts and access reviews → it looks like this will solve some of those issues.

One question I do have, is this going to help in any way with Access Requests failing for Identities with multiple accounts in the same source?

[kirby_fitch]

Thanks for the great questons, @jroozeboom !

@jroozeboom

• Human Accounts - you mention that human accounts are accounts that are correlated to identities. We have clients who have non-human identities because of other functional reasons that I will not detail here.

Yes, we think there will be a little growing pain here as we progress into a dedicated support model for non-human accounts.

@jroozeboom

• Will there be a way to categorize authoritative sources as Human or Non-Human so their accounts are properly categorized / limit confusion?

We’re headed in this direction. Although, it might not work exactly how you’ve characterized it.

@jroozeboom

• Are there plans to update the request center in ISC to where Non-Human accounts do not need to be attached to an identity? If yes, will the ServiceNow integration support this? Currently you have to have a ServiceNow account correlated to an identity to be able to request for it via the ServiceNow integration.

It’s too early to speculate on potential impacts to the Request Center.

@jroozeboom

• Just to be certain, the Remove account option still just removes it from ISC and does not perform a Delete Account operation, correct? I know you were working on providing the Delete Account admin operation in the UI and I just wanted to be sure what Remove account does with the new interface. If this is all true, is the Delete Account admin feature still forthcoming?

Yes, Remove deletes the account in ISC but leaves it intact on the source. The account would be re-created assuming it still exists on the source during the next aggregation. We’ll add a Delete action at some point that will delete it from ISC and source.

We think Delete might require an approval process. What do you think? How would that work?

@jroozeboom

• I agree that exporting account details is valuable. We wrote a Postman script to do this for us, but it would be helpful to have this capability in the UI. What was missing for us on the csv extract of accounts on a source was whether an account was disabled or not, and the identity that it was tied to (or not tied to, if uncorrelated).

Thanks, this is good to know.

@jroozeboom

• I could see the use case for doing bulk disable by an admin, especially for uncorrelated accounts.

It seems like this one is trending a bit. We’ll consider prioritizing it if we keep hearing it!

@jroozeboom

• If I remember correctly, are you also adding capability to mark an uncorrelated account as “reviewed” (or similar) so admins could quickly tell what hasn’t already been looked at?

Our goal is to help customers get their uncorrelated count to zero with ease. We see these categories of accounts in uncorrelated: 1) human accounts that could be correlated to an existing identity, 2) human accounts for which there is no existing identity, and 3) non-human accounts.

#2 occurs when businesses take on identities for which there’s no reference in their authoritative source / HCM.

Tackling the problem could involve something like a Reviewed status indicating “won’t ever be correlated,” or an option to create new identities as-needed.

Did I get the problem and those options right?

@jroozeboom

• This might be a little off topic, but has SP considered putting the filters under the header rows throughout the product so a person can always see what is being filtered on and easily modify the filter, instead of a pop-out window?

I’ll leave this question for our UX Designer, @willcashman.

[kirby_fitch]

@eabedrapo1

I feel like having a dynamic column chooser based on the attributes from the displayed source(s) would be very helpful, so it’s up to the user to pick the attributes required to identify a proper correlation.

What if we brought you the Update Correlation feature on a given source’s accounts list? Additionally, on the source-specific account list, you could choose account attributes specific to that source. Would that meet the need?

[kirby_fitch]

@rauls

One question I do have, is this going to help in any way with Access Requests failing for Identities with multiple accounts in the same source?

I don’t think it will. Another Product Manager, @jennifer_mitchell, is giving some dedicated thought to that. I’ve tagged her here to provide insight she’s able to offer.