FAQ
ForgeRock Identity Platform
Does not apply to Identity Cloud

FAQ: General IDM

Last updated Dec 8, 2021

The purpose of this FAQ is to provide answers to commonly asked general questions regarding IDM.


Frequently asked questions

Q. Are there any restrictions on the characters that can be included in the userName attribute?

A. The restrictions on userName and other managed object attributes are configured in managed.json (located in the /path/to/idm/conf directory). By default, userName is configured so that it is:

  • required
  • not-empty
  • unique
  • no-internal-user-conflict
  • does not contain the the backslash ("/") character

You can customize these policies in managed.json and policy.js.

Note

If the DS Attribute Value Uniqueness plugin has been configured for the attribute mapped to IDM's userName, then DS will not allow the creation of more than one account with the same value for this attribute. See Attribute Uniqueness for further information.

Q. What is the purpose of the lastSync attribute?

A. The lastSync attribute is used as the state in a managed object to remember what assignments were pushed to the target resources, on a per mapping basis. This attribute prevents divergences between the source and target assignment, especially when "mergeWithTarget" and "removeFromTarget" strategies are used.

You must not remove this attribute as it could cause future upgrades to fail.

Q. Why can't users log in to IDM with their existing passwords once they have been synced from DS?

A. When users are synced from DS, the users will exist in IDM but cannot log in until their password has been changed. This is because user passwords in DS are one-way encrypted and cannot be retrieved until a password change has occurred. Additionally, you must be using the Passthrough authentication method. See PASSTHROUGH for further information.

You can configure a password policy to force users to change their password when they next login. See Enforcing Password Policy for further information.

Q. Can dynamically assigned roles (via effectiveRoles.js) be used to authorize external REST requests?

A. No, this is a known limitation of effectiveRoles.js.

Q. What happens when an attribute that was previously searchable is changed to not searchable?

A. An attribute is made searchable or not by setting the searchableDefault property to true or false in the repo.jdbc.json file. After setting this option, you must run a full reconciliation to update the managedobjectproperties table. This reconciliation process then adds or removes the searchable attribute as required. No database indexes are involved.

Q. What values can I use when specifying rotation times and intervals for audit logs?

A. For rotationTimes, rotationInterval and rotationRetentionCheckInterval, you can specify the time period using the following units:

Time Period Unit
Day "days", "day", "d"
Hour "hours", "hour", "h"
Minutes "minutes", "minute", "min", "m"
Seconds "seconds", "second", "sec", "s"
Miliseconds "milliseconds", "millisecond", "millisec", "millis", "milli", "ms"
Microseconds

"microseconds", "microsecond", "microsec", "micros", "micro", "us", "\u03BCs", "\u00B5s"

The last two support 'mu' and 'micro sign' abbreviations.

Nanoseconds "nanoseconds", "nanosecond", "nanosec", "nanos", "nano", "ns"
Note

rotationRetentionCheckInterval cannot be left blank; a reasonable value for this would be 5 seconds but could be set to 5 minutes or more depending on how you have the rotation interval configured.

See Audit Event Handler Configuration for further information.

Q. What values can I use when specifying the rotationFileSuffix for audit logs?

A. The rotationFileSuffix should be a timestamp, where the allowed values comply with the Java SimpleDateFormat syntax. The default suffix format is -yyyy.MM.dd-HH.mm.ss.

Q. Why are the timestamps displayed in the audit log and openidm log different?

A. The timestamps used in the logs are different as the logs serve different purposes:

  • Audit logs use timestamps in UTC format (for example, 2018-07-18T08:48:00.160Z); UTC is a unified standard that is not affected by daylight saving time changes. The format used in audit logs is not configurable since UTC provides the consistency needed for auditing when IDM servers are deployed globally across different timezones.
  • openidm log uses the system time since it is primarily used for diagnosing issues where local timestamps are needed in troubleshooting analysis.

This does mean that timestamps will be different if your system uses a format other than UTC.

Q. What logging capabilities does the Felix web console have?

A. When the Felix web console is running in the foreground, log messages are displayed in the console and also output to the openidm log. The log level is determined by the settings in logging.properties. See Configure Server Logs for further information.

If you're running IDM as a background process, you can redirect standard output and standard error to the console.out file as described in Install and Run IDM (Run IDM as a Background Process).

See Property Files for further information about the Felix logging options that can be set in the config.properties file.

Q. Is Elasticsearch 6 supported for audit logging?

A. No, Elasticsearch 6.x is not supported for audit logging because 6.0 introduced a breaking change regarding how indices are handled (you can now only have one _type per index). 

Per the Elasticsearch documentation (Removal of mapping types):

Indices created in Elasticsearch 6.0.0 or later may only contain a single mapping type. Indices created in 5.x with multiple mapping types will continue to function as before in Elasticsearch 6.x. Mapping types will be completely removed in Elasticsearch 7.0.0. 

A possible workaround is to create the index in Elasticsearch 5 and then upgrade to Elasticsearch 6.

The Elasticsearch audit handler is deprecated in IDM 7.1.

Q. Does IDM provide protection against XSS, SQL injection and CSRF attacks?

A. Yes, IDM provides protection as follows:

  • SQL injection

IDM JDBC repositories use prepared statements (where input is parameterized appropriately) to prevent SQL injection. However, you do still need to set appropriate authorization settings to only allow required access. The recommended way of allowing access is to change the default to allow nothing and then use the white list to make functionality accessible as needed. If you build your own scripted SQL connectors, you should ensure that these queries are parameterized in a similar way to those provided.

  • XSS

The ForgeRock UI has been hardened against XSS and we are not aware of any exploits; it has been submitted to white hat review and they have confirmed this.

  • CSRF

See How do Identity Cloud and IDM (All versions) protect against CSRF attacks? for further information.

See Also

FAQ: Installing and configuring IDM

FAQ: IDM compatibility with third-party products

FAQ: Upgrading IDM

Troubleshooting IDM

Installation Guide

Setup Guide

Security Guide

Related Training

ForgeRock Identity Management Core Concepts (IDM-400)


Copyright and Trademarks Copyright © 2021 ForgeRock, all rights reserved.