Tunneling sessions via Plink

Plink stands for PuTTY Link and is a command-line connection tool similar to Unix ssh. As a networking consultant I often need to support customers from remote locations. Access to their networking equipment is mostly blocked from unknown locations. Sometimes it is allowed to directly access networking equipment, like a company firewall, from a known location. An example of such a known location could be the public IP space of my companies headquarters.

But how can I support somebody if I am not at my companies headquarters? Most Unix boys already know the answer to that questions…. SSH (Secure SHell) tunneling.

To create a SSH tunnel you need a SSH server and a SSH client. Most Unix servers can be configured as SSH servers by installing OpenSSH. There are also a lot of SSH server applications for the Windows platform. I configure and place the SSH server at my  headquarters. Since the SSH server uses my companies “allowed” public IP space, the server could connect directly, if allowed, to the customers equipment.

By using the SSH tunnel I use my companies SSH server as some kind of man-in-the-middle server. I connect to my companies SSH server via a SSH remote connection. I configure the connection to forward certain localhost connections from my laptop through the SSH tunnel and let the SSH server setup a new connection to the final destination by forwarding the traffic.

An example would be accessing a Cisco ASA firewall via ASDM from my laptop. At first I create the SSH tunnel to my companies SSH server. I “tell” the connection to forward traffic to my localhost on port TCP/1234 to the SSH server and the SSH server should forward the connection to the customers firewall on port TCP/443. That means that my laptops ASDM application uses my companies public IP space to access the customers firewall. Since my companies public IP space is allowed to access the customers firewall, I can use ASDM on my laptop. Even if I am at a completely different location.

I use Windows 7 as operating system on my laptop, so for SSH tunneling I have to use a third-party application. I always use Plink, which I copy to the C:\Windows\system32 directory, so I can run it from the command-line. Plink can be configured with different parameters, like shown below:

PuTTY Link: command-line connection utility
Release 0.60
Usage: plink [options] [user@]host [command]
(“host” can also be a PuTTY saved session name)
-V        print version information and exit
-pgpfp    print PGP key fingerprints and exit
-v        show verbose messages
-load sessname  Load settings from saved session
-ssh -telnet -rlogin -raw
force use of a particular protocol
-P port   connect to specified port
-l user   connect with specified username
-batch    disable all interactive prompts
The following options only apply to SSH connections:
-pw passw login with specified password
-D [listen-IP:]listen-port
Dynamic SOCKS-based port forwarding
-L [listen-IP:]listen-port:host:port
Forward local port to remote address
-R [listen-IP:]listen-port:host:port
Forward remote port to local address
-X -x     enable / disable X11 forwarding
-A -a     enable / disable agent forwarding
-t -T     enable / disable pty allocation
-1 -2     force use of particular protocol version
-4 -6     force use of IPv4 or IPv6
-C        enable compression
-i key    private key file for authentication
-noagent  disable use of Pageant
-agent    enable use of Pageant
-m file   read remote command(s) from file
-s        remote command is an SSH subsystem (SSH-2 only)
-N        don’t start a shell/command (SSH-2 only)
-nc host:port
open tunnel in place of session (SSH-2 only)

The best way to use Plink is by creating a batch file, which can be run from the command-line. My batch file looks like this:

@echo off
plink.exe -v -x -a -T -C -noagent -ssh -L <username>@<IP SSH server>

The command configures a SSH connection to <IP SSH server> using username <username>. All connections from my laptop to on TCP/1234 are forwarded by the SSH server to the remote IP address on TCP/443. You can add more statements to the batch file, by just adding another –L command, like shown below.

@echo off
plink.exe -v -x -a -T -C -noagent -ssh -L -L <username>@<IP SSH server>

After executing the batch file, you will receive a login prompt to enter the user credentials for the SSH server. After entering the credentials you are ready to go. Just start ASDM or another application and connect to the localhost on port TCP/443 or TCP/22. The traffic will be forwarded through the SSH tunnel and from the SSH server to the final destination.

Of course you need to make some preparations to use this solution, like installing the SSH server and publishing the SSH server to the internet. You also need to have SSH access on the remote location, because else you cannot create the SSH tunnel.

Since you are publishing a server to the internet, it is important to “strip” that server. Make sure there are no vulnerable or unnecessary services running on the server and always patch the server to the appropriate level. It is also recommended to use some kind of two-way authentication, like one-time passwords. That way you know you have a secure environment to access the assets at the final destination.

In the end you will have a secure environment with which you can support your customers or access other resources on the internet or on your internal network.

Restore RSA 7.1 primary database and RADIUS config

