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

Ulteo Open Virtual Desktop 2.0 is Put on Market

ls — Mon, 21 Dec 2009 08:38:49 +0000

Gael Duval – the founder of Mandrake/Mandriva Linux and Ulteo declared about the release of new Ulteo Open Virtual Desktop (OVD) 2.0 version. It is Linux novelty based on Debian and Ubuntu. OVD allows starting up Linux and Windows applications through Web-browser with the help of Java.

The last release of Virtual Desktop of Ulteo has a new Web-portal mode providing applications’ loading in self supporting browser windows. Besides that it has in-built MP3 and FLV players for multimedia files.

Also OVD supports LDAP- and CAS-services for autointoxication and Windows, WebDAV и Samba file services.

Linux applications basic set available in Ulteo Open Virtual Desktop 2.0 includes OpenOffice.org, Web-browser, Firebox, Thunderbird, and IM-client Pidgin.

Ulteo Open Virtual Desktop 2.0 is available for free downloading. The code can be taken under GNU GPLv2 license on code.ulteo.com.

How Microsoft went wrong with Active Directory

ls — Sat, 28 Nov 2009 13:47:49 +0000

Microsoft’s Active Directory (AD) is a powerful tool for an enterprise computing environment, but there haven’t been many enterprise environments lining up to adopt it. According to February 2001 data from the Giga Information Group, Windows 2000 server licenses exceeded the 1 million copy mark, but only 10 to 15 percent have deployed AD in any way.

Many of the AD deployments have been relegated to lab testing or small, virgin Windows 2000 environments.
Based on my experience as a systems consultant for enterprise environments, many of those 1 million Windows 2000 servers are:
Rogue workgroup file and print boxes or member servers in existing Windows NT 4.0 domains.

Acting as non-domain-connected workgroup IIS 5.0 Web servers.

Acting as Windows 2000 Terminal Servers replacing aging Citrix Winframe or Metaframe or Microsoft Terminal Server machines.While Windows 2000 Server provides a huge improvement in stability and functionality over previous versions of the product, the reception to its Active Directory has been less than lukewarm.

Why hasn’t it been embraced?

Reason 1: No PDC functionality

Microsoft shot itself in the head by not giving Windows 2000 Server the ability to act as a drop-in replacement for an existing NT 4.0 Primary Domain Controller (PDC) or Backup Domain Controller (BDC). For many environments, the NT 4.0 master domain/resource domain model is fine, and they don’t need or want a sophisticated directory service.

As it stands, you can run Windows 2000 as a member server, as a rogue workgroup machine, or as an AD domain controller. You can have a “mixed-mode” AD domain where NT 4.0 servers authenticate to a Windows 2000 domain controller, but to accomplish this you have to perform an upgrade install on your existing PDCs and BDCs.

Optimally, you should be able to drop a new Windows 2000 box into your domain and have it assume the role of a BDC (or a workgroup or member server), which could then be promoted to PDC. Then, when the environment is ready, you should be able to promote the PDC to an Active Directory domain controller, allowing for mixed-mode use.

Reason 2: History repeats itself

Remember Novell’s initial release of NetWare 4 bundled with NDS way back in 1994? Because of NDS’s complexity, it took a long time for NDS to get mind share in NetWare 3.12 shops.

Microsoft’s bundling of the first version of AD with its operating system forces an upgrade to AD if you want any kind of centralized security authentication, so it’s clear the company hasn’t learned from Novell’s bundling mistakes.

It would have made sense for AD 1.0 to be an add-on product to Windows 2000, probably in the form of Exchange 2000; except that Exchange 2000 came out quite a few months after Windows 2000.

You can’t deploy or upgrade from Exchange 5.x to Exchange 2000 without Active Directory, so it makes sense that AD’s early adopters are often Exchange shops, which already understand AD’s replication and site architecture.

Reason 3: A firm hand on the namespace

One of the key factors in a successful AD deployment is designing the Active Directory DNS namespace. Unlike NT 4.0, which uses WINS, Windows 2000 uses DNS to resolve names on the network.

Unfortunately, you can’t just use any old DNS. Active Directory requires that the DNS support dynamic updates via RFC 2136; and guess what, the only DNS that does that out of the box is included in Windows 2000.

