Novell Access Manager is already an established, flexible, and comprehensive access management solution. However access management casts a wide shadow and sometimes you just want a simple solution to a difficult problem. One of those often difficult problems to solve is how to allow your mobile users to have secure and easy access to your internal network resources. Sure there are a lot of solutions available to solve this problem. But most are either difficult to control and use like IPsec based VPNs with big fat clients that have to be installed and managed on every workstation that needs access. You can ease this pain using a hardware based appliance, but they are often quite expensive. Well now there is a simple and cost effective solution using Novell Access Manager 3.1. Now you can install all the components you need on a single server to form an SSL VPN soft appliance. This cool solution will walk you through the entire installation process so you will have a working and tested solution when you are done.

My Goals with this Project and who this will help

The Novell Access Manager SSL VPN solution is a simple installation as you will see later. Still, the issue that arises with any remote access technology is how to evaluate it without a huge effort in building a lab environment to simulate a public (i.e. Internet) and a private (i.e. corporate) network. This can involve firewalls, routers, and the networking staff at your company. Of course you could build a test system on the production network, and that may be less overall work, but usually involves someone else’s network resources often requires a lot of red tape, albeit justified, with your corporate networking group. And if you are going to go through all that trouble, you may just want to skip the evaluation and just purchase Access Manager just to make life easier; after all, it is surprisingly inexpensive.

With all this in mind, I have a two main goals for this Cool Solution:

  1. Provide an easy-to-use guide for Novell customers to quickly build a lab environment, and evaluate the Access Manager SSL VPN solution and subsequently deploy a single server SSL VPN soft appliance. The build process, fully described in this Cool Solution with screen shots and advice, will also help you better understand how the product works and what things will be needed for the planning of a production roll out.
  2. Document the details of my setup so that others may mirror it for their own lab/evaluation.

In some ways these goals conflict with each other: simple and quick vs. a detailed lab instructions. So I have split this Cool Solution into two parts. The main section describes my test environment at a high level using it as an example to guide you through the installation and configuration process. In this section I assume that the reader already has or can quickly establish an appropriate lab network with little guidance. A more detailed Appendix is included that provides a lot more detail regarding my networking setup and how to build an evaluation system on one computer using virtualization. Before we get started, lets begin with a little background about Access Manager.

Novell Access Manager Background

When Novell Access Manager 3.0 was first released, it was hailed by analysts for incorporating web single sign-on, standards based Federation support, and secure remote access to both internal web based AND non-web based IT resources – all in one solution. Web single sign-on and secure access to web-based IT resources was nothing new for Novell; iChain had been providing these features for many customers since the year 2000 when it was first released. The introduction of Access Manager 3.0 represented a “next-generation iChain” moving from a very proprietary NetWare based solution to a standards and multi-platform based solution. Access Manager 3.0 supported multiple LDAP capable directories without schema extensions; supported federation standards including Liberty, SAML, and WS-Federation; and also included an SSL VPN server to provide secure access to non web-based IT resources. Putting all these features together allows you to have one solution that normally requires three independent technologies that have to be independently purchased, managed, and consumed – also requiring multiple identities/logins. Even though Access Manager combines all of these technologies into one integrated solution, each were delivered as individual components so that you could deploy only what you needed. But, there is always a “but”, the SSL VPN component relied on and required the Access Manager Access Gateway component to function. Now with the recent release of Access Manager 3.1 you can use the SSL VPN server either with or without the Access Gateway. You still need multiple Access Manager components but now they are all easily installed simultaneously on one server for you. For more information about what has changed to make this possible and a bit about Access Manager’s federation based architecture and its relationship to SSL VPN, read the note below or skip down to the fun part of building your new SSL VPN soft appliance server.

Why couldn’t Access Manager 3.0 be deployed as single server SSL VPN soft appliance?

Access Manager 3.0 provided many significant improvements over iChain including a new standards based architecture. Where iChain used Novell proprietary APIs and required Novell eDirectory, Access Manager uses open standards-based federation protocols between its components and uses LDAP accessible repositories for its user store. These changes make it easy for Novell to expose federation features to other applications that support the federation standards.

In a federated architecture there is the concept of an Identity Provider and a Service Provider (a.k.a Identity Consumer). In a nutshell the Identity Provider(s) provide authentication services for Service Providers. Service providers provide a service for users to use, like a web application, or service like SSL VPN. For an application or service to be integrated as a truly federated service, it must be federation enabled. The Access Gateway component of Access Manager allows you to “federation enable” your existing web servers without modifying the web servers in any way – no agents, no custom coding, and no proprietary vendor lock-in. Since most every one of Novell’s Access Manager customers use the Access Gateway, it made sense to use it to “federation enable” our SSL VPN server. Still some customers would be happy to use Access Manager just for its SSL VPN features. So starting with Access Manager v3.1, the SSL VPN feature has been natively federation enabled; in other words the SSL VPN server is federation aware on its own. That means that the SSL VPN feature can now be deployed with its own “embedded service provider” removing the need to use the Access Gateway to federation enable the SSL VPN server to federation enable the SSL VPN service.

Building an Access Manager 3.1 SSL VPN soft appliance

As mentioned previously, a lot will be assumed in this section – most assumptions are regarding networking, name resolution and time synchronization which are all important to your success. If you need more than the basics or desire a much more detailed process on how to build a test/lab environment using virtualization and a minimum of hardware, see Appendix A of this Cool Solution and of course the Novell Access Manager documentation.

Prerequisites