A few days ago I was troubleshooting a problem with an ISA array after upgrading the VMware environment as you can read in this article. I had a same kind of problem with a RSA environment. After upgrading the VMware Tools and the Virtual Hardware, the RSA database didn’t start anymore. RSA noticed to much changes on the guest host, so we had to revert back to the “old” virtual machine.

To upgrade the VMware Tools and the Virtual Hardware I had to install a new server and restore the RSA primary database on the new server. The process for restoring the primary database can also be found in the RSA Administrator’s Guide.

There are two methods to restore the primary database:

  1. 1. Restore the database directly to the primary instance;
  2. 2. Promote a replica instance to be the new primary instance and restore the database to this primary instance;

I decided to use the first method, since we didn’t use a replica instance, and started installing a new server. I installed the new server under VMware. After the pre-installation I moved the server to another VLAN (port-group). I changed the hostname and the IP address of the new server to exactly the same hostname and IP address of the “live” RSA server. Next I installed a RSA AM7.1 SP2 primary instance with its default settings.

On the “live” RSA server I opened the RSA Operation Console to create a backup of the primary database (Maintenance – Backups – Create Backup).

rsa_backupThe backup process creates 3 separate files. This files need to be copied to the newly installed server. The *.dmp file is the file which contains the actual database configuration and is the most important. To restore the database on the new server, I had to take the following steps:

  1. 1. Remove all replica instances: Operations Console – Deployment Configuration – Instances – Manage Existing;
  2. 2. Stop all Authentication Manager Services on the server;
  3. 3. Restart the internal database: RSA Authentication Manager Database Server and RSA Authentication Manager Database Listener;
  4. 4. Open a new command prompt and change directories to %RSA_install_root%\utils;
  5. 5. Remove the primary database: rsautil setup-replication –a remove-primary;
  6. 6. Import the files into the database: rsautil manage-backups –a import –D –f absolute path, where absolute path is the absolute path and filename of the backup file, like C:\RSA_Backup\DB_Backup.dmp;
  7. 7. Reset the primary metadata: rsautil setup-replication –a set-primary;
  8. 8. Start the Authentication Manager primary instance;

The above steps help you restore the RSA database, but you still need to restore the RADIUS configuration separately. To restore the RADIUS configuration you first need to backup the RADIUS configuration from the “live” server. Creating a backup of the RADIUS configuration is very straightforward. You just need to copy the directory %RSA_install_root%\radius. To restore the RADIUS configuration on the new server, I had to take the following steps;

  1. 1. Stop the RADIUS server and make sure the RSA Authentication Manager is running: RSA Radius Server 7.1;
  2. 2. Overwrite the existing RADIUS installation directory with the backup data;
  3. 3. On the new RADIUS server, open a new command prompt and change directories to %RSA_install_root%\config;
  4. 4. Restore the RADIUS configuration: configUtil.cmd configure radius finalize-radius-restore;

The RADIUS server service is restarted automatically after executing the command above. After restoring the primary database and the RADIUS configuration you can shutdown the “live” server and change the network configuration (port-group assignment within VMware). The new server should be working directly. At least, it did for me.

If your configuration consists for one or more replica instances, you should perform the following steps for each replica instance:

  1. 1. On the primary instance, in the Operations Console, generate a replica package for all replica instances: Deployment Configuration – Instances – Generate Replica Package;
  2. 2. On the replica instance, in the Operations Console, provide the location of the replica package generated in the previous step;
  3. 3. On the replica instance, in the Operation Console, attach the replica instance: when the replica instance is successfully attached, all services on the replica are restarted;

If you use the On-Demand feature and you publish the RSA Self-Service portal via the reverse proxy solution, like a Microsoft ISA server, you should pay extra attention to the certificate chain configuration. The new server uses a different self-signed root certificate to sign the SSL certificate of the RSA Self-Service webpage. You need to import the new root certificate on the reverse proxy server and you should be ready to go.

Once I tried to restore the primary database with the second method (promoting replica to primary). This method wasn’t easy in my opinion and resulted in multiple error messages and an unsuccessful migration. I like the first method, because it is very straightforward and there isn’t a lot of downtime.

Windows LDAPS expired

A lot of appliances and/or security solutions use LDAP to synchronize users from an Active Directory or an eDirectory environment. Active Directory is LDAP enabled by default. If you would like to harden your network,  you would like to use LDAPS.

LDAPS is a term to refer to LDAP communication over SSL. Intercepted LDAPS traffic cannot be read easily by hackers. In an Active Directory environment you need to have at least one Certificate Authority (CA) to enable LDAPS. Windows uses Server Authentication certificates for the LDAPS operations.

