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.
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.
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.
First of all you need to get the OpenLDAP software.
Note: 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.
Building OpenLDAP will require approximately 60 MB of free disk space. Untar OpenLDAP and configure it.
Note: 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:
Table 2. Directories used by OpenLDAP
| /usr/local/lib | Shared and static libraries |
| /usr/local/bin | Client binaries for adding, deleting, and searching LDAP servers |
| /usr/local/sbin | Utility programs for manipulating the raw database files. Not needed for normal operation. |
| /usr/local/libexec | Various server programs, including the slapd binary |
| /usr/local/etc/openldap | Contains the default configuration files |
| /usr/local/etc/openldap/schema | The different schemas used by the LDAP servers. |
| /usr/local/var/... | The location of the LDAP databases (in subdirectories) |
| /usr/local/man/... | Documentation |
Once OpenLDAP has been installed, next install the NetMeeting directory kit. Untar ndk.tgz. It contains these files:
Table 3. NetMeeting directory kit files
| netmeeting.perl | Perl script used to correct NetMeeting protocol violations |
| netmeeting.schema | Custom NetMeeting schema used by the LDAP server |
| slapd.conf | Sample config file for the master LDAP server |
| slapd2.conf | Sample config file for the slave LDAP server |
| initialize | Shell script used once to initialize the slave LDAP database |
| slapd.rc | /etc/rc.d/ script |
| nmaddentry | Perl script to add entries to the NetMeeting directory |
| nmdirectory | Perl/Tk script to query the NetMeeting directory |
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.
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.
Recent NetMeeting releases initially attempt to connect to the LDAP directory server on port 1002. As described in a TechNet chat,
If a connection to port 1002 is rejected, NetMeeting will fall back on the standard LDAP port 389. However, at least one user has reported trouble with a firewall that blocks port 1002, discards the connection attempts, and thus no replies are received to reject the connection. In this case, NetMeeting takes about a minute to timeout and fall back to port 389. Opening the firewall to port 1002 allowed the rejects through and triggered a rapid fallback.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.
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.