Extended logging

Investigate Password Reset with scoped logging while keeping passwords, tokens, and session data out of diagnostics.

Extended logging

Use additional logging only for a specific investigation. Prefer CEF events and trace identifiers before increasing log verbosity. Reset requests contain the new password, and sessions or pipe state can contain assertions and access tokens.

Prepare the investigation

Reproduce the issue with synthetic accounts in an isolated test installation.
Record the product version, UI version, affected flow, and a trace identifier. Do not copy passwords, assertions, tokens, or complete customer requests into a ticket.
Save the existing log4j2.xml settings. Use the customer configuration file selected by the deployment's JVM profile; the path depends on the installation.

Enable scoped logging

For Password Reset's own components, add this entry inside the existing Loggers section of log4j2.xml:

<AsyncLogger name="fortified.pwdreset" level="DEBUG" />

Keep pipe debug valves such as DumpRequest, DumpSession, and DumpState out of the reset flow. DumpRequest logs the request, including new_password; merely choosing DEBUG instead of TRACE does not redact it. Do not enable DEBUG or TRACE broadly for foss, fortified, or fortifiedid on a production reset flow.

The scope above is not a guarantee that every diagnostic message is safe to share. Integration results can contain directory information or upstream error details. Inspect the output before sending it to support. Use TRACE only with synthetic data and a specific reason after DEBUG has proved insufficient.

Finish the investigation

Restore the previous log level, remove temporary diagnostics, and restart or reload logging according to your deployment. Limit access to diagnostic files and retain them only as required by your organization's policy.

See Log settings and Security configuration.