Página siguiente Página anterior Índice general

7. Configuración de la Autenticación

Las siguientes secciones en el archivo de configuración pueden ser utilizadas para configurar la Autentificación.

7.1 Sección [Gatekeeper::Auth]

Esta sección define los mecanismos de autenticación para el gatekeeper.

Sintaxis:

authrule=actions

 <authrule> := SimplePasswordAuth | AliasAuth | PrefixAuth | RadAuth | RadAliasAuth | ...
 <actions>  := <control>[;<ras>|<q931>,<ras>|<q931>,...]
 <control>  := optional | required | sufficient
 <ras>      := GRQ | RRQ | URQ | ARQ | BRQ | DRQ | LRQ | IRQ
 <q931>     := Setup | SetupUnreg
Una regla puede resultar en uno de los siguientes tres códigos: ok, fail, pass. También hay tres maneras de controlar una regla:

Módulos soportados actualmente:

Usted puede además configurar una regla para chequear solamente algunos mensajes RAS particulares. El siguiente ejemplo configura SimplePasswordAuth como regla opcional para chequear mensajes RRQ y ARQ. Si un mensaje RRQ no es chequeado (no contiene campos tokens o cryptoTokens), éste es chequeado por AliasAuth. La regla por defecto es aceptar todas las peticiones.

Ejemplo 1:

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

El ejemplo mostrado más abajo autentica todas las llamadas, chequeando los mensajes de señalización Setup de una manera detallada, utilizando el módulo RadAliasAuth.

Ejemplo 2:

RadAliasAuth=required;Setup
default=allow

Este ejemplo chequea los mensajes de registro de endpoints (RRQ) y mensajes de admission de llamadas (ARQ) por cualquiera de estos dos medios: por medio de un username/password (RadAuth) o mediante alias/IP (RadAliasAuth). Adicionalmente, si la llamada es desde un endpoint no registrado (y por consiguiente ninguna de las autenticaciones RRQ o ARQ ha sido realizada), La autenticación con mensajes Setup usando RadAliasAuth toma lugar (SetupUnreg).

Ejemplo 3:

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

7.2 Sección [SimplePasswordAuth]

La sección define el par de userid y password utilizados por el módulo SimplePasswordAuth. Todos los passwords estan encriptados utilizando la utilidad addpasswd.

Modo de uso:

addpasswd config section userid password

Opciones:

7.3 Sección [SQLPasswordAuth]

Autentica endpoints (H.235 enabled) utilizando passwords almacenadas en una base de datos SQL. Esta sección define el driver SQL a utilizar, los parámetros de connexion a la base de datos y las consultas a utilizar para recuperar passwords.

7.4 Sección [RasSrv::RRQAuth]

Especifica la acción sobre los mensajes de recepción (confirm or deny) para el módulo AliasAuth. El primer alias (éste será principalmente un H323ID) del endpoint a ser registrado es buscado en esta sección. Si un parámetro es encontrado, el valor sera aplicado por regla general. Una regla consiste de condiciones separadas por "&". Un registro es aceptado cuando todas las condiciones coinciden.

Sintaxis:

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

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

La notación y significado de <authparams> depende de <authtype>:

7.5 Sección [SQLAliasAuth]

Autentica endpoints utilizando reglas almacenadas en una base de datos (Las reglas tienen el mismo formato definido en la sección [RasSrv::RRQAuth]). Esta sección define el driver SQL a ser utilizado, los parámetros de conexión a la base de datoS y las consultas a utilizar para recuperar los patroneS.

7.6 Sección [PrefixAuth]

La sección define la regla de autenticación para el módulo PrefixAuth. Actualmente, solamente ARQs y LRQs pueden ser autorizados por éste módulo.

Primero, se selecciona un prefijo muy específico de acuerdo al campo destinationInfo de la petición recibida. Entonces la petición es aceptada o rechazada de acuerdo a la correspondencia de reglas con la netmask más específica. Si no se encontraron correspondencias de prefijos, y la opción default está especificada, la petición es aceptada o rechazada de acuerdo a eso. De lo contrario esta es rechazada o pasada al siguiente módulo de autenticación de acuerdo a los requerimientos del módulo.

Formato:

prefix=authrule[|authrule|...]

Syntax:

<authrule> :=  <result> <authrule>

  <result>    := deny | allow
  <authrule>  := [!]ipv4:<iprule> | [!]alias:<aliasrule>
Donde <iprule> puede ser específicada en notación decimal punteada o en la notación CIDR, <aliasrule> está expresada en espreción regular. Si el signo '!' precede la regla, el sigificado es inverso.

Ejemplo:

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

En esta configuración, todos los endpoints excepto los de la red 10.0.0.0/27 están permitidos llamar al prefijo 555 (excepto 5555). A Endpoints desde 192.168.1.0/24 no se les permite llamar al prefijo 5555, excepto 192.168.1.1. Endpoints queno pertenecen a 172.16.0.0/24 no se les permite llamar al prefijo 86. Endpoints que tienen un alias que empieza con 188884 no se les permite llamar al prefijo 09. Todas las otras situaciones estan permitidas.

7.7 Sección [RadAuth]

Esta sección define la configuración que posibilitan la autenticación RADIUS basada en H.235 CATs (Cisco Access Tokens) presentes en las peticiones RRQ, ARQ RAS y mensajes Q.931 Setup.

7.8 Section [RadAliasAuth]

En esta sección se definen parámetros de configuración que permiten la autenticación RADIUS basada en alias de endpoints y/o direcciones IP presentes en las peticiones RAS o en las peticiones Setup Q.931. Este esquema de autenticación es muy utilizado tanto para endpoints registrados en el gatekeeper (ARQ,RRQ) como para llamadas que vienen desde endpoints no registrados(Setup).


Página siguiente Página anterior Índice general