Those environments that already have Internet domains and DNS servers on their networks now have to replace their existing DNS servers with Windows 2000 boxes or create a new internal domain to host the AD. For example, if your company is called WidgetCo, and all your internal servers are TCP/IP hosts on widgetco.com, you either need to create a sub-domain called ad.widgetco.com or you need to create something like widgetco.net, as one of my associates had to do at a large Manhattan-based international law firm.

It’s possible to make Unix DNS servers like BIND (Berkeley Internet Name Daemon) support Windows 2000 dynamic DNS, but it’s a little tricky. Microsoft TechNet’s white paper on Windows 2000 DNS provides information on getting your non-MS DNS to comply with RFC 2136.

Chances are you’ll need to upgrade your Unix server to the latest version of BIND, version 8.2, to make it work. Creating an entirely new domain may be less of a headache.

4. The predominance of IT fiefdoms

Most large companies are collections of fiefdoms that each has its own IT standards. In a worst-case scenario, AD may be implemented by each IT fiefdom separately and on its own time frame.

The problem with this is that once you start an AD, the first domain becomes the parent domain and all successive domains are child domains. You either have to live with the hierarchy that someone else started or you have to wipe the entire thing out and start from scratch.

Microsoft still hasn’t given us a way to graft two ADs together, although these tools are reportedly coming in Windows 2002 Server.

5. Deficient built-in tools

AD is a failure because it lacks good tools for administering it on a large scale. Key features, such as easy drag-and-drop of objects and organizational units, and trouble-free pruning and grafting, are only available through third-party utilities.

The problems with the built-in tools are exacerbated by the Microsoft Management Console (MMC). With its scores of plug-in modules, the MMC is a bear to deal with. If the MMC designers thought like NT administrators, they would use tabular views instead of endless levels of layered dialog boxes.

What Microsoft needs to do is provide an uber-management tool like SystemTools.com’s Hyena or Dorian Software Creation’s UltraAdmin. These products let you drill down to manage the directory, objects, and services.

Those are the top five flaws I think are holding AD back. Let me know what your issues are, or, if you’ve implemented AD, whether the gain is worth the pain.

Is there a need for OpenLDAP?

ls — Tue, 24 Nov 2009 13:50:26 +0000

