Lifecycle state wont disable the accounts in the sources configured

Identity Security Cloud (ISC) ISC Discussion and Questions
, ,
1

hi everyone, im trying to create a new lifecycle state that will disable the accounts under the sources as below:

image
image1546×447 13.3 KB

however, when a user is in this lifecycle state, the account under okta (for example) is still active. how to solve this issue?

the client does not subscribe to workflow so that option is out of the window unfortunately

2

@fayolaph Are you seeing any errors during provisioning?

3

hi Manish, im not seeing anything, but i did see some Remove Entitlements Failed events under the identity for okta, in which the error details:"
[“sailpoint.connector.ConnectorException: [ ConnectorException ] \n [ Error details ] Failed to update the account. [ ConnectorException ] \n [ Error details ] Request execution failed. HTTP Error code : 403, Okta Error code : E0000023, errorSummary : Operation failed because user profile is mastered under another system, errorCauses:.”

4

Can you check which entitlement it is trying to remove?

5

its an okta user group

6

Are you assigning the user group through any role or access profile?

7

its through access profile

8

looks like the Okta user is mastered from different source like Active Directory, hence it couldn’t be processed by SailPoint.

9

if i disable the account on the master source, will it also disable okta?

10

Yes, if the Okta integration with that master source is configured to do so.

11

okay noted. one of the user was set as Okta to be the provider. the account was disabled, but when i reactivated the user back, the Okta account wont be enabled with the error saying:
[“sailpoint.connector.ConnectorException: [ ConnectorException ] \n [ Error details ] Failed to update the account. [ InvalidRequestException ] \n [ Error details ] Request execution failed. HTTP Error code : 400, Okta Error code : E0000001, errorSummary : Api validation failed: login, errorCauses:[{errorSummary\u003dlogin: An object with this field already exists in the current organization}].”]

any idea why this happens? and is it an error from ISC side?

12

as per the error message, it seems that the login name is not unique and already exists for another user with the same name/email ID. Could you try with a different unique user?

13

This is a unique user. I was just trying to reactivate the user from ISC to Okta as the user was disabled before :frowning:

Best regards,
Fayola

14

@fayolaph -

You’re hitting Okta error E0000023 (403): “Operation failed because user profile is mastered under another system.”
In simple words your Okta User is sourced (mastered) by AD/HR/another app, so any call that Okta interprets as a profile update is blocked. During “remove entitlement” from SailPoint ISC, your connector is likely attempting (or bundling) a user update along with the entitlement change → Okta rejects it.

If AD/HR is the Profile Source (Okta is NOT master), In that case even Enable/Disable (Activate/Deactivate user): :cross_mark: Blocked (E0000023). Do it in the mastering system (e.g., disable in AD/HR), let Okta import the change.

Let me know if you have any further queries.

15

okay noted. if say i want to reactivate the Okta account back, does it also have to go through AD first?

16

@fayolaph - Yes it must be go through AD first , If AD is the User Profile source in OKTA. In simple words, If OKTA users are mastered through AD then all the operation like enable/disable/modification everything should go through AD first.

17

Do you happen to know why ISC was throwing an error as above when i tried to reactivate the Okta account back?

Best regards,
Fayola

18

@fayolaph -
You’re getting HTTP 400 · E0000001 · “Api validation failed: login … already exists”.
In Okta, the login (username) must be unique within the org. The create from SailPoint ISC is colliding with an existing Okta user (active, suspended, or even deactivated—but not permanently deleted).
Refer the below Okta doc for detailed explanation -

19

but the issue is that, this is an Enable event, not create event. im just trying to reenable the account in Okta through ISC. this is an Okta-mastered account by the way not AD

20

[“sailpoint.connector.ConnectorException: [ ConnectorException ] \n [ Error details ] Failed to update the account. [ InvalidRequestException ] \n [ Error details ] Request execution failed. HTTP Error code : 400, Okta Error code : E0000001, errorSummary : Api validation failed: login, errorCauses:[{errorSummary\u003dlogin: An object with this field already exists in the current organization}].”]

For this one I usually find the account I am looking for in the uncorrelated accounts. They just need to be linked to the correct ID.