| Follow me on:

Juniper SA – Host Checker

May 19th, 2009 | No Comments

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:

Host Check

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

May 12th, 2009 | 3 Comments

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

May 12th, 2009 | No Comments

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.

SSO_TS_novell_client

Juniper SA & GroupWise WebAcc SSO

May 6th, 2009 | 1 Comment

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.

JuniperSA-gwwebacc-sso

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.

Secret Barracuda Spam firewall options

May 4th, 2009 | No Comments

While troubleshooting a Barracuda Spam Firewall 300 I found a forum on internet, which shows you how to get an extra tab under the Advanced configuration of the Barracuda Spam Firewall. The “secret” configuration page is enabled with the following steps:

  1. Logon to the Barracude Spam Firewall 300;
  2. Click on the Advanced tab;
  3. Add &expert=1 at the end of the URL and hit enter;

You will now get the extra tab Expert Variables like shown below.

barracuda_advanced_option

  • my Tweetz

    • Going to install new PacketShaper licenses in an hour. The installation steps from BlueCoat are very clear... hope the installation is too 3 days ago
    • Just met some former class mates from 15 years ago. It's funny to hear what everbody is doing nowadays 3 days ago
    • Mysteryland is over. We had a great time. We saw great dj's and herad some good sets. And only 2 drops of rain!!! 5 days ago
    • We arrived at Mysteryland. The party can begin http://moby.to/22oq2q 5 days ago
    • Online mysteryland in de zwembroek ciao 6 days ago
    • More updates...

    Powered by Twitter Tools

  • Advertisements