Webserver use, configuration and management

Unit WUCM1

Access control and user management

(see Nobles (2001), Chapter 28, Laurie (1999 or 2003), Chapter 5 or Arnold (2000), Chapter 6)

Access control

Use of httpd.conf - basic authentication

Access control relies on a number of Apache modules, so the first step is to check that these are loaded and added into the active working set for your current configuration. In an earlier practical session we added a few modules. Make sure that you have mod_access and mod_auth installed and enabled.  

The next task is to set up the necessary subdirectories of the website. Create a directory called private within your document root. The aim is to control access to files contained within that folder. Create a file (index.htm will do) in that folder and also a link to it from a page in the parent directory. Folder structure

The first test is to check it works normally before adding in the access control. Check that you can navigate to the file you created.

Assuming it is fine, then the next task is to try out the access control based on <Directory ….> settings in the httpd.conf file. Firstly, we will set up a user based access control with a password file.

Add in the following directive block. Notice that I have assumed that the user passwords are in a file in a users subdirectory, not part of the webspace, i.e. alongside the htdocs root.

<Directory "N:/WebRoot/Roger4/htdocs/private">
  AuthName "RogerPrivate"
  AuthType Basic
  AuthUserFile "N:/WebRoot/Roger4/users/users.pwd"
  require valid-user

Constructing a password file

Having specified a password file, we need to create it. Note that the password file contains an encrypted password, but it is still a text file and may be opened with a text editor. 

To do this use the htpasswd utility included in the C:\Apache\bin directory. As this directory is not on the path by default, you need to use its full path in the command line, assuming that your current directory is set up as users.htpasswd command

The –c argument on the htpasswd command instructs it to create a new file; omit it to simply add a new name to an existing file. Repeating the command with the same user name updates the password.

Notice that it uses the MD5 encryption method to add in user roger to the password file. Add one or more of your own users to test.

Testing it out

Now when you access a document in the private directory, you are challenged (in a browser pop up window) to provide a username and password. (If you are not, trying refreshing the page.)

Popup box

Popup box

Failure box

Failure page

Using a group file

Having employed a user file, it is also possible to set up a file containing group definitions so that identification can be customised more easily. Groups are also a good way of implementing role-based access controls (RBAC).

The group file is a plain text file listing the members of each group, and would normally be located in the same directory as the user file, though it doesn't have to be. Note that the group file is only to make management easier; users are still validated via the user file. An example is given below. Be as creative as you like in setting out some groups for your users. Clearly in real life you would need to have designed the user groups with as much care as the directory structure – they often relate!  

In my case I used the same extension as the password file, calling it groups.pwd.

staff: roger bill steve zoe annette
students: clive janice xavia

The syntax is reasonably obvious!   The next step is to add the group definition into the <Directory …> directive, and make use of it in the require clause. Note that you still need the password file as the users in the selected group still identify themselves via their password.

<Directory   "N:/WebRoot/Roger4/htdocs/private">
    AuthName   "RogerPrivate"
    AuthType Basic
    AuthUserFile "N:/Apache/Roger/users/users.pwd"
    AuthGroupFile "N:/Apache/Roger/users/groups.pwd"
    require group staff

Remember that all users mentioned in your groups file should exist in your password file – else authorisation will fail on the name. Whenever you make changes to the httpd.conf file remember to restart the Apache webserver. Test your setup with a variety of different logins, both staff and students. Remember to clear the caches and restart the browser to clear the password. How would you check what was happening? What logs would be worth looking at? Do you need to use a custom log in place of the standard transfer log?

An experiment with Digest

As an experiment it would be illuminating to try out switching the AuthType to Digest. The modules needed to deal with digest authentication are not included by default, so if you just change the above part of the httpd.conf file you should get an “Internal Server Error” response. Including the relevant LoadModule and AddModule directives will cure this problem, but is insufficient.   You also need to add an extra AuthDigestFile in place of the AuthUserFile and use htdigest in place of htpasswd to construct the password file.

Access control via an htaccess file

Generating an htaccess file

In order to test access control via a per directory user managed htaccess file you need to first of all remove (or comment out) the access control from httpd.conf, viz. the <Directory …> block, the AuthName etc. These directives need to be in the htaccess.hta file instead. Create a plain text file called htaccess.hta and copy the body of the directory block to it (do not include the Directory directive). You can use either the user or group version. Save this file to the private directory, or what ever you have called it in your test structure.

Telling Apache that it is an access control file

If you test at this point it will totally ignore all of your crafted access control, as Apache does not yet know that an htaccess.hta file controls access, or that it should let it. Open httpd.conf in your text editor and add the following lines. The AllowOverride directive is necessary to permit the user to change the default site wide behaviour on a per directory basis. In this case we want permission to override the access control mechanism and substitute our more restrictive set of rules. We could equally be relaxing the rules.

<Directory "N:/WebRoot/Roger4/htdocs/private">
    AllowOverride Limit AuthConfig

AccessFileName htaccess.hta

Restart Apache, clear out the browser’s caches and try again. All should work as before, but with access control being directed by the htaccess.hta file. However, if you try and download the access control file itself, at present you can, clearly a security hole.  

Any attempt would be logged (try it and check the logs!), but at present Apache would deliver the file.

Security for the Access Control file

You need a <Files …> directive to block this particular file from transfer. Add the following into the httpd.conf file and try again. What do the logs record? Could you modify the custom log to catch the attempts?

#block access to the   access control file in any directory!
<Files   "htaccess.hta">
    Order allow,deny
    Deny from all

Having installed the deny clause, you should be prevented from viewing the potentially dangerous access control file.   Every time a cracker gets detail of how your webserver is configured, then potential weaknesses are exposed.

Access control by host

Using IP address to control access

This is one of the few parts of the course that cannot really be undertaken without a real network – at least 2 machines - so you can have an external host to block against. As the current state of the test httpd.conf is set up for an access control file we will use that, but it works the same in a Directory block.

Suppose that we wish to let users from a specific host have access to the private directory without the bother of a password, but for other users – perhaps working on un-trusted hosts outside the organisation, to have to identify themselves with a password.

Modify the htaccess.hta file to:

AuthName "RogerPrivate"
AuthType Basic
AuthUserFile "N:/WebRoot/Roger4/users/users.pwd"
AuthGroupFile "N:/WebRoot/Roger4/users/groups.pwd"

require group staff

Order deny,allow
Deny from all
Allow from
#you would need to   substitute a trusted colleague’s CommsLab IP
Satisfy any

The Satisfy any lets users from in without asking for a password, but demands a password from all other IP addresses, including its own. The alternative (and default) all is to only permit access if both host IP and password identification match.


Ben Laurie and Peter Laurie
Apache: The Definitive Guide (2e)
O’Reilly, 1999
ISBN: 1565925289

Mark Arnold, Jeff Almeida & Clint Miller
Administering Apache
McGraw-Hill, 2000
ISBN: 0072122919

Peter Wainwright
Professional Apache
Wrox, 1999
ISBN: 1861003021

Ben Laurie and Peter Laurie
Apache: The Definitive Guide (3e)
O’Reilly, 2003
ISBN: 0596002033


Last updated by Prof Jim Briggs of the School of Computing at the University of Portsmouth