New Capability: Account Management

[jroozeboom (Jill Roozeboom)]

@kirby_fitch

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?

Yes, this sounds like a good starting point!

[jroozeboom (Jill Roozeboom)]

@kirby_fitch

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?

Maybe the “option” to have approval or not. If an admin is smart enough they can do a delete in other ways without approval, and I don’t see this as different, but it is easier to do, so could have bigger impacts if they delete an account inadvertently. I would make sure that there is an event logged for sure, and pop up a warning or 2 telling them exactly what they are doing and asking if they are sure.

[jroozeboom (Jill Roozeboom)]

@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 know if this helps you any @rauls , but if you are using Role-Based Provisioning, they’ve improved this a little bit recently. https://community.sailpoint.com/t5/IdentityNow-Forum/Working-with-Multiple-Accounts-on-a-Source/m-p/250873 There is definitely a lot of room for improvement as it relates to multiple accounts per source, and it’s always a top conversation we have with our clients.

[rauls (Raul Sabau)]

Thanks @jroozeboom!
Will take a look, it’s good news that this will be handled for roles… any chance this could be available for Access Profiles - at least manual selection?
Or any way to have IDN at least reply with a mail “Which account did you mean?” I know I’m asking for the moon here, but I think there is a genuine need to solve this issue.

[Prashanth1812 (Prashanth Pullammagari)]

What attribute categorize an account is HUMAN and NON HUMAN and how?

[kirby_fitch]

We’ll provide a means to do that in the future.

[jennifer_mitchell]

Kirby is right - this feature doesn’t impact that behavior in request center.

The good news is that we have started work to address that concern. In fact, the ability to choose accounts during the request process has been built and tested by a limited set of customers. We are still prioritizing some additional work we need to do before we can make this generally available, so I can’t give you a precise timeline yet, but that is on our short list of work to be done.

[eabedrapo1 (Elisa Abedrapo)]

@kirby_fitch

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?

I think it would meet the need if the column chooser is available on that screen and the Export respect the columns we selected in case we still want to work offline and bulk update accounts via CSV uploads.

[chris4898 (Chris Berry)]

Are there any plans to make these API calls (beta/public-identities) publicly available?

[angelo_mekenkamp]

@jroozeboom

Maybe the “option” to have approval or not. If an admin is smart enough they can do a delete in other ways without approval

I agree with this part. There should be an action to delete an account with configurable approval flow and an action to delete an account without using that configured approval flow.

I can imagine us going to a lifecycle state and instead of saying “Disable the account to this source as soon as the identity reaches this lifecycle state” that we will say “Delete the account of this source as soon as the identity reaches this lifecycle state”. Right now as workaround we need to use a beforeprovisioning rule and ensure that we are enabling a disabled account or disabling an enabled account to trigger the rule and, under the right conditions such as lifecyclestate and whether or not the identity is considered managed in IdentityNow for JML, trigger deletion.

I also can imagine us creating a workflow where we want as action to always delete the account, or to request to delete the account, where we expect the approval flow (defined on the source level?) to be used.

I also can imagine access certification to be occuring where the certifier is not only able to say which entitlements to keep or remove, but also whether to disable/delete the account or not.

And similar, I can imagine admins or source owners to manually delete accounts where they do (not) want the approval flow to get triggered.

@kirby_fitch

Do you think this would be an appropriate revised authorization matrix for this UI?

I think so yes, where the existence of custom user levels would leave this discussion unnecessary as we would then probably stop using the default user levels and migrate to custom user levels. Although keep in mind that Source Sub-Admin should be Authorized only to see and perform these actions on accounts that are related to sources which the source sub-admin is associated with. So maybe it should be mentioned as Authorized* with the asterisks explaining it.

Thank you for being so active here @kirby_fitch!

[kirby_fitch]

@chris4898

Are there any plans to make these API calls (beta/public-identities) publicly available?

Hi @chris4898 -

Forgive me if I’m missing something but I don’t think Account Management uses public identities. However, this endpoint is available to you:

get-public-identities | SailPoint Developer Community

[kirby_fitch]

@angelo_mekenkamp

I agree with this part. There should be an action to delete an account with configurable approval flow and an action to delete an account without using that configured approval flow.

What would be a reasonable default configuration for a configurable approval flow?

@angelo_mekenkamp

I can imagine us going to a lifecycle state and instead of saying “Disable the account to this source as soon as the identity reaches this lifecycle state” that we will say “Delete the account of this source as soon as the identity reaches this lifecycle state”. Right now as workaround we need to use a beforeprovisioning rule and ensure that we are enabling a disabled account or disabling an enabled account to trigger the rule and, under the right conditions such as lifecyclestate and whether or not the identity is considered managed in IdentityNow for JML, trigger deletion.

Thanks, this is a reasonable expectation.

@angelo_mekenkamp

I also can imagine us creating a workflow where we want as action to always delete the account, or to request to delete the account, where we expect the approval flow (defined on the source level?) to be used.

Workflow already has a Delete Account action. It only works for accounts on DelimitedFile sources. We’re going to expand it to support all source types when we make our general enhancement for deleting accounts.

@angelo_mekenkamp

I also can imagine access certification to be occuring where the certifier is not only able to say which entitlements to keep or remove, but also whether to disable/delete the account or not.

