Cover V10, I07
Article
Figure 1

jul2001.tar


Interoperating Linux with NetWare

A. J. Weinzettel

Passwords are a necessity in keeping information secure. The drawback is having so many of them -- one for email, one to access files, telnet/ssh sessions, etc. In this article, I will introduce an Apache module that allows users to use their Novell NDS password to access secure Web pages on a Linux Web server. The name of this Apache module is called mod_auth_nds, and it was written by Phillip R. Wilson. A list of software used is provided at the end of this article.

Recompiling the Linux Kernel

To install mod_auth_nds, the Linux Kernel will have to be recompiled. Instructions on recompiling the kernel can be found at: http://www.linuxdoc.org. I have tested kernel versions 2.2.17, 2.2.18, and 2.4.1 in production environments using mod_auth_nds with no problem. The basic commands for compiling the kernel are also listed below:

1. make menuconfig -- This allows you enable certain options in the kernel. Mod_auth_nds requires the following parameters to be enabled inside the Linux kernel:

Block Devices
    Network Block Device Support

Networking Options
    IPX Protocol
    Full Internal IPX Network

File Systems
    Networking File Systems
        NCP File Systems

2. make dep

3. make clean

4. make bzImage

5. make modules

6. make modules_install

7. cp ./arch/i386/boot/bzImage /boot/new_kernel

8. edit /etc/lilo.conf

9. lilo

Explaining how to set up lilo is beyond the scope of this article, but information can be found at: http://www.linuxdoc.org. Once lilo has been reconfigured to read the new kernel, the machine will have to be rebooted. When the computer is booting up, be sure to choose the new kernel at the lilo prompt if the new kernel was not set to the default in the lilo configuration.

Setting up Apache for mod_auth_nds

There are options when installing mod_auth_nds. I chose to compile the module into Apache. If you installed Apache during the installation of Linux or from an RPM, I suggest uninstalling Apache. To uninstall Apache, follow the steps below. The first command is an RPM command that queries the RPM database to see whether Apache is installed.

[aj@desktop aj]$ rpm -qa | grep apache
apache-1.3.12-25
The rpm command returned that Apache 1.3.12 is installed. Generally, there are dependencies that require Apache to be installed. To find out what dependencies are using Apache, try to uninstall Apache (you must be root to do this).

[root@desktop aj]# rpm -e apache-1.3.12-25
error: removing these packages would break dependencies:
        apache = 1.3.12-25 is needed by mod_ssl-2.6.6-25
        webserver is needed by mod_perl-1.24-4
According to my installation, mod_ssl and mod_perl depend on Apache being installed. The dependencies may differ for your installation. I suggest noting those dependencies, removing them, and then reinstalling that software. Below are the steps that I use to uninstall the dependencies, and uninstall Apache:

[root@desktop aj]# rpm -e mod_ssl-2.6.6-25
[root@desktop aj]# rpm -e mod_perl-1.24.-4

[root@desktop aj]# rpm -e apache-1.3.12-25
Next, extract Apache and mod_auth_nds from their compressed format. The command is tar -zxvf filename. This will create a separate directory for each of the files. Under the directory for mod_auth_nds, there will be a file called mod_auth_nds.c. This file will have to be copied under the Apache source tree to apache-1.3.12/src/modules/extra.

1. ./configure --sysconfdir=/etc/httpd \
--datadir=/var/www \
--iconsdir=/home/www/icons \
--htdocsdir=/home/www/html \
--cgidir=/home/www/cgi-bin \
--logfiledir=/var/log/httpd \
--add-module=src/modules/extra/mod_auth_nds.c

2. make

3. make install

Starting and Configuring Apache

This is just a personal preference, but I like to copy the /usr/local/apache/bin/apachectl file to /etc/rc.d/init.d/httpd. This allows all of the startup files to be kept in one location. To test Apache and make sure everything is working, type in service httpd start from the command prompt. If /sbin is not in $PATH, you will have to type in /sbin/service httpd start. (A note about the service script that comes with Red Hat -- for some versions, you will have to modify the script to make it work, or you can run /etc/rc.d/init.d/httpd start.)

To see if Apache is running do a process list (ps ax | grep httpd). This should list about five processes that reflect the httpd process. Another test to make sure that Apache is running is to type in lynx localhost. You should get a screen that says something along the lines of "it worked". If none of this is working, take a look at the /var/log/httpd/error_log. This should give you some insight as to why Apache does not want to run.

