Next Previous Contents

7. Authentication Configuration

The following sections in the config file can be used to configure authentication.

7.1 Section [Gatekeeper::Auth]

The section defines the authentication mechanism for the gatekeeper.

Syntax:

authrule=actions

 <authrule> := SimplePasswordAuth | AliasAuth | FileIPAuth | PrefixAuth | RadAuth | RadAliasAuth | SQLAuth | SQLAliasAuth | SQLPasswordAuth | ...
 <actions>  := <control>[;<ras>|<q931>,<ras>|<q931>,...]
 <control>  := optional | required | sufficient
 <ras>      := GRQ | RRQ | URQ | ARQ | BRQ | DRQ | LRQ | IRQ
 <q931>     := Setup | SetupUnreg

A rule may results in one of the three codes: ok, fail, pass. There are also three ways to control a rule:

Currently supported modules:

You can also configure a rule to check only for some particular RAS messages. The following example configures SimplePasswordAuth as an optional rule to check RRQ and ARQ. If an RRQ is not checked (not contains tokens or cryptoTokens fields), it is checked by AliasAuth. The default is to accept all requests.

Example 1:

SimplePasswordAuth=optional;RRQ,ARQ
AliasAuth=sufficient;RRQ

The example below authenticates all calls, checking signalling Setup message details, using RadAliasAuth module.

Example 2:

RadAliasAuth=required;Setup
default=allow

This example checks endpoint registrations (RRQ) and call admissions (ARQ) either by means of username/password (RadAuth) or alias/IP (RadAliasAuth). Additionally, if the call is from an unregistered endpoint (and therefore no RRQ or ARQ authentication has been performed), Setup message authentication using RadAliasAuth takes place (SetupUnreg).

Example 3:

RadAuth=optional;RRQ,ARQ
RadAliasAuth=required;RRQ,ARQ,SetupUnreg
default=allow

7.2 Section [FileIPAuth]

This section defines a list of IP addresses/networks which are allowed to access gatekeeper resources. Supported Gatekeeper::Auth events are: GRQ, RRQ, LRQ, Setup and SetupUnreg. Format of a single entry is:

IP=[allow | reject]

where IP is a single IP addresss, a network address (in A.B.C.D/M.M.M.M or A.B.C.D/LENGTH format) or a string 'any' or '*' to match any address. The access list can also be loaded from an external file using include directive. During authentication, network mask length defines a priority for each entry, so rule 192.168.1.1=allow takes precedence over 192.168.1.0/24=reject.

Example #1:

[Gatekeeper::Auth]
FileIPAuth=required;RRQ,LRQ,Setup

[FileIPAuth]
192.168.1.240=reject
192.168.1.0/24=allow
192.168.2.0/255.255.255.0=allow
any=reject

Example #2:

[Gatekeeper::Auth]
FileIPAuth=required;Setup

[FileIPAuth]
include=/etc/gnugk/accesslist.ini

(EOF)

Contents of /etc/gnugk/accesslist.ini:

[FileIPAuth]
192.168.1.1=allow
192.168.1.100=allow
any=reject

7.3 Section [SimplePasswordAuth]

The section defines the userid and password pairs used by SimplePasswordAuth module. All passwords are encrypted using the addpasswd utility.

Usage:

addpasswd config section userid password

Options:

7.4 Section [SQLPasswordAuth]

Authenticate H.235 enabled endpoints using passwords stored in the SQL database. This section defines SQL driver to use, SQL database connection parameters and the query to use to retrieve passwords.

7.5 Section [RasSrv::RRQAuth]

Specify the action on RRQ reception (confirm or deny) for AliasAuth module. The first alias (this will mostly be an H323ID) of the endpoint to register is looked up in this section. If a parameter is found the value will apply as a rule. A rule consists of conditions separated by "&". A registration is accepted when all conditions apply.

Syntax:

<authrules> :=  empty  |  <authrule> "&" <authrules>

  <authrule>  := <authtype> ":" <authparams>
  <authtype>  := "sigaddr" | "sigip"
  <autparams> := [!&]*

The notation and meaning of <authparams> depends on <authtype>:

7.6 Section [SQLAliasAuth]

Authenticate endpoints using rules stored in the SQL database (the rules conform to the format defined in the [RasSrv::RRQAuth] section). This section defines SQL driver to use, SQL database connection parameters and the query to use to retrieve the patterns.

7.7 Section [SQLAuth]

Authenticate and authorize endpoints/calls using an SQL database. Support for RRQ, ARQ, LRQ and Setup events is provided.

7.8 Section [PrefixAuth]

The section defines the authentication rule for PrefixAuth module. Currently, only ARQs and LRQs can be authorized by this module.

First, a most specific prefix is selected according to the destinationInfo field of the received request. Then the request is accepted or rejected according to the matched rules with most specific netmask. If no matched prefix is found, and the default option is specified, the request is accepted or rejected according to that. Otherwise it is rejected or passed to next authentication module according to the module requirement.

Format:

prefix=authrule[|authrule|...]

Syntax:

<authrule> :=  <result> <authrule>

  <result>    := deny | allow
  <authrule>  := [!]ipv4:<iprule> | [!]alias:<aliasrule>

Where <iprule> can be specified in decimal dot notation or CIDR notation, <aliasrule> is expressed in regular expression. If the `!' flag precedes the rule, the sense is inverted.

Example:

555=deny ipv4:10.0.0.0/27|allow ipv4:0/0
5555=allow ipv4:192.168.1.1|deny ipv4:192.168.1.0/255.255.255.0
86=deny !ipv4:172.16.0.0/24
09=deny alias:^188884.*
ALL=allow ipv4:ALL

In this configuration, all endpoints except from network 10.0.0.0/27 are allow to call prefix 555 (except 5555). Endpoints from 192.168.1.0/24 are not allowed to call prefix 5555, except 192.168.1.1. Endpoints not from 172.16.0.0/24 are denied to call prefix 86. Endpoints having an alias beginning with 188884 are not allowed to call prefix 09. All other situations are allowed.

7.9 Section [RadAuth]

This section defines configuration settings that enable RADIUS authentication based on H.235 CATs (Cisco Access Tokens) present in RRQ, ARQ RAS requests and Q.931 Setup messages.

7.10 Section [RadAliasAuth]

This section defines configuration settings that enable RADIUS authentication based on endpoint aliases and/or IP adresses present in RRQ RAS requests, ARQ RAS request or Q.931 Setup request. This authentication scheme is useful both for endpoints registered at the gatekeeper (ARQ,RRQ) and calls from unregistered endpoints (Setup).


Next Previous Contents