Last week I had a customer complaining that people weren’t able to access their webmail via a Microsoft ISA reverse proxy. The cause of the problem was an expired Server Certificate on the specific domain controller. The reverse proxy server uses LDAPS to authenticate the user against an Active Directory. The following event log was found on the reverse proxy server.

ldaps-error To resolve the problem I had to renew the Server Authentication certificate on the domain controller. I decided to use the “Windows method” by using the Windows CA to renew the certificate. From the domain controller with the expired certificate I opened IE and enter the URL:

http://<IP address CA>/certsrv

This opens the Microsoft Certificate Services webpage of the CA. The following screenshots show the request and installation procedure for the certificate renewal.

01_request-certSince I had to renew a Server Authentication certificate, I choose the option Request a certificate.

02_advanced To request a Server Authentication certificate I choose the option advanced certificate request.

03_create-and-submit Normally I use OpenSSL to generate the certificate signing request, which is submitted to the CA. In that scenario I had to choose option 2. This time I decide to generate the csr via the webpage and choose the first option: Create and submit a request to this CA.

04_webserver The csr is generated with the information from the screenshot above. Because I had to renew a Server Authentication certificate, I choose the Web Server certificate template. The Name field is very important and should match the FQDN of the LDAPS server. It is also important to select the Store certificate in local computer certificate store option. This ensures that the certificate isn’t installed in the user’s certificate store, because the certificate cannot be exported with private key.

When you submit the certificate request, you have to wait until the request is approved. The approval has to be done by someone who manages the CA environment. If you open the CA MMC snap-in you will see one or more pending request. The pending request needs to be approved. After the request was approved, I browsed to the Microsoft Certificate Services webpage, like shown below.

05_status_pendingI choose the option View the status of a pending certificate request. Remember that I did the whole procedure on the LDAPS server to be sure that the certificate is stored in the servers local computer certificate store. The last step involves installing the certificate in the local computers certificate store. After the installation I always check the store to see if the private key is present for the certificate.

06_install_certThe renewal of the certificate is almost done. The LDAPS services depends on the process LSASS.exe. To “associate” the SSL certificate with the LDAPS server I needed to reboot the server. During the reboot the first valid Server Authentication SSL certificate within the local computer certificate store is used by the LDAPS server.

The reverse proxy server was able to use LDAPS again after the reboot of the specific domain controller.

RSA AM 7.1SP3 Token Delivery

Using two-factor authentication is common when publishing remote services to the internet with components like Citrix NetScaler or Juniper SA appliances. RSA is a well-known provider of two-factor authentication mechanism.

Beginning with RSA Authentication Manager 7.1 people have the ability to use the On-Demand feature. This feature enables the delivery of token codes via SMS or e-mail. When using this feature you had to publish the RSA Self-Service website to the internet, so users can request a token code. The RSA Self-Service website is displayed below.


The procedure for opening a extra website to request an On-Demand token is difficult to understand for many people and increases the risk of problems and errors during the authentication process.

This behavior is changed in RSA AM 7.1SP3. With SP3 the Authentication Agent has possibility to generate the On-Demand token request on behalf of the user. The procedure to login to the Authenticaton Agent is:

  1. 1. Browse to the portal website
  2. 2. Enter your user credentials (username + password)
  3. 3. Enter only the token PIN code
  4. 4. The Authentication Agent generates the On-Demand token request and redirects the user to a website to enter the On-Demand token code
  5. 5. The user waits for the delivery of the token via SMS or e-mail
  6. 6. The user enters the On-Demand token code on the Authentication Agents website
  7. 7. The Authentication Agent validates the token code and displays the web portal

This way the delivery of token codes is less prone to problems and errors during the authentication process. I personally like this new feature.

User expiration with RSA AM 7.1

I noticed some differences in the user expiration between RSA Authentication Manager 7.1 and RSA Authentication Manager 7.1 SP2. When assigning a token to an user in RSA AM7.1, the user automatically gets an expiration date set on its user account. The default expiration date is one year. I cannot reproduce this same symptom with RSA AM7.1SP2. When I assign a token to an user, the user doesn’t get an expiration date set. I prefer this behavior above setting an expiration date on the user. Setting an expiration date means extra administrative burden for system engineers.


When an user account expires, the user doesn’t have the opportunity to log in on an Authentication Agent. When using the Real-time Activity Monitor, you will see an error message for the specific user with the reason “Principal account expired”.

I configured the reporting functionality to generate reports on monthly basis to filter all user account which expired within the next X days. You can use the built-in template “Expired User Accounts” to generate the report. Next I created a scheduled report to run every last day of the month. This way system engineers can proactively monitor which user account will expire in the near future. One drawback from the scheduled report functionality is lacking the ability to send the report to an mail account. You have to log in to the RSA Security Console to view the reports.