ssoadm fails in AM (All versions) with FATAL ERROR: Cannot obtain Application SSO token
The purpose of this article is to provide assistance if you receive the "com.sun.identity.security.AMSecurityPropertiesException: AdminTokenAction: FATAL ERROR: Cannot obtain Application SSO token" response when attempting to use ssoadm in AM.
4 readers recommend this article
The following response is received when attempting to use ssoadm:Logging configuration class "com.sun.identity.log.s1is.LogConfigReader" failed com.sun.identity.security.AMSecurityPropertiesException: AdminTokenAction: FATAL ERROR: Cannot obtain Application SSO token.
Recent changes that could result in this issue include the following:
- Upgraded to, or installed AM 7 or later.
- Enabled SSL.
- Configured AM sites.
- Upgraded AM without upgrading the ssoadm administration tool to the same version.
- Upgraded to Apache Tomcat™ 8.5 or 9.
- AM 6.x: Changed the dsameuser password.
This error can be caused by a number of different issues; the most common of which are:
- Changes in AM 7 and later, including using secure connections to the configuration store and using the universal ID of the administrative user to connect.
- Accessing the configuration store and/or AM instance using a SSL/TLS secured connection but failing to include details of the truststore in the necessary scripts.
- Having a site configuration but failing to include site-to-server-mapping in the ssoadm or ssoadm.bat script.
- Having issues with ssoadm connecting to your AM server, as indicated by the following error in the ssoadm CoreSystem debug file: ERROR: Naming service connection failed for https://am.example.com:8443/am/namingservice com.iplanet.services.comm.client.SendRequestException: Connection refused
- Having an invalid domain specified for the cookie; this causes issues on Tomcat 8.5 and later since Tomcat now enforces stricter checking for valid cookie domain values per RFC 1034 and RFC 6265.
- AM 6.x: Having different dsameuser passwords in your global and local configurations, which means the first ssoadm attempt will succeed, whereas subsequent attempts will fail.
The solution depends on the cause; you should check and rectify the following if they apply to your setup:
AM 7 and later
If you are using AM 7 or later, you should ensure that:
- You have followed all the install steps in Set up administration tools, which includes the necessary steps for specifying the truststore that contains the required certificates.
- You are using the universal ID of the administrative user to connect, for example:
If you access the configuration store and/or AM instance using a SSL/TLS secured connection, you should add a JVM parameter to specify the truststore that contains the required certificates to the setup or setup.bat script prior to installing ssoadm and to the ssoadm or ssoadm.bat script once it is installed.
This is described in FAQ: Installing and using ssoadm in AM (Q. How do I install the ssoadm administration tool if I am using SSL?).
If you have a site configuration, you need to map the load balancer to the server within your site that is being used for ssoadm. This is done by adding site-to-server-mapping to the JVM parameters in the ssoadm or ssoadm.bat script.
This is described in FAQ: Installing and using ssoadm in AM (Q. How do I install the ssoadm administration tool if I have a Site configuration?).
If you are having issues with ssoadm connecting to your AM server, you will need to investigate this further as this issue will be specific to your configuration.
Possible configuration issues to look out for include:
- Server is not reachable over the network.
- Server causes naming service to return a site URL that is not reachable.
- Connection to server or site is refused due to certificate issues.
- Supplied credentials are incorrect.
Cookie domains and Tomcat
If you have upgraded to Tomcat 8.5 or later, you need to change the cookie domain to remove the leading dot.
This is described in Login page does not load or ssoadm fails in AM (All versions) running on Apache Tomcat 8.5 or 9.
dsameuser passwords (AM 6.x)
If you have changed the dsameuser password recently and can access ssoadm on the first attempt but not subsequent attempts, you need to ensure your dsameuser has the same password in your global and local configurations.
This is described in How do I change the dsameuser password in AM 6.x? and more detail can be found on this particular issue in Subsequent attempts to use ssoadm fail in AM 6.x.
FAQ: Installing and using ssoadm in AM
Related Issue Tracker IDs