I took a minimalist approach for my setup because the main purpose is to get something working in a lab/test environment. To that end, I relied on virtualization, using VMware workstation. It goes without saying that VMware workstation would not be an appropriate platform for a real production deployment. However, Access Manager is supported under VMware ESX server or using XEN available with SLES. Also, for a real production deployment, you will want to use server class hardware scaled accordingly and possibly more than one for fault-tolerance and redundancy. Your network configuration may also differ as well. To understand what you will need for a production deployment here are some links/references for your convenience:

I built my environment using only two physical computers and two VMware Virtual Machines as briefly described below. Additional details about my specific configuration can be found in the Appendix A of this Cool Solution.

  • One physical SUSE Linux Enterprise Desktop 10 laptop to be my virtualization host using VMware workstation.
  • One physical Windows XP computer. This could have been a VM on my laptop but by using another physical PC, there is no denying that during testing the SSL VPN client is working and not able to get to your private network computers through other routes through my VMware virtual network configurations.
  • I used my home network as my public network and I used a VMware “host-only” virtual network for my private network.

If you follow my example used in this Cool Solution you will have a final configuration that looks similar to mine. Below is a logical representation of my final configuration simulating a public and private network where the Access Manager SSL VPN Server resides in a simulated DMZ.

Here is what you will need:

  1. Access Manager Evaluation Software
  2. One computer or VM for your SSL VPN soft appliance with:
    • Two network cards: one bound to your private network and one bound to your public network.
    • Operating System: Novell SUSE Linux Enterprise Server (SLES) 10 sp2 or better installed and built according to the Access Manager requirements for Linux (Identity Server Requirements). SLES 10sp2 can be downloaded from: SLES 10sp2 eMedia Kit. Details regarding my SLES installation are available in Appendix A.
  3. One computer or VM for your LDAP user store bound to your private network. This can be any eDirectory, Active Directory, or Sun One LDAP server. I already had VM with SLES10sp1 and eDirectory installed, so I used it.
  4. One computer or VM (physical computer preferred) for your SSL VPN Test Client bound to your public network.
  5. (optional) Download the restrict_console.sh script file to secure your Access Manager Administration Console.

Installation Overview

Once your computing and networking environment has been setup you are ready to start the Access Manager installation and configuration. There are only three steps to this process that I have separated into sections:

In the following sections I have used the networking addresses and setup described above as an example. Section 1 will follow the slightly abbreviated sample provided in the SSL VPN Installation Sample. I recommend that you review it before you start and keep a printout handy when you install for the first time. Each step below matches the steps in my sample configuration. Most of the prompts are self-explanatory so minimal guidance will be provided in this section. In my example, the public address is 192.168.0.41 and the private address is 172.17.2.111.

SSL VPN Installation Sample
1) ism-ids:~ # cd /mnt/cdrom
ism-ids:/mnt/cdrom #
2a) ism-ids:/mnt/cdrom # ./install.sh
Novell Access Manager Installer

2b) This installer detected that your NTP daemon was not started, so the NTP 
daemon has been started for you.  This installer made no effort to determine if your 
NTP configuration is correct, so there is still the possibility that Novell Access 
Manager will not work correctly because of invalid time synchronization.
Please make sure your NTP configuration is correct before continuing this install.
PRESS ENTER TO CONTINUE:

3) Please select the installation you wish to perform:
1. Install Novell Access Manager Administration
2. Install Novell Identity Server
3. Install Traditional Novell SSL VPN Server
4. Install ESP enabled Novell SSL VPN Server

3a) Select installation (1, 2, 3, 4 or QUIT)[1]: 1,2,4

4) IMPORTANT NOTE
You are attempting to install the SSL VPN server and this install program has 
detected that the High Bandwidth Key rpm for SSL VPN is not installed. The High 
Bandwidth Key rpm is not packaged with the SSL VPN install media in order to 
comply with the USA Export Laws. You can install the novl-sslvpn-hb-key rpm at 
any time later to turn on the High Bandwidth capability on this machine. Please refer 
to the documentation to download and install the novl-sslvpn-hb-key rpm.
PRESS ENTER TO CONTINUE:

5) Novell(r) Access Manager 3.1
Novell Software License Agreement
5a) ...
5b) DO YOU ACCEPT THE TERMS OF THIS LICENSE AGREEMENT (Y/N):y

6) Note: The administration server failover feature will not be enabled until a second server is added to the group.
6a) Is this the primary administration server in a failover group? [y]:y

7) You need to select the IP address used for the local Administration server
Please choose your server IP address from the following list of addresses found:
1 : 192.168.0.41
2 : 172.17.2.111
Select an address, type a new address or press enter to accept the default.
7a) [192.168.0.41]:192.168.0.41
7b) Enter the Access Manager Administration user ID [admin]:admin
7c) Enter the Access Manager Administration password []:
7d) Re-enter the password for verification []:

8) You need to select the IP address used for the Novell Access Manager Server
Communications Local Listener
Please choose your server IP address from the following list of addresses found:
1 : 192.168.0.41
2 : 172.17.2.111
Select an address, type a new address or press enter to accept the default.
8a)[192.168.0.41]:192.168.0.41

9) You need to select the IP address used for the SSLVPN listening IP address
Please choose your server IP address from the following list of addresses found:
1 : 192.168.0.41
2 : 172.17.2.111
Select an address, type a new address or press enter to accept the default.
9a)[192.168.0.41]:192.168.0.41

10)hostname = ism-ids.ism.utopia.novell.com
Hostname validation success

11)Installing Tomcat for Novell:                                        done
Installing Novell Access Manager Configuration Store:                   done
Setting up the Novell Access Manager Configuration Store:               done
Installing Novell iManager:                                     done
Configuring Novell iManager:                                    done
Installing Novell Audit Server:
                                                        done
