doc/proxy

   1
   2                 FreeRADIUS as a proxy RADIUS server.
   3
   4
   5 0. INTRODUCTION
   6
   7   It is possible to use FreeRADIUS as a proxy RADIUS server. This
   8   means that it can consult a remote RADIUS server to validate a user.
   9   This is handy for roaming setups, or for renting ports to someone else.
  10
  11 1. FILES
  12
  13   If a user logs in with a defined realm syntax, the "realm" portion is
  14   matched against the configuration to determine how the request should
  15   be handled.  Common realm formats are:
  16
  17                 username@realm
  18                 realm/username
  19                 username%realm
  20                 realm\username
  21
  22   The realm parsing syntax ( and search order ) is user definable via the
  23   realm module config in the /etc/raddb/radiusd.conf configuration file.
  24
  25   You can define multiple instances of the realm module to support multiple
  26   realm syntax's at the same time.  Be sure to pay close attention to the
  27   search order that you define, as you may inadvertently get unexpected
  28   behaviour ( by having a user use 'realm1/username@realm2' for instance ).
  29   If you need to proxy to IPASS, it should go first, because usernames will
  30   be in the form IPASS/username@realm and you want to proxy these users to
  31   IPASS, not to the realm behind the @.
  32
  33   The realms are configured in the file /etc/raddb/proxy.conf, which is
  34   included by radiusd.conf. The formats and sample configurations are
  35   included as comments.
  36
  37   The realm "DEFAULT" (without the quotes) matches all realms.
  38   The realm "NULL" matches any requests WITHOUT a realm.
  39
  40   If you set the remote server to "LOCAL", the request will be handled
  41   locally as usual, without sending it to a remote radius server.
  42
  43   There are several options you can add in both files:
  44
  45   - nostrip:
  46     By default the realm is stripped from the username before sending it
  47     on to the remote radius server. By specifying the "nostrip" option
  48     the @realm suffix will not be stripped.
  49   - hints
  50     By default the original username is sent to the remote radius
  51     server. By specifying the "hints" option the username will be
  52     sent as it is after the "hints" file was processed.
  53   - notrealm:
  54     By default if a realm is matched, it will be proxied to the server
  55     specified.  However, if you are using Replication functionality, you
  56     may want to override this behaviour.  This option will prevent a
  57     user who enters 'user@foobar' from being proxied if the 'foobar'
  58     realm configuration contains 'notrealm'.  This function used to be
  59     called 'notsuffix', and the old syntax is still supported.
  60
  61   The /etc/raddb/realms file is deprecated and should not be used anymore.
  62   If you use the /etc/raddb/realms file to enter realm configurations you will
  63   need to add the hostname and secret for the remote server in the
  64   file /etc/raddb/clients.
  65   It is not recommended to use both the realms file and the proxy.conf file,
  66   as that could cause confusion.
  67
  68 2. ACCOUNTING
  69
  70   All accounting data for proxied requests does NOT get stored in the
  71   standard logfiles, but in a separate directory. The name of this
  72   directory is the name of the remote radius server, and if you want you
  73   can define a nickname for it in /etc/raddb/naslist just as for normal NASes.
  74
  75 3. REMOTE SERVER
  76
  77   When your server proxies requests to another server, it acts as a NAS for
  78   the remote server. On the remote server, you need to add the hostname of
  79   your server and the same secret to /etc/raddb/clients.conf as well.
  80
  81   As you might not control the remote radius server, you might want to
  82   control the attributes sent back by the remote server in an Access-Accept
  83   packet. Have a look at the attrs file for this!
  84
  85 4. WHAT HAPPENS
  86
  87   The exact thing that happens is this:
  88
  89   - A user logs in with a realm
  90   - The hints file gets processed as usual
  91   - The user is checked against the huntgroups file. At this point
  92     the user _might_ already be rejected.
  93   - The realm is looked up in the realms file. If it isn't defined,
  94     the users file is processed normally.
  95   - If the 'notrealm' option is defined, the user is processed
  96     locally.
  97   - The realm is stripped from the username unless "nostrip" was
  98     set, and the request is sent to a remote radius server. Note that
  99     any stripping done in the hints file doesn't have an effect on the
 100     username sent to the remote radius server unless you set the
 101     "hints" option.
 102   - The remote server replies with ACK or REJECT
 103
 104     On ACK:       The initial Auth-Type is set to Accept
 105     On REJECT:    The initial Auth-Type is set to Reject
 106
 107     Then the users file is processed as usual. The username used at
 108     this point is the one after hints file processing (regardless of
 109     the "hints" option). It also includes the realm (regardless of the
 110     setting of the "nostrip" option) unless the realm is LOCAL.