WiFoo..The.Secrets.of.Wireless.Hacking [Electronic resources] نسخه متنی

LDAP

Overview

What Is a Directory Service?

A directory is a database structure that is generally optimized for reading, searching, and browsing entries. Directories tend to contain descriptives and attribute-based information, and they usually support filtering capabilities for the purpose of delivering faster and more accurate search results. Directories should be tuned to give a quick response to high-volume lookups. They might have the ability to replicate information between similar servers to increase availability and reliability of the provided service. When database information is replicated between the servers, temporary inconsistencies between the replicas could occur and should be synchronized in a short amount of time to preserve the reliability of information.

What Is LDAP?

LDAP stands for Lightweight Directory Access Protocol. The LDAP information model contains a number of individual records known as entries, which represent a collection of attributes that has a globally unique distinguished name (DN). Each of the entry's attributes has a type and one or more values. The types are typically strings, like uid for user identification, cn for common name, sn for surname, or mail for e-mail address. The syntax of values depends on the attribute type. For example, a cn attribute might contain the value Gordon Collins, and a mail attribute might contain the value Figure 13-15 shows a directory structure example. Traditionally, this structure reflected geographic or organizational boundaries. Entries representing countries appear at the top of the tree, and below them are entries representing national organizations. Below them might be entries representing organizational units, people, printers, documents, or just about anything else you can think of. Alternatively, the directory structure can be based on domain names, which is becoming increasingly popular. As you can see in Figure 13-15, the directory structure of our Arhont organization is based on domain name (i.e., dc=arhont, dc=com) instead of o=arhont, c=UK, which would represent a geographic location.

An entry in the directory structure is referenced by its DN, which is assembled by taking the name of the entry itself and adding the names of its parent entries. Thus, an entry for Gordon Collins in our earlier example should be addressed in the following manner:

uid=Gordon Collins,ou=people,dc=arhont,dc=com

How Does LDAP Work?

The LDAP directory service is based on a client/server model, where one or more LDAP servers contain the data making up the directory information tree. The client connects to the LDAP server and requests specific information, typically by issuing a search function. The server addresses its database and responds with an appropriate answer or otherwise points to the directory server where the client can get this information. No matter which LDAP server a client connects to, it sees the same view of the directory. Thus, a name presented to one LDAP server references the same entry as another LDAP server, making it an important feature of a global directory service.

Installation of OpenLDAP

This section guides you through the installation process for the LDAP server. For the purpose of this book, we include only the OpenLDAP server installation and configuration, although you are free to use other implementations of LDAP. At the time of writing, the latest release version of OpenLDAP was 2.1.20, comparing with the stable release version 2.1.17. We recommend you use the stable version of this package, but the newest release might include some features that are not found in the stable release. You can find more information about this project and download it from http://www.openldap.org/.

Satisfying Dependencies

OpenLDAP software depends on a number of software packages. Depending on the features you want to use, you might have to install additional tools. This section details commonly needed third-party software packages that you might have to install and configure to build the OpenLDAP package. Note that some of these third-party packages might have additional dependencies, which you will have to satisfy as well.

Transport Layer Security (TLS)

OpenLDAP clients and servers require the installation of OpenSSL TLS libraries to provide TLS services. The TLS libraries are included with the OpenSSL package, which is available from http://www.openssl.org.

Kerberos Authentication Services

OpenLDAP has support for Kerberos-based authentication services. In particular, OpenLDAP supports the SASL/GSSAPI authentication mechanism using either Heimdal or MIT KerberosV packages. If you intend to use Kerberos-based SASL/GSSAPI authentication, you should install either Heimdal or MIT KerberosV. Heimdal Kerberos is available from http://www.pdc.kth.se/heimdal/, whereas the MIT Kerberos is available from http://web.mit.edu/kerberos/www/.

Simple Authentication and Security Layer (SASL)

OpenLDAP requires installation of Cyrus's SASL libraries to provide SASL services. Some operating systems might provide this library as part of the base system; other systems might require the separate installation of the Cyrus SASL, which is available from http://asg.web.cmu.edu/sasl/sasl-libraryl.

Database Software

