Booches.nl

Microsoft UAG – Invalid External Port bug

Last week I have installed a Microsoft UAG array. I installed Microsoft ForeFront Unified Access Gateway 2010 including Service Pack 1. When using an array configuration you have to deploy Microsoft’s Network Load Balancing (NLB) for redundancy and load balancing purposes. I configured NLB with multicast and IGMP support. I had configured some HTTPS trunks and some HTTP trunks for http-to-https redirection.

Everything was working perfectly and I decided to install the update KB2585140 (ForeFront UAG SP1 Update 1). The main reason for installation was the introduction of SharePoint 2010 with Office Web Apps and Lync web services publishing.

The installation process was easy and completed without any errors. I noticed that after installing the update I couldn’t activate any configuration changes. Everything I hit Activate I receive the following error message:

The Activation works again by deleting all HTTP trunks and only use HTTPS trunks. The customer started a support call with Microsoft and Microsoft acknowledges this behavior when installing the update on an array configuration. At first Microsoft advised to “break” the array and use a stand-alone server deployment. If that isn’t an option we should uninstall the update. We are told that the current configuration will get to the configuration state prior to the installation.

This morning the customer received another e-mail from Microsoft stating at more and more calls were logged with the same issues. The issues now has the highest priority for the Microsoft UAG developers. Microsoft couldn’t tell when the issue will be fixed, but I guess very soon.

So when using a Microsoft UAG array configuration DON’T install Microsoft UAG SP1 Update-1.

ISA Server 2006 array – renew certificate

When configuring a Microsoft ISA Server 2006 array you have two options for authentication and communication between the Microsoft ISA 2006 Configuration Storage Server and the array members.

• Windows Authentication: Choose this option if ISA server and the Configuration Storage server are in the same domain, or in different domains with a trust relationship between them. The connection will be encrypted (signed and sealed);
• Authentication over SSL encrypted channel: Choose this option if ISA server is in a domain that does not have a trust relationship with the Configuration Storage server domain, or if it is part of a workgroup. The connection will be SSL encrypted.

I normally configure the array members within a DMZ environment en install the CSS server on the internal network.

To maximize the security the array members aren’t part of the Active Directory. So communication between the CSS and the array members is workgroup based and the authentication type used is Authentication over SSL encrypted channel. This option needs the configuration of SSL certificates to authenticate and secure the connection. The certificates have a certain validity period, after which the certificate needs to be renewed.

Normally I always ran the repair option from the installation and specified the new certificate. I discovered a new and simpler method by using the ISACertTool. This tool provides an easy way to renew the certificate on the Configuration Storage Server and the root CA certificate on the array members.

You just need to create a web server certificate in pfx format from a Windows CA server of any other CA server. If the CA server isn’t trusted by the array members, you need to install the CA certificate on the array members. If you use trusted CA server certificate, you can skip this step.

The syntax for the ISACertTool is very straightforward. On the Configuration Storage Server you need to run the following command:

ISACertTool.exe /st <pfx file> /pswd <password> /keepcerts

On the array member you run the following command to install the root CA certificate.

ISACertTool.exe /fw <root ca file>

IMPORTANT: for a correct usage of the tool you need to extract the tool to the Microsoft ISA Server install directory, which is by default C:\Program Files\Microsoft ISA Server.

Windows CA template – web server and private key export

Creating a web server certificate request is very easy when using a Windows CA server. There is one disadvantage. The requested certificate is directly stored in the user store (by default) or the local computer store, if specified during the request. The disadvantage is that you cannot export the requested certificate including the private keys. During the request the option to Mark keys as exportable is grayed out.

There is a way to mark the keys as exportable when using a Windows CA server. You need to create a new Web Server Certificate template. You can use the existing Web Server Certificate Template as default and copy the current settings. To do so, you just:

• run certtmpl.msc, which will open the Certificate Template snap-in;
• click the Web Server certificate template;
• choose Action – Duplicate Template;
• configure a unique template name;
• choose the tab Request Handling;
• enable the option Allow private key to be exported;

That is all you need to do. You can now request a new certificate with the newly create certificate template. After the certificate is issued and installed on the user or local computer store, you can export the certificate including the private key.

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)
Options:
-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 127.0.0.1:1234:80.101.152.38:443 <username>@<IP SSH server>

The command configures a SSH connection to <IP SSH server> using username <username>. All connections from my laptop to 127.0.0.1 on TCP/1234 are forwarded by the SSH server to the remote IP address 80.101.152.38 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 127.0.0.1:1234:80.101.152.38:443 -L 127.0.0.1:1235:1.1.1.1:22 <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).

The 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.