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:
Network Block Device Support
Full Internal IPX Network
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
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
[aj@desktop aj]$ rpm -qa | grep apache
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.
./configure --sysconfdir=/etc/httpd \
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
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
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
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
AuthName "Top Secret"
AuthNDSServer SERVER_01 SERVER_02
AuthNDSContext .TENNESSEE.ACME .OREGON.ACME
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:
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.
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-188.8.131.52-3
rpm -ivh ncpfs-184.108.40.206a-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:
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:
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
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
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
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
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.
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
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.
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.
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: email@example.com.