Building a Bridge to the Active Directory

with XML-RPC

by Kelvin Param
December 19, 2001

Introduction

Active Directory of Windows 2000's directory service, allowing organizations to keep and share information about networked resources and users. One significant feature of the Active Directory is that it is LDAP-compliant. Unfortunately, it is still very difficult to access the Active Directory without using the Active Directory Services Interface (ADSI). As a COM component, ADSI is very partial to the Windows operating system.

What if you want to access information in your organization's Active Directory from a host that is not running Windows? One option is to build a piece of middleware (a daemon) to bridge a non-Windows host to the Active Directory. This article describes how to build such a daemon, and how to build a simple client would communicate with that daemon.

XML-RPC and Active Perl to the Rescue

XML-RPC is a mechanism that enables platform-independent and language-independent distributed computing. It serializes function calls and their associated arguments into an XML stream, and transports the stream via the ubiquitous HTTP protocol. Although it might be an over-simplification, XML-RPC provides some of the power of CORBA without the associated pain.

Learning Perl on Win32 Systems By Randal L. Schwartz, Erik Olson & Tom Christiansen Table of Contents Index Full Description Read Online -- Safari

The aim of this article is to walk you through the construction of a daemon that accesses data from the Active Directory using ADSI and passes on this data to other non-Windows clients via XML-RPC. This daemon must, of necessity, run on a Windows host.

A daemon isn't much good unless there is a client with which to communicate. As such, I will also walk you through the construction of a simple client application.

Since Visual Basic is the de facto standard for writing Windows applications, it would seem natural to build the daemon in Visual Basic. However, I'm just not comfortable with Visual Basic, even though I had used it on several projects. Fortunately, ActivePerl from ActiveState has a very well developed COM interface that can be used to interact with ADSI.

Before we get into the details of our Active Directory Daemon and Active Directory Client, here are the links to the source code, so that you can refer to it as we discuss the code and the logic behind it.

Active Directory Daemon: activedirectory_daemon.pl
Active Directory Client: activedirectory_client.pl

The Active Directory Daemon

Our daemon will be able to do the following:

a. Authenticate a user against the Active Directory using the user ID and password. A successful login will result in the salient data (e.g. surname, given name and email address) associated with the user ID being returned.

b. Return the chain of command (the user's immediate boss, the immediate boss's immediate boss, etc).

First, we need to load the modules below, and we also invoke the strict pragma.

  use strict;
  use Win32::OLE;
  use Win32::OLE::Const 'Microsoft ActiveX Data Objects';
  use Frontier::Daemon;

The first two are part of Active Perl, while the third module is available from CPAN.

The AuthenticateUser subroutine authenticates the user against the active directory.

  sub AuthenticateUser {
        my $strUserID       = shift || "someuserid"; 
        my $strUserPassword = shift || "Somepassword1";
        my $strADsPath      = shift || 
           'LDAP://OU=somedivision,OU=somedepartment,DC=someuniversity,DC=edu';
        my $strDomain       = shift || "\@someuniversity.edu";
        my $strAttributeName = "userPrincipalName";
        my $strAttributeValue = $strUserID;

We've assigned default values to some of the scalars above to provide an example of how arguments will be used at various points in the process of querying the Active Directory. There are several ways of interacting with ADSI. In this bit of code, we bind directly to ADSI. Later on, we will show how we can use ADO to bind to ADSI. It is important to note that each method of interacting with ADSI has its own peculiarities.

         my $objNameSpace = Win32::OLE->GetObject ('LDAP:') 
                or die ("Cannot create LDAP object");.
         my $objObjSec = $objNameSpace->OpenDSObject($strADsPath, $strUserID,
   $strUserPassword, 1);
         my %hashAdRecord;

We use Win32::OLE->GetObject('LDAP:') to utilize the LDAP services of ADSI. ADSI supports several directory services such as Novell NDS, and Windows NT4 amongst others. Next we try to access the Active Directory record associated with our user ID and password. The $strADsPath variable specifies what is roughly the domain name of the Windows 2000 forest, and how far down the forest one wants to begin searching. The DC=someuniversity,DC=edu is the LDAP analog of a DNS style domain name i.e. someuniversity.edu. In this example, we want to access the Active Directory starting at the organizational unit somedepartment that is a child of the organization unit somedivision.

We use $objNameSpace->OpenDSObject($strADsPath, $strUserID, $strUserPassword, 1) to access the Active Directory and retrieve the relevant record. The last argument in this subroutine is set to 1. It indicates that we are using an unencryted password.

    if (Win32::OLE->LastError()==0) {
        $refAdRecord =
            GetUserData($strAttributeName,$strAttributeValue,$strADsPath,$strDomain);
    } else {
        %hashAdRecord =('result' => 'failed');
        $refAdRecord = \%hashAdRecord;
    }

We use Win32::OLE->LastError() to ascertain if we have a valid user. Win32::OLE->LastError() is ActivePerl's implementation of Visual Basic's Err.Number. Up to now, everything is pretty straightforward. Deciphering the error codes is a little tricky. Here's how the error logic works. Win32::OLE->LastError() returns a non-zero only if the password is invalid. However, supplying a non-existent user ID will result in zero being returned. As such this bit of code is only good for detecting an invalid password. So, how do we detect a non-existent user ID? Our GetUserData subroutine serves a dual purpose. It not only detects a non-existent user ID, but also returns data from the Active Directory object that is associated with a valid user ID.

We can only return references to the XML-RPC client, so we need to define a scalar variable to which we can assign a reference of the return value. Furthermore, the scalar variable has to be global to the XML-RPC daemon program. In our case, the scalar variable is $refAdRecord. If the user id and password are valid, the reference to the hash returned by the subroutine GetUserData is assigned to the scalar $refAdRecord. On the other hand, if the user id and password are not valid, we insert the 'result' => 'failed' key-value pair to the %hashAdRecord hash variable, and subsequently assign the reference of that hash variable to $refAdRecord.

    $objObjSec->Close;
    $objNameSpace->Close;
    return $refAdRecord;
    }

