Troubleshooting

If you encounter any of the following issues or errors, SailPoint recommends that you follow the guidance provided below to resolve the error before contacting SailPoint Support.

For issues or errors that are not addressed in this connector guide, refer to the following resources for troubleshooting information:

Important

Add a list of retryable error messages to the attributes map of the source configuration. The value must be specified as a list or array even when only a single error string is provided.

Provisioning Retry Errors

Note

For more information on SailPoint's REST APIs, refer to Best Practices: REST API Authentication and REST API - Update Source (Partial) in the SailPoint Developer Community.

SailPoint connectors that support provisioning operations have the ability to retry a failed operation based on configurable error messages.

The retryableErrors entry in the connector configuration is a list of strings that the connector searches for in the error message received from the managed source. If any of the configured error strings are found in the error message, the connector will attempt to retry the provisioning operation.

Add a list of retryable error messages to the attributes map of the source configuration. The value must be specified as a list or array even when only a single error string is provided. If the error message contains one of the specified strings, the connector will initiate a retry attempt. However, if the configured error string is not present in the error message, the connector will consider the operation as failed and will not attempt a retry.

Add the following entry in the source XML using the SailPoint REST APIs:

For example,

Use the SailPoint API by sending a PATCH request to the /v3/sources/{id} endpoint:

PATCH https://{orgName}.api.identitynow.com/v3/sources/:id

In the body of the PATCH, enter the retryable errors as follows:

[
    {
        "op": "add",
        "path": "/connectorAttributes/retryableErrors",
        "value": [
            "<error_message_1>",
            "<error_message_2>"
        ]
    }
]

Note

Error messages containing very specific information about date/time, sequence ID and so on must be avoided. Error codes or error message substrings would be good candidates for inclusion.

Aggregation Retry Errors

Aggregation retries can be set up for each source by configuring the aggregationRetryErrors attribute under the connectorAttributes section.

Send a PATCH request to the /v3/sources/{id} endpoint:

PATCH https://{orgName}.api.identitynow.com/v3/sources/:id

In the body of the PATCH, enter the aggregationRetryErrors as follows:

{
    "op": "add",
    "path": "/connectorAttributes/aggregationRetryErrors",
    "value": ["Connection reset"]
}

In addition to specifying the aggregation retry errors, you can also configure the following options:

retryWaitTime

A string specifying the amount of time (in milliseconds) to wait before attempting a retry. The default value is 5000 milliseconds (5 seconds).

In the body of the PATCH, enter the retryWaitTime as follows:

{
    "op": "add",
    "path": "/connectorAttributes/retryWaitTime",
    "value": "5000"
}

maxRetryCount

A string defining the maximum number of retry attempts that will be performed. The default value is 3.

In the body of the PATCH, enter the maxRetryCount as follows:

{
    "op": "add",
    "path": "/connectorAttributes/maxRetryCount",
    "value": "3"
}

Issues in Delta Aggregation

The following are various scenarios where data is not populated in Delta Aggregation:

Roles assigned to an account from API are not populated in delta aggregation.

Sometimes applications that are removed from users are not aggregated in account delta aggregation.

Resolution - Perform full account aggregation task.
Sometimes groups that are deleted from the managed system are not captured in account delta aggregation.

Resolution - Perform full group aggregation to refresh entitlements.
For an account created with only the default group Everyone event system logs are not captured.

Resolution - To see the default group assigned to account, perform a full account aggregation or create account with a different group so that in delta aggregation for account, both groups details (default and the other group) are aggregated.
If the HELP_DESK_ADMIN role is removed from a user on the managed system, sometimes after delta aggregation groupTargetHelpDeskAdminRole is not removed.
If groupTarget is removed from user HELP_DESK_ADMIN role, sometimes changes are not reflected after delta aggregation

Resolution - Perform full account aggregation task.
If APP_ADMIN role is removed from a user on the managed system, sometimes after delta aggregation applicationsManagedByRole is not removed.
If applicationsManagedByRole is removed from user APP_ADMIN role, sometimes changes are not reflected after delta aggregation.

Resolution - Perform full account aggregation task.

Delta aggregation processes account deletes regardless of Detect Deleted

Delta aggregation processes account deletes even when Detect Deleted is not enabled.

Resolution - As a workaround, add the following entry to the source XML using the REST APIs:

[
  {
    "op": "add",
    "path": "/connectorAttributes/accountFilterAttribute",
    "value": "true"
  }
]

Note

For more information on SailPoint's REST APIs, refer to Best Practices: REST API Authentication and REST API - Update Source (Partial) in the SailPoint Developer Community.

Unlocked Okta Account Displays Incorrect Status

For Unlocked Okta accounts from SailPoint, the account details might not display the correct status. This occurs when the managed account refresh action only affects the status of the account in SailPoint. Account details are not changed and status is one of the account attributes.

Resolution - To get the correct account details and value of the Account status, then execute the account aggregation task.

Create Account Fails for an Account Assigned to the 'Everyone' Group

By default, on the Okta managed system the group Everyone gets assigned to every account created. Create account fails with following error message displayed:

sailpoint.connector.ConnectorException: [ConnectorException] [Error details] Request execution failed. HTTP Error code: 501, Okta Error code: E0000060, errorSummary: Unsupported operation., errorCauses:[].

Resolution - While performing create account with Manage user access, select a group type other than Everyone.

Account Preview does not work/displays any data on Okta application page

Resolution - To verify Okta accounts, run the account aggregation task instead of Account Preview. For more information on best practices of Okta account aggregation, refer to Aggregation Best Practices.

While performing Account Aggregation warnings are displayed in the logs

While performing account aggregation the following warnings are displayed in the logs:

019-04-18 18:43:25,708 WARN Thread-743 openconnector.connector.okta.OktaConnector:5425 - API rate limit exceeded for endpoint, Retrying the failed request now
2019-04-18 18:43:25,709 WARN Thread-742 openconnector.connector.okta.OktaConnector:5425 - API rate limit exceeded for endpoint, Retrying the failed request now

Resolution - You may ignore the warning messages. But to improve Okta aggregation performance, increase the Okta API rate limit.

While creating or updating the primary email address of Okta user, it updates their Username (login) as the same email address. Okta has a feature of self-service registration policy. When SELF_SERVICE_REGISTRATION is enabled on Okta managed system, Okta enforces uniqueness for all primary email addresses and automatically uses that email address as the end user's username (login) and primary email address.

Resolution - Disable SELF_SERVICE_REGISTRATION in Okta managed system. For more information contact Okta Customer Support.