The OpenLDAP server, later referred to as slapd, uses a primary database backend, which requires Sleepycat Software Berkeley DB, version 4. Your operating system might provide Berkeley DB, version 4, in the base system or as an optional software component; otherwise, you are required to build it yourself. Refer to Sleepycat Software's download page at http://www.sleepycat.com/downloadl to download this package.

TCP Wrappers

Slapd supports the use of TCP wrappers (IP-level access control filters) if preinstalled. Implementation of TCP wrappers or other IP-level access filters (e.g., Netfilter) is recommended for production environment servers.

Once you have checked the dependencies, you are ready to build the server and client sides of OpenLDAP. The first thing to do is this:

arhontus:~$ tar -xvzf openldap-stable-20030410.tgz

and then

arhontus:~$ cd openldap-2.1.17

Checking custom configuration options is highly advisable to include or disable any features that you might need or are otherwise not required. This is done by the following:

arhontus:~$ ./configure --help

Then run the configure script to prepare the package and generate makefiles:

arhontus:$ ./configure

Generate the dependencies list by:

arhontus:$ make depend

Finally, compile (this might take a long time on slow systems) openLDAP by:

arhontus:$ make

You can additionally test the compilation state by doing this:

arhontus:$ make test

Once the compilation is finished, you are ready to install the software as root:

arhontus:# make install

On Debian systems, OpenLDAP server and the client side have been prebuilt in a package and can be downloaded and installed from the Internet like this:

arhontus:~# apt-get install slapd libldap2 ldap-utils

If you need to install only a client side, use this:

arhontus:~# apt-get install libldap2 ldap-utils

You will be presented with a slapd initial configuration script where you enter the details for your new OpenLDAP server. After the setup completes, you are ready to configure your server and client sides.

Configuration of OpenLDAP

Once the software is compiled and installed, the first step to undertake in the configuration of the LDAP server is to examine and understand the structure of the configuration files as well as various options and settings that can be changed to tune performance and operability. First, let's take a look at the configuration files OpenLDAP uses. If you've built the package from source, the default location of the configuration files is /usr/local/etc/openldap; alternatively, if you have installed prebuilt software on a Debian system, you'll find these files in the /etc/ldap directory. The layout of the directory might look like this:

-rw-r--r-- 1 root   root    6578 May 10 23:01 ldap.conf
-rw-r--r-- 1 root   root     333 Apr 19 01:25 ldap.conf.dpkg-dist
drwxr-xr-x 2 root   root    4096 Apr 24 13:58 schema
-rw------- 1 root   root    2405 Apr 24 13:58 slapd.conf

The ldap.conf file is used for the clients and any programs that intend to address the LDAP server. More information about the structure of this file can be found from man 5 ldap.conf. The extract from this file looks as follows:

BASE    dc=arhont,dc=com
URI    ldaps://ldap.core.arhont.com/

The BASE attribute represents the database suffix that will be addressed during the client connection. The URI entry provides the information about the LDAP server; for instance, in the preceding example we specified to use LDAP over SSL/TLS by assigning ldaps:// before the ldap.core.arhont.com server name. If your DNS resolution is done through the LDAP server, you should include the IP address instead of the server name, like this:

URI    ldaps://192.168.66.101/

The schema directory includes LDAP schema files that are used to contain LDAP definitions such as syntax and object class definitions. The default schema files should be sufficient for many server requirements, and the scope of this book does not cover the structure schema files. If you would like to know more about the structure of such files, you can find additional information at man 3 ldap_schema, http://www.openldap.org, or from your best friend http://www.google.com.

The slapd.conf is used for specifying configuration options to the slapd OpenLDAP server. The description of the file and all available options can be found from man 5 slapd.conf or man 8 slapd. An extract from the slapd.conf file is shown here:

#Global Directives section
# Schema and objectClass definitions
include         /etc/ldap/schema/core.schema
include         /etc/ldap/schema/cosine.schema
include         /etc/ldap/schema/nis.schema
include         /etc/ldap/schema/rolodap.schema
include         /etc/ldap/schema/misc.schema
include         /etc/ldap/schema/openldap.schema
...
...
# Disallow anonymous logins
disallow       bind_anon
#allow          bind_v2
####################################################
#Database Directives
#ldbm database definitions
####################################################
# The backend type
database        bdb
# The base of your directory
suffix          "dc=arhont,dc=com"
# Where the database files are physically stored
directory       "/var/lib/ldap"
#Root DN entry
rootdn  "cn=root,dc=arhont,dc=com"
rootpw  "{SSHA}N95/ff6AEJSDOhmCgjT+vRym7nHAf9bw"
# Indexing options
index           objectClass eq
...
...
#Access Control Lists
# The userPassword by default can be changed
# by the entry owning it if they are authenticated.
# Others should not be able to see it, except the
# admin entry below
access to attribute=userPassword
by dn="cn=admin,dc=arhont,dc=com" write
by anonymous auth
by self write
by * none
# The admin dn has full write access
access to *
by dn="cn=admin,dc=arhont,dc=com" write
by users read
by * none

As you can see from the slapd.conf file, we start by specifying global directives, where specified directives apply to all backends and databases, unless specifically overridden in a backend or database definition. Then we identify the backend type and the basics of database structure. LDAP has support for various back end types, listed in Table 13-3.

Although the default backend type that is implemented in OpenLDAP is the Berkeley DB transactional backend, you can use any one of the supported types that you are more accustomed to or that better meets your requirements.

Next you should include the information about the database itself, such as the database suffix, the location of the database files, what objects to index, and various other related options. As you can see from the slapd.conf file earlier, the suffix for the database is dc=arhont,dc=com, the database files are to be located and stored in /var/lib/ldap, and indexing should be done on the objectClass attribute.

It is advisable to include the rootdn and rootpw entry that will allow the user to access the slapd daemon with root privileges. This can be useful to create an initial database entry, as in the case of an administrator user with full database access. After the administrator user has been created, you can safely remove the rootdn/rootpw entry. To generate the password hash for rootpw entry, you should use the slappasswd command in the following way:

arhontus:~# slappasswd -h {SSHA} -s testing123

This produces the password hash for the password testing123 that can be used in the slapd.conf file. Alternatively, you can use this command without the -s switch that will ask you to enter the desired password. The list of supported hashing schemas and their respective descriptions can be found in man slappasswd.

Once the configuration of a database descriptive is done, we are ready to move on to the last section of the server configuration file, which specifies the access control lists (ACLs). These tell the server who is allowed to access particular database objects and in what manner. For instance, the first ACL states that only the authenticated user and administrator of a database (cn=admin,dc=arhont,dc=com) can have write access to the userPassword attribute. In other words, we allow only the administrator and a user who is logged on to change his or her own password. The second ACL entry in the slapd.conf file states the default access to all other database entries, which is specified by access to *. This entry provides full access to the administrator account, write access to user-owned entry, and no access to anyone else.

Once the preliminary ACL entries are prepared and the general slapd.conf file represents your organization, we are ready to run the slapd daemon for the first time. Run the following as root:

arhontus:~# /etc/init.d/slapd start

If all goes well, you should have the slapd service running on ports 389 and/or 636. Otherwise, run the slapd servicee in debugging mode to check and correct the errors. Now that the server has started successfully, we should add the top organizational structure and an administrator account to the database. To do this, you should create an LDIF-compliant file with initial entries. More information on LDIF text entry format is provided later in this chapter. Use your favorite editor, such as vi, to edit a file like the initial.ldiff with the contents suitable for your organization. It should look similar to the following:

dn: dc=arhont,dc=com
objectClass: organization
o: Arhont
dn: cn=admin,dc=arhont,dc=com
objectClass: organizationalRole
objectClass: simpleSecurityObject
cn: admin
description: LDAP administrator
userPassword: {SSHA}N95/ff6AEJSDOhmCgjT+vRym7nHAf9bw

Now, save this file and use the following command, replacing the -D switch with one relevant for your organization to import the entries to your new LDAP database:

arhontus:~$ ldapadd -W -x -D cn=root,dc=arhont,dc=com -f initial.ldif

Once you have successfully added the contents of the initial.ldiff file to your database, you can move to the next part and undertake an initial server testing by performing entry searches.

