Excerpts from the DNU Course "Enabling Authentication in Your Applications and Web Solution"
Articles and Tips: tip
Senior Research Engineer
Novell, Inc.
kburnett@novell.com
01 Apr 2003
The following is from the DeveloperNet University (DNU) course Enabling Authentication in your Applications and Web Solution . This is one of a series of DeveloperNet University courses which will help you learn eDirectory programming.
In addition to learning ways to authenticate to eDirectory, you will be introduced to other methods of authentication utilizing platforms such as Netscape Web Server, and Apache Web Server; along with programming languages such as PERL, C, and Java. LDAP will be featured prominently. The whole course is available, free, at:http://developer.novell.com/ education/tutorials/webservices/index.htm
This portion of the course describes how to enable authentication against a Directory Services using LDAP Authentication Module for Apache (mod_auth_ldap).
mod_auth_ldap
This module allows you to authenticate users against an LDAP tree. It is based on mod_auth_dbm. You can get the latest version of this module at the http://nona.net/software/ldap/ URL.
Compile with Apache
Prerequisites.
You need both Apache and mod_auth_ldap source archives. If you can't find Apache on your favorite ftp archive, see http://www.apache.org. mod_auth_ldap is available at http://nona.net/software/ldap/.
Additionally, you will need to have LDAP libraries installed, if you don't already have them, check out http://www.openldap.org for a free LDAP implementation. Finally, you need a working build environment on your machine.
Unpacking the Stuff.
Unpack Apache as usual, and change into its "modules" directory:
% gzip -dc ../path/to/archive/apache_1.3.6.tar.gz | tar
-xv<BR>
...
% cd apache_1.3.6/src/modules
Then, unpack the mod_auth_ldap archive into the modules directory.
% gzip -dc ../path/to/archive/mod_auth_ldap-0.5.tar.gz
| tar -xv
Configuring, Building, and Installing.
Change into the newly created mod_auth_ldap directory, and configure the module itself (some parts of the Sha algorithm are endian-dependent, and endianess is not checked by the Apache configure script, so the module comes with its own autoconf script).
% cd mod_auth_ldap; ./configure
Now it's time to choose your favorite apache Config options, and additionally activate the LDAP authentication module.
% cd ../../..; ./configure --prefix=/var/apps/apache \ --activate-module=src/modules/mod_auth_ldap/mod_auth_ldap.c
After Apache has been configured, make and install it as usual:
% make ... % make install
Configuring the Module.
After installation, we need to configure it for operation. For general Apache configuration issues, refer to the Apache documentation. We will focus on the directives introduced by mod_auth_ldap and associated standard directives.
In this example, we want to protect the location "/internal" on our server, and use an LDAP directory to store user's credentials. Let's start by adding the following lines to our httpd.conf:
<Location "/internal"> AuthName "very confidential information" AuthType Basic
Note: Do this for any other type of password protection with Apache.
Now we tell mod_auth_ldap where it can reach our LDAP server(s) and how to bind to the directory:
AuthLDAPHosts "ldapserver otherserver:1234"
You can specify more than one LDAP server (as the line above shows). If you're doing this, multiple hosts have to be separated by spaces. If one of the LDAP daemons doesn't listen on the standard port (389), you can add the port number as shown above. Of course, you can also use FQDN's and IP addresses.
By default, mod_auth_ldap tries to bind anonymously to the LDAP directory. If you want the module to use specific credentials for binding, you can do that by specifying them in the config section:
AuthLDAPBindDN "reader=web,type=access,o=nonanet,c=at" AuthLDAPBindPassword abc123
Warning: Keep in mind that anyone being able to read those credentials may be able to use them to gain unauthorized access to your LDAP directory.
Double-check the permissions on the config file. Use the credentials supported by the browser by adding the following lines to the config:
AuthLDAPBindAsUser on AuthLDAPBaseDN "type=luser,o=nonanet,c=at" AuthLDAPUserKey lusername
The module will construct a DN like "lusername=<username>,type=luser,o=nonanet,c=at", and try to bind to the directory using that DN and the browser-supported password. If that succeeds, no more password checks are done, and the browser supported credentials are believed to be correct.
If we don't use "AuthLDAPBindAsUser" (and therefore didn't add the above lines to the config file), we'll now have to tell the module where and how to find the user's credentials in the LDAP directory. If all your users are at the same level of the directory (e.g. exactly one level below "type=luser,o=nonanet,c=at") and they all have the same key in their RDN (e.g. "webuser=<username>"), the story is rather simple:
AuthLDAPBaseDN "type=luser,o=nonanet,c=at" AuthLDAPSearchScope base AuthLDAPUserKey webuser AuthLDAPPassKey webpassword
(The last line above tells the module that the user's password is stored in the attribute named "webpassword." The module will search below "webuser=<username>,type=luser,o=nonanet,c=at"; in other words, it can directly "hit" the entry, which is fast, but sometimes not flexible enough.
Suppose all of your users are still below the same base DN as described above, but some of them have different RDNs. For example, there may be one department storing all their users using the RDN "surname=<name>", maybe another department chose "extension=<number>." If all of those entries have their Web credentials stored in the same attributes (e.g. "webuser" and "webpassword" again), you will have to change one line of the config snippet above to:
AuthLDAPSearchScope onelevel
If your users are NOT at exactly on level below the base DN, but scattered through a specific subtree, you can use:
AuthLDAPSearchScope subtree
Again, all those users need to have their credentials in the same attributes, once again "webuser" and "webpassword." We now go into comparing the password supplied by the browser against the value from the user's node in the LDAP directory.
If we're using AuthLDAPBindAsUser, the password check is being skipped, because the password has already been checked (hopefully) by the LDAP server. For clear text password strings (generally a very bad idea), you don't have to add anything to the configuration. If your password strings are encrypted, you'll have to add
AuthLDAPCryptPasswords on
to your config snippet. Be aware, that if you have crypted passwords in the directory, and don't set this option to "on," users will be able to authenticate successfully using the crypted password string, which may not be what you want.
There is a third alternative: use scheme prefixed passwords as described in RFC 2307. This seems to be the preferred method to store passwords in Netscape's directory server. You can enable scheme prefixed passwords by setting AuthLDAPSchemePrefix on.(Pretty straight forward, isn't it?) mod_auth_ldap will then be able to check passwords prefixed with "{crypt}" (Un*X crypt) and "{sha}" (Base64 encoded SHA1 digests as described in FIPS-180-1). Case of the prefix strings doesn't matter.
Now that we've finally checked the user's password, we can open the gates. That is, expect if only members of specific groups are permitted to enter. In this case, we need to tell mod_auth_ldap the name of the attribute listing the user's memberships, by adding:
AuthLDAPGroupKey webgroup
and listing the user's groups comma separated
<Limit GET POST> require valid-user </Limit>
or
<Limit GET POST> require group beerdrinking </Limit>
before you close the Location with
</Location>
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.