PMDF System Manager's Guide
Previous Contents Index

14.2.3 Authentication Sources

An authentication source specifies where (and in some cases how) authentication information is stored. A particular sort of authentication source can support one or more sorts of authentication mechanisms, compatible with the underlying storage of the authentication information; that is, some authentication sources will support only one sort of authentication mechanism, whereas other sources can be able to support additional sorts of authentication mechanisms. For instance, a system password file can only support the PLAIN (plaintext) authentication mechanism. Authentication sources can also support custom configuration options.

Authentication sources are configured via a block of the form 


[AUTH_SOURCE=auth-source-name] 
...
in the security configuration file. It is not necessary to include an AUTH_SOURCE block for predefined authentication sources, unless setting special options for that source or unless the source is one such as LDAP which has special required options. An AUTH_SOURCE block must, however, be used when defining a site specific authentication source, as discussed below in Section 14.2.3.2.

14.2.3.1 Predefined Authentication Sources

The following authentication source names are reserved:

ANONYMOUS

This is used for anonymous access. If you want to specify a username for anonymous users, you can set the USER option to the desired user name in the [AUTH_SOURCE=ANONYMOUS] authentication source definition block; e.g., 


[AUTH_SOURCE=ANONYMOUS] 
USER=username

LDAP

The LDAP source is used when authentication verifiers are stored in an LDAPv2 or LDAPv3 or X.500 directory accessed via an LDAPv2 or LDAPv3 server. Currently, the LDAP source only supports the PLAIN mechanism (plaintext passwords) and the CRAM-MD5 mechanism. Note that this authentication source requires setting two options to site-specific values, so in order to use it, you must define it in an [AUTH_SOURCE=LDAP] section as illustrated below. 


[AUTH_SOURCE=LDAP] 
SERVER=ldap-server-host-name:port
BASEDN=distinguished-name
or 


[AUTH_SOURCE=LDAP] 
SERVER=ldap-server-host-name
BASEDN=distinguished-name
If the port is omitted from the SERVER option, then the standard LDAP port (port 389) is assumed. When looking for an authentication verifier in an LDAP directory, PMDF searches by default for a uid attribute matching the username which the user typed. If the LDAP_ATTRIBUTE option is specified, then that attribute is used for searching instead of uid. To do this search, by default an anonymous bind is done. If the LDAP_SEARCHACCT_DN and LDAP_SEARCHACCT_PASSWORD options are specified, then the bind is done using the specified distinguished name and password instead. Note that if the LDAP server is Active Directory then you should specify the LDAP_ATTRIBUTE option as "sAMAccountName", and you should provide values for both LDAP_SEARCHACCT_DN and LDAP_SEARCHACCT_PASSWORD options. For example: 


[AUTH_SOURCE=LDAP] 
SERVER=ldap-server-host-name
BASEDN=distinguished-name
LDAP_ATTRIBUTE=sAMAccountName 
LDAP_SEARCHACCT_DN=distinguished-name
LDAP_SEARCHACCT_PASSWORD=password
After doing the search, PMDF then does a bind against the LDAP server with the resulting DN and the user-supplied password. The option LDAP_VERSION controls whether an LDAPv2 or LDAPv3 query is made. The default, if this option is not specified, is LDAP_VERSION=3, causing PMDF to perform a v3 query. If querying an LDAPv2 directory, then LDAP_VERSION=2 must be set; this causes PMDF to perform a v2 query (which is less efficient than a v3 query). Sites using this source should make sure for performance reasons that the uid attribute (or alternate attribute specified by the LDAP_ATTRIBUTE option) is indexed on the LDAP server. Also note that this source is not currently suitable for high volume use, as in this implementation each authentication opens a separate connection to the LDAP server. High volume sites should instead use the MSGSTORE authentication source and arrange to keep it synchronized with their LDAP server. PMDF has the ability to access LDAP servers using TLS authentication. Note that sites wanting to use LDAP over TLS must make sure that their LDAP server is set up to do TLS. In order to enable TLS, specify the PMDF_TLS_MODE option as 1 (to try TLS) or 2 (to require TLS). You may need to have the Certificate Authority (CA) certificate to be used by LDAP on your PMDF system. If so, by default the CA certificate should be placed in the file pmdf_table:ldap-cacert.pem. If you wish to use a different file, you may specify it using the LDAP_CACERTFILE option. For example, to use TLS: 


