LISTSERV can interface to LDAP servers to authenticate user logins, to insert LDAP attributes in mail-merge distributions, as well as to implement Dynamic Queries (see Section 9
Dynamic Queries for more information).
Note: For clarity, Dynamic Query functions have been omitted from the diagram, but they also interface with the LDAP functionality.
The LDAP interface is at the same level as the DBMS interface – not at the level of the vendor-specific SQL drivers. Quite simply, LDAP servers do not “speak” SQL. To support LDAP, we had to teach the mail-merge and authentication modules to “speak” LDAP. This is why there is a new syntax for every LDAP-related function.
The first step in using LDAP with LISTSERV is to add one or more LDAP servers in the LISTSERV site configuration. This can be done via the LISTSERV web administration interface (the preferred method), or alternately by adding the entries manually to SITE.CFG or ‘go’.
Each LDAP server is given a nickname in the LISTSERV configuration, similarly to DBMS data sources. You can also configure one unnamed LDAP server, again like with DBMS data sources, but it is probably less confusing to assign a nickname to every LDAP server.
The userid and password that LISTSERV should use in order to login to the LDAP server. The exact format of the userid depends on your LDAP server. LISTSERV does not attempt to parse or reformat these variables. If the password is the empty string, most LDAP servers will perform an anonymous login. If both userid and password are the empty string, LISTSERV will attempt a default login, as defined by the LDAP library for your operating system. Under Windows, LISTSERV will be logged in with its current domain credentials (assuming it is connecting to an Active Directory server), and this usually provides sufficient access – try it before configuring a userid and password.
The ‘distinguished name’ that should be the ‘base’ for searches when LISTSERV looks for a user account (see below for an explanation of the authentication process). This can be used to restrict LISTSERV access to a particular organizational unit within the enterprise. If omitted, LISTSERV tries to guess the DN that will admit any Active Directory Windows account, but this is a difficult guess to make, and of course you may not even be connecting to Active Directory.
The LDAP ’filter’ that should be used when looking up user accounts (if this filter returns at least one entry, LISTSERV allows the user to try and log in; otherwise, the login is rejected, even if the user would otherwise be able to log in to the LDAP server with the supplied credentials). Any occurrences of ‘%s’ are replaced with the user’s full e-mail address, while ‘%u’ expands to just the userid and ‘%h’ expands to the hostname. If omitted, LISTSERV uses a filter that is suitable for most Active Directory installations.
Because of its complex, machine-friendly syntax, LDAP is primarily suited for scripting. While it is relatively easy for a programmer to write a script that sends a weekly notice to every member of a particular department, it is not realistic to expect ordinary list owners or end-users to understand the intricacies of LDAP and devise working search filters. For instance, to select all users in an Exchange database, one would have to use the following filter:
L-Soft expects that LDAP-based distributions will be created by customer-developed scripts – either intranet web scripts or traditional ‘cron’ jobs or scheduled tasks. At this point, there are no plans to provide a web interface page into which raw LDAP search filters could be entered.
Similarly to SQL-based distributions, the ‘TO’ DD contains a list of LDAP search statements, rather than a list of actual recipients. Each line in the ‘TO’ DD can be one of the following statements:
Note: The
E-MAIL and (if enabled)
PARTS attributes must be specified or the distribution will fail.
LISTSERV can be configured to use one or several LDAP servers for authentication (user login). You can choose to allow users without an LDAP account to log in with an internal LISTSERV password, or to restrict access to users with an LDAP account.
Warning: Make sure to test your LDAP settings before enabling this option, or you will not be able to undo it from the web interface! Enabling this option on a server that previously had external users is likely to result in significant confusion for the external users, whose passwords will no longer work.
Note: This option does not control LISTSERV’s own use of SSL when communicating with the LDAP server. See the LDAP_SERVER_nickname variable.
The purpose of the “require SSL” option is to prevent ordinary, non-malicious users from jeopardizing their login credentials for their personal convenience, for instance by typing clear-text passwords in e-mail requests because it is faster than waiting for a confirmation ‘cookie’ at the particular Internet café where they are reading their mail. The “require SSL” option effectively disables these login attempts and forces users to log in using the web interface and SSL.
As LISTSERV does not directly process SSL sessions, it has no first-hand knowledge as to whether SSL was used to encrypt the login session or not. It is the web server that handles the SSL session with the user’s browser, notifies the LISTSERV web interface that SSL was used, and the web interface script in turn notifies LISTSERV that the password was not sent in clear text. LISTSERV has no way to verify this representation or guarantee that SSL was in fact used to transmit the password. This being said, there is no advantage for a malicious user in logging in to LISTSERV with his own credentials over an unencrypted connection. The malicious user’s interest is for other, non-malicious users to expose their passwords by sending them in clear text, so that the malicious user may gather them.
The optional LDAP_PW_BIND site configuration variable is now available in all LISTSERV 16.0 builds. This variable contains the string to format and use when logging on a user. The default is "%n", which works "out of the box" with Active Directory and, in most cases, with OpenLDAP. For other LDAP implementations, or if a different bind string is required for your local installation, it can be defined in this setting and may use the %u/%h/%s escapes.
|
•
|
VMS: LDAP_PW_BIND_MYSERVER "%n"
|
|
•
|
unix: LDAP_PW_BIND_MYSERVER="%n"
|
export LDAP_PW_BIND_MYSERVER
|
•
|
Win: LDAP_PW_BIND_MYSERVER=%n
|
Important: The default value for LDAP_PW_BIND is now "%n".
Setting up LISTSERV to authenticate via LDAP with SSL can be challenging. There are several scenarios that are dependent primarily on the version of Solaris you are running.
|
1.
|
Confirm that you have the ‘certutil’ utility on your system AND that it operates in the old cert7.db format. This utility does not come pre-installed and is unlikely to be in root’s default path. This would be something you or a colleague installed manually at some point, presumably in /usr/local/bin, but it could be elsewhere.
|
This scenario will generally be unworkable because of certificate incompatibilities introduced by Sun in Solaris 9. Although Sun's LDAP for Solaris 9 requires certificates to be formatted in the older cert7.db format, the certutil utility that ships with Solaris 9 creates cert8.db format files.
Important: We strongly recommend that Solaris 9 users wishing to use LDAP with LISTSERV contact Sun directly for support on this issue. L-Soft is unable to provide support for this issue as it is a problem that only Sun can resolve.
If you do not have a Solaris 8 system available, you could download and install the "Directory Server Resource Kit 5.2.1" from Sun, and install it in a temporary directory.
Important: If you install the Directory Server Resource Kit 5.2.1 under Solaris 9, then you
must NOT overwrite anything that came with your Solaris 9 system.
Do not provide a password. Just type RETURN twice. Verify that you created the right ‘flavor’ of database: cert7 for Solaris 8 and 9, cert8 for Solaris 10. Otherwise you need to start again with the right certutil.
|
2.
|
Obtain the public SSL certificate for the LDAP server you want to connect to. This example assumes you used the standard PEM exchange format (base64-encoded ASCII), there are other formats that may require additional or different switches. We will assume that you have saved the certificate in a file called cert.txt.
|
|
1.
|
Obtain the public SSL certificate for the LDAP server you want to connect to, in PEM format (ASCII). If you receive the file in a different format, it is probably easier to ask the LDAP server administrator for a PEM file in ASCII than to try and convert it yourself. If you must convert the file, there are too many possible scenarios to cover here, but check the man pages for the openssl command.
|
