The purpose of this article is to provide assistance in getting support for questions, problems, and incidents involving the ForgeRock
Identity Cloud or Identity Platform.
Cut to the case!
To avoid confusion and delay, when raising a ticket for technical support, please be sure to select your specific Product/Platform from the dropdown choice list in the ticket form. This will ensure the ticket is routed directly to the subject matter experts for a timely response.
To simplify this check, if you have no means of providing a log or script file, then you are working in the CLOUD environment, and corresponding artifacts will be maintained via ForgeRock. Once you have identified the network environment your issue exists in, please familiarize yourself with the appropriate Best Practices for each environment and open a case with ForgeRock Support as needed.
CLOUD: Best practice for raising an Identity Cloud ticket with ForgeRock Support
PLATFORM: Best practice for raising an Identity Platform ticket with ForgeRock Support
Copy to the case!
CLOUD
HAR FILES: To support subscriptions for the ForgeRock Identity Cloud, troubleshooting efforts shift FROM ADMIN TO USER INTERFACE. Thus providing logs in the traditional manner of troubleshooting technical issues shifts as well. Subscribers no longer need to provide the logs or configuration settings since we maintain the source code and cloud environment itself. This means as a USER, you should produce an additional audit trail directly from your browser. This is accomplished by creating an HTML ARCHIVE (known as a “har file”) that captures each Request and Response taken in the Browser recorded via DevTools. Providing a har file for unexpected behavior captured in the browser is a Best Practice when opening these types of cases.
PATCHES: When bugs are discovered and fixed in a Cloud environment, all users of the Cloud version in question will receive fixes at the same time based on internal testing and verification prior to roll-out. Thus it is important to understand how fixes are delivered to the Cloud. No action is required by the subscriber to deploy a patch, as they will be notified when a fix is in place via each related use case.
PLATFORM
PLAYERS: Note all relevant Product NAMES and Version info to validate QA Certified and Supported components within the environment facing an issue (e.g., DS Requirements from the AM 7.1 Release Notes).
Highlight any one-off patches or API specific versions. Support needs to be made aware of what we need to reproduce the behavior that isn’t working as documented. Support will verify or open discrepancies with Sustaining when default ‘out-of-the-box’ (OOTB) functionality or workflows fail when localized.
SUSPECTS: ForgeRock products interface, interchange, and exchange data with a myriad of 3rd Party products. Be sure any product involved in a case has been identified and noted, even when ruling out, so as to isolate the root cause. For instance, in Production environments, the embedded ForgeRock Directory Services (DS) that ships with ForgeRock Access Management (AM) will have been replaced with an external DS. Thus it is common for lower environments to build & explore AM workflows using the embedded DS to begin testing immediately and until externalized. For instance, when troubleshooting an issue involving a Directory Server AND AM, be sure you note WHERE the AM Datastores are for the various TYPES of AM Datastores: Configuration, User, Core Token Service (CTS), Policy, Agent, and Application.
Likewise, if you want to use our Identity Governance Administration and Reporting (IGA) and (IDR) modules, you must have an external SQL Repository for IGA related tasks and reporting through ForgeRock Identity Management (IDM). So if an issue has to do with a database query or index usage, be sure to note it so Support can work with vendor-specific syntax when necessary.
EVIDENCE: Support engineers typically request corresponding logs that capture challenging conditions output by the process(es) writing to the log file(s). Log Writers have a trace setting that controls WHAT information will be written to the log file. Typically, the setting in Production environments is restricted to SEVERE or WARN level messages. Company policy may prevent tracing at the highest level in Production to avoid creating a performance bottleneck due to more log write operations. For example, in IDM, you would set /conf/logging.properties .level=FINEST as the highest trace level capturing ALL calls and return codes while at this setting. You can find product specific links to adjusting your log files Message or ‘trace’ level setting per product here: Sending troubleshooting data to ForgeRock Support for analysis.