Provisioning operations troubleshooting

Identity status remains as PENDING_*

Symptom: Status of user's identity after provisioning remains PENDING_CREATE or PENDING_UPDATE for long time, even if you are sure connector already has performed the operation of creating/updating user.

Possible reason: connector got unbound from RabbitMQ and no longer receives request from OpenIAM. This is known issue and OpenIAM team works on solid solution for it.

Solution: We suggest to re-save connector and check if responses from connector came back to OpenIAM. Go to Webconsole > Provisioning > Connectors find connector that experiences issues and without any changes on configuration page click Save. Then open managed system dashboard and click icon of connector replies on the proper managed system raw to make sure IAM got responses back. Other way to check is Audit Logs, you should see actions at the top of the search results like:

1. SAVE_CONNECTOR_RESPONSE
2. SAVE_GROUP_CONNECTOR_RESPONSE
3. SEARCH_CONNECTOR_RESPONSE
4. ENABLE_CONNECTOR_RESPONSE
5. DISABLE_CONNECTOR_RESPONSE
6. DELETE_CONNECTOR_RESPONSE
7. RESET_PASSWORD_CONNECTOR_RESPONSE

Sync via connector connection doesn't return values

Symptom: Audit event PROVISIONING_USER_SEARCH and PROVISIONING_GROUP_SEARCH has the "Response is not received from RabbitMQ during reply timeout" error.

Possible reason: connector got unbound from RabbitMQ and no longer receives request from OpenIAM.

Solution:

1. We suggest to re-save connector and check if responses from connector came back to OpenIAM. Go to Webconsole -> Provisioning -> Connectors find connector that experiences issues and without any changes on configuration page click save. Then open managed system dashboard and click icon of connector replies on the proper managed system raw to make sure IAM got responses back.
2. Make sure you use in Synchronization Source: 'Connector - Asynchronous & Multithreaded' and not 'Solution: Now we suggest to resave connector and check if responses from connector came back to OpenIAM. Open webconsole > Provisioning > Connectors > find connector that experienced issues > click Save. Then open Managed system dashboard and click icon of connector replies on the proper managed system raw to make sure IAM got responses back.' (this one is deprecated as of now)
3. Another possible reason might be that request query returned lots of results and connector needed more than 30 sec (standard timeout time frame) to process the data. Solution here is extending timeout for IDM and synchronization services.
   • to do that for Docker deployment:
     • In Docker compose file 3.2/services/docker-compose.yaml, in OPENIAM_JAVA_OPT_ARGS add a new -Dorg.openiam.mq.broker.reply.timeout=[timeout in ms] option to IDM and Synchronization services. For example:

   OPENIAM_JVA_OPT_ARGS: "-Dlogging.level.root=${LOGGING_LEVEL} -Dlogging.level.org.openiam.common.mq.listener=DEBUG -Dorg.openiam.mq.broker.reply.timeout=3000000"

• Save the file and run ./startup.sh to apply changes.

• After services will be re-deployed, re-try sync operation.

  • For RPM deployment, add -Dorg.openiam.mq.broker.reply.timeout=[timeout in ms] option into startup.sh in /usr/local/openiam/services. For example:

$JAVA_HOME/bin/java -Dlogging.level.root=INFO -Dlogging.level.org.openiam=WARN -Dorg.openiam.mq.broker.reply.timeout=3000000 -Dconfpath=$HOME_DIR -jar $JAVA_OPTS $HOME_DIR/services/bin/$1.jar > $HOME_DIR/logs/$1.log```

• Restart IDM and syncronization services and re-try sync operation.