- Q. How can I configure an AM server without using the AM admin UI?
- Q. How do I configure multiple AM instances using the configurator tool?
- Q. How do I integrate IDM, AM and DS?
- Q. How can I secure AM?
- Q. How can I restrict access to the AM admin UI based on IP address?
- Q. Is there a maximum number of realms permitted in AM?
- Q. Can I use multiple identity repositories in the same realm?
- Q. Can I use wildcards (for example *) in Realm/DNS alias settings?
- Q. Can I change the configuration store suffix (for example, dc=am,dc=forgerock,dc=org) in between doing an export and import?
- Q. Which authentication modules work with HTTP Basic Authentication?
- Q. Can I change session timeouts during the session and/or the authentication process?
- Q. Does AM have a maximum password length?
A. You can use the configurator.jar tool (for example, openam-configurator-tool-220.127.116.11.jar for AM 7) to configure a deployed AM server. This tool allows you to easily configure an AM server in a silent, unattended manner (whether for a new install, upgrade or even in a scenario where you are moving to new servers and want to replicate an existing configuration) all without using the AM admin UI. This tool can be included in scripts to automate the configuration process if required.
The configurator.jar tool is included in AM but is not installed by default.
See Installing Silently for an overview of the process. The most important part is creating a valid comprehensive config.file as this is used for the actual configuration. A sampleconfiguration file is included when you install the configuration tools, which you should use as the basis of your configuration file; the properties that can be set within this file are described in configurator.jar. When AM is installed from the AM admin UI, the parameters that would be used in the configuration.jar configuration file are written to the install log. This can be used as a quick way to generate such a configuration file.
If you are configuring multiple AM servers within a site, you must ensure the AM_ENC_KEY property in the configuration file has the same value for each server. An RFE exists for this: OPENAM-8726 (Using configurator CLI should not require setting the correct encryption key when setting up additional servers).
You can also use Amster to configure AM as detailed in Install AM with Amster.
A. You can configure multiple instances using the configurator tool as follows according to which version of AM you are using. When you install the configuration tools, a sampleconfiguration file is included, which you should use as the basis of your config.file.
AM 7 and later
The password encryption key (AM_ENC_KEY) in the config.file must be the same on all servers in a multi-server installation. See configurator.jar for further information and examples.
You need to include the following property in the config.file for the second AM instance to point to the first instance:existingserverid=https://am1.example.com:443/am
Additionally, the following properties must be identical in the config.file for both instances:locale PLATFORM_LOCALE AM_ENC_KEY ADMIN_PWD AMLDAPUSERPASSWD COOKIE_DOMAIN ACCEPT_LICENSES DATA_STORE DIRECTORY_SSL DIRECTORY_SERVER DIRECTORY_PORT DIRECTORY_ADMIN_PORT DIRECTORY_JMX_PORT ROOT_SUFFIX DS_DIRMGRDN DS_DIRMGRPASSWD
See configurator.jar for further information and examples.
A. You should refer to Platform Setup for further information.
A. See Security for best practice advice on securing AM.
This type of question and deployment is outside the scope of ForgeRock support; if you want more tailored advice, consider engaging Deployment Support Services.
The following things should be considered when planning realm numbers:
- Each realm loads certain organizational configuration schema, which is cached on the AM instance; this means you must have enough JVM heap assigned based on load testing.
- Any changes to global configuration triggers the cache to be cleared; this means you may find global configuration changes take longer than expected if you have a lot of realms with cached data.
- The AM admin UI may be slow or may not be able to load all realms depending on your configuration.
- Policy evaluation may be slow or hang if you have policies under each realm, depending on your policy configuration.
- The CTS token store must be carefully designed depending on the number of users residing under each realm.
- DS has an index-entry-limit and if the number of indexes (that is, sunxmlKeyValue, which stores realm alias names) exceeds this limit, the search will be an unindexed search, which will impact performance.
- DS user stores will need to be tuned carefully to handle the additional overhead of persistent searches and connections pools generated by each realm's data stores and/or LDAP authentication modules.
- A large number of realms can exhaust system resources such as file descriptors. For example, each realm will have a series of listeners each with an open file descriptor; factoring in other open file descriptors in use on the system and operating system limitations, we tend to advise against a very large number of realms to avoid nearing maximum file descriptor limits. Please consult your operating system documentation for your particular deployment and refer to Setting Maximum File Descriptors and Processes Per User for further information.
A. As per the Preparing Identity Repositories:
You should not configure more than one writeable identity repository in a single realm. AM will try to perform write operations on each identity repository configured in a realm, and there is no way to configure which repository is written to.
To manage identities and reconcile differences between multiple identity repositories, use ForgeRock Identity Management.
Q. Can I change the configuration store suffix (for example, dc=am,dc=forgerock,dc=org) in between doing an export and import?
A. No. If you attempt this (using export-svc-cfg and import-svc-cfg), references to the old configuration store suffix will be imported into your new configuration store and related functionality will silently cease to work.
- Active Directory
- Data Store
A. The maximum session timeout (AMMaxSessionTime) and maximum idle timeout (AMMaxIdleTime) can be updated as Session properties during post authentication processing. These timeouts can be set as follows:ssoToken.setProperty("AMMaxSessionTime", "timeout_in_minutes"); ssoToken.setProperty("AMMaxIdleTime", "timeout_in_minutes");
Creating a custom PAP is outside the scope of ForgeRock support; if you want more tailored advice, consider engaging Deployment Support Services.
There is a known issue where the session does not reflect the change but the change is enacted: OPENAM-9278 (Setting Session properties via SSOToken#setProperty is not reflected in Session). For example, setting the Maximum Session Time to "1", will automatically log out the user in 1 minutes time.
See LDAP Authentication Module for further information.