Announcements

SecurID® Discussions

Browse the SecurID discussion board to get product help and collaborate with other SecurID users.
XavierKoenig
Beginner
Beginner

Only FQDN:7004/Console-IMS/ webpage working?

Jump to solution

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.

0 Likes
1 Solution

Accepted Solutions

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.

View solution in original post

10 Replies
JayGuillette
Apprised Contributor Apprised Contributor
Apprised Contributor

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

0 Likes

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.

0 Likes
JayGuillette
Apprised Contributor Apprised Contributor
Apprised Contributor

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

0 Likes
StevenSpicer
Valued Contributor Valued Contributor
Valued Contributor

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.

0 Likes
KevinDouglas
Respected Contributor Respected Contributor
Respected Contributor

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]

0 Likes

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 #

0 Likes

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.

StevenSpicer
Valued Contributor Valued Contributor
Valued Contributor

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?

0 Likes

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)

0 Likes