Testing LDAP

Here we explain a few utilities that might be useful in performing LDAP database testing. The first tool is a command-line utility that comes with the OpenLDAP software package named ldapsearch. Several useful options for implementation with this tool are listed next:

-b basedn  base dn for search
-D binddn  bind DN
-h host    LDAP server
-p port    port on LDAP server
-v        un in verbose mode (diagnostics to standard output)
-w passwd  bind password (for simple authentication)
-W       prompt for bind password
-x       Simple authentication

Additional options with this tool can be found in man 1 ldapsearch or by performing ldapsearch --help. For example, let us search for any cn entries contained in the LDAP database:

arhontus:~$ ldapsearch -W -x -D cn=root,dc=arhont,dc=com cn=*

This should produce output similar to this:

# extended LDIF
#
# LDAPv3
# base <> with scope sub
# filter: cn=*
# requesting: ALL
#
# root, arhont.com
dn: cn=root,dc=arhont,dc=com
objectClass: organizationalRole
objectClass: simpleSecurityObject
cn: root
description: LDAP administrator
userPassword:: e1UUUEF9bmR2STBuQT111JXQW1USHNBeAvTVzhxK2tDcTTzkhUNWI=
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1

This utility is one of our favorite tools, as it provides an excellent and fast way to search through the database. The output of the file complies with LDIF format and can be used by the ldapadd utility to add entries to the LDAP database.

The next tool that allows searching and is very useful for database visualization, viewing, and editing is called GQ client. It can be considered a GUI frontend to many LDAP utilities that come with the OpenLDAP package. The official home page of GQ is located at http://biot.com/gq/ and it can be downloaded at http://sourceforge.net/projects/gqclient/. The installation procedure is quite simple:

arhontus:$ ./configure
arhontus:$ make
arhontus:# make install

Implementation of this tool is straightforward, as are the majority of GUI applications. After configuring this application for your server, you can simply browse the LDAP directory structure, view, modify, and add new entries. A screen shot of the GQ client is shown in Figure 13-16.

At the time of writing, there were some problems, with the gq-0.6.0 stable release in regards to modifying and adding entries to the LDAP database. Therefore, if you experience similar problems you are advised to install the latest beta version.

Now that we have done the initial testing of the LDAP daemon, we are going to discuss the various ways of populating your database with users and other entries specific to your network.

Populating the LDAP Database

We should now take a look back and review what we have done so far with the OpenLDAP software and what more needs to be done to have a functional LDAP directory service that is suited to your organization and eases the maintenance load for your administrators. The directory service can be very useful for a range of tasks from storing address book entries and keeping user profiles in one place to centralizing authentication for your entire user base.

Thus, you have installed the OpenLDAP daemon and client utilities, configured the server and client sides by editing configuration files, and added an administrator account and your top organization entry to the database. You are now ready to populate your database with users, groups, mail aliases, and other related information. There are several tools that will help with this process. The easiest way is to use the MigrationTools collection written by the PADL group. You can download it from http://www.padl.com. Additionally, you can do this task by using generic OpenLDAP tools such as ldapadd, ldapmodify, ldapcompare, ldapdelete, ldapmodrdn, and so on.

To use OpenLDAP tools, you are advised to create an LDIF-compatible file containing the information that you want to add to or delete from the directory service. LDIF is used to show LDAP entries in text format. Utilities such as ldapadd and ldapsearch read and write in LDIF-compatible style. The values in the LDIF file can be specified as UTF-8 text or as base64 encoded data, or a URI can be provided to the location of the attribute value. Here is an example structure of the LDIF format:

dn: <distinguished name>
<attrdesc>: <attrvalue>
<attrdesc>: <attrvalue>
<attrdesc>:: <base64-encoded-value>
<attrdesc>: < <URL>
...

Additional information about the LDIF format can be found from man 5 ldif or by addressing the standards specification in RFC 2849.

Now, let's examine the PADL MigrationTools utility in more detail. After downloading and extracting the set of tools from http://www.padl.com/download/MigrationTools.tgz you will need to edit a few site-specific configurations and variables in the migrate_common.ph file, namely:

$DEFAULT_MAIL_DOMAIN
$DEFAULT_MAIL_HOST
$DEFAULT_BASE

Once this file is configured to fit your requirements, it is time to run an individual tool to convert each of your /etc database files into an LDIF file. Alternatively, use the migrate_all_online.sh script to add all relevant file database entries from /etc to your database online or migrate_all_offline.sh for an offline database population. The script will ask you a series of questions about the layout of your LDAP directory and then start importing entries into your database. Table 13-4 shows you the usage criteria for each of the script files that come with MigrationTools.

If you want to import only a particular local file database into the LDAP directory, you should use the individual scripts. For instance, to import the user database from your /etc/passwd and /etc/shadow files, run the following commands, replacing the -D switch with a value appropriate for your server:

arhontus:~# perl migrate_passwd.pl /etc/passwd /tmp/passwd.ldif
arhontus:~# ldapadd -W -x -D cn=admin,dc=arhont,dc=com -f /tmp/passwd.ldif

When you have populated the database with all available and usable information, you are ready to look into the procedure for centralizing authentication in your organization. With centralized authentication, it is much easier to control, administer, and monitor users.

Centralizing Authentication with LDAP

First, we'll discuss centralizing authentication on UNIX clients, and then we'll describe an authentication library that allows Windows-based clients to authenticate against the LDAP server.

Once again we are going to consider the PADL software libraries, namely pam_ldap and nss_ldap, which can be downloaded from /pub/nss_ldap.tgz, respectively. The pam_ldap library provides LDAP authentication support for Pluggable Authentication Module (PAM)-enabled operating systems, such as some distributions of Linux, FreeBSD, HP-UX, Solaris, and many others. The nss_ldap library, on the other hand, has support for operating systems that are based on an older interface known as Nameservice Switch (nsswitch). Such operating systems include some distributions of Linux, AIX, HP-UX, Solaris, and several variants of BSD-based systems.

The installation procedure is very simple and straightforward and is done the following way:

arhontus:$ ./configure
arhontus:$ make
arhontus:# make install

After successfully building and installing the libraries, you should copy the example of the ldap.conf file into /etc/openldap or /usr/local/etc/openldap, depending on your setup, and edit it. Additionally, for the pam_ldap module you should copy the pam.d and pam.conf files into your /etc directory, making a backup copy just in case something goes wrong. Similarly, you should copy the nsswitch.ldap file into /etc/nsswitch.conf, creating a backup of your original files. This allows LDAP addressing of your nsswitch and PAM-enabled programs. The default configuration files included with pam_ldap and nss_ldap should work fine, and you will be able to authorize yourself against the LDAP centralized directory. However, we have experienced some problems with default files located in the pam.d directory on the FreeBSD 4.x and 5.x systems. After the installation of pam_ldap from the Ports repository, it was necessary to edit all of the required pam files to change the locations of security libraries. For instance, here is a sample copy of the default pam sshd file:

#%PAM-1.0
auth       required     /lib/security/pam_nologin.so
auth       sufficient    /lib/security/pam_ldap.so
auth       required     /lib/security/pam_unix_auth.so try_first_pass
account    sufficient   /lib/security/pam_ldap.so
account    required     /lib/security/pam_unix_acct.so
password   required     /lib/security/pam_cracklib.so
password   sufficient   /lib/security/pam_ldap.so
password   required     /lib/security/pam_pwdb.so use_first_pass
session    required     /lib/security/pam_unix_session.so

It should be edited to look like this:

## $FreeBSD: src/etc/pam.d/sshd,v 1.9 2002/12/03 15:48:11 des Exp $
#
# PAM configuration for the "sshd" service
#
auth    required    pam_nologin.so     no_warn
auth   sufficient  pam_opie.so        no_warn no_fake_prompts
auth    required    pam_opieaccess.so  no_warn
auth    sufficient  /usr/local/lib/pam_ldap.so
auth   required    pam_unix.so        no_warn  try_first_pass
account   required  pam_login_access.so
auth    sufficient  /usr/local/lib/pam_ldap.so
account   required  pam_unix.so
session   required  pam_permit.so
password  sufficient  /usr/local/lib/pam_ldap.so
password  required  pam_permit.so

