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.
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:
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.
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.
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.
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.
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:
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 #
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.
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:
Start the configuration...
The result should look similar to the screen shot below with a red status light on the "Identity Servers" block:
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.
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.
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:
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.
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
The dashboard will be displayed and will look like the screen shot below with a green status light on the "Identity Servers" block:
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.
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.
Traffic Policies
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.
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.
iptables -t nat -A POSTROUTING -s 12.8.0.0/16 -j SNAT --to 172.17.2.111
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.
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.
#!/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 "------------------------------------------------------------"
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:~ #
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:~ #
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:~ #
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:~ #
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:~ #
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.
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.
Support
Documentation
Learning Services
Partner Programs