Installing Novell Audit Platform Agent:                         done
Installing Novell Device Manager:                               done
Configuring Novell Device Manager:                              done
Installing Novell Identity Server Administration Plugin:                done
Configuring Novell Identity Server Administration Plugin:               done
Installing Novell Access Manager Server Communications:         done
Configuring Novell Access Manager Server Communications:                done
Installing Novell Identity Server:                                      done
Configuring Novell Identity Server                              done
Installing Novell SSLVPN:                                       done
Configuring Novell SSLVPN:                                      done
Configuring Novell Embedded Service Provider:                   done

12) Successfully installed the following components:
Tomcat for Novell
Configuration Store
Novell iManager
Novell iManager Configuration
Novell Audit Server
Novell Audit Platform Agent
Novell Device Manager
Novell Device Manager Configuration
Novell Identity Server Administration Plugin
Novell Identity Server Administration Plugin Configuration
Novell Access Manager Server Communications
Novell Access Manager Server Communications Configuration
Novell Identity Server
Novell Identity Server Configuration
Novell SSLVPN
Novell SSLVPN Configuration
Novell Embedded Service Provider Configuration

13) For information regarding this install look in the logfile directory found at
/tmp/novell_access_manager.

14) To configure the installed service, please log into the management console at
http://192.168.0.41:8080/nps using the user ID "admin".

15) Installation complete.
ism-ids:/mnt/cdrom #

Section 1: SSL VPN Soft-Appliance Installation

  1. On your server or VM that is to serve as your SSL VPN soft appliance, mount the evaluation .iso file (e.g. mount -o loop disk1.iso /mnt ) or the CD/DVD media (e.g. mount /dev/cdrom /mnt/cdrom).
  2. At the root of the .iso locate the installation script file: install.sh. Once you execute the script it will first perform some checks of your system which may take a while depending on your environment – so be patient. The installation process that follows may differ slightly from what you see in this document because of those checks. You will be prompted for input several times as described in the remainder of this section.
    1. To execute the script run the command:

      ./install.sh
    2. You MAY get a warning regarding NTP. Normally, time synchronization is very important for federated solutions, but all the relevant components are on the same server so time will always be in synch. Still the install script will check to see if the NTP daemon is running and warn you that it will start it if it is not already running. NOTE: It will not change your NTP configuration to start the NTP daemon upon boot.
  3. Choose your installation options.
    1. Select options 1,2,4
  4. High Bandwidth Warning
    1. This is only important for production roll-out. Press [ENTER] to continue.
  5. Novell Software License Agreement
    1. Be sure to read it all :-) It is several pages long so it has been removed from the sample for convenience sake.
    2. Accept the terms to continue.
  6. Administration server fail-over configuration.
    1. Answer: Yes
  7. Local Administration Server IP Address and Administrator ID.
    1. Our server has two network bindings: one for the public network and one for the private network. For now, you must enter your public IP address (e.g. 192.168.0.41), and hit [Enter]. We will be changing this later so that the administration console is available only from the private network.
    2. Enter an Administrator ID
    3. Enter an Administrator Password
    4. Re-enter the Administrator Password
  8. Access Manager Communications Local Listener IP address. This is the Identity Server’s listener address for the administration console.
    1. Enter your public network IP address (e.g. 192.168.0.41)
  9. SSLVPN listener IP Address.
    1. Enter your public network IP address (e.g. 192.168.0.41)
  10. Hostname Validation – no interaction required.
  11. Package Installation – no interaction required.
    1. At this point you just need to simply wait. You will not be prompted for any more information. Some of the components can take quite a while to finish so, again, be patient. I found the configuration of the Novell Device Manager to be the most time consuming step.
  12. Installation Summary.
  13. Installation log file location. /tmp/novell_access_manager
  14. Administration Server URL.
    1. Take note of this. You will need it for step 2 below. It will be in the form:

      http://<public IP address>:8080/nps
  15. Installation Complete!
    1. You should wait a few minutes before proceeding to let things settle down.
    2. Now wasn’t that easy?

Section 2: Identity Server Configuration

Now that you have everything installed, you need to configure and connect the components. First we must configure the Access Manager Identity Server component. The Identity Server will be the Identity Provider for the SSL VPN service. It is the Identity Server that uses your existing LDAP directory to authenticate users to build federation tokens and user roles for the SSL VPN to use.

NOTE: The Access Manager “Identity Server” should not be confused with Novell Identity Manager or Novell eDirectory. It may sound confusing, but it is called an Identity Server because of its role in a standard federation architecture/solution. For the purposes of this article, the Identity Server is the authentication server for our SSL VPN server.

Before you start this section, make sure that your LDAP directory that you want to use to verify user authentications is functional and can be reached by the SSL VPN server.

Before you start this section, make sure that your LDAP directory that you want to use to verify user authentications is functional and can be reached by the SSL VPN server. Your SLES server includes several standard LDAP tools that can be helpful if you need them. If you are unfamiliar with these tools reference their help by running the command “man ldapsearch” on your SLES server console. Below are some sample commands for your convenience:

Sample ldapsearch Commands

Typical samples for eDirectory
/usr/bin/ldapsearch -x -h 172.17.2.91 -s base -D cn=admin,o=services -w novell

/usr/bin/ldapsearch -x -H ldap://172.17.2.91/ -s base -D cn=admin,o=services -w novell

/usr/bin/ldapsearch -x -H ldaps://172.17.2.91/ -s base -D cn=admin,o=services -w novell