The complete set of working pam files can be found on the accompanying Wi-Foo Web site. It should be noted that to implement centralized authentication using the LDAP directory, each of the clients should have either nsswitch.conf with ldap.conf or pam.conf, pam.d directory, and ldap.conf files and the server side should be kept unaltered. Once you have prepared the clients to use LDAP authentication, you are ready to perform the testing by logging in:

Client:

arhontus:~$ id
uid=1100(andrei) gid=1100(andrei) groups=1100(andrei)
arhontus:~$ su - gordon
Password:
arhontus:~$ id
uid=1103(gordon) gid=1103(gordon) groups=1103(gordon)
arhontus:~$ pwd
/home/gordon

OpenLDAP server log:

arhontus:~# tail -100 /var/log/syslog |grep slapd
Jun 2 15:48:28 pingo slapd[32232]: conn=17 fd=16 ACCEPT from
IP=192.168.66.78:49159 (IP=0.0.0.0:389)
Jun 2 15:48:28 pingo slapd[887]: conn=17 op=0 BIND
dn="cn=admin,dc=arhont,dc=com" method=128
Jun 2 15:48:28 pingo slapd[887]: conn=17 op=0 BIND
dn="cn=admin,dc=arhont,dc=com" mech=simple ssf=0
Jun 2 15:48:28 pingo slapd[887]: conn=17 op=0 RESULT tag=97
err=0 text=
Jun 2 15:48:28 pingo slapd[887]: conn=17 op=1 SRCH
base="dc=arhont,dc=com" scope=2 filter="(uid=gordon)"
Jun 2 15:48:28 pingo slapd[887]: conn=17 op=1 SEARCH RESULT
tag=101
err=0 nentries=1 text=
Jun 2 15:48:28 pingo slapd[887]: conn=17 op=2 BIND anonymous
mech=implicit ssf=0
Jun 2 15:48:28 pingo slapd[887]: conn=17 op=2 BIND
dn="uid=gordon,ou=people,dc=arhont,dc=com" method=128
Jun 2 15:48:28 pingo slapd[887]: conn=17 op=2 BIND
dn="uid=gordon,ou=people,dc=arhont,dc=com" mech=simple
ssf=0
Jun 2 15:48:28 pingo slapd[887]: conn=17 op=2 RESULT tag=97
err=0 text=
Jun 2 15:48:28 pingo slapd[887]: conn=17 op=3 BIND anonymous
mech=implicit ssf=0
Jun 2 15:48:28 pingo slapd[887]: conn=17 op=3 BIND
dn="cn=admin,dc=arhont,dc=com" method=128
Jun 2 15:48:28 pingo slapd[887]: conn=17 op=3 BIND
dn="cn=admin,dc=arhont,dc=com" mech=simple ssf=0
Jun 2 15:48:28 pingo slapd[887]: conn=17 op=3 RESULT tag=97
err=0 text=
Jun  2 15:48:28 pingo slapd[887]: conn=17 op=4 UNBIND
Jun  2 15:48:28 pingo slapd[887]: conn=17 fd=16 closed

One of the ways to allow LDAP-centric authentication on Windows is to use the pGina software libraries that provide alternative methods of authentication. These libraries can be downloaded from http://pgina.xpasystems.com. They incorporate a modular approach to authentication. Additionally, you are advised to download a plug-in testing utility as well as the LDAP authentication plug-in to enable LDAP server addressing. After installation of the package, open up the Configuration tool, which will allow you to control various aspects of the software. Figure 13-17 shows the configuration window.

You will need to adjust the settings for pGina as well as for ldapauth_plus.dll to look similar to Figure 13-18 and Figure 13-19, replacing site-specific features such as domain suffix and administrative user accounts.

Prior to deployment of these libraries on a wide corporate scale you should test the usability by running pluging_tester.exe, the utility that allows you to test configuration options of the implemented plug-ins. Figure 13-20 depicts this utility in action.

