raddb/protocol_filter.conf

   1 #\r
   2 #       Filter protocols by realm (or other key)\r
   3 #       The "protocol_filter" module reads this file, and implements\r
   4 #       the restrictions contained in it.\r
   5 #\r
   6 #       The main purpose of this configuration file is to permit the\r
   7 #       administrator to control, by realm (or any other key), which\r
   8 #       protocols the request is permitted to contain.  This allows\r
   9 #       the server to permit users in one realm to use (say) EAP, and\r
  10 #       to deny EAP to users in other realms.\r
  11 #\r
  12 #       The key is used to look up entries by subsection.  Within each\r
  13 #       subsection, there is a list of attributes, with value "permit"\r
  14 #       or "deny".  When a request comes in, the attributes from the\r
  15 #       request packet are looked up in the appropriate section given\r
  16 #       by the key.  If the section has an entry which says "permit"\r
  17 #       for that attribute, the request is permitted to continue.  If\r
  18 #       the section has and entry which says "deny" for that\r
  19 #       attribute, the request is immediately rejected.\r
  20 #\r
  21 #       The default (if the attribute is not listed in the subsection)\r
  22 #       is to permit the attribute.\r
  23 #\r
  24 #       The attribute names MUST be spelled the same way as in\r
  25 #       the dictionary files.\r
  26 #\r
  27 #       The entries can have sub-sections, too.  Each subsection\r
  28 #       MUST begin with a "key" entry, which is used to apply\r
  29 #       one of the rules in the subsection.  Only one rule from\r
  30 #       each subsection is applied, and that rule is the one pointed\r
  31 #       to by the key.  The key is dynamically expanded (see doc/variables.txt)\r
  32 #       at run time, for each request as it comes in.\r
  33 #\r
  34 DEFAULT {\r
  35         #\r
  36         #  There is no key here, as the key is always hard-coded to be\r
  37         #  attributes in the request.  For a request to pass the tests\r
  38         #  in this section, ALL of the rules below must permit the\r
  39         #  request to pass.  That is, the rules are logically ANDed\r
  40         #  together.\r
  41         #\r
  42 \r
  43         # allow requests to contain a user password attribute.\r
  44         User-Password = permit\r
  45 \r
  46         # Deny requests which try to use MS-CHAP, for testing.\r
  47         # just because we can.  Both MS-CHAPv1 and MS-CHAPv2\r
  48         # use MS-CHAP-Challenge, so we just deny that.\r
  49         # If we wanted to deny just MS-CHAPv2, we would deny the\r
  50         # MS-CHAP2-Response attribute.\r
  51         MS-CHAP-Challenge = deny\r
  52 \r
  53         #\r
  54         #  Allow some EAP protocols, but not others.\r
  55         #\r
  56         #  The use of the EAP-Type for the key, below, means that the\r
  57         #  protocol_filter module MUST be listed after "eap" in the\r
  58         #  "authorize" section.\r
  59         #\r
  60         EAP-Message {\r
  61                 #\r
  62                 #  See the dictionary for the names of the EAP-Types.\r
  63                 #  e.g. VALUE EAP-Type <name> <number>\r
  64                 #\r
  65                 #  The names for the EAP types MUST be exactly the same\r
  66                 #  as the names in the dictionary file.\r
  67                 #\r
  68                 key = %{EAP-Type:-DEFAULT}\r
  69 \r
  70                 #  This is insecure, so we don't allow it.\r
  71                 MD5-Challenge = deny\r
  72 \r
  73                 # Permit one EAP type.  We picked this one at random.\r
  74                 EAP-MSCHAP-V2 = permit          \r
  75 \r
  76                 DEFAULT = deny\r
  77         }\r
  78 }\r
  79 \r
  80 #\r
  81 #  A more complicated example.\r
  82 #\r
  83 example.com {\r
  84         #\r
  85         #  For various reasons, we often would like to use the same\r
  86         #  configuration entries inside, and outside of the TLS tunnel.\r
  87         #  This allows us to keep all of the per-realm configuration in\r
  88         #  one place.\r
  89         #\r
  90         EAP-Message {\r
  91                 #\r
  92                 #  Define subsections, based on the request being\r
  93                 #  inside, or outside, of the TLS tunnel.\r
  94                 #\r
  95                 key = %{FreeRADIUS-Proxied-To:-Outer}\r
  96 \r
  97                 #\r
  98                 #  Outside of the tunnel.\r
  99                 #\r
 100                 Outer {\r
 101                         key = %{EAP-Type:-DEFAULT}\r
 102 \r
 103                         #  This is insecure, so we don't allow it.\r
 104                         #  It's not necessary, as the DEFAULT below will\r
 105                         #  take care of it, but this is a good example.\r
 106                         MD5-Challenge = deny\r
 107 \r
 108                         # We allow TTLS & PEAP as EAP types.\r
 109                         EAP-TTLS = permit\r
 110 \r
 111                         PEAP = permit\r
 112 \r
 113                         DEFAULT = deny\r
 114                 }\r
 115 \r
 116                 #\r
 117                 #  Inside of the tunnel.\r
 118                 #\r
 119                 127.0.0.1 {\r
 120                         key = %{EAP-Type:-DEFAULT}\r
 121 \r
 122                         #  We don't do TLS inside of TTLS.\r
 123                         EAP-TLS = deny\r
 124 \r
 125                         DEFAULT = permit\r
 126                 }\r
 127         }\r
 128 }\r