sa

Upgrade Juniper SA cluster

Add On: This procedure also works for the new Juniper MAG appliances. But keep in mind during the upgrade of the second host (and also the first): BE PATIENT!!

A Juniper SA cluster can be configured as active/active or active/standby cluster. An active/active cluster uses an external load balancer or DNS round-robin to enable load-sharing across multiple appliances. Today I had to upgrade an active/standby cluster and found an KB article on the Juniper website (restricted access) about the preferred upgrade method.

Juniper uses the following steps to upgrade a cluster:

1. Login directly to a member in the cluster as administrator;
2. Disable the member from the cluster;
3. Upgrade the service package on the disabled member;
4. After the upgrade is completed login back to the IVE and enable the disabled member in the cluster configuration;

The following notes are mentioned by Juniper:

In active/standby cluster mode, it is recommended to start the upgrade process with the passive members and after completing the upgrade on the passive IVE and moving to the upgrade of the active IVE please note all connections are dropped when the active IVE is disabled. However after disabling the active node the passive IVE becomes active;
Once the upgraded member is enabled back in the cluster, it shows the other nodes as Unreachable. This is expected behavior as the cluster members are running different versions and hence cannot sync with each other;
Once the second IVE is being upgraded all user connections are dropped and not migrated due to the mismatch of software versions. This limitation is addressed in 4.0 with the Minimal downtime cluster upgrade available in the licensable Central Manager feature set;

I followed the steps mentioned above and the upgrade of the IVE cluster went smoothly. I disabled the passive node and upgraded the firmware with the new package. After the upgrade (and a reboot) the passive node was reachable in standalone mode. Next I logged in to the active IVE and enabled the passive node back into the cluster. When you hit Enable you receive the warning message that the configuration of the new cluster node will be erased and overwritten with the configuration of the active node. Just choose Yes.

After enabling the passive node, you will loose your web session with the active node. The VIP address is taken over by the new node in the cluster and the “old active” node starts updating automatically. This is a little tricky, because you don’t notice anything from the update process taken place. Just have patience and ping the node to check when it is online again. When the node is back online, login to the IVE and check the Cluster Status. Both IVE are now updated and members of the cluster. You could decide to do a manual Fail-Over IP to the “old active” node so everything is back to the original state before the upgrade.

Juniper SA – Host Checker

Security is getting more and more important for people. I notice that especially IT manager would like to implement some kind of security measurements to improve the safety of their network and data. Lately I have been busy with configuring a Juniper SA solution. The customer wants to publish different kind of services through the Juniper SA to his employees or suppliers. Example of these services are file sharing and full IPSec tunnels. When using file sharing and full IPSec tunnels, the use of a virus scanner is arbitrary for all workstations connecting to the customers network through the Juniper. Juniper provides an option to configure a Host Checker to check if the client has a (specific) virus scanner. This kind of predefined check only works with Windows clients.

I wanted to configure a predefined Host Checker for all the Windows clients connecting to the Juniper SA box. The configured policy checks all Windows clients on a, by Juniper supported, virus scanner. This works perfectly, but I noticed at all Linux and Mac OS X users weren’t able to connect anymore. When configuring a Host Checker policy for Windows, you also have to configure a policy for other OS-users, like Linux and Mac OS X.

I didn’t know which policy to configure for these users, because the outcome of the policy check should be positive at all times. I have the option to check the presence of a specific file. This gave me the idea to configure a dummy file check for Linux and Mac OS X clients. The dummy file check has the following properties:

The policy checks the presence of the file mac_dummy_file. To pass the host checker test, the file should NOT be present of the client. I configured a similar rule for Linux clients. By configuring the policy like this, all Windows clients are checked on the presence of a virus scanner and the Linux and Mac OS X hosts are checked on the dummy file. Normally, the dummy file doesn’t exist on the specific Linux / Mac OS X clients, so they are always allowed access to the Juniper.

I guess it’s a nice workaround….

Juniper SA & Terminal Service with JavaRDP

Today I tried to configure a JavaRDP as fallback Terminal Services method on the Juniper SA appliances. It took me some time and with help of my colleague, I finally got it working. Even with Single Sign On to the Terminal Server.

First of all, you need to upload a new Java applet. The Java applet I use can be downloaded here:

JavaRDP14-1.1.zip

