Truststore has the certs required for connections with DS and AM over SSL
I’ve included the right admin name: ‘’’ uid=amAdmin,ou=People,dc=openam,dc=forgerock,dc=org ‘’’
Cookie is set for a valid Domain name
dsameuser password has not been changed
Not using a site configuration
When going through the errors in ssoadm logs, I see the below entries:
com.sun.identity.cli.CLIException: Failed to process request for http://frlab.securdi.com:80/am/json/serverinfo: No content to map due to end-of-input
at [Source: (String)“”; line: 1, column: 0]. Can ignore with JDK flag am.fileBasedConfiguration
at com.sun.identity.cli.CLIUtil.getServerInfo(CLIUtil.java:321)
at com.sun.identity.cli.CLIUtil.isFileBasedConfigMode(CLIUtil.java:285)
at com.sun.identity.cli.CommandManager.serviceRequestQueue(CommandManager.java:652)
at com.sun.identity.cli.CommandManager.(CommandManager.java:243)
at com.sun.identity.cli.CommandManager.main(CommandManager.java:174)
Sorry, I wasn’t clear in my question. AM is up and running. I’m able to login via the UI. And infact, I get a valid response if I hit https:///am/json/serverinfo/version. However, ssoadm is trying to reach https:///am/json/serverinfo. Is there any additional setup needed for just /serverinfo to work?
This is definitely strange. Are you definitely getting a 404 error on /serverinfo, and not a 400? I get a 400, but it contains a JSON response that can be parsed. That “No content to map due to end-of-input” message sure makes it seem like you are not getting that JSON error response so I’m assuming the 404 is indeed the response you are getting.
Is it correct to assume that you are using an embedded DS config store? The only reason I ask is that if you installed a separate config store for AM your amadmin userid may not be correct (for example, I installed DS using the “AM configuration data store” profile, and using the default values for that profile will result in the admin name being uid=amAdmin,ou=People,ou=am-config). You can confirm the correct username by going to Configure->Server Defaults->Advanced and looking for the com.sun.identity.authentication.super.user property. Once you have that, the %ROOT_SUFFIX% value can be found in your boot.json file, as the value of configStoreList.baseDN.
To the best of my knowledge, this type of change cannot be handled via Amster.
I rechecked on the error code, and it was indeed 400, not 404. Sorry about that.
But I got the issue. The error message was misleading. The error said it is trying to access http:///am/json/serverinfo. However, I checked the network packets and saw that ssoadm is actually hitting http:///am/json/serverinfo/*. The URL http:///am/json/serverinfo/* is a valid URL and I’m getting a 200 response.
However, the problem is that ssoadm is trying to access via HTTP, but my TOMCAT is setup to redirect all HTTP to HTTPS. Because of this, the initial call to the URL results in a 302 redirect response, and that’s why the “No content to map due to end-of-input” error. I got it to work when i disabled the redirection on my tomcat. Although I’m not sure why ssoadm behaves like this. HTTP → HTTPS redirection is a pretty common use case.
I was able to export the configurations. I changed all occurences of the hostnames and then tried to import it. The import failed though with the following error:
Parser error at line: 26,809
org.xml.sax.SAXParseException; lineNumber: 26809; columnNumber: 290; Attribute "validator" must be declared for element
type "SubSchema".
Edit: I tried to import the file that I exported, without any changes to it. And I still get the same error. The line in question seems to have the validator attribute as well. So can’t make out what it’s looking for
Since I’m having trouble with ssoadm, I was wondering if i could do this using ldif export and import. I’d do an ldif export, change all the hostnames, and then do and ldif import. And then change the boot.json with the new URL. I’m not sure if this will be covering all the configuraitons though. Would this be a right approach?
First off, great catch on the redirect. As for why ssoadm works like that, ssoadm is an older tool and makes some assumptions about how things are configured, which is likely why a) there are so many various things you have to do to get it working in various scenarios, and b) it is deprecated in favor of amster. Of course, as you’ve learned, there are still certain use cases that aren’t documented for Amster. That’s not to say that Amster couldn’t handle this, but I certainly have never tried it and I don’t see it as a documented solution via Amster.
On the import side of things, I wish I could tell you why that is failing but that error is certainly not helpful. It’s even more confusing when you look at the output file and see there are many SubSchema entries that do not have a validator attribute.
So with regards to the ldif export and import, I believe that yes, this would work. In the past I’ve successfully changed my AM host name by manually modifying entries in the config store however I will give the caveat that this was on a much older version of AM, likely around 5 or 13. I’d also give the caution that this is likely not something that ForgeRock supports.
The ssoadm documentation specifically asked me upload the SSL cert of my AM to the truststore. So I was expecting it to use SSL connection
Anyways, I actually went ahead and tried it out. I exported the ldif, changed and host names and imported it back to the configuration store. And then edited the URL in boot.json. The instance came up and things seem to be working. However I’ll keep an eye out to see if it causes any issues further down the line. I’m not working with a prod instance right now, so this will be a good test.
Specifically the bit: " AM provides a set of administration tools that are now deprecated in favor of Amster. They are part of the [AM distributable file]
The ssoadm tool requires access to the AM configuration files and therefore must be installed on the same host as AM. "