Thanks, this is also a reasonable expectation. CC @SarahKhan

@angelo_mekenkamp

And similar, I can imagine admins or source owners to manually delete accounts where they do (not) want the approval flow to get triggered.

What user levels should be allowed to delete an account without approvals?

@kirby_fitch

Thank you for being so active here @kirby_fitch!

You’re welcome! One last new question for you:

We’re considering one or two new user levels:

1. An Account Manager that is authorized to manage human and non-human accounts.
2. A Human Account Manager that is authorized to manage human accounts and a Non-Human Account Manager that is authorized to manage non-human accounts.

Action	Account Manager	Human Account Manager	Non-Human Account Manager
Aggregate Account	Authorized	Authorized	Authorized
Disable Account	Authorized	Authorized	Authorized
Enable Account	Authorized	Authorized	Authorized
Remove Account	Authorized	Authorized	Authorized
Update Correlation	Authorized	Authorized	Authorized
Unlock Account	Authorized	Authorized	Authorized
Delete Account (No Approval)	Authorized	Authorized	Authorized

Would you use these user levels?

Is there value to having two separate user levels or is a sole Account Manager user level sufficient?

[angelo_mekenkamp]

@kirby_fitch

What would be a reasonable default configuration for a configurable approval flow?

One size fits nobody, so I would not expect such a default configuration to be defined by SailPoint. In the system settings you can define the default approval flow for entitlement requests yourself, if you choose to allow entitlement requests. If you want to offer a default configuration, I would suggest to put this default configuration here, such that admins can choose their own default configuration for the request account deletion process.

@kirby_fitch

Workflow already has a Delete Account action. It only works for accounts on DelimitedFile sources. We’re going to expand it to support all source types when we make our general enhancement for deleting accounts.

Yes we know this, but since it is not supporting direct connections, the most common connection, it is practically useless to us. It even gives the suggestion that this functionality already exists. I believe that the workflow team were not even aware of this limitation when they created the action initially, making the assumption that this functionality was already existing in full. We are definitely looking forward to this limitation to be removed.

@kirby_fitch

What user levels should be allowed to delete an account without approvals?

To me, this is one size fits nobody, which is another argument for the need of custom user levels. Same answer for your additional question.

I think we would need to be able to grant people actions like idn:accounts:read, perhaps through custom user levels. And this can be further limited by specifying specific segments of accounts. For example I only want to be able to see accounts from source X or only be able to accounts that are correlated to identities from country Y. This to ensure that we can enable local admins to perform tasks that they can’t do now, because we can only allow them to manage this if we allow them to manage it for too big a scope.

Hope this helps!

Kind regards,
Angelo

[jishnu_suresh]

Hi Kirby,

Thanks for this update. This new feature for account correlation through UI is very much helpful and easy to use!
A small feedback from myside, While filtering out uncorrelated account based on a source, It would be helpful if the overall uncorrelated accounts in each source can also be displayed from the UI.

[Crimson3708 (Alexander Hatcher)]

@kirby_fitch Howdy! Your earlier post on this noted that this may be rolling out to production as soon as May 20th. Has there been any updated timeframes for when this is rolling out?

We are eagerly awaiting this added functionality to manage uncorrelated identities.

[tozinga (Tori Ozinga)]

Hello @Crimson3708! We are beginning rollout to production for this feature tomorrow. Thanks for your patience!

[eabedrapo1 (Elisa Abedrapo)]

Looking forward to it! Using spreadsheet to fix uncorrelated accounts needs a lot of steps and I hope this upcoming feature help us to accelerate this effort a bit further.

That said, I still miss a lot of common attributes in the column chooser, especially “email” as the columns available on the current page don’t help much in identifying the identity we should correlate the account to.

Also, I’m missing a way to hide uncorrelated accounts that I want to ignore (e.g. computers that are set as “users” in the source and are still imported while I work with operations to fix them on the source). I could un-ignore them in the future when working on non-human accounts, but during the clean-up exercise they’re just noise.

[Crimson3708 (Alexander Hatcher)]

Good morning Tori Has there been any updates on when this should have hit all prod tenants? I haven’t seen this hit my tenant yet so I was curious.

[kirby_fitch]

Good points, @eabedrapo1

@eabedrapo1

That said, I still miss a lot of common attributes in the column chooser, especially “email” as the columns available on the current page don’t help much in identifying the identity we should correlate the account to.

You are able to update an account’s correlation while you’re looking at it in detail. That should give you a clear view of what you’re doing.

@eabedrapo1

Also, I’m missing a way to hide uncorrelated accounts that I want to ignore (e.g. computers that are set as “users” in the source and are still imported while I work with operations to fix them on the source). I could un-ignore them in the future when working on non-human accounts, but during the clean-up exercise they’re just noise.

Our next area of focus will be tools to mark uncorrelated accounts as non-human accounts. This should help you further shrink your uncorrelated account footprint.

There’s room for an “ignore” feature as well.

[kirby_fitch]

@Crimson3708

Good morning Tori Has there been any updates on when this should have hit all prod tenants? I haven’t seen this hit my tenant yet so I was curious.

We have rolled out to some production tenants so far. We’d like to wrap up production rollout by June 13th.