RSA ID Plus

RSA Authentication Manager (8.7 SP2 and later)

RSA Identity Router (embedded AM only)

The following IP addresses and subnets are used by default internally within RSA Authentication Manager (AM) server, for networking between AM and its embedded RSA Identity Router (IDR). 

When embedded IDRs are used, subnets for the Bridge and Docker interfaces must be reserved in the organization's network strictly for embedded IDR use only.  The same subnets can be used on every AM server, however if either of those subnets is routable in the network for anything else, then issues will occur. Impacts are dependent on IP usage and routing.  Common impacts are:

• Unable to access the IDR's login page after clicking the Configure Identity Router button during IDR setup
• After downloading and installing an IDR, AM Security Console and Operations Console become inaccessible from computers with IPs in the 172.19.x.x and 172.17.x.x ranges
• If AM itself (or the administrators, agents, other AM servers in the deployment or LDAP/domain controllers communicating with AM) uses an IP in the 172.19.x.x or 172.17.x.x ranges, all network access to AM will be lost.  Authentications will fail.  AM management consoles and normal SSH will be unavailable.  AM will only be accessible via out-of-band methods (KVM, VM console, iDRAC, serial cable, etc).

To fix such issues, the default subnet(s) in AM must be changed to unused subnet(s).

The steps in this KB explain how to manually change the two AM virtual interfaces in AM to any unused private subnets of your choice.  If you are changing the subnets, do the same steps on every AM server in your deployment that will be running an embedded IDR.  Note: the same two subnets can be used on every AM server.

Part A: Select Alternate Subnet(s) and IP(s)

Part B: Preparation

Part C: Change the Bridge subnet

Part D: Change the Docker subnet

Part E:  Apply the changes

Part F: Check the changes

Part G: Ongoing Maintenance

Part A: Select Alternate Subnet(s) and IP(s)

Check with your organization's network team to select unused private subnets that can be used instead of 172.17.0.0/16 and/or 172.19.0.0/16 .   The two subnets must meet the following requirements:

• They must not overlap with each other or any other subnet used in the enterprise network.
• They can be as small as /30 because only two IPs are needed for the Bridge interface and one IP for the Docker interface.
• The selected subnets can be class A, B or C.   They do not both have to be the same class.
• Any two usable host IPs must be chosen from within the new Bridge subnet and any one usable host IP from within the new Docker subnet
• You can change just the Bridge subnet or just the Docker subnet.  You do not have to change both if there is overlap with only one of the subnets in the enterprise network.

We will use the below new subnets and IPs as examples in this KB.

Part B: Preparation

1. If not already done, audit the enterprise network to ensure the new replacement subnets do not overlap with any other existing or planned internal networks.
2. Identify a folder where backups of original script files will be saved.  /tmp is used in the examples below.   Backups must not be saved to the original scripts folders because AM configuration tools or future patch/upgrade scripts may inadvertently process or copy backup files in scripts folders.
3. Save a VM snapshot of AM if possible.
   • An AM backup alone is not sufficient - it does not back up the files modified by these steps and cannot be used to reverse these changes.
4. Remove the Embedded Identity Router from RSA Authentication Manager
5. SSH to the AM server and login as rsaadmin.

Part C: Change the Bridge subnet

Perform these steps if the Bridge interface's subnet needs to be changed.

1. Take backups of files IDRSoftware.groovy and ifup-rules .  Tip:  if you have to do Part C again in future, use a different filename suffix next time (not orig) for the backup copy, so you don't overwrite the original files:

cp /opt/rsa/am/config/src/scripts/IDRSoftware.groovy /tmp/IDRSoftware.groovy.orig
cp /etc/sysconfig/network/scripts/ifup-rules /tmp/ifup-rules.orig

2. Edit the IDRSoftware.groovy script:

sudo vi /opt/rsa/am/config/src/scripts/IDRSoftware.groovy

1. Search and update the values for idrContainerIPAddress and idrNetworkSubnet as seen below.

3. Modify the routing policy database rules:

sudo vi /etc/sysconfig/network/scripts/ifup-rules

Search and update as shown below:

ip rule add to 192.168.1.0/24 table main priority 0

Part D: Change the Docker subnet

Perform these steps if the Docker interface's subnet needs to be changed.

1. sudo to root:  

sudo su -

2. Take a backup of file /usr/lib/systemd/system/docker.service.  Tip:  if you have to do Part D again in future, use a different filename suffix next time (not orig) for the backup copy, so you don't overwrite the original backup file:

cp /usr/lib/systemd/system/docker.service /tmp/docker.service.orig

3. Edit file /usr/lib/systemd/system/docker.service 

vi /usr/lib/systemd/system/docker.service

4. Find the line in the file that starts with ExecStart=/usr/bin/dockerd.  Then add --bip "192.168.2.1/24" (or your selected docker0 gateway IP and subnet prefix length) at the end of that line, as shown here:

ExecStart=/usr/bin/dockerd --add-runtime oci=/usr/sbin/docker-runc $DOCKER_NETWORK_OPTIONS $DOCKER_OPTS --bip "192.168.2.1/24"

Part E:  Apply the changes

1. Check you have uninstalled the embedded IDR before proceeding!  See Part B: Preparation above.
2. Remove the old Docker bridge network if present:

docker network rm idr-network 2>/dev/null

3. Reboot AM.  Do this from Operations Console if possible to ensure orderly shutdown of AM services.   See Reboot the Appliance.  If Operations Console is not available, reboot from the command line:
   1. Stop AM services

/opt/rsa/am/server/rsaserv stop all

1. 2. Verify Services Have Stopped

/opt/rsa/am/server/rsaserv status

1. 3. Reboot the Appliance OS

sudo /sbin/shutdown -r now

3. Download, reinstall and configure the IDR (triggers IDRSoftware.groovy).

4. • In Security Console, go to Setup > System Settings > RSA Cloud Authentication Service Identity Router.

Part F: Check the changes

1. SSH to AM and login as rsaadmin
2. Run ifconfig to check
   • the "br-" interface is listed with the new Embedded IDR management subnet with the correct IP and netmask and 
   • the docker0 interface is listed with the new Embedded IDR docker subnet with the correct IP and netmask
3. Check the routing table.  Below is an example where only the Bridge interface had been modified.  The Docker interface was left unchanged.

netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.101.56.1     0.0.0.0         UG        0 0          0 eth0
10.101.56.0     0.0.0.0         255.255.254.0   U         0 0          0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 br-53a16a36c0e5
172.17.0.0      0.0.0.0         255.255.0.0     U         0 0          0 docker0

4. Check network routing.  In the below example both Bridge and Docker interfaces had been modified.

netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.101.56.1     0.0.0.0         UG        0 0          0 eth0
10.101.56.0     0.0.0.0         255.255.254.0   U         0 0          0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 br-53a16a36c0e5
192.168.2.0     0.0.0.0         255.255.255.0   U         0 0          0 docker0

5. Test RSA Cloud Authentication Service and AM authentications.

Part G: Ongoing Maintenance

The steps in this KB modify the following files:

• /opt/rsa/am/config/src/scripts/IDRSoftware.groovy
• /etc/sysconfig/network/scripts/ifup-rules
• /usr/lib/systemd/system/docker.service

These files are not backed up in an AM backup.  Take and store manual offline copies of the modified files.

Restore

Restore scenarios:

• As these files are not backed up by AM backup they must be restored manually during disaster recovery.
• The files may be modified by changes, patches, or upgrades, so may need to be restored manually following maintenance.