Each security configuration for MFDS, ES Default Security, or a particular Enterprise Server instance support additional configuration
that can be set by modifying the text in the
Configuration Information field. Text in this field is organized into sections which begin with a tag label in square brackets, followed by lines containing
You can add these settings in the
Configuration Information field for the security configuration, and not a Security Manager. Security Managers also have a custom configuration setting,
with parameters defined by the External Security Manager module they use. See the documentation for the specific ESM module
for more information.
The following are the configuration sections, and the options that can be set in each section:
- category 3 events=yes | no
- Setting this option disables audit category 6 events for SAF Auth and XAuth calls, and enables category 3 events for Verify,
Auth, and XAuth calls. This option is provided for backwards compatibility.
By default, this is set to
- password change success = yes | no
- Setting this option enables an extra audit event for every successful password change.
Note: Password change rejections (and related errors) are always audited. See Audit event 6 2 in
Audit Event Codes for more information.
By default, this is set to
- allow-list=yes | no
- If this is set to
yes, then Admin LIST requests, for example, list users, groups, and resource access rules are allowed for all users, with no
additional access check.
- flush on change=yes | no
- Set to
yes to tell the cache that it should discard any cached Verify result if it receives another request for the same user with a
different result. See
Using Flush on Change for more information. This is only useful when Verify caching is enabled.
- report interval=seconds
- You can configure how often reporting happens by setting the
report interval option. Its value is an integer, representing the approximate time between reports in seconds. Setting this to
0 disables reporting.
- requests=list of request types
- This setting specifies what type of ESF requests can be cached. It is set to a list of tokens, separated by commas or spaces.
Requests for a full list of possible tokens.
See the chapter
ESF Caching for more information.
- failover retry interval=seconds | never
This option changes the behavior of redundant mode. It is ignored if redundant mode is not enabled. See the redundant setting
below for more information. By default, when redundant mode is enabled, failing Security Managers are retried on every request
when they would normally be invoked. This may cause performance issues if a failed manager takes a long time to respond.
If this option is set to a positive number, a failed Security Manager only be retries when at least that many seconds have
elapsed since it failed.
If this option is set to 0 or "never", a failed Security Manager is disabled until ESF is reinitialized or the process is
- redundant=yes | no
- If this option is set to yes, you can configure multiple equivalent Security Managers and let processing continue as long
as at least one Security Manager is available. By default, if any Security Manager returns an error during initialization
or security request processing, the request fails. If redundant mode is enabled, initialization and request processing only
need one successful Security Manager.
By default, redundant is set to
- update interval=seconds
If this is set to a positive number, ESF waits at least that many seconds between checks for administrative update notifications.
Update notifications are used to tell ESF that security information has changed and it should discard cached data and update
information it has stored about users and groups. This check may affect performance under heavy loads, in which case setting
an update interval can improve performance, at the cost of ESF taking more time to recognize that security information has
- user exit=module-name
- Configure a user exit module. See
ESF User Exit for more information.
- allow=none | generate | signon | both | yes
none disables pastokens,
generate enables passtoken generation but not their use,
signon enables passtoken use for signon but not generation,
both enables both generation and signon, and
yes which is a synonym for both.
Passtoken Options for ESF Manager for more information.