Typical samples for Active Directory
/usr/bin/ldapsearch -x -h 172.17.2.93 -s base -D cn=administrator,cn=Users,dc=ad,dc=ism,dc=utopia,dc=novell,dc=com -w novell

/usr/bin/ldapsearch -x -H ldaps://172.17.2.93/ -s base -D cn=administrator,cn=Users,dc=ad,dc=ism,dc=utopia,dc=novell,dc=com -w novell

/usr/bin/ldapsearch -x -H ldaps://172.17.2.93/ -s base -DAdministrator@AD.ISM.UTOPIA.NOVELL.COM -w novell

Start the configuration…

  1. Log into the Administration Console
    1. Disable your pop-up blocker in your browser for the Administration Server you are using – this will get in the way later.
    2. At the end of the installation, (install step 14 of section 1) you were provided with a URL for the Administration Console. Open a web browser and enter that URL.
    3. Login using the credentials you entered during install step 7 of section 1 above.
  2. Verify Status
    1. Select Access Manager | Dashboard as highlighted by the red box in the graphic below:

      The result should look similar to the screen shot below with a red status light on the “Identity Servers” block:

  3. Select and configure the Identity Server
    1. From the Access Manager Dashboard, click on “Identity Servers” block:
    2. Create a new Identity Server cluster by clicking on “New Cluster” from the menu bar. This will add your Identity Server to a cluster (a cluster of one, but others can be added in the future) and start a 3-step wizard that will walk you through the remainder of the configuration process:
    3. When prompted, enter a cluster name and be sure to tick the box for the IDS server so it is added to the cluster:
    4. Click OK when done – a configuration wizard will initiate a 3-step configuration process.
  4. Step 1 of 3: Specify Name and Base URL

    In the sample below the Name field is filled in for you but the remainder of the settings are at their defaults. The key configuration item in this step is the Base URL.

    1. For this lab, you will leave most of the Base URL unmodified from the defaults. Since the Base URL represents an Identity Server cluster, I have chosen one that does not match the Identity Server’s actual hostname. What is most important is to use a name that is unique and resolvable by servers and clients as shown in the example excerpt below:

      Whatever you choose for the Base URL, make note of it for later use when making sure this name is resolvable to its IP address.

    2. Leave the other settings at their defaults.
    3. Click Next to continue.
  5. Step 2 of 3: Specify Organization

    Although the elements with a red asterisk are required to complete the Identity Server configuration, it is not important for the SSL VPN service. This information is used when federating with other organizations. For a production roll-out, if you envision extending your deployment beyond just SSL VPN, it would be best to use valid information here. This information can be modified later. If you use bogus information to get by for now, you will want to be sure to change it before sharing your metadata with other federation partners.

    1. Since this lab only is for the SSL VPN service, we can put any information here. Below is an example with the required values filled in:
      NOTE: For our purposes, the URL value used above (www.lab-idp-c1.corp.com) does not have to actually exist.

    2. Click Next to continue.
  6. Step 3 of 3: Specify Initial User Store

    This is the step where you configure the Access Manager Identity Server to communicate with your existing LDAP user store. As an example, I used Novell eDirectory, but you can choose others as mentioned previously. NOTE: You can also use multiple LDAP user stores and configure Access Manager to search each in succession or you can associate some protected resources with one and other protected resources with another user store. Refer to the Access Manager 3.1 documentation regarding Configuring Authentication Methods for more information regarding these features.

    Below is a screen shot of this step before any information has been entered:

    1. Configure your LDAP User Store – Here is where you configure the IDS authentication to your LDAP user store:
      1. NAME: [choose a descriptive name. e.g. LDAP Tree]
      2. ADMIN NAME: [enter a tree admin’s FDN using LDAP format. e.g. “cn=admin,o=services” or “cn=Administrator,cn=users,dc=ad,dc=corp,dc=com”]
      3. ADMIN PASSWORD: [enter the admin password]

        DIRECTORY TYPE: [choose from the drop-down list. e.g. eDirectory]

    2. Enter the Server Replicas – Every replica server you add here will become part of a load-balanced and fault-tolerant pool of servers that the Identity Server will use for authentication.
      1. NAME: [Enter a name to uniquely identify your replica]
      2. IP ADDRESS & PORT: [Enter the IP address and port of the LDAP server replica]
      3. USE SECURE LDAP CONNECTIONS: [Optionally select this to use LDAPS]
      4. (OPTIONAL) AUTO IMPORT TRUSTED ROOT: [If you are using a secure port to communicate with the replica, click this link to start a wizard that will automatically import the LDAP replica’s trusted root certificate into the appropriate keystore.]

        If you did not disable your pop-up blocker as suggested, you will need to do so for this wizard to work. The wizard will prompt you to confirm the import of the trusted root as shown in the example below:

        Click OK to confirm the import of the trusted root certificate.

        Next, type in an alias to identity this trusted root in the trust store (“ldapTR” in the example below) and click OK.

      5. The following shows a successful replica configuration. If all the settings were entered correctly and communication has been established with the LDAP replica, the Validation Status will have a green check mark:
    3. Add Search Context – The Search context tells the Identity Server where to start searching for user objects and how far to search below that context.
      1. Click New to start the wizard.
      2. Enter your Search context and select the Scope:
      3. Click OK to continue.
    4. Finish the Identity Server Configuration – Below is a sample screen shot showing a completed configuration using the examples above:
      1. After reviewing your configuration, click the Finish button. A pop-up will appear…
  7. Restart Tomcat
    1. The following browser pop-up will prompt you to restart tomcat by clicking OK:
    2. Restarting tomcat will also restart the administration console. Wait a while before trying the URL again. If the pop-up was blocked by a pop-up blocker, you can manually restart tomcat, by entering the following command at the server console:

      /etc/init.d/novell-tomcat5 restart
  8. Check your Identity Server Health
    1. Wait about a full minute to let the Identity and Administration servers to restart and settle down.
    2. Log into the Access Manager Administration console. Select Access Manager | Dashboard as shown below:
    3. The dashboard will be displayed and will look like the screen shot below with a green status light on the “Identity Servers” block:

    4. From the dashboard, click on the “Identity Servers” block:
    5. Make sure that the Identity Server Status is showing “Current” and Commands shows as “Complete”:
  9. Name Resolution
    1. Since the single server SSL VPN service is made of three individual Access Manager components, it is important that each can resolve the names of the others. Even though the components are all running on the same server, components are often referenced by their name/URL, so name resolution (both name to IP and IP to name), is critical – including the Identity Server’s Base URL. Be sure that the server itself and the clients that will use these services can resolve the names you are using.

