Mercurial > hg > fD-testbed
comparison conf/radpxy.eap.testbed.aaa/freeradius/sites-available/example @ 11:44f87917c579
Added a RADIUS proxy using freeradius in the eap testbed
author | Sebastien Decugis <sdecugis@nict.go.jp> |
---|---|
date | Thu, 16 Sep 2010 14:23:42 +0900 |
parents | |
children |
comparison
equal
deleted
inserted
replaced
10:7b569c198c7c | 11:44f87917c579 |
---|---|
1 ###################################################################### | |
2 # | |
3 # An example virtual server configuration. | |
4 # | |
5 # $Id: example,v 1.2 2007/10/09 14:25:36 aland Exp $ | |
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 documenation | |
38 # and examples, and should not appear on the net. You shouldn't | |
39 # use it for anything, either. | |
40 # | |
41 client 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 ###################################################################### | |
54 server 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 } |