Firewall Ports for Token-to-RSA-Server Communication

[BENJAMINMORRIS]

Hi RSA folks,

In the document000024531 - Which firewall ports need to be open for RSA SecurID 5.2-6.1 to work properly? , there are some helpful rules on what ports need to be opened between authentication agents and the RSA servers.

However, I didn't see any documentation about what ports need to be opened to allow the RSA Software token to connect to the RSA server.

I have exported the .CTF for my token and successfully transferred it to my Android device. However, when I click the link (beginning with 127.0.0.1), the Token App throws an error for 'Error communicating with server. Token import failed.'. There is no record of this communication on the server, so I expect this is a firewall/network issue.

How can I enable communication between my token software and my RSA server?

[EdwardDavis]

The RSA software token app only needs to connect to the RSA server itself, if you are using ctkip to the self service console, that is tcp port 7004.

If you are ctkip to a web tier, that will be the web tier port you select when installing the web tier (typically 443).

So, RSA server = 7004/tcp...web tier = port you set up

see my other reply below for more

[JayGuillette]

Hey Benjamin,

A couple of points;

That document is for Primary and Replica AM server communication, Older versions of ACE 5.2 to 6.1.x, and Those TCP ports 5505..5515 were database replication ports, so translate that to TCP port 7002 in AM 8.x 

Authentication Agents, Windows Servers, VPNs from Cisco, Juniper, CheckPoint, the list goes on..., communicate to AM servers over UDP 5500, with some new agents that need IPv6 communicating of TCP port 5500.  Windows agents in particular need access to TCP port 5580 on the AM servers for offline data and Windows Password integration.  On an AM protected server or VPN, you would enter your TokenCode or PassCode, but it would be sent over the agent port, most likely UDP 5500, but in new and less rare cases over TCP 5500.

The software tokens (and hardware tokens for that matter) do not communicate when they are running, they are basically synchronized to what the AM server has for that token Serial Number, so both calculate the same tokencode at the same time.

With a software token Device, e.g. on a Smart Phone or Windows PC, you need the software token application installed for that Device, which you download from the Smart Phone App store or from RSA Link here, then you need a Token, or more specifically a TokenSeed.  The AM server has to Distribute this software Token to the User it is assigned to, and that specific software token can either be a file (.sdtid extension) which you might email or hand deliver, or through an encrypted link known as CTKIP, basically a URL.  This is communication between a Device and the AM sever. If you are coming through the Internet, you would need something called a Web Tier.  If you were on an internal LAN inside your Corporate FireWall, the CTKIP URL would go against the AM Server TCP port 7004, which is also used for Self-Service and for Security Console Administration work, so you should not open this port to the Internet.

 The attached PDF covers a lot of Software Token Basics

[EdwardDavis · Accepted solution]

When using Android, any URL with 127.0.0.1 may mean CTF (and a live connection is never needed) or CTKIP (a live connection is needed). The 127.0.0.1 with CTF is telling the Android...do this action locally...so, if you are using CTF, there is never a need to network anywhere, the entire token and encryption scheme is contained in that rather long CTF URL with 127.0.0.1.

If there are issues with CTF, then it is an Android RSA software token app version token problem, or the version of Android and CTF format is incorrect, or something along those lines. Perhaps it is formatted incorrectly or a part of it is chopped off. The Android RSA Software Token app admin guide states the correct way to format a CTF URL. 

Can you show us here the entire CTF URL (but mask the long encrypted series of numbers) ?

[keep the same number of characters, just change them up manually to invalidate the actual long code in there....]

Here is an actual token Android 1.0 CTF URL (this is a valid one for device type a01c4380-fc01-4df0-b113-7fb98ec74694)

http://127.0.0.1/securid/ctf?ctfData=200013225166546230222524415334322670514042340117474544245172163270570273072652053 

Here is an Android 2.0 CTF URL (this is a real token, anyone can install this if the identifier a01c4380-fc01-4df0-b113-7fb98ec74694 matches)

http://127.0.0.1/securid/ctf?ctfData=200013225166526237115414626360141621646311744315714767165172163270174753072636237 

Do any of mine install ?

The URL link must start with the following prefix text:
http://127.0.0.1/securid/ctf?ctfData

[BENJAMINMORRIS]

Ah....I think that's what my issue is. Somehow the link I was using got switched up.

What I had was:

http://127.0.0.1/securid/ctkip?scheme=https&url=tdss-vrsa01.test.lab:7004/ctkip/services/CtkipService&activationCode=001… 

But I got the right URL (long string of numbers) after exporting again. Oops. User error.

Thanks to both of you -- your support is excellent!

[EdwardDavis]

In your example URL you were using CTKIP, and the port there would have been 7004. That URL tells the device to go internal (127.0.0.1) and then the app would see the test lab address, and attempt a real connection on port 7004...if the entire URL was formatted correctly for the device-type. [ URL Formats have changed periodically over the years.]