how to access self-service interface using public IP address

[XiaoliDing]

We have a RSA SecurID 8.2 deployed on virtual machine. During installation, host name for internal access and private IP address are used for this server. But later, the client wants to allow end user to access the self-service console from Internet. And to do that, host name for external access and public IP address will be used. They don't plan to configure NAT for this situation. They only open the firewall to allow access to the server via public IP address. But the server was initially configured with private IP and internal host name, so it does not respond to the external access to the self-service console (via port 7004). What we should do about this situation? Please suggest, thanks.

And below is what the client said:

"we are not doing a NAT on the firewall. We are expecting the 169.x.x.x address (public) to be accessible and simply allowing the traffic through the firewall. The 10.x.x.x address (private, server was installed with this IP) should not be in play for the publicly accessible self service tool."

[_EricaChalfin]

Xiaoli Ding‌,

With the complexity of your issue, I would recommend contacting RSA Support and opening a case to work directly with one engineer on your issue.

Regards,

Erica

[XiaoliDing]

Hi Erica,

I did opened a RSA support ticket 00895618 for this issue. For some

reasons no consistent supports are provided by any one RSA support person.

I have been receiving messages from different sources, and get confused

sometimes.

Please suggest.

Thanks,

Xiao-Li Ding

Information Security Consultant and IT Architect

MS in Computer Science, CISSP, CISA, MBA

IBM Security Services, NA

xding@us.ibm.com

(678) 248-3727

.................................................................................................

Links: IBM Security | Data Security | Emergency Response |

[_EricaChalfin]

aJRZt5g4dKx7U5ZD8SpwUIe4477GnhWhbnKiiwP436U=‌,

I see you have a case open for this issue that was owned by a TSE in APJ.  Since you are in the US, I asked the SecurID team manager to move your case to one of our US engineers.  It looks like it was assigned to 98n5OVAjoJAyQX05ErBBnm4DhCEdmmBlVS1qCZNrnSQ=‌ earlier today.  He left you a voicemail at 3:53 PM to discuss this case and followed up with an email at 3:58 PM.  

Please contact him at your earliest convenience.  He is in the office from 10:00 AM - 7:00 PM ET.

Regards,

Erica

[XiaoliDing]

Thanks Erica,

I received voice message and email message from Donnie. I replied to his

email message and left voice messages to him.

Regards,

Xiao-Li Ding

Information Security Consultant and IT Architect

MS in Computer Science, CISSP, CISA, MBA

IBM Security Services, NA

xding@us.ibm.com

(678) 248-3727

.................................................................................................

Links: IBM Security | Data Security | Emergency Response |

[XiaoliDing]

Hi Chris,

Is there any way to change the default self-service URL, in our case it is

https://machinename.outsidedomain.mhas.ibm.com:7004/console-selfservice,

because this primary RSA was installed with this FQDN:

machinename.outsidedomain.mhas.ibm.com. We want to make the self-service

URL looks like

https://rsa-selfservice.mhas.ibm.com:7004/console-selfservice, this way

the host name can be recognized from the Internet.

Please reply.

Thanks,

Xiao-Li Ding

Information Security Consultant and IT Architect

MS in Computer Science, CISSP, CISA, MBA

IBM Security Services, NA

xding@us.ibm.com

(678) 248-3727

.................................................................................................

Links: IBM Security | Data Security | Emergency Response |

[JayGuillette]

The FQDN is bound as the CN within the device identity certificate of an AM server, so you cannot simply make a DNS entry.  You already heard about our Web Tier, only other option would be for you to build your own reverse proxy that terminates the SSL connections of your users and builds a new connection to the real name of the Self service.  Kind of a lot of work compared to deploying a Web Tier (which also offloads Self Service Admin work from the primary and blocks access to the Security console which runs on the same port.

[MayaCondomitti]

Hi Xiao-Li, sorry to hijack your post.

That is a really interesting post as we are facing a similar problem - exposing the self service console to internet without any luck . We've been down the road of using Apache reverse proxy but getting issue with rewriting rule .

Jay, can you clarify what you mean with "Web Tier" and forward to where to find documentation. Also , about "build your own reverse proxy" , can you forward to any documentation that could help achieve this.

Thanks, 

Maya

[JayGuillette]

A Web Tier is an Authentication Manager application that installs on a Red Hat Linux or Windows 2008R2 /Win2012R2 server (VM or physical, but may have problems if Linux hosted AWS server) that is the easiest way to safely present Self Service console to the Internet.  

You need your Windows or RHEL server, but I would not have IIS or any web server included, just the OS.  Then from the AM extras folder, find the Web Tier application that you will install.

In the AM Operations Console, you need to create/configure the Web Tier(s), generate a Web Tier Package that will be used during the Web Tier Installation.  Under Deployment Configuration

You can also put a Load Balancer, like an F5 or Citrix NetScaler, to act as a virtual host for users on the Internet.  For that configure a Virtual Host, also in the Ops Console

You can use RSA self-signed Certificates or use your Private or a Public CA to sign your Cert for the VH.  You can even terminate SSL connections on the Load Balancer by exporting the private key for the Virtual host from AM.