Section 3: SSL VPN Server Configuration

I have broken up the SSL VPN service configuration into three sub-steps. First, we must configure the SSL VPN server’s Embedded Service Provider (ESP) to use the Identity Server we just configured in Section 2 above. Second, the default Traffic Policies will not let SSL VPN users access private resources, so we will add a new policy. Third, we need to make sure that our Network Configuration will allow the private resources to communicate back through the SSL VPN server to the SSL VPN clients..

Embedded Service Provider (ESP)

One of the last steps for the Identity Server configuration was to check its health using the Access Manager Dashboard. While there, you may have noticed that the SSL VPN service had a red or yellow status light. That is because it has not yet been configured.

  1. Log into the Administration Console
    1. a)If you did not do so before during the IDS configuration, disable your pop-up blocker in your browser for the Administration Server you are using.
    2. At the end of the initial installation, (install step 14 of section 1) you were provided with a URL for the Administration Console. Open a web browser and enter your URL. For example: http://192.168.0.41:8080/nps
    3. Login using the credentials you entered during install step 7 of section 1 above.
  2. Select the SSL VPN Server
    1. Select Devices | SSL VPNs. Do not click on the IP address that represents your SSL VPN server, instead click on “SSL VPNs” as shown below:

    2. A list of SSL VPN servers will be displayed. We have only one:
    3. In the above sample, you will see a health status of either “Update” or “Current” – you can ignore this for now.
  3. Configure the SSL VPN Server
    1. Select the SSL VPN server listed and then click the “Edit” link at the end of the line:

  4. Authentication Configuration – Here we are going to configure the SSL VPN server’s embedded service provider (ESP) so it will use our Identity Server for authentication.
    1. Click on the “Authentication Configuration” link:

    2. Below is the initial SSL VPN ESP configuration screen before we have made any changes:
    3. Configure the ESP
      1. IDENTITY SERVER CLUSTER: [Select the Identity Server Cluster from the drop-down list.]

      2. AUTHENTICATION CONTRACT: [Select a contract from the drop-down list.]
      3. EMBEDDED SERVICE PROVIDER BASE URL: [This is a lab so HTTP is fine. The server’s hostname will be used by default. It is best to provide a unique DNS name to represent the SSL VPN server. e.g. sslvpn.ism.utopia.novell.com]. Note this URL for later use when making sure this name is resolvable to its IP address.
      4. After changing the Base URL name click on some white space. You will notice that the URL Information will automatically update to reflect your name change:
      5. Click OK to continue. You will be returned to the “Server Configuration: SSL VPN – <IP Address>” page that will look similar to the one shown below. Do not hit OK yet.
      6. Before we apply/update the SSL VPN server with our ESP configuration, we will first configure the SSL VPN traffic policies and apply both configurations simultaneously. Your browser should still be at the “Server Configuration: SSL VPN – <IP Address>” page like the example shown above.

  5. Continue with the sub-section: “Traffic Polices” that follows.

    Traffic Policies

    1. Configure the SSL VPN Traffic Policies by clicking the “Traffic Polices” link:

    2. Default Traffic Policies
      1. The graphic below shows the default Traffic Policies:

      2. The policies shown above are not likely to be useful in your configuration so you can delete them if you like. However, for our SSL VPN to work will need to define a traffic policy that allows traffic into and from your private network.
    3. Create a new traffic policy.
      1. For easy testing lets just add a traffic policy so that will allow all traffic to and from our private network through the SSL VPN server. Click “New…” from the menu bar; Another prompt will pop-up for you to name your new policy (e.g. “Any_Private_Net” as shown below):

      2. After hitting OK, your new policy will be displayed in the list. The new policy is set to the defaults so it will need to be modified by clicking on it:
      3. Below is what the default policy will look like:
      4. For our lab, we need to modify the following:
        1. DESTINATION NETWORK: [enter your private network address]
        2. NETWORK MASK: [this will likely be automatically entered for you]
        3. PREDEFINED APPLICATIONS: [for testing purposes we are going to let everything through so select “Any”].
        4. Below is an example of a modified configuration:
        5. Click OK to return to the list of traffic policies.
      5. Notice below that our traffic policy is defined but not yet enabled:
      6. Click the box on the left of our traffic policy and click “Enable” from the menu bar:
      7. The traffic policy should now be defined and enabled:
    4. Apply the changes
      1. Click the OK button to return to the “Server Configuration: SSL VPN – <IP Address>” page similar to the following:

      2. Click the OK button again to return to the SSL VPN Server list page similar to the following:
      3. Notice that our SSL VPN server status indicates “Update”. This means our configuration changes have not yet been sent to the SSL VPN server. To apply the changes click the “Update” link and then click OK when prompted:
      4. After hitting OK, the administration console will send the SSL VPN configuration to the SSL VPN server. Whenever applying changes – be patient. The status information will automatically refresh. While it is updating, you may see the Status and Commands fields in a “Pending” state and the Health light will remain yellow:
      5. When the update is complete, the Status will be “Current”, the Health light will turn green and the Commands will show as “Succeeded”:
      6. When you leave this screen you should be notified with a pop-up that the Identity Server configuration must also be updated:

        Occasionally, I have noticed that the message above does not appear. Even if it does not, you will still need to “update” your Identity Server configuration as described in the next step.

    5. Update the Identity Server configuration
      1. Now that your NAM configuration is complete, you can use the “Dashboard View” to get an overall view of the health of your implementation. You should see lots of green lights:

      2. Click on the “Identity Servers” block in the dashboard view:
      3. The Identity Server status is will be “Update All”:
      4. Click the “Update All” link – a pop-up box will appear. Click OK to apply the configuration changes to the Identity Server:
      5. Just like any other time you are applying changes – be patient. The status information will automatically refresh. While it is updating, you may see the Status and Commands fields in a “Pending” state. When done, you should see a Status of “Current” and Commands will show as “Complete”:

    Network Configuration

    All of our NAM configuration is now complete. Only one last step remains before we can do a test using our SSL VPN Enterprise mode client. We need to make sure that our name resolution is properly configured and ensure that servers on our private network know how to route their SSL VPN client responses through the SSL VPN server for the Enterprise Mode client. One easy way to do this without involving the networking staff is to use iptables to create a NAT on our SSL VPN server.

    1. Name Resolution
      1. Near the end of the Identity Server configuration, there was a note about IP to name and name to IP address resolution. The same applies to the SSL VPN server configuration. In my lab I simply used /etc/hosts files for resolution but you may choose to use DNS servers. Based on my lab and the values I used as examples, I entered the following entries in my both my Identity Server (/etc/hosts) and my Windows XP client (c:\windows\system32\drivers\etc\hosts) hosts files:

        192.168.0.41 ids-c1.ism.utopia.novell.com ids-c1
        192.168.0.41 sslvpn.ism.utopia.novell.com sslvpn

    2. Set up our NAT
      1. From the SSL VPN server console enter the following command using the following format:

        iptables -t nat -A POSTROUTING -s <vpn subnet> -j SNAT –to <private ip addr>

        Using my lab as an example the command would be:

        iptables -t nat -A POSTROUTING -s 12.8.0.0/16 -j SNAT --to 172.17.2.111

        The vpn subnet used above (12.8.0.0/16) is the default vpn subnet used by the SSL VPN server.
        This can be changed using the “Gateway Configuration” link of the SSL VPN server.

      2. Since we entered this command at the server console it will not be executed if the server is restarted. It can be made persistent by using a typical linux start-up script as described in the Access Manager 3.1 documentation section Configuring the Routing Table and the Source NAT For Enterprise Mode. There is also a recently posted Cool Solution script that is a bit more sophisticated that you can use: Novell Access Manager SSLVPN NAT Script

