Troubleshooting

The Okta connector source supports retry mechanism for provisioning use case.

Resolution: Add following parameters in the application XML to execute retry while provisioning.

maxRetryCount represents the total number of retries, and retryWaitTimerepresents the time interval to wait before retrying the use case. The default value for maxRetryCount is 5, and the default for retryWaitTime is 60,000 milliseconds. Add the error string from the exception message to retryableErrors, which is the list of errors that should trigger a retry during provisioning.

<entry key="maxRetryCount" value="5"/>

<entry key="retryWaitTime" value="60000"/>

<entry key="retryableErrors">
    <value>
        <List>
            <String>failed to respond</String>
            <String>Authentication failed</String>
            <String>Failed to connect to the Okta instance</String>
        </List>
    </value>
</entry>

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.

For Unlocked Okta accounts from Identity Security Cloud, 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 Identity Security Cloud. 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.

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.

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 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.

• The following error message displays:

  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:

  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:

  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.

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

• The following error message displays:

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

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

  [ 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.

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

[ 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.

[ 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.

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 following error message is displayed while modifying the account attribute during the Enable operation:

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:

POST https://{orgName}.api.identitynow.com/cc/api/source/update/{OktasourceID}

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

• Key – connector_WaitTimeAfterEnable

• Value – 20000

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.

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:

POST https://{orgName}.api.identitynow.com/cc/api/source/update/{OktasourceID}

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

• Key – connector_provisioningTimeout

• Value – 20000

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.

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

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 Identity Security Cloud 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.

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.