LdapGuru - all about LDAP, IT news, and IT art » Manual

Create an LDAP Address Book

ls — Fri, 23 Oct 2009 13:45:18 +0000

This article will attempt to demonstrate how to connect to an LDAP server using PHP. Specifically, the example given will connect to a public LDAP server and perform searches. This example closely mimics the way Netscape® Communicator 4.* uses its address book to connect to LDAP resources.

Introduction to LDAP

Many have probably heard much about LDAP, but have no idea what it is or how it works. I will not attempt to teach everything there is to know about LDAP, but here is a brief description of the protocol. LDAP is a protocol for distributing directory information to many different resources. Most commonly it is used as a centralized address book, but it can be much more powerful depending on an organization’s needs. LDAP in its most basic form is a standard way to connect to a database. The database is optimized for read queries. Thus, it retrieves information very quickly, in contrast to additions or updates which are slower. It is important to note that LDAP most often uses a hierarchal database, rather than a relational database to store data. Therefore, the structure is better represented with a tree than a table. As a result, SQL syntax will be rendered unusable. In short, LDAP is a fast way to retrieve centralized, static data containing information about people and/or resources.

Requirements

PHP v.4 (previous versions may work but are untested) compiled with support for LDAP, I.E. –with-ldap.
Publically accessible LDAP directory. Two are provided in the example.

Overview of Example

Setup Public LDAP Server Information
Create LDAP Query
Connect to LDAP Server
Process Query if Connection Was Successful
Format Output
Close Connection
Make HTML Form for Search Interface
Echo Results

Setup Public LDAP Server Information

The first thing we need to do is define all of the LDAP servers we might want to search. “LDAP_NAME”
= The name of the new LDAP entry. “LDAP_SERVER”
= The IP address or hostname of the new LDAP entry. “LDAP_ROOT_DN”
= The root distinguished name of the new LDAP entry.

Create LDAP Query

As mentioned previously, LDAP queries are not much like SQL queries. Therefore, the syntax may seem a bit limiting, but here is a basic example and one that works in this scenario.

//Create Query
$ldap_query = "cn=$common";

In our example “cn”
is the attribute on which we are performing the search, and $common
is the search string variable from the search form. LDAP query syntax allows for wildcard matching using ‘*’. For example, ‘*stanley’ will find ‘dan stanley’.

Connect to LDAP Server

The given function connects to an LDAP resource and assigns the connection link identifier to a variable, much like connecting to a regular database, like MySQL.

In our example, “$connect_id”
is the link identifier, $LDAP_SERVER
is the array of possible ldap servers, and $SERVER_ID
is the LDAP server variable from the search form.

Process Query if Connection Was Successful

If our connection was successful, we will have a valid LDAP link identifier and we can process the query.

Once we have established a connection to the LDAP services, we must identify ourselves. Most database connections with PHP send the username and password with the connection. However, with LDAP, credentials are unknown until a bind
is performed. In our example, “$bind_id”
is the bind link identifier. We are performing an anonymous bind to the public LDAP servers. Therefore, no argument is sent to ldap_bind()
accept the connection link identifier. After we have been authorized, via bind as anonymous, we perform the query using the ldap_search()
function. $search_id
is created and is our search link identifier. Then, we assign our result set to the variable $result_array
using the function ldap_get_entries(). This will allow us to sort the information in a logical manner for display.

Format Output

When an LDAP search is performed, the data is returned in whatever sequence it is found. In other words, there is not an easy way to sort the data like with a common SQL ORDER BY
statement. As well, many public LDAP directories do not have standard capitalization. Since the sort is based on the ASCII value of the strings, we must format the strings with all lowercase letters to appropriately alphabetize our output. It is important to note, that an LDAP result set is returned as a multi-dimensional array. Thus, at this point in our script $result_array
contains something like this:

$result_array[0]["cn"] [0] = "Dannie Stanley" ["dn"] [0] = "uid=dannie,dc=spinweb.net" ["givenname"][0] = "Dannie" ["sn"] [0] = "Stanley" ["mail"] [0] = "danSPAM@spinweb.net" $result_array[1]["cn"] [0] = "Michael Reynolds" ["dn"] [0] = "uid=michael,dc=spinweb.net" ["givenname"][0] = "Michael" ["sn"] [0] = "Reynolds" ["mail"] [0] = "michaelSPAM@spinweb.net"

The data is stored in this format because each attribute may have more than one value (IE a tree structure). For example, if my name is ‘Dannie,’ yet everyone knows me as ‘Dan,’ I could add an attribute to LDAP to store both representations of my given name like this:

$result_array[0]["cn"] [0] = "Dannie Stanley" ["dn"] [0] = "uid=dannie,dc=spinweb.net" ["givenname"][0] = "Dannie" ["givenname"][0] = "Dan" ["sn"] [0] = "Stanley" ["mail"] [0] = "danSPAM@spinweb.net"

For this search, we are only worried about the first value of every attribute so we will be using 0 as the index for each attribute, except for dn
(Distinguished Name), which contains only one value. Here is a brief list of attributes and their meaning: “cn”
= Common Name “dn”
= Distinguished Name “givenname”
= First Name “sn”
= Last Name “mail”
= Email Address