Assuming Apache is running with the mod_auth_nds module, it is time to configure Apache to authenticate against the NDS database. Figure 1 is the layout of the NDS tree that I am authenticating against.

I have a tree with the name of ACME_TREE, an organization of ACME and three organizational units -- one called TENNESSEE, one called OREGON, and another called UTAH. We want to give access to user "feb03112" and access to "ajw02085", but when user "bsh03191" tries to access our secure Web pages, he will be denied access. Below is the Directory entry that I added to /etc/httpd/httpd.conf that allows this type of access:

<Directory "/home/www/html/secrets">
AuthType Basic
AuthName "Top Secret"
AuthNDSUserFile /home/www/secret_access
       AuthNDSServer SERVER_01 SERVER_02
        AuthNDSContext  .TENNESSEE.ACME .OREGON.ACME
          require valid-user
</Directory>
The configuration setting is fairly self-explanatory. I am setting up Basic Authentication, with a name of "Top Secret". The file that Apache reads to get a list of people who can access the Web pages is /home/www/secret_access. Once Apache reads the AuthNDSUserFile, it will first authenticate to SERVER_01. If by some chance SERVER_01 is not responding, then try to authenticate to SERVER_02 via NDS. The next part of the configuration file is the context in the NDS Tree where the users are located. The last part of the configuration tells Apache to allow access only to valid users.

The last part of configuring Apache is to build an access file. This is relatively an easy task. We will give access to user "ajw02085" and "fdb03110" to the "Top Secret" files. The contents of the /home/www/secret_access are as follows:

ajw02085
feb03112
In our configuration of mod_auth_nds, the context was set to .TENNESSEE.ACME and .OREGON.ACME. This allows us to add just the user name with no context appended to the end of the user id. You must be careful though; if you have two users with the same user id this will cause problems. If you do have two users with the same user id, and you want both of them to access the secure Web pages, you must put the full context inside the secret_access file. This means when the user logs into the secure pages, users must enter their full context as their username. All in all, life is much easier when there are not two user ids that are the same.

Configuring IPX

After compiling the kernel with IPX support and running on the new kernel, you will need to configure IPX. Other packages also need to be installed before IPX can run. These packages are ipxutils and ncpfs. The author of the module has done a great job of configuring these packages. I strongly suggest downloading these from his Web site. When you are ready to install these packages, make sure they are not already installed by running rpm -qa | grep ipxutils and rpm -qa | grep ncpfs. If either one of the packages are already installed, I suggest uninstalling them with the rpm -e package name command. To install, simply do the following:

rpm -ivh ipxutils-2.2.0.17-3
rpm -ivh ncpfs-2.2.0.17a-2
Now we can move on to configuring IPX. You can use linuxconf to configure IPX, but I prefer to modify files that make up the configuration of IPX. The files are /etc/sysconfig/network and /etc/sysconfig/network-scripts/ifcfg-eth0. The first file that we are going to look at is /etc/sysconfig/network:

NETWORKING=yes
HOSTNAME="server03.acme_co.com"
GATEWAY=10.1.1.1
IPX="yes"
IPXINTERNALNETNUM="0"
IPXINTERNALNODENUM="0"
IPXAUTOPRIMARY="off"
IPXAUTOFRAME="off"
I added the last five lines of the configuration file. Going through the file, we will turn on IPX by saying "IPX=yes". The zero value for the lines IPXINTERNALNETNUM and IPXINTERNALNODENUM is to get the network number and network node number from current values that reside on your network. I am also setting IPXAUTOPRIMARY and IPXAUTOFRAME to off. I do not want the kernel to pick my IPX frame type for me. The frame type will be set in the next configuration file, /etc/sysconfig/network-scripts/ifcfg-eth0:

DEVICE="eth0"
BOOTPROTO="none"
BROADCAST=10.1.255.255
IPADDR="10.1.100.32"
NETMASK="255.255.0.0"
NETWORK=10.1.0.0
ONBOOT="yes"
IPXNETNUM_802_2=""
IPXPRIMARY_802_2="no"
IPXACTIVE_802_2="no"
IPXNETNUM_802_3=""
IPXPRIMARY_802_3="no"
IPXACTIVE_802_3="no"
IPXNETNUM_ETHERII=""
IPXPRIMARY_ETHERII="yes"
IPXACTIVE_ETHERII="yes"
IPXNETNUM_SNAP=""
IPXPRIMARY_SNAP="no"
IPXACTIVE_SNAP="no"
When you look at this file, the IPX entries may or may not be there. If the IPX entries are there, just change the no to yes for the IPX frame type you are running on your network. In my case, I am running ETHERII.

