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.

You can download OpenLDAP from the main site located at ftp://ftp.OpenLDAP.org/pub/OpenLDAP/openldap-release/ or any mirror.

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 open-ldap-2.0.x.tgz and configure it.

bash$ ./configure --enable-shell
      

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. Create the directory /usr/local/var/openldap-netmeeting to store the LDAP database, and make it world writable.

Especially if you've changed the directories, 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. DNS issues with Windows 2000

Windows 2000 implements a modified DNS SRV (RFC 2782), an enhanced means of locating network servers, including LDAP. To avoid delays in connecting to an LDAP server from a Windows 2000 client, SRV records should be provided by the DNS server. ISC Bind has supported SRV records since version 8.2.2. As described in the Bind FAQ, the "check-names ignore" option is required to permit underscores in the DNS names. Basically, if your NetMeeting server name is "ils.freesoft.org", Microsoft Active Directory will expect to use a subzone called "_msdcs.ils.freesoft.org". Within this subzone, the "global catalog" server will be called "gc._msdcs.ils.freesoft.org" and its LDAP SRV record will be called "_ldap._tcp.gc._msdcs.ils.freesoft.org", as described by Microsoft. Got it? Your DNS database entry will then look something like this:

$ORIGIN _msdcs.ils.freesoft.org.

_ldap._tcp.gc     IN     SRV     1 1 389 ils.freesoft.org.
      

I've not yet been able to test this myself, not having a Windows 2000 system, so any feedback would be appreciated.

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.