# 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:

- [SailPoint Identity Services Documentation](<https://documentation.sailpoint.com/saas/help/index.html>)
- [SailPoint Support Knowledge Base](<https://support.sailpoint.com/csm?id=kb_view2&amp;kb_id=05ff44289f011200550bf7b6077fcfa3>)
- [SailPoint Developer Community](<https://developer.sailpoint.com/>)

> [!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](<https://developer.sailpoint.com/docs/api/authentication/>) and [REST API - Update Source (Partial)](<https://developer.sailpoint.com/docs/api/update-source-v-1/>) 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:

```json
[
    {
        "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:

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

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

> [!NOTE]
>
> **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:
>
> ```json
> {
>     "op": "add",
>     "path": "/connectorAttributes/retryWaitTime",
>     "value": "5000"
> }
> ```

> [!NOTE]
>
> **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:
>
> ```json
> {
>     "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:

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

> [!NOTE]
>
> For more information on SailPoint's REST APIs, refer to [Best Practices: REST API Authentication](<https://developer.sailpoint.com/docs/api/authentication/>) and [REST API - Update Source (Partial)](<https://developer.sailpoint.com/docs/api/update-source-v-1>) 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:

```text
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](<https://documentation.sailpoint.com/connectors/okta/va/help/aggregation_best_practices.html>).

## While performing Account Aggregation warnings are displayed in the logs

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

```text
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 primary email address of Okta user, it updates Username (login) as same email address

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.

## Account Aggregation fails with an error message

- The following error message displays:

  ```text
  Exception during aggregation of Object Type account on Application Okta. Reason: [ InvalidConfigurationException ] [ Possible suggestions ] Ensure the resource mentioned in the Okta URL is correct. The URL resource is /api/v1/groups/<groupID>/users?limit=10000 [ Error details ] Request execution failed. HTTP Error code : 405, Okta Error code : E0000022, errorSummary : The endpoint does not support the provided HTTP method, errorCauses:[]
  ```

  **Resolution** - Due to the HTTP 405 response code from Okta instance, ensure that the Okta URL is correct and able to access the Okta resources.

  This issue occurs due to the vanity Okta URL (customized). Verify the correct settings with Okta team and allow the API response.
- While performing account aggregation with the **OAuth 2.0** authentication type, aggregation fails with the following error message:

  ```text
  openconnector.ConnectorException: [ ConnectorException ]
  [ Error details ] Request execution failed. HTTP Error code : 403, Okta Error code : E0000005, errorSummary : Invalid session, errorCauses:[].
  ```

  **Resolution** - If the `type_name` and `type_displayName` attributes are configured in the account schema, delete these attributes and perform the account aggregation.

  > **Note**
  >
  > Aggregation of `type_name` and `type_displayName` is only supported with the **API Token** authentication type.
- The following error message displays:

  ```text
  Exception during aggregation of Object Type account on Application Okta. Reason: Unable to create iterator sailpoint.connector.InsufficientPermissionException: [InsufficientPermissionException]
  [Possible suggestions] Furnish appropriate permission to the Okta API token owner.
  [Error details] Insufficient privileges detected. HTTP Error code: 401, Okta Error code: E0000015, errorSummary: You do not have permission to access the feature you are requesting
  ```

  **Resolution**:

  - Ensure that the correct permissions or roles are assigned to the API Owner (the user whose API token is used in the Okta application). The API Owner must have SUPER ADMIN roles assigned for aggregation.

    > **Note**
    >
    > To aggregate Okta roles, SUPER\_ADMIN role is required.
  - The **List Users with Search** parameter supports pagination (to a maximum of 50000 results).
  - Ensure you correctly set the **List Users with Search** attribute.

## Test Connection failures with OAuth 2.0 authentication

While performing a test connection, it fails with following errors:

- The following error message displays:

  ```text
  [ InvalidRequestException ] [ Error details ] Request execution failed. HTTP Error code : 400, Okta Error code : invalid_client, errorSummary : Invalid value for 'client_id' parameter., errorCauses:[].
  ```

  **Resolution** - Ensure that the **Issuer** is correct and it is the same as the **Client ID** of the service application created in Okta.
- The following error message displays:

  ```text
  [ ConnectorException ] [ Error details ] Request execution failed. HTTP Error code : 401, Okta Error code : invalid_client, errorSummary : The subject claim for client_assertion is not a valid client_id., errorCauses:[].
  ```

  **Resolution** - Ensure that the **Subject** is correct and it is the same as the **Client ID** of the service application created in Okta.
- The following error message displays:

  ```text
  [ ConnectorException ] [ Error details ] Request execution failed. HTTP Error code : 401, Okta Error code : invalid_client, errorSummary : The audience claim for client_assertion must be the endpoint invoked for the request., errorCauses:[].
  ```

  **Resolution** - Ensure that the URL provided in **Audience** is correct for authorization.

## Operations failed with an error message

While performing any operation with OAuth 2.0 Authentication Type, it fails with the following error message:

```text
[ ConnectorException ] [ Error details ] Request execution failed. HTTP Error code : 403, Okta Error code : , errorSummary : , errorCauses:[].
```

**Resolution** - Ensure that the appropriate scopes are provided to the Okta service application and the same are provided in the `scope` configuration parameter.

## Error while removing APP Target, App Instance Target, or Group Target from a User

```text
[ InvalidConfigurationException ] [ Possible suggestions ] Ensure the resource mentioned in the Okta URL is correct. The URL resource is //api/v1/users/00u1jw6jffvr3GG395d7/roles/IFIFAX2BIRGUSTQ/targets/catalog/apps/hellofax [ Error details ] Request execution failed. HTTP Error code : 405, Okta Error code : E0000091, errorSummary : The provided role type was not the same as required role type., errorCauses:[].
[ InvalidConfigurationException ] [ Possible suggestions ] Ensure the resource mentioned in the Okta URL is correct. The URL resource is //api/v1/users/00u2on1gcpgu4gIc55d7/roles/JBCUYUC7IRCVGS27IFCE2SKO/targets/groups/00g2dyy3zoPvqGkvI5d7 [ Error details ] Request execution failed. HTTP Error code : 405, Okta Error code : E0000091, errorSummary : The provided role type was not the same as required role type., errorCauses:[].
```

**Resolution** - Do not remove last app target or app instance target. Instead, directly remove the `APP_ADMIN` role or the `HELP_DESK_ADMIN` role from the user.

## Add Entitlement Failed is populated in the activity log while creating or updating APP Target, App Instance Target, or Group Target to User

**Resolution** - Ensure the following:

- While assigning APP target and App Instance Target to the user, APP\_ADMIN role is not in the request.
- While assigning Group Target to the user, HELP\_DESK\_ADMIN role is not in the request.

## The Update Account attribute failed during the Enable operation

The following error message is displayed while modifying the account attribute during the Enable operation:

```text
Request execution failed. HTTP Error code : 409, Okta Error code : E0000112, errorSummary : Cannot update this user because they are still being activated. Please try again in a few minutes., errorCauses:[].
```

**Resolution** - Add the following entry to the source XML using the REST APIs:

```text
Patch https://{orgName}.api.identitynow.com/v2025/sources/{OktasourceID}
```

In the body of the Patch, use the form-data as follows:

```json
{
  "op": "add",
  "path": "/connectorAttributes/connector_provisioningTimeout",
  "value": "20000"
}
```

> [!NOTE]
>
> For more information on SailPoint's REST APIs, refer to [Best Practices: REST API Authentication](<https://developer.sailpoint.com/docs/api/authentication/>) and [REST API - Update Source (Partial)](<https://developer.sailpoint.com/docs/api/update-source-v-1>) in the SailPoint Developer Community.

## User status is not being updated after the Enable or Disable operation

Due to slow Okta API response times, there may be a delay in receiving the correct user status after performing the Enable or Disable operation.

**Resolution** - Add the following entry to the source XML using the REST APIs:

```text
Patch https://{orgName}.api.identitynow.com/v2025/sources/{OktasourceID}
```

In the body of the Patch, use the form-data as follows:

```json
{
  "op": "add",
  "path": "/connectorAttributes/connector_provisioningTimeout",
  "value": "20000"
}
```

> [!NOTE]
>
> For more information on SailPoint's REST APIs, refer to [Best Practices: REST API Authentication](<https://developer.sailpoint.com/docs/api/authentication/>) and [REST API - Update Source (Partial)](<https://developer.sailpoint.com/docs/api/update-source-v-1>) in the SailPoint Developer Community.

## Test connection failing with error message

When performing a test connection, it fails and the following error displays:

```text
Exception: sailpoint.connector.ConnectionFailedException: [ ConnectionFailedException ] [ Possible suggestions ] a) Make sure Okta instance is reachable. b) Make sure there is a smooth connectivity between Identity Server and Okta instance. [ Error details ] Failed to connect to the Okta instance.
```

If there is a firewall between SailPoint and the Okta tenant, it is likely causing the blocking the connection.

**Resolution** - Verify if there are any firewall rules present in your environment that are blocking the Okta URL, FQDN, or IP address. If the rules are blocking this communication, unblock them.

## Custom role data for users is not getting aggregated correctly

The Okta source supports the aggregation of custom roles that are assigned directly to the accounts only.

**Resolution**: Before aggregation, ensure that custom roles for the users and groups are assigned directly.

For example, let us assume that for the user John, John Test Role is a custom role. The John Test Role added for the user John is a direct assignment.

But, if John Test Role is added to the Custom\_Group, and Custom\_Group is then assigned to the user John. Then, the John Test Role will not be a direct assignment for the user John.

## Account Aggregation Fails with a Connection Pool Shut Down Error

Account aggregation fails with the following error message:

```text
Unable to create iterator sailpoint.connector.ConnectorException: java.lang.IllegalStateException: Connection pool shut down
```

**Resolution**: Removing the Caching Parameters from the source configuration.

```text
<entry key="appCacheThreadSize" value="4"/>
<entry key="applicationSkinnyUsers" value="true"/>
<entry key="enableMultiThreadedCacheCreationApps" value="true"/>
<entry key="enableMultiThreadedCacheCreationGroups" value="true"/>
<entry key="groupCacheThreadSize" value="4"/>
<entry key="groupSkinnyUsers" value="true"/>
```

Re-run the Account Aggregation.