Section 4: SSL VPN Client Tests

To ensure that this is a valid test, I used my Windows XP desktop which is connected only to my public network (192.168.0.0) with an IP address of 192.168.0.27 to try to access (ping) the eDirectory server that I am using for my user store. My server has a single IP address of 172.17.2.91 is bound only to my private network.

  1. Verify that there is no connectivity to the private network
    1. Try to ping the eDirectory server to verify that there is no connectivity:

  2. Login to Access Manager
    1. To install the SSL VPN Enterprise mode client, you must have Administrator rights to the Windows PC so I logged in as Administrator.
    2. Start a browser. I used Firefox but you can use Internet Explorer too.
    3. Enter the SSL VPN Base URL as configured during install and setup:
      1. If you followed my example the URL is: http://sslvpn.ism.utopia.novell.com:8080/sslvpn/login
    4. Login as a user in the user store configured for use with Access Manager. In our example we are logging is as ablake:
    5. When using Firefox, after a successful login the java based applet will be sent to your browser whereupon you will be prompted to trust the signed applet as shown below:
    6. Click “Yes” to accept the certificate. The SSL VPN Enterprise Mode client will automatically download, install, and start. During this process the progress and status is continually updated:
  3. Once the client is up and running the connection status will change to “Connected” and the connection statistics will be updated:

    Also note that since the client is running as a browser applet, the browser must stay open to maintain the SSL VPN connection.

  4. Test connectivity to private network resources
    1. Try to ping the eDirectory server to verify that we now have connectivity:

    2. This time our pings are successful! Notice that our connection statistics were also updated and now show data has been sent and received:
  5. To disconnect click the “Exit” button highlighted in red below.
    1. You will be prompted for some options before exiting:

    2. For information regarding these options, click the help icon:
    3. Click the Logout button to complete the logout.

Section 5: Restrict the Administration Console