$fname $lname";
$result_list .= " <$email>
 ";
}
elseif
($dn &amp;&amp; $cn &amp;&amp; $email)
{ $result_list .= "$cn"; $result_list .= " <$email>
 "; } } }
else
{ echo "Result set empty for query: $ldap_query"; } ?>

In our example, $format_array
is our new array which contains the query results in a format optimized for output. First, we loop through every element of the $result_array
and assign it to a two-dimensional array for sorting purposes. At the same time we are using the strtolower()
function to make all values lower-case. Second, we sort the array using a handy little search algorithm provided by PHP called sort(). The first argument is the array. The second is what type of sorting to perform, as defined by the PHP documentation. Since we are sorting by string, we use “SORT_STRING”. Third, we loop through the newly formatted array and assign it to an output string named $result_list
that contains the HTML representation of the data. It is important to note that I have used the ldap URL format for the hyper-links. An example of this looks something like this: HREF=”ldap://ldap.domain.net/uid=dannie,dc=domain.net”.

Close Connection

Now that we have all of our data contained in $result_list, we can safely disconnect from the LDAP connection.

Make HTML Form for Search Interface

Finally, we get to the HTML output of the script. This set of code prints out the form that is used for performing the searches.

";
echo "Search in:
"; echo "Search for:";
echo "
";
echo "(You can use * for wildcard searches, ex. * Stanley will find all Stanleys)
"; echo ""; ?>

The only portions of this code that is interpreted is $PHP_SELF
which is a global constant for the name of the script itself and the loop that creates the SELECT box from our $LDAP_NAME
variable.

Echo Results

Now that all of the work has been done, we print out the result set. If no results were returned, a message is given stating the same.

$result_list
 
"; } else echo "No Results"; ?>

Source Code

Here is the complete source code. Simply cut and paste this into a valid HTML document and give it a try.

$fname $lname<
/A>"; $result_list .= " <$email>
 "; } elseif($dn &amp;&amp; $cn &amp;&amp; $email) {
$result_list .= "$cn"; $result_list .= " <$email>
 "; } } } else {
echo "Result set empty for query: $ldap_query"; }
//Close Connection
ldap_close($connect_id);
//Make Form
echo "";
echo "Search in:
"; echo "
Search for:"; echo "
"; echo "(You can use * for wildcard searches, ex. * Stanley will find all Stanleys)
"; echo "";
//Echo Results
if($result_list) { echo "$result_list
 "; } else echo "No Results"; } ?>

LDAP Login Example

ls — Sun, 02 Aug 2009 13:43:43 +0000

This app provides a simple example of login authentication using Netscape’s LDAP Java API.

Release Notes

For Solaris, make sure to compile on the deployed server to ensure all necessary classes are included in the CLASSPATH.

The example contains one AppLogic, Login.java (plus the standard base classes Session and BaseAppLogic), and two HTML files: LDAPLogin.html and wrongLogin.html. The login page, LDAPLogin.html, lets the user enter a user name and password, which are used to authenticate the user on the LDAP server. If successful, the user’s LDAP attributes are streamed out to the client. (In a real app, this would probably call a method to extract a user ID or role to save to the session, and then call another App Logic that goes into the application itself.) If the login is not successful, then the user is redirected to wrongLogin.html and allowed to try again, up to a maximum number of failures, after which all login attempts will be refused, until the user’s session expires.

In addition to the standard execute() and guid() method, the Login AppLogic contains the following methods:

maxFailuresReached: determines if the user’s maximum number of failed logins has been reached.
getDN: gets the LDAP distinguished name for the specified user
authenticateUser: attempts to authenticate the user with the specified password on the specified LDAP server.To get this example working you need to do the following:
Put the LDAP JAR file, LDAPJDK.JAR, on your NAS machine, and add it to your system CLASSPATH.
Because Java classes with native methods must be loaded by the default Java VM classloader, aka the ‘primordial’ classloader, instead of the KIVA classloader, you must edit a filter list in the registry. Start up kreg tool (Regedit on NT: HKEY_LOCAL_MACHINE).Navigate in the tree to the following key…SOFTWARE/KIVA/Enterprise/2.0/CCS0/SYSTEM_JAVAEdit the GX_CLASSPATH_CORE value. It’s default installed value should be…java.;gx.;com.kivasoft.Add “netscape.” so that it now looks like:java.;gx.;com.kivasoft.;netscape.
Then restart your Netscape Application Server.

Searching LDAP Servers with Net::LDAP

ls — Tue, 21 Jul 2009 13:53:01 +0000

The Lightweight Directory Access Protocol (LDAP) is the Internet standard for directory services. Perl provides one of the best tools you can use to build LDAP-based applications. In this article we’re going to learn how to use Perl to search LDAP servers.

Why Do We Need LDAP?

A directory service is specialized database that has been optimized for read access. The data that is contained in a directory service is usually the type of data that is accessed more often than it’s updated (things like password databases, DNS tables, etc). A directory is usually organized in a hierarchical fashion as opposed to a relational format. Finally a directory service generally is designed so that it can be easily distributed across different servers.

Directory services provide us with the ability to provide all sorts of services such as a network email address book, ability to provide single sign-on or manage networked devices like printers.

There several different directory service protocols, such as NIS/NIS+, Novell’s NDS and X.500. LDAP is an open-standard (X.500 is also an open standard and is the forebearer to LDAP, but it wasn’t widely implemented because of its roots in the OSI protocol) and has gained popularity because all of the major proprietary directory service vendors (Sun, Novell, Microsoft) have all released versions of their directory service products that can ’speak’ LDAP.

The most important thing LDAP provides for us is the ability to centralize the management of data that has been decentralized across the enterprise. This data has been decentralized because it was too hard to get access to it if it was managed centrally (e.g. in a mainframe). The reason why we want to move this data back to the ‘center’ is that in a networked environment, much of the information we need to accurately manage our connected world is stored in various data stores that aren’t easily accessed via a standard management interface.

Take user databases for example.

At the University of North Texas we created the concept of an ‘enterprise userid’ that could form the basis of single-signon. We came up with this specification about 8 years ago and in Academic Computing Services we have implemented the system. However, we have never had a real good idea of who should have access and when their access should be turned off (e.g. they graduated, left for a different job, etc). The best we could do was attempt to ‘read the tea leaves’ that we got in the form of a flat-file from our ID Card Office. In reality this information was actively maintained in a particular database in the mainframe, but we didn’t have a way to get access to the data in the mainframe from our Solaris boxes (CORBA was out of the question because our mainframe database doesn’t support a CORBA interface, it’s a long story .

Another problem was that other systems on campus, such as our Novell group wanted to be able to use our EUID database so that students could have the same userid on our UNIX systems and Novell systems.

Finally, in ironic twist, the Administrative Computing Services group (aka ‘the mainframe programmers’) wanted access to our student email addresses so that they could send them official messages like financial aid statements and grades.

Thus we decided to build an LDAP server since it would allow us to give access to this type of data via a standard, secure, open, Internet-based protocol.

Now the mainframe will provide us with a better feed (via a CORBA like product called EntireBroker) so that we have a better idea of who should & shouldn’t have access to computing services. We are also able to provide extra services such as automatically creating ‘bulk mail’ services for our administration and faculty. For example select members of the administration can send messages to students based on a particular query (e.g. all freshmen biology majors) and faculty can send messages to students in their courses. We use the LDAP server to answer these queries and to control access to who can send these messages.

Onto Perl!

Ok, you’re now wondering what does this have to do with Perl? Well a couple of things. One is that Perl is the de-facto standard for CGI programming and one of the most popular things to do with LDAP is to provide a Web interface to its information (generally in the form of an enterprise email/phone search). Second, LDAP is often populated with data from legacy information and Perl is one of the best tools you can use to move data from one source to another (in particular if you have to do any type of data normalization).

The rest of this article we are going to cover how to search an LDAP server using the Net::LDAP module.

First A Brief Intro to LDAP

Before we dive directly into LDAP programming, there are a few other things you need to know.

First the term ‘LDAP’ can mean one of four things. One is a data model. The data model defines what an LDAP entry looks like. Second, there is the naming model which defines how LDAP entries are named. Third is the security model which defines how to protect your data in an LDAP server. Finally there is an access model. The access model defines how LDAP clients and servers talk to each other.

The data stored in the LDAP server (as specified by the data model) are stored as entries. Entries have a collection of attributes which are represented as name-value pairs. Each attribute can have one or more values associated with it. The values can be text or binary. There is a special attribute called the Distinguished Name (DN) which must be unique within its particular directory server. A DN is made up of attributes found in the entry. By reading a DN you can determine where that entry fits into the directory server, just like you can figure out where a file fits on a hard-drive by looking at its path-name. One key difference between a DN and a path-name is that a DN goes from leaf to root while a path-name goes from root to leaf.

Here is an example of a DN:


uid=mewilcox,ou=people,o=airius.com

Check the resources section at the end of this article to learn where you can find more about LDAP.

Why Net::LDAP

Now we’ll actually start to do some programming. In our examples here we are going to be using Graham Barr’s Net::LDAP module. There are two other LDAP modules, Net::LDAPapi (no longer actively maintained) and Netscape’s PerLDAP which are Perl wrappers around the Netscape C LDAP API.

The Net::LDAP module is written in pure Perl, no C compiler required which makes this module incredibly portable. All you need is a copy of Perl 5.004 or later and you’re ready to go. On the Net::LDAP mailing list we’ve heard from people who have used the module on everything from MacPerl, to Windows, to all flavors of Unix and I’m pretty sure someone has even had a copy running on a mainframe somewhere all without having to recompile or port any code!

Assuming that you have the Perl lib-net bundle (required to do any network programming in Perl & I’m pretty sure a standard module set these days), then Net::LDAP only requires 2 modules, Convert::BER (soon to replaced by Convert::ASN1, I’ll explain more about this later) and Net::LDAP. Optionally you can also install Digest::MD5 (used for SASL-CRAM MD5 authentication) and the URI module (used to parse LDAP URLs). All of these modules are available on CPAN.

After you have downloaded the modules, they are a pretty straightforward install. If you are going to use the optional modules, you should install those modules first. Then you must install Convert::BER followed by Net::LDAP.

All of the modules follow a similar install procedure:

1. unpack the module
2. cd into their unpacked directory (e.g. perl-ldap-0.14)
3. type perl Makefile.PL
4. type make
5. type make test
6. type make install

Now you are ready to start hacking away.

Examples

In this article we are going to confine our examples to just searching an LDAP server. The steps to do this are:

1. load the Net::LDAP module
2. connect to the LDAP server
3. bind (authenticate) to the LDAP server
4. define what attributes we wish to have returned from the server
5. define a search base
6. define a search scope
7. define a search filter
8. perform the LDAP search
9. display the results

To connect to an LDAP server all you have to do is:


my $ldap = new Net::LDAP( 'hostname');

The next step is you must authenticate your connection to the LDAP server via an LDAP bind. The LDAP bind operation associates a client connection to a particular entry in the LDAP server. While LDAP can support a variety of authentication mechanisms including digital certificates and Kerberos (via the SASL mechanism), we are only going to concern ourselves with simple authentication which requires the Distinguished Name (DN) of an entry and a password. A DN is the unique name each LDAP entry has. Under LDAP you can authenticate to the server anonymously, this is very common for when you are using LDAP to publish a public directory service and you don’t want to issue accounts to the millions of potential users on the Internet. Generally, anonymous connections only have a very limited access to the server.

Here is how you authenticate as a particular user:


my $mesg = $ldap->bind('uid=mewilcox,ou=people,o=airius.com', password => 'password');

Here is how to authenticate anonymously:


my $mesg = $ldap->bind();

Nearly every function in Net::LDAP will return an Net::LDAP::Message object which I’ve put in my example here in the $mesg variable. You can use the Net::LDAP::Message::code function to check the LDAP return code. This will tell you if you successfully authenticated or not. Here is the code I use:


die ("failed to bind with ",$mesg->code()," ") if $mesg->code();

The code I just showed you works because under LDAP all non-successful operations will have an LDAP result code of 1 or greater. Since under Perl false is zero and any non-zero values is true, the die function will only be called if the LDAP operation did not succeed.

Our next step is to build our search function. A search requires three elements, a search base, a search scope and a filter.

The search base is the DN of the entry you want to be begin to your search at.

The search scope defines how much of the LDAP server you want to search at one time. There are three scopes. The most common scope is sub, which means start the search at the search base and search all entries below the base, but include the base entry in your search. There is also the base scope which starts at the search base and searches all entries below the base, but does not include the base entry. Finally there is a scope of one, which only searches the entry specified by the search base.

In a search filter you specify the attributes and values you want to match to declare a successful search. Whether a search is case sensitive or not depends upon what attribute you are searching. When you configure an LDAP server you tell it which attributes are case-sensitive and which ones are not.

A search filter can be very simple like this one:

(sn = Wilcox)

Which says find all entries that have a sn attribute that contains a value of Wilcox.

You can also do wildcard searches like this:

(sn = Wil*)

Which will find all entries that have an sn attribute that contains a value that starts with Wil.

You can also do boolean searches. AND is represented by the &. OR is represented by the | and NOT is represented by the !. You can combine AND and OR with different filters, but NOT can only apply to one filter.

For example here’s how you can say ‘give me all entries who have a last name of Wilcox and work in Accounting (where they work is specified in the ou attribute)’.

(&(sn = Wilcox) (ou=Accounting))

Or we can say ‘give me all people who work in Accounting or Engineering’.

(|(ou=Accounting)(ou=Engineering))

Or we can say ‘give me all entries except for those who work in Accounting’.
(!(ou=Accounting))

Or we can combine some of these like this.
(&(sn=Wilcox)(|(ou=Accounting)(ou=Engineering)))

Here is an example search in Net::LDAP:


$mesg = $ldap->search(
base => 'ou=people,o=airius.com',
scope => 'sub',
filter => '(objectclass=*)'
);

The searchbase is ou=people,o=airius.com, the scope is sub and the filter is (objectclass=*). This last filter says return all entries that have a value in their objectclass attribute. The objectclass attribute is the only attribute guranteed to be in each entry in the LDAP server (the DN is a special attribute is not really part of the entry). An objectclass attribute is used by the LDAP server to determine what attributes a particular LDAP entry is required to have and which ones it is simply allowed to have.

Again we can check for the success of the operation by using the returned Net::LDAP::Message object.

die (”search failed with “,$mesg->code(),” “) if $mesg->code();

The entries returned from a search are also contained in our Net::LDAP::Message object.

We can get them one at a time using either Net::LDAP::Message::shift_entry or Net::LDAP::Message::pop_entry. Or we can get all of the entries as once using Net::LDAP::Message::entries. An LDAP entry is stored in a Net::LDAP::Entry object.

I generally dump my entries using code that looks something like this:


while (my $entry = $mesg->shift_entry())
{
$entry->dump();
}

The easiest way to display the results of a search is using the Net::LDAP::Entry::dump method which simply dumps the contents of an entry to STDOUT in LDIF format. The LDAP Data Interchange Format is the standard way to display LDAP data in a human readable format. There is a newer XML standard, DSML, but it hasn’t been widely implemented anywhere (yet).

If you use simplesearch.pl or bindedsimplesearch.pl to search your local LDAP server, you will see results that look something like this:


dn:uid=scarter, ou=People, o=airius.com
cn: Sam Carter
sn: Carter
givenname: Sam
objectclass: top
person
organizationalPerson
inetOrgPerson
ou: Accounting
People
l: Sunnyvale
uid: scarter
mail: scarter@airius.com
telephonenumber: +1 408 555 4798
facsimiletelephonenumber: +1 408 555 9751
roomnumber: 4612

————————————————————————

One thing you’ll likely notice when you run these two example scripts is that the bindedsimplesearch.pl results will display more attributes than the simplesearch.pl. This is because LDAP uses ACLs to control access to the attributes stored in its entries. By properly configuring ACLs you can easily provide different ‘views’ to entries stored in the LDAP server.

While these scripts are handy for testing out LDAP servers, they don’t work real well when you want to either change how your results are displayed or when you only want to retrieve a select number of attributes from an entry.

One way to limit the attributes you are seeing is by telling the LDAP server to only retrieve particular attributes. This requires two steps.

First you must specify the attributes via an anonymous array like this:

my $attrs = ['cn','mail'];

Second you must pass these attributes to the LDAP server in the search method like this:


$mesg = $ldap->search(
base => 'ou=people,o=airius.com',
scope => 'sub',
filter => '(objectclass=*)',
attrs => $attrs,
);

Now lets say that instead of dumping the attributes out to STDOUT, you would like to dump the results out to a text file. While it is true you could simply pipe the output from the earlier scripts into a text file, there is a cleaner solution in Net::LDAP with the Net::LDAP::LDIF class. The Net::LDAP::LDIF class lets you read and write LDIF files. What’s great about this is that LDIF allows us to specify LDAP update commands in the LDIF itself and by using Net::LDAP::LDIF we can take other LDIF files and with relative ease, modify our LDAP server without having to write a lot of code.

However, for now we just simply want to write our search results out to a file. First you must directly import Net::LDAP::LDIF with use Net::LDAP::LDIF because Net::LDAP doesn’t automatically load the module into your program.

Next you must obtain an instance of the Net::LDAP::LDIF class like this:


my $ldif = new Net::LDAP::LDIF ('example.ldif','w') || die ("failed to open example.ldif. $! ");

This will open a new file named example.ldif that is ready to be written to.

Third instead of simply dumping the results to the screen with Net::LDAP::Entry::dump, you write them to the LDIF file like this:

$ldif->write($entry);

Finally when you are done with the LDIF file you can close it by:

$ldif->done();

But what about if you don’t want plain old LDIF. What if you wanted to be ahead of the curve and actually write your results out in DSML so that you could other things with it (e.g. apply style sheets to it for displaying in a browser or feed another datasource that only takes XML tagged data).

Here’s how you could do that.

First we must open a file to print our XML data out to.
open(DSML,”>example.xml”) || die(”failed to open example.xml.$! “);

Second we print out the first lines of our XML file.

print DSML ” “;
print DSML ” “;

Next we perform a search on the server and retrieve each entry one by one. Instead of dumping the entry to STDOUT or into a LDIF object, we are going to retrieve each of the entry’s attributes and values so that we can transform them into DSML entities.

Our first attribute we must get is the DN of the entry and print it out as DSML like this:
my $dn = $entry->dn();
print DSML ” “;

Next we get an array of the attributes stored in the entry.
#get a list of attributes
my @attributes = $entry->attributes;

Our next trick is to step through each attribute, get its values from the entry and then print out the resulting DSML.


for my $attribute (@attributes)
{
#in DSML objectclasses are written differently than other attributes
if ( $attribute eq 'objectclass')
{
print DSML " ";

my $values = $entry->get($attribute);

for my $v (@{$values})
{
print DSML "$v ";
}
print DSML " ";
}
else
{
#Rabbit
my $values = $entry->get($attribute);

print DSML " ";
for my $v (@{$values})
{
print DSML "$v ";
}
print DSML " ";
}
}

Finally we must close off all of our DSML entry tags.
print DSML " ";
}
print DSML " ";

The final steps are to close the DSML filehandle and the LDAP connection (via Net::LDAP::unbind, something you should do in all of your LDAP programs, though Perl will take care of it for you if you forget).

The resulting program, dsmlsearch.pl will print out an entry that looks something like this:

Sam Carter

scarter@airius.com

top
person
organizationalPerson
inetOrgPerson

Our final example will show you how to use the callback parameter of Net::LDAP. A callback is simply a subroutine that is called everytime a Net::LDAP::Message object is created during a search. The reason you want to go through the trouble of doing such a thing is that it can make your program appear to run faster, which is important when you’re using Net::LDAP to build a Web application. The reason why it appears to run faster is that you can start to work on the results as soon as they appear instead of having to wait for all of the results in a non-callback approach.

To make it easier to compare the code, I’ve rewritten the simplesearch.pl script to use a callback in a script called callbacksearch.pl.

Here’s the callback routine.


sub callback {
my ($mesg,$entry) = @_;

$entry->dump() if ref $entry eq 'Net::LDAP::Entry';
}

Now here’s the modified search method.


$mesg = $ldap->search(
base => 'ou=people,o=airius.com',
scope => 'sub',
filter => '(objectclass=*)',
callback => &amp;callback
);

Convert::ASN1

The most common complaint about Net::LDAP is that it’s ‘too slow’. Of course this is all a matter of perception. For all of the applications that I have written, Net::LDAP’s performance has been more than adequate. And any of it’s inefficiencies have been either covered up by network latency on the client’s connection or have been minor compared to the headache of compiling and installing a C based Perl module (especially if you must compile the C API from scratch). Another great thing about Net::LDAP is that people helping to contribute development represent users of all of the popular LDAP servers out there to help make sure that Net::LDAP stays vendor nuetral.

Net::LDAP will always be a bit slower than it’s C wrapper counterparts because it is pure Perl. Occasionally users have asked Graham to completely rewrite the API in C so that it will speed it up. But as Graham has pointed out, this isn’t necessary. The bulk of the work during any LDAP operation is in the encoding and decoding of the ASN.1 op-codes that LDAP uses to conduct its operations (occasionally LDAP does show its X.500/OSI roots). These methods have been carried out in the past by a module named Convert::BER (BER stands for Basic Encoding Rules, which is the encoding set LDAP uses for ASN.1). Graham has recently written a new module called Convert::ASN1. This module (still in pure Perl!) has already doubled the performance of Net::LDAP (at least in the development releases Graham and I have been testing out). He might even have a release on CPAN of Net::LDAP that uses Convert::ASN1 by the time you are reading this.

Graham also has written Convert::ASN1 in a way that will make it easier to put in a XS module so that those of us who can/want a C based back-end can have one, once such a module is written.