blob: 05522ea15f1c5c66b567c87edba7e7e22fa95c30 [file] [log] [blame]
Chetan Gaonker7f4bf742016-05-04 15:56:08 -07001######################################################################
2#
3# An example virtual server configuration.
4#
5# $Id: e58e24319d6320a0a0d56fd649d937bf95156739 $
6#
7######################################################################
8
9
10#
11# This client will be available to any "listen" section that
12# are defined outside of a virtual server section. However,
13# when the server receives a packet from this client, the
14# request will be processed through the "example" virtual
15# server, as the "client" section contains a configuration item
16# to that effect.
17#
18# Note that this client will be able to send requests to any
19# port defined in a global "listen" section. It will NOT,
20# however, be able to send requests to a port defined in a
21# "listen" section that is contained in a "server" section.
22#
23# With careful matching of configurations, you should be able
24# to:
25#
26# - Define one authentication port, but process each client
27# through a separate virtual server.
28#
29# - define multiple authentication ports, each with a private
30# list of clients.
31#
32# - define multiple authentication ports, each of which may
33# have the same client listed, but with different shared
34# secrets
35#
36# FYI: We use an address in the 192.0.2.* space for this example,
37# as RFC 3330 says that that /24 range is used for documentation
38# and examples, and should not appear on the net. You shouldn't
39# use it for anything, either.
40#
41client 192.0.2.10 {
42 shortname = example-client
43 secret = testing123
44 virtual_server = example
45}
46
47######################################################################
48#
49# An example virtual server. It starts off with "server name {"
50# The "name" is used to reference this server from a "listen"
51# or "client" section.
52#
53######################################################################
54server example {
55 #
56 # Listen on 192.0.2.1:1812 for Access-Requests
57 #
58 # When the server receives a packet, it is processed
59 # through the "authorize", etc. sections listed here,
60 # NOT the global ones the "default" site.
61 #
62 listen {
63 ipaddr = 192.0.2.1
64 port = 1821
65 type = auth
66 }
67
68 #
69 # This client is listed within the "server" section,
70 # and is therefore known ONLY to the socket defined
71 # in the "listen" section above. If the client IP
72 # sends a request to a different socket, the server
73 # will treat it as an unknown client, and will not
74 # respond.
75 #
76 # In contrast, the client listed at the top of this file
77 # is outside of any "server" section, and is therefore
78 # global in scope. It can send packets to any port
79 # defined in a global "listen" section. It CANNOT send
80 # packets to the listen section defined above, though.
81 #
82 # Note that you don't have to have a "virtual_server = example"
83 # line here, as the client is encapsulated within
84 # the "server" section.
85 #
86 client 192.0.2.9 {
87 shortname = example-client
88 secret = testing123
89 }
90
91 authorize {
92 #
93 # Some example policies. See "man unlang" for more.
94 #
95 if ("%{User-Name}" == "bob") {
96 update control {
97 Cleartext-Password := "bob"
98 }
99 }
100
101 #
102 # And then reject the user. The next line requires
103 # that the "always reject {}" section is defined in
104 # the "modules" section of radiusd.conf.
105 #
106 reject
107 }
108
109 authenticate {
110
111 }
112
113 post-auth {
114
115 Post-Auth-Type Reject {
116 update reply {
117 Reply-Message = "This is only an example."
118 }
119 }
120 }
121
122}