# Règles ## Général Toutes les règles que vous avez configurées seront appliquées **après** une authentification réussie des identifiants, ce qui signifie que les règles ne deviennent effectives qu’après la fourniture d’identifiants d’authentification valides. Cela implique que, pour franchir la première barrière d’authentification, des **Trusted Roots** (authentification basée sur certificat) ou **Utilisateurs** (authentification basée sur nom d’utilisateur et mot de passe) doivent être ajoutés à votre instance. ### Règle par défaut Pour éviter toute perturbation d’une instance existante ou si vous ne souhaitez pas utiliser du tout le moteur de règles, toute authentification est autorisée si aucune règle n’est définie par défaut. Cela est réalisé grâce à notre règle par défaut **Toute authentification autorisée**. {% hint style="warning" %} La règle par défaut **Toute authentification autorisée** nécessite toujours la présence d’identifiants d’authentification valides pour qu’une authentification réseau réussisse. {% endhint %} ### Ordre d’exécution des règles Si vous avez plusieurs règles configurées, elles seront appliquées dans l’ordre que vous voyez dans votre portail web — de haut en bas. La seule exception est la **Toute authentification autorisée** règle, qui sera traitée en dernier si elle est configurée. Cela est particulièrement utile lors d’un scénario de montée en charge initiale, où vous n’êtes peut-être pas certain que vos règles couvrent tous les cas d’utilisation ou emplacements. Toute demande d’authentification rejetée par les règles précédentes sera alors toujours acceptée par la règle par défaut. Dans le tableau de bord, vous pouvez alors observer les appareils/utilisateurs échouant pour toutes les autres règles et corriger/étendre les règles en conséquence. Si vous vous retrouvez avec un grand nombre de règles, nous recommandons — afin de maintenir de hautes performances — d’ordonner les règles de manière à ce que les règles les plus probables soient atteintes en premier.

Affichage des règles

## Options des règles ### Authentification * Autoriser uniquement des sources d’authentification spécifiques * par ex. Wi-Fi ou LAN (la prise en charge du VPN est en cours) * Autoriser uniquement des types d’authentification spécifiques * par ex. Certificat ou nom d’utilisateur et mot de passe #### Authentification basée sur certificat * Autoriser uniquement des AC de confiance spécifiques (AC racines ou AC émettrices) * Autoriser uniquement des ID Intune spécifiques ou ignorer entièrement l’attribut du certificat #### Authentification basée sur nom d’utilisateur/mot de passe * Autoriser uniquement les noms d’utilisateur qui correspondent à un modèle Regex ### Configuration #### Contraintes d’infrastructure * Définir quels **SSID** sont autorisés * Définir quels **les points d’accès ou commutateurs réseau** sont autorisés (basé sur l’adresse MAC) #### Affectation de VLAN Attribuer des ID VLAN ... * Statiquement * En évaluant un **extension de certificat** * personnalisé **nom du sujet** #### Attributs de retour RADIUS supplémentaires Par défaut, vous pouvez sélectionner dans la liste suivante d’attributs de retour que vous pouvez renvoyer dans le cadre d’une règle correspondante : * Filter-Id * Fortinet-Group-Name * Framed-MTU * Tunnel-Password * Cisco-AVPair * Class {% hint style="info" %} Les attributs de retour RADIUS permettent aux administrateurs réseau de définir des paramètres spécifiques pour des utilisateurs ou des groupes individuels. Par exemple, * pour la configuration du profil utilisateur, un attribut peut spécifier la durée maximale de session, les services autorisés (tels que VPN ou Wi-Fi) et la méthode d’attribution de l’adresse IP. * pour l’attribution dynamique d’adresse IP, un attribut peut indiquer que l’utilisateur doit recevoir une adresse IP statique ou utiliser DHCP pour une attribution dynamique. * pour le contrôle d’accès et l’autorisation, un attribut détermine le niveau d’accès de l’utilisateur (par ex. invité, employé, administrateur) et toute restriction (par ex. limites de temps). * pour la gestion des sessions, un attribut peut spécifier le délai d’expiration de session (durée pendant laquelle l’utilisateur peut rester connecté), le délai d’inactivité (déconnexion après inactivité) et le nombre maximal de connexions simultanées. * pour la qualité de service (QoS), un attribut peut prioriser le trafic vocal par rapport au trafic de données pour un utilisateur spécifique. Les fournisseurs peuvent créer leurs propres attributs personnalisés (attributs spécifiques au fournisseur ou VSA). Ceux-ci permettent des fonctionnalités supplémentaires au-delà des attributs IETF standard. Les VSA sont encapsulés dans l’attribut standard 26. {% endhint %} Renvoyer des attributs RADIUS supplémentaires ... * Statiquement * En évaluant un **extension de certificat** * personnalisé **nom du sujet** --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.radiusaas.com/fr/portail-dadministration/settings/rules.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.