This file is indexed.

/etc/freeradius/3.0/sites-available/README is in freeradius-config 3.0.16+dfsg-1ubuntu3.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
1.  Virtual Servers.

  FreeRADIUS 2.0 supports virtual servers.  This is probably the
single largest change that is NOT backwards compatible with 1.x.

  The virtual servers do NOT have to be set up with the
"sites-available" and "sites-enabled" directories.  You can still have
one "radiusd.conf" file, and put the server configuration there:

	...
	server {
		authorize {
			...
		}
		authenticate {
			...
		}
		...
	}
	...

  The power of virtual servers lies in their ability to separate
policies.  A policy can be placed into a virtual server, where it is
guaranteed to affect only the requests that are passed through that
virtual server.  In 1.x, the policies were global, and it sometimes
took much effort to write a policy so that it only applied in certain
limited situations.


2.  What do we mean by "virtual server"?


  A virtual server is a (nearly complete) RADIUS server, just like a
configuration for FreeRADIUS 1.x.  However, FreeRADIUS can now run
multiple virtual servers at the same time.  The virtual servers can
even proxy requests to each other!

  The simplest way to create a virtual server is to take the all of
the request processing sections from radius.conf, ("authorize" ,
"authenticate", etc.) and wrap them in a "server {}" block, as above.

  You can create another virtual server by:

    1) defining a new "server foo {...}" section in radiusd.conf
    2) Putting the normal "authorize", etc. sections inside of it
    3) Adding a "listen" section *inside* of the "server" section.

  e.g.

	...
	server foo {
		listen {
			ipaddr = 127.0.0.1
			port = 2000
			type = auth
		}

		authorize {
			update control {
				Cleartext-Password := "bob"
			}
			pap
		}

		authenticate {
			pap
		}
	}
	...

  With that text added to "radiusd.conf", run the server in debugging
mode (radiusd -X), and in another terminal window, type:

$ radtest bob bob localhost:2000 0 testing123

  You should see the server return an Access-Accept.


3. Capabilities and limitations


  The only sub-sections that can appear in a virtual server section
are:

	listen
	client
	authorize
	authenticate
	post-auth
	pre-proxy
	post-proxy
	preacct
	accounting
	session

  All other configuration parameters (modules, etc.) are global.

  Inside of a virtual server, the authorize, etc. sections have their
normal meaning, and can contain anything that an authorize section
could contain in 1.x.

  When a "listen" section is inside of a virtual server definition, it
means that all requests sent to that IP/port will be processed through
the virtual server.  There cannot be two "listen" sections with the
same IP address and port number.

  When a "client" section is inside of a virtual server definition, it
means that that client is known only to the "listen" sections that are
also inside of that virtual server.  Not only is this client
definition available only to this virtual server, but the details of
the client configuration is also available only to this virtual
server.

  i.e. Two virtual servers can listen on different IP address and
ports, but both can have a client with IP address 127.0.0.1.  The
shared secret for that client can be different for each virtual
server.


4. More complex "listen" capabilities

  The "listen" sections have a few additional configuration items that
were not in 1.x, and were not mentioned above.  These configuration
items enable almost any mapping of IP / port to clients to virtual
servers.

  The configuration items are:

	virtual_server = <name>

		If set, all requests sent to this IP / port are processed
		through the named virtual server.

		This directive can be used only for "listen" sections
		that are global.  i.e. It CANNOT be used if the
		"listen" section is inside of a virtual server.

	clients = <name>

		If set, the "listen" section looks for a "clients" section:

			clients <name> {
				...
			}

		It looks inside of that named "clients" section for
		"client" subsections, at least one of which must
		exist.  Each client in that section is added to the
		list of known clients for this IP / port.  No other
		clients are known.

		If it is set, it over-rides the list of clients (if
		any) in the same virtual server.  Note that the
		clients are NOT additive!

		If it is not set, then the clients from the current
		virtual server (if any) are used.  If there are no
		clients in this virtual server, then the global
		clients are used.

		i.e. The most specific directive is used:
			* configuration in this "listen" section
			* clients in the same virtual server
			* global clients

		The directives are also *exclusive*, not *additive*.
		If you have one client in a virtual server, and
		another client referenced from a "listen" section,
		then that "listen" section will ONLY use the second
		client.  It will NOT use both clients.


5. More complex "client" capabilities

  The "client" sections have a few additional configuration items that
were not in 1.x, and were not mentioned above.  These configuration
items enable almost any mapping of IP / port to clients to virtual
servers.

  The configuration items are:

	virtual_server = <name>

		If set, all requests from this client are processed
		through the named virtual server.

		This directive can be used only for "client" sections
		that are global.  i.e. It CANNOT be used if the
		"client" section is inside of a virtual server.

  If the "listen" section has a "server" entry, and a matching
client is found ALSO with a "server" entry, then the clients server is
used for that request.


6. Worked examples


  Listening on one socket, and mapping requests from two clients to
two different servers.

	listen {
		...
	}
	client one {
		...
		virtual_server = server_one
	}
	client two {
		...
		virtual_server = server_two
	}
	server server_one {
		authorize {
			...
		}
		...
	}
	server server_two {
		authorize {
			...
		}
		...
	}

  This could also be done as:


	listen {
		...
		virtual_server = server_one
	}
	client one {
		...
	}
	client two {
		...
		virtual_server = server_two
	}
	server server_one {
		authorize {
			...
		}
		...
	}
	server server_two {
		authorize {
			...
		}
		...
	}

  In this case, the default server for the socket is "server_one", so
there is no need to set that in the client "one" configuration.  The
"server_two" configuration for client "two" over-rides the default
setting for the socket.

  Note that the following configuration will NOT work:

	listen {
		...
		virtual_server = server_one
	}
	client one {
		...
	}
	server server_one {
		authorize {
			...
		}
		...
	}
	server server_two {
		client two {
			...
		}
		authorize {
			...
		}
		...
	}

  In this example, client "two" is hidden inside of the virtual
server, where the "listen" section cannot find it.


7. Outlined examples

  This section outlines a number of examples, with alternatives.

  One server, multiple sockets
	- multiple "listen" sections in a "server" section

  one server per client
	- define multiple servers
	- have a global "listen" section
	- have multiple global "clients", each with "virtual_server = X"

  two servers, each with their own sockets
	- define multiple servers
	- put "client" sections into each "server"
	- put a "listen" section into each "server"

	Each server can list the same client IP, and the secret
	can be different

  two sockets, sharing a list of clients, but pointing to different servers
	- define global "listen" sections
	- in each, set "virtual_server = X"
	- in each, set "clients = Y"
	- define "clients Y" section, containing multiple clients.

	This also means that you can have a third socket, which
	doesn't share any of these clients.


8.  How to decide what to do


  If you want *completely* separate policies for a socket or a client,
then create a separate virtual server.  Then, map the request to that
server by setting configuration entries in a "listen" section or in a
"client" section.

  Start off with the common cases first.  If most of the clients
and/or sockets get a particular policy, make that policy the default.
Configure it without paying attention to the sockets or clients you
want to add later, and without adding a second virtual server.  Once
it works, then add the second virtual server.

  If you want to re-use the previously defined sockets with the second
virtual server, then you will need one or more global "client"
sections.  Those clients will contain a "virtual_server = ..." entry
that will direct requests from those clients to the appropriate
virtual server.