Login fails for some users with an Access denied, user inactive error when IDM 5.x or 6.x is integrated with AM

Last updated Nov 2, 2020

The purpose of this article is to provide assistance if some users cannot authenticate to AM, resulting in an "Access denied, user inactive" error. This issue occurs when you have OAuth2 based Single Sign On established between AM and IDM. This integration is achieved using the OAUTH_CLIENT module (IDM 5.5 and later) or the OPENID_CONNECT module (IDM 5).


Authentication fails and you may see the following response:

{"code":401,"reason":"Unauthorized","message":"Access Denied"}

If you examine network traffic using your browser's Developer Tools or by capturing a HAR file, you will see the full response:

{ "code": 401, "reason": "Unauthorized", "message": "Access Denied", "detail": { "failureReasons": [ { "code": 401, "reason": "Unauthorized", "message": "Access denied, user inactive" } ] } }

You can capture a HAR file as described in: How do I create a HAR file for troubleshooting IDM/OpenIDM (All versions)?

The following error is shown in the openidm0.log when this happens:

360] Apr 04, 2019 4:11:57 PM org.forgerock.openidm.auth.modules.AugmentationScriptExecutor executeAugmentationScript FINE: Augmentation script auth/amSessionCheck.js:text/javascript:1658e66cef7 threw userName when augmenting security context for org.forgerock.json.resource.PermanentException: Access denied, user inactive org.forgerock.json.resource.PermanentException: Access denied, user inactive at org.forgerock.json.resource.ResourceException.newResourceException( at org.forgerock.openidm.script.ScriptThrownException.toResourceException( at org.forgerock.openidm.auth.modules.AugmentationScriptExecutor.executeAugmentationScript( at org.forgerock.openidm.auth.modules.IDMAuthModuleWrapper$1.apply( at org.forgerock.openidm.auth.modules.IDMAuthModuleWrapper$1.apply( ... Caused by: org.forgerock.openidm.script.ScriptThrownException: [object Object] {code=401, message=Access denied, user inactive}

Recent Changes

Integrated IDM with AM per the documentation: Samples Guide › Configuring AM for Integration with IDM.


The amSessionCheck.js script (located in the /path/to/idm/bin/defaults/script/auth directory) checks that a user is active and specifically looks for an account status of 'active' (all lowercase). If the user's status is anything other than this, they are deemed not active and you will see the 401 response. The relevant part of the script is:

if (managedUser.result[0].accountStatus !== "active") { throw { "code" : 401, "message" : "Access denied, user inactive" }; }

IDM uses 'active' by default to indicate the account status, but a different status may be used elsewhere. For example, a status coming from DS via a sync may be set to 'Active' (mixed case); in which case, IDM will determine the user is inactive and they will be unable to authenticate per this script's logic.


This issue can be resolved by changing the amSessionCheck.js script to accept valid account statuses as follows:

  1. Navigate to the IDM Admin UI >  Manage Users > [User] > Details tab and check the value of the Status field for the managed user who cannot log in. For example, it might be set to 'Active'.
  2. Create a script/auth directory within your project. For example, if you are using the full-stack sample, you would create the following: /path/to/idm/samples/full-stack/script/auth
  3. Copy the existing amSessionCheck.js file from /path/to/idm/bin/defaults/script/auth to the new script/auth directory you created in step 2.
  4. Edit the new version of the amSessionCheck.js file and change the relevant part of the script from: !== "active" to something that also includes the value identified in step 1, for example: !== ("active"||"Active") So that the resulting section of the script now looks like this: if (managedUser.result[0].accountStatus !== ("active"||"Active")) { throw { "code" : 401, "message" : "Access denied, user inactive" }; }
  5. Save the file and retest. All users should now be able to authenticate.

See Also

How does the OIDC authorization flow work when IDM 5.5.x or 6.x is integrated with AM?

Authentication fails with IDM 5.x or 6.x integrated with AM when session-jwt cookie size exceeds browser limits

Integrator's Guide › Supported Authentication Modules

Related Training


Related Issue Tracker IDs


Copyright and TrademarksCopyright © 2020 ForgeRock, all rights reserved.