When you are done configuring IPX, it is time to test and make sure that IPX will bind to the network card. To restart your network settings, you can run service network restart or you can run /etc/rc.d/init.d/network restart. To actually test whether IPX is bound to the card, run the command /sbin/ifconfig. The following is the result of the command on my box:

eth0   Link encap:Ethernet  HWaddr 00:02:B3:0A:20:F2
         inet addr:10.1.100.32  Bcast:10.1.255.255
Mask:255.255.0.0
         IPX/Ethernet II addr:001001E2:0002B30A20F2
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:49456814 errors:11 dropped:0 overruns:0 frame:0
         TX packets:6515777 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:100
         Interrupt:11

lo     Link encap:Local Loopback
         inet addr:127.0.0.1  Mask:255.0.0.0
         UP LOOPBACK RUNNING  MTU:16192  Metric:1
         RX packets:8599 errors:0 dropped:0 overruns:0 frame:0
         TX packets:8599 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:0
The information we are concerned with is the third line for eth0 (IPX/Ethernet II addr:001001E2:0002B30A20F2). This tells me that Ethernet II is bound to the card with the network number of 001001E2 and a node address of 0002B30A20F2. If you did not get the same results, make sure you are running your new kernel with IPX support, have made changes to both the /etc/sysconfig/network and /etc/sysconfig/network-scripts/ifcfg-eth0 files, and have restarted the network. If you are still running into problems, check your /var/log/messages file for more information.

Testing Authentication

Now that we have gone through this extensive configuration of the Linux Kernel, Apache, and setting up IPX, we can test whether everything works. First, we create a file that we will access in the secret_access directory. The name of the file will be index.html and the contents, for the sake of this article, will be "Congratulations you have found the Top Secret Stuff".

Here is a quick checklist to make sure everything is correct:

1. We are running the new kernel.

2. NCPFS and IPXutils are installed.

3. IPX is configured and bound to the network card.

4. Apache has been installed and configured to use mod_auth_nds.

5. The /home/www/html/secret_access/index.html file is created.

6. Is Apache running? (ps ax | grep httpd)

We are now ready to test our authentication against NDS. Open a browser on a workstation and type in the address of your Web server (http://10.1.100.32/index.html). If that works, proceed with accessing the secret stuff (http://10.1.100.32/secret_access/index.html). You should get a login prompt at this point. Put in the user id of a valid user and the NDS password of that same user. If all is working correctly, you should see the contents of the secret_access file that we created called index.html. If this does not work, refer to /var/log/httpd/error_log for any errors that might have occurred.

Conclusion

There are other ways to implement mod_auth_nds and you can also use mod_ssl to create an SSL connection upon login. When users type in their passwords, the passwords do not go over the wire unencrypted. Check out Mr. Wilson's Web site at: http://www.users.drew.edu/~pwilson/mod_auth_nds for more documentation and other configuration properties for Apache.

Phillip Wilson has created something great with this module. Reducing the number of passwords users have to remember makes administration easier, lowers the total cost of ownership, and makes the user base happier. In reducing the number of passwords, the chance the user community will write down passwords is decreased, which in turn makes for a better security policy. I thank Mr. Wilson for the contribution he has made. When people work together and share ideas to create solutions the possibilities are endless.

Software Used

1. Apache -- http://www.apache.org

2. Kernel -- http://www.kernel.org

3. mod_auth_nds -- http://www.users.drew.edu/~pwilson/mod_auth_nds

4. ipxutils -- http://www.users.drew.edu/~pwilson/mod_auth_nds

5. ncpfs -- http://www.users.drew.edu/~pwilson/mod_auth_nds

6. Novell Netware 5.1 NDS Version 8.59

7. Red Hat Linux version 6.2

A.J. Weinzettel is a Linux consultant in Chattanooga, Tennessee. He holds a SAIR Linux LCP certification and is working toward SAIR's LCA certification. A.J. can be reached at: aj@linuxaid.org.