[AUTH_SOURCE=LDAP] 
SERVER=ldap-server-host-name
BASEDN=distinguished-name
LDAP_TLS_MODE=1 
LDAP_CACERTFILE=ca-cert-file-name

LOGIN

The LOGIN source is used to provide the non-standard LOGIN mechanism. (The LOGIN mechanism is similar to PLAIN and offers no additional functionality, but is nevertheless used by some popular clients.) As implemented in PMDF, the LOGIN authentication source provides the LOGIN mechanism as a shell on top of the PLAIN mechanism from other sources. You must have at least one PLAIN mechanism enabled in order to use the LOGIN authentication source. For instance: 


ENABLE=SYSTEM/*,LOGIN/*
or equivalently: 


ENABLE=SYSTEM/PLAIN,LOGIN/LOGIN

MSGSTORE

This is the set of user authentication profiles used by the PMDF MessageStore and PMDF popstore. This authentication source currently supports the CRAM-MD5, DIGEST-MD5, POP and PLAIN mechanisms. (Note that it always stores the password in a format suitable for use by APOP.) Initial user entries in this authentication source must be generated using PMDF MessageStore or PMDF popstore management utilities; see the PMDF popstore & MessageStore Manager's Guide.

PASSDB

Initial user entries in this authentication source must be generated using the pmdf password utility. It currently supports the CRAM-MD5, DIGEST-MD5, APOP, and PLAIN mechanisms.

POPPROXY

This source is used to authenticate against a POP server. When used with automatic transitioning options, this source can be used to migrate passwords from a POP server to a new source, even if the exact storage of the passwords on the POP server is unknown. Such password transitioning is generally done in conjunction with migration of messages from a POP server to a new message store, such as the PMDF MessageStore, though note that such message migration is an entirely separate process from the password migration. See the discussion of the pmdf movein utility in the PMDF popstore & MessageStore Manager's Guide for a discussion of message migration. This source only supports the PLAIN mechanism. In order to use the POPPROXY source, you must set the SERVER option to tell PMDF the host name of the POP server against which to authenticate, and optionally the port number; if the port number is omitted, then the standard POP port of 110 is assumed. Up to three servers may be specified, separated by commas. To use TLS on the connection to the POP server, specify the TLS_MODE option. A value of 1 will turn on TLS. Note that in order to use TLS, you must specify a port which is dedicated to TLS (the standard port is 995). POPPROXY does not support issuing an STLS command to the standard POP port. Some examples: 


[AUTH_SOURCE=POPPROXY] 
SERVER=pop.example.com
or 


[AUTH_SOURCE=POPPROXY] 
SERVER=pop.example.com:995, pop2.example.com:995 
TLS_MODE=1

SYSTEM

This is the system password file, that is, the SYSUAF file on OpenVMS, or usually /etc/passwd or /etc/shadow on UNIX. This authentication source only supports the PLAIN mechanism. Initial user entries in this authentication source must be generated using system utilities. On OpenVMS, there is support for the PWDMIX SYSUAF flag, however the following special characters are not allowed in the password:

14.2.3.2 Site Specific Authentication Sources

You can define your own password/authentication source by specifying a shared image to call. To add an authentication source called auth-source-name where auth-source-name can be an arbitrary alphanumeric string other than those reserved above, include a block defining the new authentication source (after all global options) of the following form. On OpenVMS: 


[AUTH_SOURCE=auth-source-name] 
IMAGE=logical-pointing-to-shared-image
FUNCTION=function-entry-point
...
On UNIX: 


[AUTH_SOURCE=auth-source-name] 
IMAGE=shared-image-name
FUNCTION=function-entry-point
...
On NT: 


[AUTH_SOURCE=auth-source-name] 
IMAGE=dll-name
FUNCTION=function-entry-point
...
The IMAGE option specifies the shared image to use and the FUNCTION option specifies the entry point. Note that on OpenVMS, the IMAGE value must be a system, executive mode logical name translating to the actual shared image; on UNIX, the IMAGE value must be the actual shared image file name; on NT, the IMAGE value must be the name of a dynamic link library (DLL). These options are mandatory for site defined authentication sources. Additional configuration options specific to that authentication source can also be included.

The PMDF authentication services API can be used to add authentication sources; contact Process Software for details.

Previous Next Contents Index