AnsweredAssumed Answered

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

Question asked by 8uZPwazuaLdUDEHBlmCEnXtMcNNGCxAmytp7hB97ef4= on Jun 6, 2016
Latest reply on Jun 17, 2016 by 8uZPwazuaLdUDEHBlmCEnXtMcNNGCxAmytp7hB97ef4=
Branched to a new discussion

Like • Show 0 Likes0
Comment • 10

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.

Mostafa Helmy

Jun 17, 2016 11:17 AM

Correct Answer

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.

See the reply in context

No one else had this question

Outcomes

Jay Guillette

Jun 6, 2016 5:25 PM

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

Actions

8uZPwazuaLdUDEHBlmCEnXtMcNNGCxAmytp7hB97ef4= @ Jay Guillette on Jun 6, 2016 5:50 PM

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.

Actions

Jay Guillette

Jun 6, 2016 6:10 PM

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

Actions

Steven Spicer

Jun 11, 2016 10:15 AM

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.

Actions

Kevin Douglas

Jun 17, 2016 10:59 AM

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]

Actions

8uZPwazuaLdUDEHBlmCEnXtMcNNGCxAmytp7hB97ef4= @ Kevin Douglas on Jun 17, 2016 11:09 AM

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 #

Actions

Mostafa Helmy

@ 8uZPwazuaLdUDEHBlmCEnXtMcNNGCxAmytp7hB97ef4= on Jun 17, 2016 11:17 AM

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.

1 person found this helpful

Actions

8uZPwazuaLdUDEHBlmCEnXtMcNNGCxAmytp7hB97ef4= @ Mostafa Helmy on Jun 17, 2016 12:04 PM

This wound up resolving the issue. The log file was unbelievably huge, and parsing it with vi was proving to be rather difficult. resetting the server cert allowed all services to restart normally. Thanks a million for your help!

Actions

Kevin Douglas

@ 8uZPwazuaLdUDEHBlmCEnXtMcNNGCxAmytp7hB97ef4= on Jun 17, 2016 11:28 AM

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)

Actions

Steven Spicer

Jun 17, 2016 11:25 AM

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?

Actions

10 Replies

Jay Guillette Jun 6, 2016 5:25 PM
Mark Correct
Correct Answer
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
Like • Show 0 Likes0
Actions
- 8uZPwazuaLdUDEHBlmCEnXtMcNNGCxAmytp7hB97ef4= @ Jay Guillette on Jun 6, 2016 5:50 PM
  Mark Correct
  Correct Answer
  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.
  Like • Show 0 Likes0
  Actions
Jay Guillette Jun 6, 2016 6:10 PM
Mark Correct
Correct Answer
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
Like • Show 0 Likes0
Actions
Steven Spicer Jun 11, 2016 10:15 AM
Mark Correct
Correct Answer
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.
Like • Show 0 Likes0
Actions
Kevin Douglas Jun 17, 2016 10:59 AM
Mark Correct
Correct Answer
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]
Like • Show 0 Likes0
Actions
- 8uZPwazuaLdUDEHBlmCEnXtMcNNGCxAmytp7hB97ef4= @ Kevin Douglas on Jun 17, 2016 11:09 AM
  Mark Correct
  Correct Answer
  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 #
  Like • Show 0 Likes0
  Actions
  - Mostafa Helmy @ 8uZPwazuaLdUDEHBlmCEnXtMcNNGCxAmytp7hB97ef4= on Jun 17, 2016 11:17 AM
    Unmark Correct
    Correct Answer
    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.
    1 person found this helpful
    Like • Show 1 Like1
    Actions
    - 8uZPwazuaLdUDEHBlmCEnXtMcNNGCxAmytp7hB97ef4= @ Mostafa Helmy on Jun 17, 2016 12:04 PM
      Mark Correct
      Correct Answer
      This wound up resolving the issue. The log file was unbelievably huge, and parsing it with vi was proving to be rather difficult. resetting the server cert allowed all services to restart normally. Thanks a million for your help!
      Like • Show 0 Likes0
      Actions
  - Kevin Douglas @ 8uZPwazuaLdUDEHBlmCEnXtMcNNGCxAmytp7hB97ef4= on Jun 17, 2016 11:28 AM
    Mark Correct
    Correct Answer
    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)
    Like • Show 0 Likes0
    Actions
Steven Spicer Jun 17, 2016 11:25 AM
Mark Correct
Correct Answer
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?
Like • Show 0 Likes0
Actions

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

Outcomes

Related Content

Recommended Content