- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Only FQDN:7004/Console-IMS/ webpage working?
Hi all, I've recently inherited the management of our company's RSA system, and we've been experiencing this issue for some time. Currently running Authentication Manager 8.1 SP1 P09, and although I've read that you should be able to access the security console from three separate addresses (https://FQDN/, https://FQDN/sc, and https://FQDN:7004/console-ims/), only my last address is working. Doing some investigating, I also noticed that neither of my operations console links are working either(all get connection refused). We are running a primary/secondary setup on SLES11 SP2 (kernel 3.0.101-0.7.23), and it's worth mentioning that all of the addresses(including the OC ones) work just fine on my secondary system; it's only the primary can't access either of the OC and all but the last SC link.
Running "iptables -nL" from an elevated SSH bash, I get the following tidbit of info:
Chain rsaserv (1 references)
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:7002
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:7004
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:7022
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:7072
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:7082
However, when I run the following command: netstat -lnt | awk '$6 == "LISTEN" && $4 ~ "7072$"' I get zero results, while changing the 7072$ to 7004$ gives me five entries on the loopback and IPv4/IPv6 addresses of the server.
Is there a service that needs restarted, or should I possibly restart the entire server? Thanks in advance.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you tail the contents of /opt/rsa/am/server/logs/AdminServer.log and see what the stack trace is at the end of the file?
Possible fixes could include:
1. Expired console certificate -> Use /opt/rsa/am/utils/rsautil reset-server-cert
2. System modifications since that last services restart -> Try /opt/rsa/am/utils/rsautil manage-secrets -a recover
3. Sometimes I would try /opt/rsa/am/server/rsaserv stop all then /opt/rsa/am/server/rsaserv start all or reboot instead of restarting services.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The https://FQDN:7004/console-ims/ is the good one, it is the 'real' one, and if it does not work you have a problem. The https://FQDN/scā is a short cut to the good one, and should work if 443 is listening and not blocked. https://FQDN/ won't work, neither will https://<IP_address>:7004/console-ims
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm assuming that 443 should be functional, based on the output of my iptables result(ACCEPT tcp anywhere tcp dpt:443 for Chain rsaserv). This also doesn't really explain why none of the operations console web addresses are working, and instead get connection refused.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Try some different browsers. If you are just deploying an AM 8.1 version, but using current Chrome or IE 11, the Ciphers in your browser might not accept what the AM server provided back at the time AM 8.1 was released. If you have anything old, like IE 6 or 8, or older Chrome or FF, try those.
If you can patch up to AM 8.1 SP1 Patch 2 or later, the newer browsers might work.
NESSUS or other port scanning tools have been known to stop Port 443 from listening on Authentication Manager Server. Do a netstat -an | grep 443 and see if listening
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
First, I'd try the "is-it-plugged-in" test: although your iptables settings allow it, have you tried tcpdump to confirm that the 443 traffic is actually getting to the primary from your browser? Sometimes outside forces take over. š Once you confirm that the traffic is reaching the primary, try restarting the RSA services. Obviously that will take down all the services for a few minutes so you'll need to schedule an admin outage. Log in as rsaadmin and run "/opt/rsa/am/server/rsaserv restart all" The replica will pick up the failover authentication load.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, that's a quirky thing when doing a start that way. You are not in /home/rsaadmin. If you run it from any place other than /home/rsaadmin you get that message, but it does work from /home/rsaadmin see below.
rsaadmin@am81ptrust:~> pwd
/home/rsaadmin
rsaadmin@am81ptrust:~> /opt/rsa/am/server/rsaserv restart radius
Stopping RSA RADIUS Server: **
RSA RADIUS Server [SHUTDOWN]
Starting RSA Database Server:
Starting RSA Administration Server with Operations Console: *
RSA Administration Server with Operations Console [RUNNING]
Starting RSA RADIUS Server Operations Console:
RSA RADIUS Server Operations Console [RUNNING]- RSA Database Server [RUNNING] *
Starting RSA Runtime Server:
RSA Runtime Server [RUNNING]
Starting RSA RADIUS Server: **
RSA RADIUS Server [RUNNING]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Wish I had your luck, but even setting my working directory to /home/rsaadmin gives me the same result.
lxrsa01:/home/rsaadmin # /opt/rsa/am/server/rsaserv start radius
Running as rsaadmin...
Starting RSA Administration Server with Operations Console:
Starting RSA Database Server: *****
RSA Administration Server with Operations Console [FAILED]
Starting RSA RADIUS Server Operations Console: /
lxrsa01:/home/rsaadmin #
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you tail the contents of /opt/rsa/am/server/logs/AdminServer.log and see what the stack trace is at the end of the file?
Possible fixes could include:
1. Expired console certificate -> Use /opt/rsa/am/utils/rsautil reset-server-cert
2. System modifications since that last services restart -> Try /opt/rsa/am/utils/rsautil manage-secrets -a recover
3. Sometimes I would try /opt/rsa/am/server/rsaserv stop all then /opt/rsa/am/server/rsaserv start all or reboot instead of restarting services.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I notice you're running as root. Have you tried running as rsaadmin? I see the prompt saying that rsaserv is running as rsaadmin, but it's better to be sure.
Sometimes file not found doesn't mean it's not there; it just means the process in question doesn't see it. Have you checked the file and directory permissions on each component of the full path to the missing log file?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Running from the proper directory gets rid of the stack error. For the radius start failure, you should create a new thread.
log4j:ERROR setFile(null,true) call failed.
java.io.FileNotFoundException: logs/imsCluTrace.log (No such file or directory)
