3. NetMeeting directory kit

3.1. What is it?

Each NetMeeting client can register with an LDAP server and has a directory window that lists other NetMeeting clients registered with the same server. The NetMeeting directory kit is an extension to the OpenLDAP server that provides directory service to NetMeeting clients.

3.2. Why is it needed?

While NetMeeting can connect directly to another H.323 device by specifying an IP address or DNS name, normally you'll want to use an LDAP directory server. Using an LDAP server lets users see a directory listing of available destinations, and is required if you need to resolve aliases, for example if you want to serve multiple H.323 destinations from a single IP address. A directory server isn't required to connect directly from Linux to a NetMeeting client; use OpenH323 for this.

The NetMeeting client violates the LDAP protocol in several ways, so you'll have problems if you try using a standard LDAP server. The NetMeeting directory kit corrects for these problems and allows an OpenLDAP server to be used for NetMeeting directory service.

3.3. How it works

                 Block diagram of NetMeeting directory kit

___________________         _______    __________________        ______________
|    LDAP server  | request |      |   |   LDAP server  | request|            |
|                 | <-------| Perl |<--|                | <------| NetMeeting |
| on private port |         |script|   | on public port |        |  client    |
|  (i.e, 2345)    |-------> |      |-->|     389        |------->|            |
|                 | reply   --------   |                |  reply --------------
|                 |                    |                |      
-------------------                    ------------------

The directory server consists of a 'master' LDAP server to receive requests, a Perl script to correctly interpret the Microsoft NetMeeting requests and, after interrogation of a 'hidden' LDAP server, formats the results in a way that the NetMeeting client can understand. OpenLDAP's 'shell backend' is used to call the Perl script. A custom schema is also required. The script presently handles all of the above problems, with the exception of timing out entries, which it doesn't do.

3.4. Where to get the software

First of all you need to get the OpenLDAP software.

Pre-built OpenLDAP software (i.e, RPMs) won't work unless configured with support for the shell backend.

You can download OpenLDAP from the main site located at ftp://ftp.OpenLDAP.org/pub/OpenLDAP/openldap-release/ or any mirror. I've successfully used OpenLDAP 2.0.7.

The NetMeeting directory kit is available from http://www.freesoft.org/software/NetMeeting/download.

You need Perl 5, available from http://www.perl.org, but already included in all common Linux distributions. You will also need the Net::LDAP module from the Perl CPAN archive, which can be downloaded and installed directly from Perl:

[root@y2k baccala]# perl -MCPAN -e shell

cpan shell -- CPAN exploration and modules installation (v1.58)
ReadLine support enabled

cpan> install Net::LDAP

... much output omitted ...

  /usr/bin/make install -- OK

cpan>

If you've never used CPAN before, you will be prompted first with a series of configuration questions. Once CPAN is configured, the Net::LDAP module will be downloaded, compiled, and installed automatically.

3.5. Installation

Building OpenLDAP will require approximately 60 MB of free disk space. Untar OpenLDAP and configure it.

Be sure to specify the shell backend function "--enable-shell"

I also recommend specifying "--disable-debug" to prevent OpenLDAP from exiting if an assertion fails.

bash$ ./configure --enable-shell --disable-debug
      

Now build and install it with:

bash$ make

... much output omitted ...

bash# make install
      

It will normally install under /usr/local:

Once OpenLDAP has been installed, next install the NetMeeting directory kit. Untar ndk.tgz. It contains these files:

Copy netmeeting.perl to the /usr/local/libexec directory, netmeeting.schema to the /usr/local/etc/openldap/schema directory, and copy both slapd.conf and slapd2.conf to the /usr/local/etc/openldap directory.

Be sure to use core.schema.patch to patch openldap's core schema in the /usr/local/etc/openldap/schema directory:

bash$ cd /usr/local/etc/openldap/schema
bash$ ls
corba.schema   inetorgperson.schema  misc.schema        nis.schema
core.schema    java.schema           nadf.schema        openldap.schema
cosine.schema  krb5-kdc.schema       netmeeting.schema
bash$ cp core.schema core.schema.bak
bash$ patch core.schema < ~/core.schema.patch
      

Create the directory /usr/local/var/openldap-netmeeting to store the LDAP database, and make it world writable.

Especially if you're using directories from the samples, edit slapd.conf and slapd2.conf and verify their configuration settings.

You will need to run two copies of slapd. One uses slapd.conf and must be started as root, since it binds to port 389. The -u option can be specified to cause slapd to chown to an unprivileged user after binding the port (a wise precaution). The other slapd uses slapd2.conf, binds to an unprivileged port, and only needs sufficient privilege to write the database directory.

bash# /usr/local/libexec/slapd -f /usr/local/etc/openldap/slapd.conf -u nobody
bash$ /usr/local/libexec/slapd -h ldap://localhost:2345/ -f /usr/local/etc/openldap/slapd2.conf
      

You now have to initialize the slave database with a single entry. This is only done once, by running the initialize script included in the kit. The "rootdn" and "rootpw" entries are in the slave config file to allow access for the initialization script, and must match the -D and -w options in the script. Once you've initialized the database with a single parent entry, you can comment out the "rootdn" and "rootpw" lines from slapd2.conf, though this is not critical.

The server should now be up and running. For systems with /etc/rc.d/ style initialization scripts (like RedHat), the slapd.rc is provided to automate the starting and stopping of the slapds.

3.6. Server Security

As shown above, I run both slapds as an unprivileged user, minimizing the possibility of compromised security due to a bug in either the server software or the Perl script. Of course, this requires the database directory to be world writable so that the unprivileged slave server can update it. This isn't as glaring a hole as it might first appear, since the NetMeeting clients themselves use no authentication. Thus, even if the database directory were better protected, anyone on a local or remote host could use LDAP client programs to delete or modify any of the database entries.

3.7. LDAP issues with Windows 2000

Recent NetMeeting releases initially attempt to connect to the LDAP directory server on port 1002. As described in a TechNet chat,

Prior to Windows 2000, an ILS server would listen on port 389 for NetMeeting clients. When an ILS server is set up on a Windows 2000 machine, it will default to port 1002.

3.8. Interoperation with other LDAP service

The instructions above assume that your LDAP server is only being used for NetMeeting directory service. Yet what if you want to use a single server for both NetMeeting directory service and other LDAP service? Only one server can be bound to port 389, but OpenLDAP allows multiple database sections to be specified in its configuration file, each serving different parts of the LDAP namespace. NetMeeting uses only the "objectClass=RTPerson" subtree, so as long as you avoid this subtree, you can configure additional database sections to serve other subtrees with other databases. The biggest problem you are likely to encounter is the custom NetMeeting schema, which conflicts slightly with the standard schema. Since the NetMeeting schema is more liberal than the standard schema, I'd suggest commenting out the conflicting parts of the standard schema. NetMeeting clients won't work with the standard schema. See the LDAP RFCs and the OpenLDAP documentation for more information about configuring LDAP servers.