entitlementThresholdValue limit exceeded

[Paul_Meyer]

For an full access recon job, the following error is encountered:

entitlementThresholdValue limit exceeded. No changes has been imported from Recon.

I cannot find any reference to "entitlementThresholdValue" in product documentation.

Any ideas where this setting should be configured?

[sahil]

This config can either be defined under STATUS_THRESHOLD_CONFIG parameter or statusAndThresholdConfig variable specified in the ImportAccountEntJSON parameters.

Below is a sample of the config for reference and you can find it in the documentation by entThresholdValue keyword

{
"statusAndThresholdConfig": {
"accountThresholdValue": 100,
"inactivateAccountsNotInFile": true,
"statusColumn": "customproperty30",
"activeStatus": [
"ENABLE",
"PROVISIONED"
],
"inactivateEntsNotInFeed": true,
"entThresholdValue": {
"entType": {
"Group": {
"ent": 100
},
"Role": {
"ent": 100
}
}
}
}
}

[Paul_Meyer]

@sahil 

Using the following STATUS_THRESHOLD_CONFIG, with silly numbers, still gives the same error:

{
	"statusAndThresholdConfig": {
		"accountThresholdValue": 10000000,
		"entThresholdValue": {
			"entType": {
				"Organizations": {
					"ent": 10000000
				},
				"Roles": {
					"ent": 10000000
				}
			}
		},
		"inactivateAccountsNotInFile": true,
		"statusColumn": "customproperty10",
		"activeStatus": [
			"true"
		],
		"inactivateEntsNotInFeed": true,
		"correlateInactiveAccounts": true,
		"deleteAccEntForActiveAccounts": false,
		"deleteLinks": true
	}
}

Managed to find some log entries referring to "entTypeThreshold". Seems like there is a disconnect between the setting names used in the config and what the associated name is actually used in logs.

[sahil]

Can you share the complete JSON you are using if its still not working and also the job log if you can. Please update ConfigJSON param in the REST connection with value {"showLogs":true} before you run the job.

[Paul_Meyer]

@sahil 

Configs attached.

[Paul_Meyer]

According to the log file, for each of the entitlements there is no status updates to be done, yet the access recon job end state is "Failed". If there is nothing to update, why would the job be in a failed status?

2023-05-18/14:59:07.084 [{}] [quartzScheduler_Worker-3] DEBUG services.ImportUtilityService - Start updateEntitlementStatus
2023-05-18/14:59:07.090 [{}] [quartzScheduler_Worker-3] DEBUG services.ImportUtilityService - entTypeThreshold for entType Duties: 10000000
2023-05-18/14:59:07.090 [{}] [quartzScheduler_Worker-3] DEBUG services.ImportUtilityService - Query to get Entitlements not Inserted/Updated in this job:
SELECT EV.ENTITLEMENT_VALUEKEY AS ENTITLEMENT_VALUEKEY FROM ENTITLEMENT_VALUES EV WHERE
EV.ENTITLEMENTTYPEKEY = 244 AND (EV.JOB_ID<>233948 OR EV.JOB_ID IS NULL)
AND EV.STATUS<>2

2023-05-18/14:59:07.106 [{}] [quartzScheduler_Worker-3] DEBUG services.ImportUtilityService - Entitlements to be inactivated: 0
2023-05-18/14:59:07.106 [{}] [quartzScheduler_Worker-3] DEBUG services.ImportUtilityService - Cannot inactivate Entitlements as the no of entitlements not in feed is either zero or exceed entTypeThreshold

[rushikeshvartak]

How many ents in app ?

[Paul_Meyer]

@rushikeshvartak 

• 30 "Organizations"
• 659 "Roles"
• 17141 "Duties"
• 203092 "Privileges"

[Paul_Meyer]

@rushikeshvartak @sahil 

Any recommendations or would you recommend a FD support request?

[rushikeshvartak]

203000 try this limit

[Paul_Meyer]

Same error, failed job:

[sahil]

@Paul_Meyer Can you confirm if this is still an issue or was this resolved.

[Paul_Meyer]

@sahil 

Still an open issue (FD #1632967). The issue is when you enable inactivateEntsNotInFeed. If there is nothing to do, ie no entitlements to inactivate, the jobs fails.

2023-06-02/16:16:31.565 [{}] [quartzScheduler_Worker-2] DEBUG services.ImportUtilityService - Entitlements to be inactivated: 0

2023-06-02/16:16:31.565 [{}] [quartzScheduler_Worker-2] DEBUG services.ImportUtilityService - Cannot inactivate Entitlements as the no of entitlements not in feed is either zero or exceed entTypeThreshold

My thoughts are that if there is nothing to inactivate, it is a valid use case. If there is nothing to inactivate, there is nothing to inactivate, the job should not fail. There is probably an if statement that needs adjusting...

[sahil]

It does seem that way. Looks like the support team is already working on it and should be able to help with a solution. Once you get a resolution it would be helpful if you could also update the same here so the others could also benefit from it.

[Paul_Meyer]

According to Support, it is fixed in v2021.0.4, as connector fix CONN-7863.

Only reference I can find to CONN-7863 is in the release notes of v2022.0.1 as:

CONN-7863 The CyberArk connector displays the correct status of the import job in the Job Control Panel when there are no entitlements to deactivate in EIC.

I can only assume that the fix has been applied to the base rest connector, as the CyberArk connector is a SCIM based rest connector.

Since v5.5SP5 seems to no longer be supported, a fix will not be provided. We'll have to continue waiting for a migration/upgrade. 1+ year and counting...

[rushikeshvartak]

What if configuration removed

[Paul_Meyer]

From test results, the access recon job does set the entitlement status (Inactive or "SUSPENDED FROM IMPORT SERVICE"), depending on true/false config of inactivateEntsNotInFeed. When set to true, and the job has no entitlements to be set to Inactive, the job completes but the job status is "Failed" with the warning as posted above.