And, it's time to destroy the ADSI objects that we created earlier.

Now, we move on to the XML-RPC specific bits of the daemon program.

    my $methods = {
    'activedirectory_daemon1.GetUserData' => \&GetUserData,
    'activedirectory_daemon1.GetCommandChain' => \&GetCommandChain,
    'activedirectory_daemon1.AuthenticateUser' => \&AuthenticateUser

    };

We declare a hash of subroutines that are accessible to the XML-RPC client. The key of each entry is the name of the method prefixed by an identifier using the dot convention. In our case, we arbitrarily use the name of the daemon file as the identifier. The value part of each hash entry is the de-referenced pointer to the corresponding method. This hash serves as a sort of look up table for requests to methods made at the XML-RPC client. The subroutines besides AuthenticateUser will be discussed later in this article.

    Frontier::Daemon->new(LocalPort => 8080, methods => $methods) 
           or die ("Cannot start HTTP daemon: $!");

At this juncture, we insert the code that fires up the XML-RPC daemon. We do so creating a new Frontier::Daemon instance. The constructor subroutine takes two arguments, each as a key-value pair. The first argument is the port used by the daemon. Since the host may already be running a web server, we'll use port 8080. The second argument is the set of subroutines to be published for use by the XML-RPC client (see above).

Besides the AuthenticateUser subroutine, we've also included a couple of subroutines that retrieve useful information about a user. GetUserData retrieves data like the user's email address, telephone number, etc. Although we call GetUserData from other subroutines (AuthenticateUser and GetCommandChain) within the daemon program, GetUserData may also be called from an XML-RPC client to retrieve data in the Active Directory about any user whose record is accessible. Instead of binding directly with ADSI, in this case, we use ADO to bind with the Active Directory, just so that the retreived data is presented as a record like if the data was retrieved from a relational database.

    sub GetUserData {
        my $strAttributeName  = shift; #could be userPrincipalName, cn etc
        my $strAttributeValue = shift; #could be user ID, cn value etc
        my $strADsPath        = shift; #could be
        # "LDAP://OU=somedivision,OU=somedepartment,DC=someuniversity,DC=edu"
		
        my $strDomain         = shift; #could be "someuniversity.edu"

        if ($strAttributeName eq "userPrincipalName") { 
            $strAttributeValue = $strAttributeValue . $strDomain; s
        }

        my $strProvider = "Active Directory Provider";

        my $strConnectionString = $strProvider;

        my $strFilter = "(" . $strAttributeName . "=" . $strAttributeValue . ")";

        my $strAttribs =
             "userPrincipalName,sn,givenName,cn,department,telephoneNumber,mail,title,manager";

        my $strScope = "subtree";

        my $strCommandText = "<" . $strADsPath . "E>;" . $strFilter . "
        ;" . $strAttribs . ";" . $strScope;

        my $objConnection = Win32::OLE->new ("ADODB.Connection") 
             or die ("Cannot create ADODB object!");

        my $objRecordset = Win32::OLE->new ("ADODB.Recordset")
             or die ("Cannot create ADODB recordset!");

        my $objCommand = Win32::OLE-E<gt>new ("ADODB.Command") 
             or die ("Cannot create ADODB command!");

        my %hashAdRecord;

The above code snippet from the GetUserData subroutine shows what values are assigned to varaibles. This subroutine has four arguments:

a. $strAttributeName

b. $strAttributeValue

c. $strADsPath

d. $strDomain

At this juncture, I'll try to explain how the above variables are used. In our case, we will search the Active Directory for the record that contains a given value for the userPrincipalName. As such, $strAttributeName = "userPrincipalName". If the user ID is jsmith12, then $strAttributeValue = "jsmith12". Alternatively, if we call the GetUserData subroutine from inside the AuthenticateUser subroutine, we declare $strAttributeValue = $strUserID in the AuthenticateUser subroutine.

Pages: 1, 2

Next Page