man/man8/radiusd.8

   1 .TH RADIUSD 8 "21 March 1999" "" "Cistron Radius Daemon"
   2 .SH NAME
   3 radiusd -- Authentication, Authorization and Accounting server
   4 .SH SYNOPSIS
   5 .B radiusd
   6 .RB [ \-A ]
   7 .RB [ \-S ]
   8 .RB [ \-a
   9 .IR accounting_directory ]
  10 .RB [ \-b ]
  11 .RB [ \-c ]
  12 .RB [ \-d
  13 .IR config_directory ]
  14 .RB [ \-f ]
  15 .RB [ \-i
  16 .IR ip-address ]
  17 .RB [ \-l
  18 .IR log_directory ]
  19 .RB [ \-p
  20 .IR port ]
  21 .RB [ \-s ]
  22 .RB [ \-v ]
  23 .RB [ \-x ]
  24 .RB [ \-y ]
  25 .RB [ \-z ]
  26 .SH DESCRIPTION
  27 This is the Cistron implementation of the well known
  28 .B radius
  29 server program. It is based on \fILivingston's\fP radius version 1.16.
  30 Even though this program is largely compatible with \fILivingston's\fP
  31 radius version 2.0, it's \fBnot\fP based on any part of that code.
  32 .PP
  33 \fBRADIUS\fP is a protocol spoken between an access server, typically
  34 a device connected to several modems or ISDN lines, and a \fBradius\fP
  35 server. When a user connects to the access server, (s)he is asked for
  36 a loginname and a password. This information is then sent to the \fBradius\fP
  37 server. The server replies with "access denied", or "access OK". In the
  38 latter case login information is sent along, such as the IP address in
  39 the case of a PPP connection.
  40 .PP
  41 The access server also sends login and logout records to the \fBradius\fP
  42 server so accounting can be done. These records are kept for each terminal
  43 server seperately in a file called \fBdetail\fP, and in the \fIwtmp\fP
  44 compatible logfile \fB/var/log/radwtmp\fP.
  45 .SH OPTIONS
  46
  47 .IP \-A
  48 Write a file \fIdetail.auth\fP in addition to the standard \fBdetail\fP file
  49 in the same directory. This file will contain all the authentication-request
  50 records. This can be useful for debugging, but not for normal operation.
  51
  52 .IP \-S
  53 Write the stripped usernames (without prefix or suffix) in the \fIdetail\fP
  54 file instead of the raw record as received from the terminal server.
  55
  56 .IP "\-a \fIaccounting directory\fP"
  57 This defaults to \fI/var/log/radacct\fP. If that directory exists,
  58 \fBradiusd\fP will write an ascii accounting record into a detail file for
  59 every login/logout recorded. The location of the detail file is
  60 \fIacct_dir/\fP\fBterminal_server\fP\fI/detail\fP.
  61
  62 .IP "\-l \fIlogging directory\fP"
  63 This defaults to \fI/var/log\fP. \fBRadiusd\fP writes a logfile here called
  64 \fIradius.log\fP. It contains informational and error messages, and optionally
  65 a record of every login attempt (for aiding an ISP's helpdesk). The
  66 special argument \fIstdout\fP causes the information to get written
  67 to the standard output instead.
  68
  69 .IP "\-d \fIconfig directory\fP"
  70 Defaults to \fI/etc/raddb\fP. \fBRadiusd\fP looks here for its configuration
  71 files such as the \fIdictionary\fP and the \fIusers\fP files.
  72
  73 .IP "\-i \fIip-address\fP"
  74 Defines which IP addres to bind to for sending and receiving packets-
  75 useful for multi-homed hosts.
  76
  77 .IP \-b
  78 If the \fBradius\fP server binary was compiled with \fIdbm\fP support,
  79 this flag tells it to actually \fIuse\fP the database files instead of the
  80 flat \fIusers\fP file.
  81
  82 .IP \-c
  83 This is still an \fIexperimental\fP feature.
  84 Cache the password, group and shadow files in a hash-table in memory.
  85 This makes the radius process use a bit more memory, but username
  86 lookups in the password file are \fImuch\fP faster.
  87 .IP
  88 After every change in the real password file (user added, password changed)
  89 you need to send a \fBSIGHUP\fP to the radius server to let it re-read
  90 its configuration and the password/group/shadow files !
  91
  92 .IP \-f
  93 Do not fork, stay running as a foreground process.
  94
  95 .IP "\-p \fIport\fP"
  96 Normally radiusd listens on the ports specified in \fI/etc/services\fP
  97 (radius and radacct). With this option radiusd listens on the specified
  98 port for authentication requests and on the specified port +1 for
  99 accounting requests.
 100
 101 .IP \-s
 102 Normally, the server forks a seperate process for accounting, and a seperate
 103 process for every authentication request. With this flag the server will not
 104 do that. It won't even "daemonize" (auto-background) itself.
 105
 106 .IP \-x
 107 Debug mode. In this mode the server will print details of every request
 108 on it's \fBstderr\fP output. Most useful in combination with \fB-s\fP.
 109 You can specify this option 2 times (-x -x or -xx) to get a bit more
 110 debugging output.
 111
 112 .IP \-y
 113 Write details about every authentication request in the
 114 \fIradius.log\fP file.
 115
 116 .IP \-z
 117 Include the password in the \fIradius.log\fP file \fBeven\fP for successful
 118 logins. \fIThis is very insecure!\fP.
 119
 120 .SH CONFIGURATION
 121 \fBRadiusd\fP uses 6 configuration files. Each file has it's own manpage
 122 describing the format of the file. These files are:
 123 .IP dictionary
 124 This file is usually static. It defines all the possible RADIUS attributes
 125 used in the other configuration files. You don't have to modify it.
 126 .IP clients
 127 Contains the IP address and a secret key for every client that wants
 128 to connect to the server.
 129 .IP naslist
 130 Contains an entry for every NAS (Network Access Server) in the network. This
 131 is not the same as a client, especially if you have \fBradius\fP proxy server
 132 in your network. In that case, the proxy server is the client and it sends
 133 requests for different NASes.
 134 .IP
 135 It also contains a abbreviated name for each
 136 terminal server, used to create the directory name where the \fBdetail\fP
 137 file is written, and used for the \fB/var/log/radwtmp\fP file. Finally
 138 it also defines what type of NAS (Cisco, Livingston, Portslave) the NAS is.
 139 .IP hints
 140 Defines certain hints to the radius server based on the users's loginname
 141 or other attributes sent by the access server. It also provides for
 142 mapping user names (such as Pusername -> username). This provides the
 143 functionality that the \fILivingston 2.0\fP server has as "Prefix" and
 144 "Suffix" support in the \fIusers\fP file, but is more general. Ofcourse
 145 the Livingston way of doing things is also supported, and you can even use
 146 both at the same time (within certain limits).
 147 .IP huntgroups
 148 Defines the huntgroups that you have, and makes it possible to restrict
 149 access to certain huntgroups to certain (groups of) users.
 150 .IP users
 151 Here the users are defined. On a typical setup, this file mainly contains
 152 DEFAULT entries to process the different types of logins, based on hints
 153 from the hints file. Authentication is then based on the contents of
 154 the UNIX \fI/etc/passwd\fP file. However it is also possible to define all
 155 users, and their passwords, in this file.
 156 .SH SEE ALSO
 157 builddbm(8rad), users(5rad), huntgroups(5rad), hints(5rad),
 158 clients(5rad), dictionary(5rad).
 159 .SH AUTHOR
 160 Miquel van Smoorenburg, miquels@cistron.nl.