Home
Products
Download
Buy Now
Support
Company

Authentication Module, MultiAuth

MultiAuth enables you to authenticate against any number of different authentication modules. You should configure and test each individual module that you are going to authenticate against before attempting to configure MultiAuth.

Multiauth is also useful for migrating users from module to module (see Migration) and managing additional information for a read-only module (see Master Modules).

Installing and Setup

Some applications already come with this version already built. If you have not got a build and/or require the latest code it can be downloaded from the one of the links below:

Source: Not Available  
Windows multiauth_10t_windows.zip 86k
FreeBSD 4 multiauth_10t_freebsd4.tar.gz 39k
Linux (libc6) multiauth_10t_linux.tar.gz 101k
Solaris multiauth_10t_solaris.tar.gz 124k

 

Configuration Options:

The configuration options below go in an multiauth.ini file which is located in the same directory as the multiauth binary OR in a directory specified by the -path command line option.

The MultiAuth config file is slightly different to most other authent modules. It's different in that it has global settings and blocks of settings specific to each module you want it to run. The specific settings are used if specified, otherwise the global setting is used, if that is not specified then the default value is used.

An example config file might go...

loglevel debug
do_del false


module 0
  binary c:\surgemail\nwauth.exe -path c:\surgemail
  match *domain1.com


module 1
  binary c:\surgemail\odbcauth.exe -path c:\surgemail
  match *domain2.com

NOTE: The match setting should not contain an '@' symbol as SurgeMail does not use one for it's search commands.
NOTE 2: The ini file is sensitive to trailing white spaces, make sure you remove any!

Setting Default  
loglevel error The amount of data to log, error logs only errors, info logs errors and info, debug logs everything. GLOBAL only this setting has no effect in a module block.
module   This is not really a setting, this line starts a module block. The parameter for this line is a priority rating, the module with the lowest rating is used first.
binary   This is the full path and filename plus parameters of the module.
match * This setting specifies what commands are sent to the module. The username must match this seting. You can override this value with a value specific to the command, see the lookup, check, set, del and search settings.
ip_match * This setting specifies what commands are sent to the module. If the command contains the users ip then it must match this.
lookup <value of the match setting> This setting specifies what usernames are sent to the module for a lookup command.
check <value of the match setting> This setting specifies what usernames are sent to the module for a check command.
set <value of the match setting> This setting specifies what usernames are sent to the module for a set command.
del <value of the match setting> This setting specifies what usernames are sent to the module for a del command.
search <value of the match setting> This setting specifies what usernames are sent to the module for a search command.
do_check true [true|false|move_from] This setting specifies whether the module receives check commands.
do_lookup true [true|false] This setting specifies whether the module receives lookup commands.
do_set existing [true|false|existing|move_from|move_to] This setting specifies whether the module receives set commands.
do_del false [true|false] This setting specifies whether the module receives del commands.
do_search true [true|false] This setting specifies whether the module receives search commands.
strip_prefix   This setting specifies the prefix to strip from usernames (if present) before sending the command on to the module.
eg: strip_prefix domain_
strip_suffix  

This setting specifies the suffix to strip from usernames (if present) before sending the command on to the module.
eg: strip_suffix @domain.com
set_once false [true|false] If 'true' then "set" operations are performed on the "first matching module only" as opposed to the default behaviour which is to perform it on "all matching modules".
del_once false [true|false] If 'true' then "del" operations are performed on the "first matching module only" as opposed to the default behaviour which is to perform it on "all matching modules".
look_once false [true|false] If 'true' then "lookup" and "check" operations are performed on the "first matching module only" as opposed to the default behaviour which is to perform it on "all matching modules".
timeout 20000 Time to wait for a reply from a module before giving up on it. Time is in milliseconds ie: 'timeout 1000' == 1 second.
restart_max 5 Number of times to restart a faulty module (returning -DEAD) before giving up on it.
restart_delay 0 Delay in seconds to wait before restarting a faulty module.
master
Specifies a module priority, the module with that priority is considered a "master" module. See Master Modules below.
master_field
Multi value, comma seperated list of field names. These fields are read from the "master" module and displayed in addition to any information found in the "slave" module.
force_dead
[true|false] This setting forces Multiauth to return all -DEAD responses it gets. Default behaviour is to return the result from the last matching module (which may be a -ERR response from a module attempted after the -DEAD was recieved).

Command Line Options

-path Tells MultiAuth where to create it's logfile and where to find it's config file.
-debug Causes debug logging to be done.
-version Reports the version number.

Supported Commands

The commands below are the list of commands that this module supports. For a full description about the command see Authentication Protocol

Command Parameters
check <user> <pass>
lookup <user>
set <user> <pass>|(NULL) [label="value"]
del <user>
search <string> [-from n] [-max m]
version
quit
exit

Master Modules

MultiAuth supports the use of master/slave modules. This allows 2 modules to be used to emulate a single module. It is especially useful when a module is read-only (it would be configured as the 'master'). The 'master' setting is used in the slave setting block, it specifies the master module. A 'master' module does not take part in normal operation, instead all commands/operations to the slave also involve the master.

The master is authorative for user existance, the password, and any fields specified in the master_field setting(s) (also specified in the slave setting block). The slave is authorative for all other information fields.

Example config:

module 0
  binary c:\surgemail\nwauth.exe -path c:\surgemail
  master 1
  master_field a,b

module 1
  binary c:\surgemail\odbcauth.exe -path c:\surgemail

The above uses nwauth as a slave to odbcauth. The fields 'a' and 'b' will be read from odbcauth, other fields will be stored in nwauth. Entries will be added to nwauth as required, and removed as required based on the existance of entries in odbcauth. The fields 'a' and 'b' cannot be changed, the password cannot be changed, users cannot be deleted.

Migration

MultiAuth can be used to migrate users from one module to another. It uses do_set and do_check setting values move_from and move_to. Example:

module 0
  binary c:\surgemail\nwauth.exe -path c:\surgemail
  do_check move_from
  do_set move_from

module 1
  binary c:\surgemail\odbcauth.exe -path c:\surgemail
  do_set move_to

The above config will move users on check and set commands from module 0 to module 1.
Be sure to remove trailing white space from ini settings, e.g. do_set move_to<space> will fail!