Minor reformatting.

[freeradius.git] / raddb / experimental.conf

#
#  This file contains the configuration for experimental modules.
#
#  By default, it is NOT included in the build.
#
#  $Id$
#

        # Configuration for the Python module.
        #
        # Where radiusd is a Python module, radiusd.py, and the
        # function 'authorize' is called.  Here is a dummy piece
        # of code:
        # 
        #       def authorize(params):
        #           print params
        #           return (5, ('Reply-Message', 'banned'))
        #
        # The RADIUS value-pairs are passed as a tuple of tuple
        # pairs as the first argument, e.g. (('attribute1',
        # 'value1'), ('attribute2', 'value2'))
        #
        # The function return is a tuple with the first element
        # being the return value of the function.
        # The 5 corresponds to RLM_MODULE_USERLOCK. I plan to
        # write the return values as Python symbols to avoid
        # confusion.
        #
        # The remaining tuple members are the string form of
        # value-pairs which are passed on to pairmake().
        #
        python {
                mod_instantiate = radiusd_test
                func_instantiate = instantiate

                mod_authorize = radiusd_test
                func_authorize = authorize

                mod_accounting = radiusd_test
                func_accounting = accounting

                mod_preacct = radiusd_test
                func_preacct = preacct

                mod_detach = radiusd_test
                func_detach = detach
        }

        
        # Configuration for the example module.  Uncommenting it will cause it
        # to get loaded and initialized, but should have no real effect as long
        # it is not referencened in one of the autz/auth/preacct/acct sections
        example {
                #  Boolean variable.
                # allowed values: {no, yes}
                boolean = yes

                #  An integer, of any value.
                integer = 16

                #  A string.
                string = "This is an example configuration string"

                # An IP address, either in dotted quad (1.2.3.4) or hostname
                # (example.com)
                ipaddr = 127.0.0.1

                # A subsection
                mysubsection {
                        anotherinteger = 1000
                        # They nest
                        deeply nested {
                                string = "This is a different string"
                        }
                }
        }


        #  This module is an SQL enabled version of the counter module.
        #  
        #  Rather than maintaining seperate (GDBM) databases of
        #  accounting info for each counter, this module uses the data
        #  stored in the raddacct table by the sql modules. This
        #  module NEVER does any database INSERTs or UPDATEs.  It is
        #  totally dependent on the SQL module to process Accounting
        #  packets.
        #
        #  The 'sqlmod_inst' parameter holds the instance of the sql
        #  module to use when querying the SQL database. Normally it
        #  is just "sql".  If you define more and one SQL module
        #  instance (usually for failover situations), you can
        #  specify which module has access to the Accounting Data
        #  (radacct table).
        #
        #  The 'reset' parameter defines when the counters are all
        #  reset to zero.  It can be hourly, daily, weekly, monthly or
        #  never.  It can also be user defined. It should be of the
        #  form:
        #       num[hdwm] where:
        #       h: hours, d: days, w: weeks, m: months
        #       If the letter is ommited days will be assumed. In example:
        #       reset = 10h (reset every 10 hours)
        #       reset = 12  (reset every 12 days)
        #
        #  The 'key' parameter specifies the unique identifier for the
        #  counter records (usually 'User-Name').
        #
        #  The 'query' parameter specifies the SQL query used to get
        #  the current Counter value from the database. There are 3
        #  parameters that can be used in the query:
        #               %k      'key' parameter
        #               %b      unix time value of beginning of reset period 
        #               %e      unix time value of end of reset period
        #
        #
        #  The 'check-name' parameter is the name of the 'check'
        #  attribute to use to access the counter in the 'users' file
        #  or SQL radcheck or radcheckgroup tables.
        #
        #  DEFAULT  Max-Daily-Session > 3600, Auth-Type = Reject
        #      Reply-Message = "You've used up more than one hour today"
        #
        sqlcounter dailycounter {
                counter-name = Daily-Session-Time
                check-name = Max-Daily-Session
                sqlmod-inst = sqlcca3
                key = User-Name
                reset = daily

                # This query properly handles calls that span from the
                # previous reset period into the current period but
                # involves more work for the SQL server than those
                # below
                query = "SELECT SUM(AcctSessionTime - GREATEST((%b - UNIX_TIMESTAMP(AcctStartTime)), 0)) FROM radacct WHERE UserName='%{%k}' AND UNIX_TIMESTAMP(AcctStartTime) + AcctSessionTime > '%b'"

                # This query ignores calls that started in a previous
                # reset period and continue into into this one. But it
                # is a little easier on the SQL server
                # query = "SELECT SUM(AcctSessionTime) FROM radacct WHERE UserName='%{%k}' AND AcctStartTime > FROM_UNIXTIME('%b')"

                # This query is the same as above, but demonstrates an
                # additional counter parameter '%e' which is the
                # timestamp for the end of the period
                # query = "SELECT SUM(AcctSessionTime) FROM radacct WHERE UserName='%{%k}' AND AcctStartTime BETWEEN FROM_UNIXTIME('%b') AND FROM_UNIXTIME('%e')"               
        }

        sqlcounter monthlycounter {
                counter-name = Monthly-Session-Time
                check-name = Max-Monthly-Session
                sqlmod-inst = sqlcca3
                key = User-Name
                reset = monthly

                # This query properly handles calls that span from the
                # previous reset period into the current period but
                # involves more work for the SQL server than those
                # below
                query = "SELECT SUM(AcctSessionTime - GREATEST((%b - UNIX_TIMESTAMP(AcctStartTime)), 0)) FROM radacct WHERE UserName='%{%k}' AND UNIX_TIMESTAMP(AcctStartTime) + AcctSessionTime > '%b'"

                # This query ignores calls that started in a previous
                # reset period and continue into into this one. But it
                # is a little easier on the SQL server
                # query = "SELECT SUM(AcctSessionTime) FROM radacct WHERE UserName='%{%k}' AND AcctStartTime > FROM_UNIXTIME('%b')"

                # This query is the same as above, but demonstrates an
                # additional counter parameter '%e' which is the
                # timestamp for the end of the period
                # query = "SELECT SUM(AcctSessionTime) FROM radacct WHERE UserName='%{%k}' AND AcctStartTime BETWEEN FROM_UNIXTIME('%b') AND FROM_UNIXTIME('%e')"               
        }

        #  Do server side ip pool management. Should be added in post-auth and
        #  accounting sections.
        #
        ##  This module is highly experimental at the moment. Please
        ##  give feedback on the mailing list.
        #
        #  The module also requires the existance of the Pool-Name
        #  attribute. That way the administrator can add the Pool-Name
        #  attribute in the user profiles and use different pools
        #  for different users. The Pool-Name attribute is a *check* item not
        #  a reply item.
        #
        # Example:
        # radiusd.conf: ippool students { [...] }
        # users file  : DEFAULT Group == students, Pool-Name := "students"
        #
        # ********* IF YOU CHANGE THE RANGE PARAMETERS YOU MUST THEN ERASE THE DB FILES *******
        #
        ippool main_pool {

               #  range-start,range-stop: The start and end ip
               #  addresses for the ip pool
                range-start = 192.168.1.1
                range-stop = 192.168.3.254

                #  netmask: The network mask used for the ip's
                netmask = 255.255.255.0

                #  cache-size: The gdbm cache size for the db
                #  files. Should be equal to the number of ip's
                #  available in the ip pool
                cache-size = 800

                # session-db: The main db file used to allocate ip's to clients
                session-db = ${raddbdir}/db.ippool

                # ip-index: Helper db index file used in multilink
                ip-index = ${raddbdir}/db.ipindex
        }
       
        #  To create a dbm users file, do:
        #
        #   cat test.users | rlm_dbm_parser -f /etc/raddb/users_db
        #
        #  Then add 'dbm' in 'authorize' section.
        #
        #  Note that even if the file has a ".db" or ".dbm" extension,
        #  you may have to specify it here without that extension.  This
        #  is because the DBM libraries "helpfully" add a ".db" to the
        #  filename, but don't check if it's already there.
        #
        dbm {
                usersfile = ${raddbdir}/users_db
        }

        #
        #  Persistent, embedded Perl interpreter.
        #
        perl {
                #
                #  The Perl script to execute on authorize, authenticate,
                #  accounting, xlat, etc.  This is very similar to using
                #  Exec-Program-Wait = "/path/foo.pl", but it is persistent,
                #  and therefore faster.
                #
                module = /path/to/your/perl_program

                #
                #  The following hashes are given to the module and
                #  filled with value-pairs (Attribute names and values)
                #
                #  %RAD_REPLY           Attributes to go into the reply
                #  %RAD_REQUEST         Attributes from the request
                #  %RAD_CHECK           Check items
                #
                #  Only the %RAD_REPLY hash can be modified.
                #  All of the other hashes are read only.
                #
                #  The return codes from functions in the perl_script
                #  are passed directly back to the server.  These
                #  codes are defined in doc/configurable_failover,
                #  src/include/modules.h (RLM_MODULE_REJECT, etc),
                #  and are pre-defined in the 'example.pl' program
                #  which is included.
                #               
                func_accounting = accounting
                func_authentication = authenticate
                func_preacct = preacct
                func_checksimul = checksimul
                func_xlat = xlat
        }

        #
        #  The digest module.  It doesn't take any configuration
        #  parameters, but it does require a configuration section,
        #  otherwise the parser complains.
        #
        #
        #
        #  See '../doc/rfc/draft-sterman-aaa-sip-00.txt' for details
        #  on performing digest authentication for Cisco SIP servers.
        #
        digest {
        }

        #
        #  Perform NT-Domain authentication.  This only works
        #  with PAP authentication.  That is, Authentication-Request
        #  packets containing a User-Password attribute.
        #
        #  To use it, add 'smb' into the 'authenticate' section,
        #  and then in another module (usually the 'users' file),
        #  set 'Auth-Type := SMB'
        #
        smb {
                server = ntdomain.server.example.com
                backup = backup.server.example.com
                domain = NTDOMAIN
        }

        # See doc/rlm_fastusers before using this
        # module or changing these values.
        #
        fastusers {
                usersfile = ${confdir}/users_fast
                hashsize = 1000
                compat = no
                # Reload the hash every 600 seconds (10mins)
                hash_reload = 600
        }

        #  A simple value checking module
        #
        #  It can be used to check if an attribute value in the request
        #  matches a (possibly multi valued) attribute in the check
        #  items This can be used for example for caller-id
        #  authentication.  For the module to run, both the request
        #  attribute and the check items attribute must exist
        #
        #  i.e.
        #  A user has an ldap entry with 2 radiusCallingStationId
        #  attributes with values "12345678" and "12345679".  If we
        #  enable rlm_checkval, then any request which contains a
        #  Calling-Station-Id with one of those two values will be
        #  accepted.  Requests with other values for
        #  Calling-Station-Id will be rejected.
        #
        #  Regular expressions in the check attribute value are allowed
        #  as long as the operator is '=~'
        #
        checkval {
                # The attribute to look for in the request
                item-name = Calling-Station-Id

                # The attribute to look for in check items. Can be multi valued
                check-name = Calling-Station-Id

                # The data type. Can be
                # string,integer,ipaddr,date,abinary,octets
                data-type = string
        }

        #
        #  Execute external programs
        #
        #  The first example is useful only for 'xlat'.  To use it,
        #  put 'exec' into the 'instantiate' section.  You can then
        #  do dynamic translation of attributes like:
        #
        #  Attribute-Name = `{%exec:/path/to/program args}`
        #
        #  The value of the attribute will be replaced with the output
        #  of the program which is executed.  Due to RADIUS protocol
        #  limitations, any output over 253 bytes will be ignored.
        #
        #  The RADIUS attributes from the user request will be placed
        #  into environment variables of the executed program, as
        #  described in 'doc/variables.txt'
        #
        exec {
                wait = yes
                input_pairs = request
        }

        #
        #  This is a more general example of the execute module.
        #
        #  If you wish to execute an external program in more than
        #  one section (e.g. 'authorize', 'pre_proxy', etc), then it
        #  is probably best to define a different instance of the
        #  'exec' module for every section.     
        #       
        exec echo {
                #
                #  Wait for the program to finish.
                #
                #  If we do NOT wait, then the program is "fire and
                #  forget", and any output attributes from it are ignored.
                #
                #  If we are looking for the program to output
                #  attributes, and want to add those attributes to the
                #  request, then we MUST wait for the program to
                #  finish, and therefore set 'wait=yes'
                #
                # allowed values: {no, yes}
                wait = yes

                #
                #  The name of the program to execute, and it's
                #  arguments.  Dynamic translation is done on this
                #  field, so things like the following example will
                #  work.
                #
                program = "/bin/echo %{User-Name}"

                #
                #  The attributes which are placed into the
                #  environment variables for the program.
                #
                #  Allowed values are:
                #
                #       request         attributes from the request
                #       reply           attributes from the reply
                #       proxy-request   attributes from the proxy request
                #       proxy-reply     attributes from the proxy reply
                #
                #  Note that some attributes may not exist at some
                #  stages.  e.g. There may be no proxy-reply
                #  attributes if this module is used in the
                #  'authorize' section.
                #
                input_pairs = request

                #
                #  Where to place the output attributes (if any) from
                #  the executed program.  The values allowed, and the
                #  restrictions as to availability, are the same as
                #  for the input_pairs.
                #
                output_pairs = reply
        }