Page suivante Page précédente Table des matières

7. Configuration de l'Authentication

La section suivante du fichier de configuration permet de configurer l'authentification.

7.1 Section [Gatekeeper::Auth]

La section définie le méchanisme d'authentification du gatekeeper.

Syntax:

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
Une règle peut retourner un de ces trois codes: ok, fail, pass. Il existe aussi trois façons de contrôler une règle.

Modules actuellement supportés:

Vous pouvez aussi configurer une règle afin de vérifier seulement une partie du message RAS. L'exemple suivant montre comment vérifier uniquement les RRQ et ARQ à partir du module SimplePasswordAuth avec une règle optionnelle. Si un RRQ n'est pas vérifié (ne contient pas de champs tokens ou cryptoTokens), il est passé à la règle suivante AliasAuth. La règle par défaut est d'acepter toutes les requêtes.

Exemple 1:

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

L'exemple ci-dessous authentifie tous les appels, vérifie le détils des messages de signalisation Setup avec le module RadAliasAuth.

Exemple 2:

RadAliasAuth=required;Setup
default=allow

L'exemple suivant vérifie l'enregistrement des terminaux (RRQ) et l'admission d'appel (ARQ) soit par username/password (RadAuth) soit par alias/IP (RadAuthAlias). De plus, si l'ppel provient d'un terminal non enregistré (ET qu'aucune authentification par RRQ ou ARQ n'est été faite), le module RadAliasAuth vérifie alors le message Setup (SetupUnreg).

Exemple 3:

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

7.2 Section [SimplePasswordAuth]

Cette section définie la paire userid/password utilisé par le module SimplePasswordAuth. Tous les mots de passe sont cryptés avec le programme addpasswd.

Usage:

addpasswd config section userid password

Options:

7.3 Section [SQLPasswordAuth]

Authentifie les terminaux compatibles H.235 à partir de mots de passe enregistrés dans une base de données SQL. Cette section définie les gestionnaires SQL à utiliser, les paramètres de connexion à la base de données SQL et la requête pour récupérer les mots de passe.

7.4 Section [RasSrv::RRQAuth]

Spécifie l'action lors de la réception d'un message RRQ (confirmation ou rejet) pour le module AliasAuth. Le premier alias (le plus souvent un H323ID) du terminal à enregistrer est recherché dans la section. Si un paramètre est trouvé la valeur sera appliquée comme une règle. Une règle est constituée de condititions séparées par des '&'. Un enregistrement est accepté si toutes les conditions sont vérifiées.

Syntax:

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

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

La notation et la signification des <authparams> dépendent de <authtype>:

7.5 Section [SQLAliasAuth]

Authentifie les terminaux par des règles stockées dans base de données SQL (les règles doivent être conformes au format de la section [RasSrv::RRQAuth]). Cette section définie le gestionnaire SQL à utiliser, les paramètres de la connexion à la base de données and la requête à utiliser.

7.6 Section [PrefixAuth]

Cette section définie les règles d'authentification pour le module PrefixAuth. Actuellement, seuls les messages ARQs et LRQs peuvent être authentifiés par ce module.

On débute par le préfix le plus spécifique du champ destinationInfo de la reqête reçue. Ensuite la requête est eccepté ou non suivant les règles dans l'ordre spécifique décroissant. Si aucune correspondance de préfix n'est trouvée, et que l'option par default est spécifié, cette dernière accepte ou non la reqête. Autrement la requête continue sont parcourt dans les modules d'authification suivant les conditions du module.

Format:

prefix=authrule[|authrule|...]

Syntax:

<authrule> :=  <result> <authrule>

  <result>    := deny | allow
  <authrule>  := [!]ipv4:<iprule> | [!]alias:<aliasrule>
<iprule> peut être noté en notation décimal ou CIDR, <aliasrule> est une expression régulière. Si `!' précède la règle, le sens est inversé.

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

Dans cette configuration, tous les terminaux sauf ceux du réseau 10.0.0.0/27 sont autorisés à appeler le préfix 555 (execpté le 5555). Les terminaux du réseau 192.168.1.0/24 sont autorisés à appeler le préfix 5555, sauf 192.168.1.1. Les terminaux ne provenant pas de 172.16.0.0/24 ne sont pas autorisés à appeler le préfix 86. Les terminaux ayant un alias commençant par 188884 ne sont pas autorisés à appeler le préfix 09. Toutes les autres situations sont autorisées.

7.7 Section [RadAuth]

Cette section définie les options qui permettent d'activer l'authentification RADIUS basé sur le H.235 CATs (Cisco Access Tokens) présent dans les requêtes RAS RRQ et ARQ et les messages Setup Q931.

7.8 Section [RadAliasAuth]

Cette section permet de configurer la partie qui s'occupe d'activer les authentification RADIUS des alias de terminal ou des adresses IP présents dans les requêtes RAS RRQ, ARQ ou Setup Q.931. Ce schéma authentification est utile à la fois pour les terminaux enregistrés auprès de la GateKeeper (ARQ,RRQ) et aussi pour les appels provenant de terminaux non-enregistrés (Setup).


Page suivante Page précédente Table des matières