- Q. Is AM compatible with Oracle® Java Development Kit (JDK) 11?
- Q. Why does AM require a JDK rather than just a JRE?
- Q. Can AM be used with OpenJDK™?
- Q. Is the Pivotal TC Server supported?
- Q. Does AM support IPv6?
- Q. Can I install AM on a system configured with SELinux in Enforcing mode?
- Q. Do I need to be a root user to install and administer AM?
- Q. Can I use an IP address for the AM server URL?
- Q. How do I debug issues when I am installing or upgrading AM?
- Q. How do I add a new server to a Site configuration?
- Q. What is the difference between the primary URL and secondary URLs?
- Q. Can I use the embedded configuration and/or user stores in production?
- Q. Can I have the user store and the configuration store in the same DS installation?
- Q. Can two separate instances of AM share the same DS user store?
- Q. Does AM support user stores with a dynamic groups LDAP structure?
- Q. Can I have a fully operational AM cluster where the nodes are running different AM versions?
A. Yes, as of AM 6.5, Oracle JDK 11 is supported. However, there is a known issue in AM 6.5.x with the display of some pages in the admin console. See Federation related pages do not display in the console with a java.lang.NoClassDefFoundError: sun/misc/CharacterEncoder error in AM 6.5.x for further information.
You should only use supported versions to prevent compatibility issues.
A. AM primarily requires a JDK to compile the bundled JSP files. Most web application containers include a JDK, although Tomcat does not. However, Tomcat includes a JSP engine (Jasper) that will compile JSPs. Although AM should run if deployed on Tomcat without a JDK, it should be noted that this is not supported. Additionally, utilities such as jar and jstack, which are referred to in the product documentation and used for troubleshooting, are only available when the JDK is installed.
A. The Pivotal TC Server is a Web application server based on open-source Apache Tomcat™, but it is customized in a way that the configuration filename and its location etc are not compliant with the default Tomcat server. For example:pivotal-tc-server-developer-3.1.7.RELEASE/templates/base-tomcat-7/conf $ls catalina-fragment.properties catalina.policy logging-fragment.properties server-fragment.xml web-fragment.xml pivotal-tc-server-developer-3.1.7.RELEASE/tomcat-7.0.72.B.RELEASE $ls LICENSE NOTICE bin lib
As such, AM cannot install on the Pivotal TC Server by default, it has not been tested nor is it supported. If you encounter any issues running on the Pivotal TC Server, you will be asked to reproduce them on a supported container.
See Apache Web Agent (All versions) does not start after installing it on RHEL or CentOS configured with SELinux for further information.
A. No, AM does not require root user usage. Providing Apache Tomcat™ does not attempt to use ports below 1024, you can use any user for AM. When running as a non-root user, the web application container must be able to write to its own home directory as this is where AM stores its configuration files.
A. No, you must use a Fully Qualified Domain Name (FQDN) for the AM server URL, otherwise cookies will not work. The FQDN should be in the format hostname.domainname for the AM server, for example, http://<hostname.domain>:8080/openam
See Installation Guide › Preparing an FQDN for further information.
You must never use the localhost domain for AM, not even for testing purposes.
A. You can enable Message level debugging in the web application container as described in How do I enable message level debugging for install and upgrade issues with AM (All versions)?
A. You can follow the procedure outlined in the documentation: Installation Guide › Configuring Sites and Adding Servers to Sites.
One or more secondary site URLs can be included, which is useful for internal VIPs or as alternate entry point to the site. It’s essentially there to make AM aware that it should handle other FQDNs in addition to the primary URL. The secondary site URLs are not used by any AM clients like Agents; the way that AM functions means only the primary site ID will be included in the SSOToken and therefore Agents will always use the primary site URL to communicate with AM.
See Reference › Deployment Configuration for further information.
A. You can for small systems in pre-AM 7, but it is not generally recommended for large-scale production systems. You should also consider that using external data stores allows you to tune your LDAP servers separately, which gives you greater control over performance. If you have a small scale deployment that is relatively simple, the embedded stores may be suitable for your needs; you should performance test this option to check it is appropriate before continuing.
If you plan on using external configuration/user stores, it is recommended that you start with the external stores rather than migrating to them after you have gone live.
This advice also applies to the CTS store; see FAQ: Core Token Service (CTS) and session high availability in AM (Q. Can I used the embedded CTS store in production?) for further information.
A. It is best practice to keep the user store and configuration store in separate DS installations. This means you can cache and index these stores differently. Additionally, by having two installations you will have separate Java Virtual Machines (JVM), which means you can tune the stores differently as well.
A. Yes it does. You should ensure the Attribute Name for Group Membership property is set to isMemberOf in your data store configuration; AM will use this attribute to fetch group membership, which includes dynamic groups. See Setup Guide › To Configure an Identity Store for further information.
See isMemberOf attribute does not return current group membership details for a user in AM (All versions) for details of returning group membership details via REST.
Resolved RFE: OPENAM-9030 (Improve group management implementation)
A. It is not recommended other than for upgrade purposes and will always depend on the actual differences between the releases. If there are changes to the AM schema and these changes are replicated to all the other configuration stores, it is very likely that the old nodes will not be compatible and may not be fully functional.
Although it is usually possible to have a mix of AM versions in a cluster for upgrade purposes, you should not make any changes to the configuration until all nodes in the cluster have been updated. As a precaution, it is also recommended that you temporarily remove old nodes from the cluster once the first node has been upgraded and that you remove the node that is currently being upgraded to prevent your users seeing an Upgrade AM page.