Now that the SSL VPN has been tested and is functioning we have one more thing to consider. During installation the Access Manager administration console was configured listen on the public IP binding. This can be a security concern. To prevent browsers from connecting to the administration console from the public network, we need to run a script.

  1. Download or create the script file
    1. OPTION 1: The script is available for download from the following link: restrict_console.sh

    2. OPTION 2: Below is a copy of the script file for you to manually create the script:
      #!/bin/bash
      XMLMOD=/opt/novell/devman/bin/xmlmod
      SERVERXML=/var/opt/novell/tomcat5/conf/server.xml
      SERVERXMLBAK=/var/opt/novell/tomcat5/conf/server.xml.bak-restrict_console-`date +%F_%I:%M%p`
      
      IPADDR=`${XMLMOD} ${SERVERXML} "//Connector[@port='8080']/@address" 2>/dev/null`
      
      IPADDR=(${IPADDR//./ });
      DEFAULT_RESTRICT="${IPADDR[0]}.${IPADDR[1]}.*"
      read -e -p "Please specify the addresses to deny [$DEFAULT_RESTRICT]:" RESTRICT
      if [ -z "$RESTRICT" ]
      then
      	RESTRICT="$DEFAULT_RESTRICT"
      fi
      
      # Backup the server.xml file
      if [ ! -e ${SERVERXMLBAK} ]
      then
      	cp "${SERVERXML}" "${SERVERXMLBAK}"
      fi
      
      ${XMLMOD} -r ${SERVERXML} "//Connector/@address" 2>/dev/null
      
      NPS_CTX=`${XMLMOD} ${SERVERXML} "/Server/Service/Engine/Host/Context[@docBase='nps']/@path" 2>/dev/null`
      if [ -z "$NPS_CTX" ]
      then
      	${XMLMOD} ${SERVERXML} "/Server/Service/Engine/Host" "/" << XMLOUT 
      
      XMLOUT
      fi
      
      echo "------------------------------------------------------------"
      echo "Finished restricting access to the Administration Console."
      echo "Please restart Tomcat (/etc/init.d/novell-tomcat5 restart)."
      echo "------------------------------------------------------------"
  2. Copy the script to the SSL VPN server
    1. You can use any method you like to get the script up to the SSL VPN server, I copied the file from my SLED10 laptop so I simply used the SCP command line utility to copy the file into the root user’s home directory. For example:

      pfm@sled10pc:~ # scp restrict_console.sh root@172.17.2.111:
      Password:
      ism-ids:~ # restrict_console.sh                           100% 1251     1.5KB/s   00:00
      ism-ids:~ #
    2. Once copied to the server make sure that it has the correct permissions set so we can execute the script. I used ssh from my SLED10 laptop to access the server as the root user and check the file permissions. For example:
      pfm@sled10pc:~ # ssh root@172.17.2.111
      Password:
      Last login: Tue Mar 24 15:22:05 2009 from 172.17.2.1
      ism-ids:~ # ls -al restrict_console.sh
      -rw-r--r-- 1 root root 1251 2009-06-15 15:40 restrict_console.sh
      ism-ids:~ #
    3. Notice that the current permissions for the script are set to “-rw-r-r–“. The script is not flagged as executable. To fix it use the chmod command:
      ism-ids:~ # chmod 744 restrict_console.sh
      ism-ids:~ # la restrict_console.sh
      -rwxr--r-- 1 root root 1251 2009-06-15 15:40 restrict_console.sh
      ism-ids:~ #
    4. Now the script is an executable and is displayed in green to reflect that it is executable.
  3. Run the Restrict Console script on the SSL VPN server
    1. The script works by modifying your tomcat server.xml file. Before any changes are made, the script will back-up your server.xml file as the value of the SERVERXMLBAK variable defined in the script. The default variable value in the script will create a backup file including the date that the backup file was created in the filename as in the following example:

      /var/opt/novell/tomcat5/conf/server.xml.bak-restrict_console-2009-06-06_02:20AM
    2. From the SSL VPN server run the script using the command:

      ./restrict_console.sh
    3. NOTE: You can run this script while the server is running but you will need to restart tomcat to make it effective (step 4 below). I usually stop tomcat (/etc/init.d/novell-tomcat5 stop), run the script and then restart tomcat (/etc/init.d/novell-tomcat5 start) when I am done.

    4. The script will inspect your configuration and suggest the addresses from which to deny access to the administration console. In my example the public network is 192.168.0.0 so I want to deny all addresses from this network (192.168.*). The script suggested the same so I simply hit [Enter] when prompted as shown below:
      ism-ids:~ # ./restrict_console.sh
      Please specify the addresses to deny [192.168.*]:
      -----------------------------------------------------------------------
      Finished restricting access to the Administration Console.
      Please restart Tomcat (/etc/init.d/novell-tomcat5 restart).
      -----------------------------------------------------------------------
      ism-ids:~ #
  4. Restart SSL VPN services
    1. The changes are persistent even after a reboot, but for them to take effect we must restart Tomcat which will restart all Access Manager services using the command:

      /etc/init.d/novell-tomcat5 restart
    2. For example:
      ism-ids:~ # /etc/init.d/novell-tomcat5 restart
      Stopping tomcat5: Using CATALINA_BASE: /var/opt/novell/tomcat5
      Using CATALINA_HOME: /var/opt/novell/tomcat5
      Using CATALINA_TMPDIR: /var/opt/novell/tomcat5/temp
      Using JRE_HOME: /opt/novell/jdk1.6.0_07/jre
      waiting for processes to exit
      waiting for processes to exit
      waiting for processes to exit
      Starting tomcat5: Using CATALINA_BASE: /var/opt/novell/tomcat5
      Using CATALINA_HOME: /var/opt/novell/tomcat5
      Using CATALINA_TMPDIR: /var/opt/novell/tomcat5/temp
      Using JRE_HOME: /opt/novell/jdk1.6.0_07/jre
      ism-ids:~ #
    3. If you stopped tomcat before running the script restart tomcat using the following command:

      /etc/init.d/novell-tomcat5 start
  5. Test the change: Deny access to the Administration Console from the public network
    1. From a workstation on the public network, try to access the Access Manager Administration Console. The Windows XP PC where we did the SSL VPN client testing is a good one to use since we already established it has no access to the private network resources when not using the SSL VPN client.
    2. Open a browser and enter the URL for the Administration Console using the public IP Address (Use the IP address to avoid any confusion regarding name to IP address resolution):

      http://<SSL VPN Server Public IP Address>:<port>/nps

      Using my example the URL would be:

      http://192.168.0.41:8080/nps

    3. You should be denied access by Tomcat:
  6. Test the change: Allow access to the Administration Console from the private network
    1. From a workstation on the private network, try to access the Access Manager Administration Console. The LDAP user store server that we used for our ping test when we did the SSL VPN client testing is a good one to use since we have established that it is only accessible from the private network or via the SSL VPN client.
    2. Open a browser and enter the URL for the Administration Console using the public IP Address:

      http://<SSL VPN Server Private IP Address>:<port>/nps

      Using my example the URL would be:

      http://172.17.2.111:8080/nps
    3. After accepting the SSL certificate, you should have access to the Administration Console and prompted to login:
  7. Test the change (Optional): Allow access to the Administration Console from the public network via SSL VPN
    1. Now that everything is properly configured, your NAM administration console is only accessible from your private network. Since the point of the SSL VPN service is to provide secure access to your private network resources from the public network, you can use/test your SSL VPN service to access the NAM Administration Console.
    2. To test this, use what you learned (Section 4 above) to launch your SSL VPN client from your public workstation and access the NAM administration console from that workstation.

Congratulations! Not only have you built a single server SSL VPN soft appliance using Novell Access Manager 3.1, you have tested your configuration and hopefully learned a bit more about Novell Access Manager.

Appendix A

This appendix includes additional detail regarding my lab environment. It assumes you are at least somewhat familiar with general networking concepts, VMware workstation and its networking features. Indeed, the most complex aspect of my lab environment was the networking configuration so I will start there.

VMware Network Configuration

A logical representation of my networking environment was depicted in the main section and shown again here for your convenience:

In the graphic above the two VMs (SSL VPN Server & LDAP User Store) both hosted on my SLED10 laptop using VMware. The trickiest part of this environment is the networking – how to simulate a DMZ using VM’s on public and private networks when they are hosted on the same physical SLED10 laptop. My solution was to utilize the built-in networking features of VMware Workstation – vmnets. For my public network, I configured vmnet0 to be a bridged to my physical home network. For my private network, I configured vmnet1 as “hostonly”. Using this configuration allows my VM Host to communicate with all the VMs, but does not allow any physical resources to communicate directly with any VMs associated with my private network (the hostonly vmnet1). This establishes my DMZ where I can connect my SSL VPN server to both my public (vmnet0) and private (vmnet1) networks.

Confused yet? To better understand my setup, it is graphically depicted below. The green block represents my physical SLED10 VM host. The blue elements are physical resources. The gray elements are provided by VMware workstation.

Virtual Machine Build Notes – SSL VPN Server

Once I got my networking all planned out and ready to go, I had to build a base VM with SLES10sp2 for me to install the Access Manager components. Partly because of a lack of resources on my VM Host, but mostly since I was building only a lab environment, I did not bother following the Access Manager minimum requirements recommendations. I still may have been excessive with some resources and you may be able to use less for your lab, but below is what worked for me.

VMware VM Config:

RAM: 2.0GB [After the SSL VPN installation I was able to reduce RAM to 1.0GB]
	DISK: 20GB - SCSI using 2GB Files [My final VM consumed just under 9GB]
SLES10 Install:
	CLOCK: Local Time | Etc | GMT
	PARTITIONS:
		Size		Mount Point	Filesystem
		1GB		/boot		ext3
		1GB		swap		swap
		17.9	Extended:
			2GB		/var	ext3
			15.9GB	/	ext3
	SOFTWARE: Server Base System Only 
	[I confirmed NAM requirements and included some optional packages that I like to install.]
	I typically install:
		+gtk
		+gtk2
		+gettext (included by default)
		+python (included by default)
		+compat (included by default)
		+sysstat [I always install this package]
		+gcc [for vmware tools]
		+kernel-source [for vmware tools]
		+C/C++ Compiler and Tools [old habit – you should not need these]
	NETWORKING:
		Firewall:	OFF
		Ipv6 support:	OFF
		IP (static):  192.168.0.41
		DNS:  192.168.0.1
		GW:   192.168.0.1
	CUSTOMER CENTER: Config Later
	CA Management & Open LDAP: skip config [openldap server will not be
		installed; only openldap2-client]

POST SLES10 INSTALLATION CHANGES:
	VMWARE TOOLS: Installed & Configured VmwareTools-5.5.3-34685
	VMWARE NETWORKING CONFIG CHANGES:
		Added 2nd NIC: "Ethernet 2"
		VM Ethernet1 = Bridged vmnet0 net=192.168.0.0
		VM Ethernet2 = HostOnly vmnet1 net=172.17.2.0 IP=172.17.2.1
	SLES CHANGES:
		SLES eth0 = 192.168.0.41 GW=192.168.0.1 DNS=.1
		SLES eth1 = 172.17.2.111
		
		

Virtual Machine Build Notes – LDAP User Store

I just happened to have had another SLES10 VM with Novell eDirectory 8.8 already installed, but you can use others including Active Directory and/or Sun One. From an Access Manager perspective there is no difference. Only the specifics of your particular LDAP store (e.g. admin user name & password) configuration of your Identity Provider user store(s) is different.

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.
Loading...Loading...
Categories: Uncategorized

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.

Leave a Reply

No Comments
pmckeith
By: pmckeith
Jun 17, 2009
5:20 pm
Reads:
2,579
Score:
Unrated