Once you have tested and successfully logged in using the LDAP directory, you are ready to implement the centralized authentication on a full organizational scale. Figure 13-21 shows the pGina main login window.

Mobile Users and LDAP

By now you are probably wondering how all this information is related to wireless networking and why you should go through so much trouble and hours of debugging sessions. Isn't the Plug-and-Play sign on my wireless client equipment box meant to do it all (i.e., give me usability, fast installation, "working out-of-the-box," and effective security)? The answer is no! The Arhont team has tested dozens of wireless devices and we have not seen any that provide even basic security features out-of-the-box. The truth is that even expensive equipment that is meant to comply with industry security standards does not give you the out of the box protection that is necessary for wireless networking, or for any networking. Sadly or not, you can achieve a higher level of data protection only by implementing other techniques of securing your airwaves on top of the features that are built into the access points and wireless cards. The proper implementation of RADIUS, 802.1x/EAP, LDAP and, in some cases, VPN deployment will give you the protection required to secure the wireless medium properly. However, don't forget that the weakest link is usually the human factor, so you should not forget to design a thorough security policy, implement it, and train your staff to strictly follow it. By combining these steps you will greatly minimize the risk factor of crackers breaking into your WLANs and advancing further into the wired network.

If your organization wants to restrict the use of mobile equipment to the office space or, to be more precise, wireless coverage zone space, it is possible to do this using LDAP authentication schemes. The solution is quite simple for wired as well as for wireless nets and involves setting up authentication servers on the LAN side of the IT infrastructure. The server side would restrict the logins either by TCP wrappers or by firewalling. On the client side (e.g., notebooks and PDAs), the administrator should not create any user accounts, instead relying on the nsswitch and PAM to perform authentication against the LDAP database. This way, the client will be able to log in to a particular device only within the presence of the LDAP authentication server. This layout will work on the entire perimeter of wireless network coverage, so the clients will be able to use their equipment on the office premises, but not elsewhere. This setup might be required for government institutions or research and development departments with highly sensitive information. If the equipment is lost or stolen, it will be far more difficult to gain local and network access, thus providing yet another significant hurdle for the malicious attacker. Thus, software wireless network defense against physical theft of client devices is possible and, in many cases, feasible.

LDAP-Related Tools

LDAP has been in use for quite some time and has become popular within the networking community. There are many reasons for this, including the increasing development support in software from the OpenSource community and proprietary organizations. This section details several OpenSource tools that might be of use to the administrator in the day-to-day management of LDAP servers and clients.

Directory Administrator

This tool allows the easy administration of a small-scale LDAP directory. It shows the users in the database and allows for creation, modification, and deletion of entries. We recommend this tool to all novice LDAP administrators, as using it doesn't require a lot of understanding and experience with LDAP. Figure 13-22 shows what this tool looks like. The official home page is located at http://diradmin.open-it.org/, where you can read LDAP-relevant information.

LdapExplorer

LdapExplorer is a Web-based tool written in PHP that provides visual aspects to LDAP administration. Its functionality is similar to Directory Administrator in the way it simplifies the administration of small to medium LDAP directories. This tool shows the LDAP directory tree, unlike Directory Administrator, which shows only a flat LDAP structure. If you do not want to learn the commandline structure of OpenLDAP tools and are not required to administer a medium LDAP directory, this tool might be for you. It works with Apache or similar Web servers, provided you have a PHP support. Figure 13-23 shows this software in action. LdapExplorer can be downloaded from

YALA

YALA stands for Yet Another LDAP Administration. This tool, just like LdapExplorer, is written in PHP and depicts a tree directory structure. Its functionality and appearance are similar to LdapExplorer, thus it should be used to administer small and medium directories. YALA is very easy to install and is meant to operate on virtually any Web server with PHP 4.0.5 and greater support. The official site is located at http://yala.sourceforge.net/, where you can download the latest version. Figure 13-24 shows YALA in action.

LDAP Tool

The advantage of this software is that it is licensed under a BSD license and allows you to do anything you want with the source code. It works on many operating system platforms, including Windows. The tool can be downloaded from http://ldaptool.sourceforge.net/ and depends on wxWindows gtk libraries available at http://www.wxwindows.org/.