Readers of my Wired Windows column in Network World know that I’m not a big fan of the open source movement – at least as far as commercial-grade software is concerned. For that reason, I haven’t paid much attention to Open Lightweight Directory Access Protocol (LDAP) – (http://nww1.com/go11/0611DSV2A.html), the open source directory service.

Of course, there’s also the fact that OpenLDAP defines itself as “…an open source implementation of the Lightweight Directory Access Protocol.” Last time I looked, LDAP was defined in a series of Internet Engineering Task Force Requests for Comment (IETF RFCs), which is about as “open” (that is, its published for all to use freely) as you can get!

OpenLDAP.org is run by something called the OpenLDAP Foundation, a non-profit organization which is evidently designed to solicit donations for itself. I would like to speak to any of the officers of the foundation but, curiously, they aren’t listed anywhere on the Web that I could find. They appear also to not have telephone numbers, although there is a mailing address (in Redwood Shores, CA – also the home of Oracle. Coincidence?).

Most of the OpenLDAP project is either taken directly from, or derived from on-going work at the University of Michigan (where LDAP originated). The SLAPD (LDAP daemon) and SLURPD (LDAP update daemon) servers are almost direct ports of work from Michigan. There’s nothing wrong with that as it is in the public domain. But there’s little evidence of much new development from the OpenLDAP group.

OpenLDAP did fill a need for an easily obtainable, LDAP-enabled directory service with a low entry price (it’s free – but you had to compile the source code). Shoestring funded start-ups in the directory-enabled applications business could use it for building and testing their software, and even recommend it to clients who didn’t have an installed directory service (or didn’t know they had one). Now that Novell is giving away eDirectory to independent software vendors and Active Directory is included with Windows 2000 servers, those reasons go away.

Since the initial reasons for the OpenLDAP project no longer exist, I’d like to suggest a change. Let’s forget about duplicating commercial efforts to create data repositories and directory services. Instead, let’s focus on creating directory- enabled applications that leverage the installed base of LDAP- enabled directory services. Give users some concrete applications that make use of the authentication, authorization and personalization mechanisms the directory makes available. That would be a public service.

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.

The Top Ten Reasons AOL was Off-Line

ls — Mon, 15 Jun 2009 14:01:54 +0000

The Top Ten Reasons AOL was Off-Line and the Advantages Plus, The real reason for the big Western Power Outage.

Reasons:

1. Agent Mulder and Scully’s celebrity chat shut down by unexplainable forces from somewhere out there.

2. Disgruntled employee tired of AOL’s practice of rounding back their paycheck to the nearest ten dollars.

3. Their new version 3.0 software code was written by the IBM Olympic software team.

4. Steve Case was reading his latest net-worth statement and began clapping. He forgot the AOL server was turned on and off by “The Clapper”.

5. Bill Gates, in his usual “I don’t get angry, I get even” way, decided it was time for “Justice Department Anti-Trust Investigation” payback.

6. Tribbles

7. Changing their name to AWOL.

8. “Blackout” actually part of the First Annual AOL-vs.-MSN Corporate Sabotage Extravaganza. MSN won.

9. AOL carrying “Campaign ‘96″ updates. Temperature-sensitive components damaged by all that hot air.

Advantages:

1. No e-mail from people with moronic screen names like KewlDude45@aol.com

2. $$$$$$$ No idiot get-rich-quick spams to Usenet! $$$$$$

3. I won’t be stood up this evening by yet another AOL date.

4. May force millions of people to actually talk to their families.

5. Will most certainly see a rise the number of newborns in 9 months.

OUTAGE DUE TO ERRANT SOFTWARE ON POWER COMPANY COMPUTER

PORTLAND, OREGON (INI) – A software disk that had not properly been erased is to blame for an outage that cut power to 4 million customers across the West, one of the most severe in U.S. history. Officials at Western System operations now say a “free” America Online disk that had been thought to been erased, and then was re-used, is to blame for the outage. Technicians had used the disk to run computers that control power grids for nine U.S. states.

The problem was first noticed Saturday at 2:00 PM (PST) when control room computers began sending an audio message stating “you’ve got new mail” and then shut down a power grid for two states. Computer operators began to re-start their system but before they could complete it an AOL 3.0 Web browser appeared on their screens and then shut down grids for the remaining states.

A power company spokesman said part of the blame for the outage should be shared by America Online. “They send you a disk almost every other day. They know people are going to re-use them.” An AOL official denied reports that his company would give affected power company customers one free day of electricity plus ten hours of online access and an AOL “tote bag” as compensation for the outage.

Softerra LDAP Tools

ls — Thu, 12 Mar 2009 14:16:38 +0000

Description: Although Softerra specializes in developing custom solutions, we are also offering several standard products that may be useful for different kinds of organizations.

SofterraTM LDAP AdministratorTM is a fast and easy-to-use tool for managing LDAP directories. It has been developed specially for Win32 platforms. It provides a convenient Explorer-like interface to facilitate your work. LDAP Administrator connects to any LDAP v2 and v3 servers. More…

SofterraTM LDAP Browser is a free utility for viewing LDAP catalogues. Here you may download the latest version. More…

SofterraTM Time-AssistantTM is an effective time-tracking and salary-calculating solution, whose online version is available for FREE. You may also order an Intranet version for your organization. More…

SofterraTM KeyPen Suite – on-screen keyboard and handwriting recognition software for Win CE platform. The evaluation version is available for a FREE download. More…

SofterraTM PHP Developer Library is a selection of classes and functions to help you create a quality PHP code for various web solutions. It is being distributed under GNU LGPL conditions. You may download the latest version right here. More…

SofterraTM Hex Editor is a freeware component that can be used by software developers to seamlessly integrate a hex editor in their applications. It is implemented as a 32-bit ActiveX (OCX) control and can be used with the most popular ActiveX (OLE, OCX) control containers, such as Delphi, C++ Builder, Visual C++ and many more. More…