I use the JavaRDP provided by Elusiva. After uploading the JavaRDP applet I created a custom HTML page for the JavaRDP applet, like shown below:

<html>
<head>
<title>Booches RDP Applet</title>
<meta http-equiv=”Content-Type” content=”text/html; charset=iso-8859-1″>
</head>
<!–
Notes:
1) << CODEBASE >> is a system value that will get replaced at the time the applet is launched. Please do not modify this value.
2) Please modify the remaining values as needed.
3) Please make sure all attribute names/values are enclosed in double quotes.
–>
<body>
<applet code=”com.elusiva.rdp.applet.RdpApplet.class”
codebase=”<< CODEBASE >>”
archive=”JavaRDP14-1.1.jar”
width=”1024″ height=”768″
name=”Booches RDP” align=”top”>
<param name=”code” value=”com.elusiva.rdp.applet.RdpApplet.class”>
<param name=”codebase” value=”<< CODEBASE >>”>
<param name=”archive” value=”JavaRDP14-1.1.jar”>
<param name=”cabbase” value=””>
<param name=”name” value=”Booches RDP”>
<param name=”width” value=”1024″>
<param name=”height” value=”768″>
<param name=”align” value=”top”>
<!–
Please specify additional params here after the comment.
<param name=”paramname” value=”paramvalue”>
–>
<param name=”Server” value=”<<HOST>>”>
<param name=”Port” value=”<<PORT>>”>
<param name=”Username” value=”<<USER>>”>
<param name=”Password” value=”<<PASSWORD>>”>
</applet>
</body>
</html>

The solution works like a charm!!!

Juniper SA & Terminal Server with Novell Client SSO

Normally configuring SSO on a Terminal Server in conjunction with a Juniper SA isn’t that hard. On the Juniper you pass the user credentials to the Terminal Server. On a normal Terminal Server you have to check the following:

Disable Always prompt for password under:

Terminal Services Configuration –> Connections –> Properties of RDP-tcp –> Tabblad Logon Settings

On a Terminal Server, which is member of a Windows Domain, you have to check the following Group policy:

Disable Always prompt client for password upon connection under:

Computer Configuration –> Administrative Templates –> Windows Components –> Terminal Services –> Encryption and Security –> Policy “Always prompt client for password upon connection”

Now I had to configure Single Sign On to a Terminal Server where the Novell Client is installed. As soon as I pushed the user credentials to the Terminal Server, I noticed that the RDP session tries to logon as Workstation only. I found a nice thread on the Novell website to Enable TSClientAutoAdminLogon.

I added the following two registry keys to the registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Novell\Login 
Value Type=REG_SZ, Name=TSClientAutoAdminLogon, Data=1 
Value Type=REG_SZ, Name=DefaultLoginProfile, Data=Default

I am able to logon to the Terminal Server using SSO after adding both registry keys to the registry. All registry entries under HKEY_LOCAL_MACHINE\SOFTWARE\Novell\Login are displayed in the picture below.

Juniper SA & GroupWise WebAcc SSO

While configuring a Juniper SA2500 in conjunction with Novell GroupWise WebAccess, the customers wanted single sign on (SSO) configured. The default Novell GroupWise WebAccess login page uses FBA (Forms Based Authentication). So it should be possible to push the correct POST parameters to enable SSO for GroupWise WebAccess.

I started with looking at the page source of the login page and found the POST configuration. You can find them by searching the string:

<form method=”post” action=”/gw/webacc” name=”loginForm” target=”_top”>

I configured a Web Resource Profile in the Juniper SA. This Resource Profile has a bookmark which displays the Novell GroupWise WebAccess page. Next I configured a Form POST Resource Policy. The picture below shows the configuration.

The table displays the POST detail settings:

User label	Name	Value
error	error	login
User.displayDraftItems	User.displayDraftItems	1
merge	merge	webacc
action	action	User.Login
Url.hasJavaScript	Url.hasJavaScript	1
Low.bandwidth	Low.bandwidth	0
User.interface	User.interface	css
User.Theme.index	User.Theme.index	1
Username	User.id	<USER>
Password	User.password	<PASSWORD>
User.lang	User.lang	nl
User.settings.speed	User.settings.speed	high

The above configuration works in my situation. The user is automatically logged in to their corresponding Novell GroupWise WebAccess page.