4 |
- |
1 |
# -*- text -*-
|
|
|
2 |
######################################################################
|
|
|
3 |
#
|
|
|
4 |
# This is a virtual server that handles *only* inner tunnel
|
|
|
5 |
# requests for EAP-TTLS and PEAP types.
|
|
|
6 |
#
|
34 |
- |
7 |
# $Id: bb0b93bc9cc9ade4e78725ea113d6f228937fef7 $
|
4 |
- |
8 |
#
|
|
|
9 |
######################################################################
|
|
|
10 |
|
|
|
11 |
server inner-tunnel {
|
|
|
12 |
|
|
|
13 |
#
|
|
|
14 |
# This next section is here to allow testing of the "inner-tunnel"
|
|
|
15 |
# authentication methods, independently from the "default" server.
|
|
|
16 |
# It is listening on "localhost", so that it can only be used from
|
|
|
17 |
# the same machine.
|
|
|
18 |
#
|
|
|
19 |
# $ radtest USER PASSWORD 127.0.0.1:18120 0 testing123
|
|
|
20 |
#
|
|
|
21 |
# If it works, you have configured the inner tunnel correctly. To check
|
|
|
22 |
# if PEAP will work, use:
|
|
|
23 |
#
|
|
|
24 |
# $ radtest -t mschap USER PASSWORD 127.0.0.1:18120 0 testing123
|
|
|
25 |
#
|
|
|
26 |
# If that works, PEAP should work. If that command doesn't work, then
|
|
|
27 |
#
|
34 |
- |
28 |
# FIX THE INNER TUNNEL CONFIGURATION SO THAT IT WORKS.
|
4 |
- |
29 |
#
|
34 |
- |
30 |
# Do NOT do any PEAP tests. It won't help. Instead, concentrate
|
|
|
31 |
# on fixing the inner tunnel configuration. DO NOTHING ELSE.
|
4 |
- |
32 |
#
|
|
|
33 |
listen {
|
|
|
34 |
ipaddr = 127.0.0.1
|
|
|
35 |
port = 18120
|
|
|
36 |
type = auth
|
|
|
37 |
}
|
|
|
38 |
|
|
|
39 |
|
|
|
40 |
# Authorization. First preprocess (hints and huntgroups files),
|
|
|
41 |
# then realms, and finally look in the "users" file.
|
|
|
42 |
#
|
|
|
43 |
# The order of the realm modules will determine the order that
|
|
|
44 |
# we try to find a matching realm.
|
|
|
45 |
#
|
|
|
46 |
# Make *sure* that 'preprocess' comes before any realm if you
|
|
|
47 |
# need to setup hints for the remote radius server
|
|
|
48 |
authorize {
|
|
|
49 |
#
|
|
|
50 |
# The chap module will set 'Auth-Type := CHAP' if we are
|
|
|
51 |
# handling a CHAP request and Auth-Type has not already been set
|
|
|
52 |
chap
|
|
|
53 |
|
|
|
54 |
#
|
|
|
55 |
# If the users are logging in with an MS-CHAP-Challenge
|
|
|
56 |
# attribute for authentication, the mschap module will find
|
|
|
57 |
# the MS-CHAP-Challenge attribute, and add 'Auth-Type := MS-CHAP'
|
|
|
58 |
# to the request, which will cause the server to then use
|
|
|
59 |
# the mschap module for authentication.
|
|
|
60 |
mschap
|
|
|
61 |
|
|
|
62 |
#
|
|
|
63 |
# Pull crypt'd passwords from /etc/passwd or /etc/shadow,
|
|
|
64 |
# using the system API's to get the password. If you want
|
|
|
65 |
# to read /etc/passwd or /etc/shadow directly, see the
|
|
|
66 |
# passwd module, above.
|
|
|
67 |
#
|
|
|
68 |
# unix
|
|
|
69 |
|
|
|
70 |
#
|
|
|
71 |
# Look for IPASS style 'realm/', and if not found, look for
|
|
|
72 |
# '@realm', and decide whether or not to proxy, based on
|
|
|
73 |
# that.
|
|
|
74 |
# IPASS
|
|
|
75 |
|
|
|
76 |
#
|
|
|
77 |
# If you are using multiple kinds of realms, you probably
|
|
|
78 |
# want to set "ignore_null = yes" for all of them.
|
|
|
79 |
# Otherwise, when the first style of realm doesn't match,
|
|
|
80 |
# the other styles won't be checked.
|
|
|
81 |
#
|
|
|
82 |
# Note that proxying the inner tunnel authentication means
|
|
|
83 |
# that the user MAY use one identity in the outer session
|
|
|
84 |
# (e.g. "anonymous", and a different one here
|
|
|
85 |
# (e.g. "user@example.com"). The inner session will then be
|
|
|
86 |
# proxied elsewhere for authentication. If you are not
|
|
|
87 |
# careful, this means that the user can cause you to forward
|
|
|
88 |
# the authentication to another RADIUS server, and have the
|
|
|
89 |
# accounting logs *not* sent to the other server. This makes
|
|
|
90 |
# it difficult to bill people for their network activity.
|
|
|
91 |
#
|
|
|
92 |
suffix
|
|
|
93 |
# ntdomain
|
|
|
94 |
|
|
|
95 |
#
|
|
|
96 |
# The "suffix" module takes care of stripping the domain
|
|
|
97 |
# (e.g. "@example.com") from the User-Name attribute, and the
|
|
|
98 |
# next few lines ensure that the request is not proxied.
|
|
|
99 |
#
|
|
|
100 |
# If you want the inner tunnel request to be proxied, delete
|
|
|
101 |
# the next few lines.
|
|
|
102 |
#
|
|
|
103 |
update control {
|
|
|
104 |
Proxy-To-Realm := LOCAL
|
|
|
105 |
}
|
|
|
106 |
|
|
|
107 |
#
|
|
|
108 |
# This module takes care of EAP-MSCHAPv2 authentication.
|
|
|
109 |
#
|
|
|
110 |
# It also sets the EAP-Type attribute in the request
|
|
|
111 |
# attribute list to the EAP type from the packet.
|
|
|
112 |
#
|
|
|
113 |
# The example below uses module failover to avoid querying all
|
|
|
114 |
# of the following modules if the EAP module returns "ok".
|
|
|
115 |
# Therefore, your LDAP and/or SQL servers will not be queried
|
|
|
116 |
# for the many packets that go back and forth to set up TTLS
|
|
|
117 |
# or PEAP. The load on those servers will therefore be reduced.
|
|
|
118 |
#
|
|
|
119 |
eap {
|
|
|
120 |
ok = return
|
|
|
121 |
}
|
|
|
122 |
|
|
|
123 |
#
|
|
|
124 |
# Read the 'users' file
|
|
|
125 |
files
|
|
|
126 |
|
|
|
127 |
#
|
|
|
128 |
# Look in an SQL database. The schema of the database
|
|
|
129 |
# is meant to mirror the "users" file.
|
|
|
130 |
#
|
|
|
131 |
# See "Authorization Queries" in sql.conf
|
|
|
132 |
# sql
|
|
|
133 |
|
|
|
134 |
#
|
|
|
135 |
# If you are using /etc/smbpasswd, and are also doing
|
|
|
136 |
# mschap authentication, the un-comment this line, and
|
|
|
137 |
# configure the 'etc_smbpasswd' module, above.
|
|
|
138 |
# etc_smbpasswd
|
|
|
139 |
|
|
|
140 |
#
|
|
|
141 |
# The ldap module will set Auth-Type to LDAP if it has not
|
|
|
142 |
# already been set
|
|
|
143 |
# ldap
|
|
|
144 |
|
|
|
145 |
#
|
|
|
146 |
# Enforce daily limits on time spent logged in.
|
|
|
147 |
# daily
|
|
|
148 |
|
|
|
149 |
#
|
|
|
150 |
# Use the checkval module
|
|
|
151 |
# checkval
|
|
|
152 |
|
|
|
153 |
expiration
|
|
|
154 |
logintime
|
|
|
155 |
|
|
|
156 |
#
|
|
|
157 |
# If no other module has claimed responsibility for
|
|
|
158 |
# authentication, then try to use PAP. This allows the
|
|
|
159 |
# other modules listed above to add a "known good" password
|
|
|
160 |
# to the request, and to do nothing else. The PAP module
|
|
|
161 |
# will then see that password, and use it to do PAP
|
|
|
162 |
# authentication.
|
|
|
163 |
#
|
|
|
164 |
# This module should be listed last, so that the other modules
|
|
|
165 |
# get a chance to set Auth-Type for themselves.
|
|
|
166 |
#
|
|
|
167 |
pap
|
|
|
168 |
}
|
|
|
169 |
|
|
|
170 |
|
|
|
171 |
# Authentication.
|
|
|
172 |
#
|
|
|
173 |
#
|
|
|
174 |
# This section lists which modules are available for authentication.
|
|
|
175 |
# Note that it does NOT mean 'try each module in order'. It means
|
|
|
176 |
# that a module from the 'authorize' section adds a configuration
|
|
|
177 |
# attribute 'Auth-Type := FOO'. That authentication type is then
|
|
|
178 |
# used to pick the apropriate module from the list below.
|
|
|
179 |
#
|
|
|
180 |
|
|
|
181 |
# In general, you SHOULD NOT set the Auth-Type attribute. The server
|
|
|
182 |
# will figure it out on its own, and will do the right thing. The
|
|
|
183 |
# most common side effect of erroneously setting the Auth-Type
|
|
|
184 |
# attribute is that one authentication method will work, but the
|
|
|
185 |
# others will not.
|
|
|
186 |
#
|
|
|
187 |
# The common reasons to set the Auth-Type attribute by hand
|
|
|
188 |
# is to either forcibly reject the user, or forcibly accept him.
|
|
|
189 |
#
|
|
|
190 |
authenticate {
|
|
|
191 |
#
|
|
|
192 |
# PAP authentication, when a back-end database listed
|
|
|
193 |
# in the 'authorize' section supplies a password. The
|
|
|
194 |
# password can be clear-text, or encrypted.
|
|
|
195 |
Auth-Type PAP {
|
|
|
196 |
pap
|
|
|
197 |
}
|
|
|
198 |
|
|
|
199 |
#
|
|
|
200 |
# Most people want CHAP authentication
|
|
|
201 |
# A back-end database listed in the 'authorize' section
|
|
|
202 |
# MUST supply a CLEAR TEXT password. Encrypted passwords
|
|
|
203 |
# won't work.
|
|
|
204 |
Auth-Type CHAP {
|
|
|
205 |
chap
|
|
|
206 |
}
|
|
|
207 |
|
|
|
208 |
#
|
|
|
209 |
# MSCHAP authentication.
|
|
|
210 |
Auth-Type MS-CHAP {
|
|
|
211 |
mschap
|
|
|
212 |
}
|
|
|
213 |
|
|
|
214 |
#
|
|
|
215 |
# Pluggable Authentication Modules.
|
|
|
216 |
# pam
|
|
|
217 |
|
|
|
218 |
#
|
|
|
219 |
# See 'man getpwent' for information on how the 'unix'
|
|
|
220 |
# module checks the users password. Note that packets
|
|
|
221 |
# containing CHAP-Password attributes CANNOT be authenticated
|
|
|
222 |
# against /etc/passwd! See the FAQ for details.
|
|
|
223 |
#
|
|
|
224 |
unix
|
|
|
225 |
|
|
|
226 |
# Uncomment it if you want to use ldap for authentication
|
|
|
227 |
#
|
|
|
228 |
# Note that this means "check plain-text password against
|
|
|
229 |
# the ldap database", which means that EAP won't work,
|
|
|
230 |
# as it does not supply a plain-text password.
|
|
|
231 |
# Auth-Type LDAP {
|
|
|
232 |
# ldap
|
|
|
233 |
# }
|
|
|
234 |
|
|
|
235 |
#
|
|
|
236 |
# Allow EAP authentication.
|
|
|
237 |
eap
|
|
|
238 |
}
|
|
|
239 |
|
|
|
240 |
######################################################################
|
|
|
241 |
#
|
|
|
242 |
# There are no accounting requests inside of EAP-TTLS or PEAP
|
|
|
243 |
# tunnels.
|
|
|
244 |
#
|
|
|
245 |
######################################################################
|
|
|
246 |
|
|
|
247 |
|
|
|
248 |
# Session database, used for checking Simultaneous-Use. Either the radutmp
|
|
|
249 |
# or rlm_sql module can handle this.
|
|
|
250 |
# The rlm_sql module is *much* faster
|
|
|
251 |
session {
|
|
|
252 |
radutmp
|
|
|
253 |
|
|
|
254 |
#
|
|
|
255 |
# See "Simultaneous Use Checking Queries" in sql.conf
|
|
|
256 |
# sql
|
|
|
257 |
}
|
|
|
258 |
|
|
|
259 |
|
|
|
260 |
# Post-Authentication
|
|
|
261 |
# Once we KNOW that the user has been authenticated, there are
|
|
|
262 |
# additional steps we can take.
|
|
|
263 |
post-auth {
|
|
|
264 |
# Note that we do NOT assign IP addresses here.
|
|
|
265 |
# If you try to assign IP addresses for EAP authentication types,
|
|
|
266 |
# it WILL NOT WORK. You MUST use DHCP.
|
|
|
267 |
|
|
|
268 |
#
|
|
|
269 |
# If you want to have a log of authentication replies,
|
|
|
270 |
# un-comment the following line, and the 'detail reply_log'
|
|
|
271 |
# section, above.
|
|
|
272 |
# reply_log
|
|
|
273 |
|
|
|
274 |
#
|
|
|
275 |
# After authenticating the user, do another SQL query.
|
|
|
276 |
#
|
|
|
277 |
# See "Authentication Logging Queries" in sql.conf
|
|
|
278 |
# sql
|
|
|
279 |
|
|
|
280 |
#
|
|
|
281 |
# Instead of sending the query to the SQL server,
|
|
|
282 |
# write it into a log file.
|
|
|
283 |
#
|
|
|
284 |
# sql_log
|
|
|
285 |
|
|
|
286 |
#
|
|
|
287 |
# Un-comment the following if you have set
|
|
|
288 |
# 'edir_account_policy_check = yes' in the ldap module sub-section of
|
|
|
289 |
# the 'modules' section.
|
|
|
290 |
#
|
|
|
291 |
# ldap
|
|
|
292 |
|
|
|
293 |
#
|
|
|
294 |
# Access-Reject packets are sent through the REJECT sub-section of the
|
|
|
295 |
# post-auth section.
|
|
|
296 |
#
|
|
|
297 |
# Add the ldap module name (or instance) if you have set
|
|
|
298 |
# 'edir_account_policy_check = yes' in the ldap module configuration
|
|
|
299 |
#
|
|
|
300 |
Post-Auth-Type REJECT {
|
|
|
301 |
# log failed authentications in SQL, too.
|
|
|
302 |
# sql
|
|
|
303 |
attr_filter.access_reject
|
|
|
304 |
}
|
|
|
305 |
|
|
|
306 |
#
|
|
|
307 |
# The example policy below updates the outer tunnel reply
|
|
|
308 |
# (usually Access-Accept) with the User-Name from the inner
|
|
|
309 |
# tunnel User-Name. Since this section is processed in the
|
|
|
310 |
# context of the inner tunnel, "request" here means "inner
|
|
|
311 |
# tunnel request", and "outer.reply" means "outer tunnel
|
|
|
312 |
# reply attributes".
|
|
|
313 |
#
|
|
|
314 |
# This example is most useful when the outer session contains
|
|
|
315 |
# a User-Name of "anonymous@....", or a MAC address. If it
|
|
|
316 |
# is enabled, the NAS SHOULD use the inner tunnel User-Name
|
|
|
317 |
# in subsequent accounting packets. This makes it easier to
|
|
|
318 |
# track user sessions, as they will all be based on the real
|
|
|
319 |
# name, and not on "anonymous".
|
|
|
320 |
#
|
|
|
321 |
# The problem with doing this is that it ALSO exposes the
|
|
|
322 |
# real user name to any intermediate proxies. People use
|
|
|
323 |
# "anonymous" identifiers outside of the tunnel for a very
|
|
|
324 |
# good reason: it gives them more privacy. Setting the reply
|
|
|
325 |
# to contain the real user name removes ALL privacy from
|
|
|
326 |
# their session.
|
|
|
327 |
#
|
|
|
328 |
# If you want privacy to remain, see the
|
|
|
329 |
# Chargeable-User-Identity attribute from RFC 4372. In order
|
|
|
330 |
# to use that attribute, you will have to allocate a
|
|
|
331 |
# per-session identifier for the user, and store it in a
|
|
|
332 |
# long-term database (e.g. SQL). You should also use that
|
|
|
333 |
# attribute INSTEAD of the configuration below.
|
|
|
334 |
#
|
|
|
335 |
#update outer.reply {
|
|
|
336 |
# User-Name = "%{request:User-Name}"
|
|
|
337 |
#}
|
|
|
338 |
|
|
|
339 |
}
|
|
|
340 |
|
|
|
341 |
#
|
|
|
342 |
# When the server decides to proxy a request to a home server,
|
|
|
343 |
# the proxied request is first passed through the pre-proxy
|
|
|
344 |
# stage. This stage can re-write the request, or decide to
|
|
|
345 |
# cancel the proxy.
|
|
|
346 |
#
|
|
|
347 |
# Only a few modules currently have this method.
|
|
|
348 |
#
|
|
|
349 |
pre-proxy {
|
|
|
350 |
# attr_rewrite
|
|
|
351 |
|
|
|
352 |
# Uncomment the following line if you want to change attributes
|
|
|
353 |
# as defined in the preproxy_users file.
|
|
|
354 |
# files
|
|
|
355 |
|
|
|
356 |
# Uncomment the following line if you want to filter requests
|
|
|
357 |
# sent to remote servers based on the rules defined in the
|
|
|
358 |
# 'attrs.pre-proxy' file.
|
|
|
359 |
# attr_filter.pre-proxy
|
|
|
360 |
|
|
|
361 |
# If you want to have a log of packets proxied to a home
|
|
|
362 |
# server, un-comment the following line, and the
|
|
|
363 |
# 'detail pre_proxy_log' section, above.
|
|
|
364 |
# pre_proxy_log
|
|
|
365 |
}
|
|
|
366 |
|
|
|
367 |
#
|
|
|
368 |
# When the server receives a reply to a request it proxied
|
|
|
369 |
# to a home server, the request may be massaged here, in the
|
|
|
370 |
# post-proxy stage.
|
|
|
371 |
#
|
|
|
372 |
post-proxy {
|
|
|
373 |
|
|
|
374 |
# If you want to have a log of replies from a home server,
|
|
|
375 |
# un-comment the following line, and the 'detail post_proxy_log'
|
|
|
376 |
# section, above.
|
|
|
377 |
# post_proxy_log
|
|
|
378 |
|
|
|
379 |
# attr_rewrite
|
|
|
380 |
|
|
|
381 |
# Uncomment the following line if you want to filter replies from
|
|
|
382 |
# remote proxies based on the rules defined in the 'attrs' file.
|
|
|
383 |
# attr_filter.post-proxy
|
|
|
384 |
|
|
|
385 |
#
|
|
|
386 |
# If you are proxying LEAP, you MUST configure the EAP
|
|
|
387 |
# module, and you MUST list it here, in the post-proxy
|
|
|
388 |
# stage.
|
|
|
389 |
#
|
|
|
390 |
# You MUST also use the 'nostrip' option in the 'realm'
|
|
|
391 |
# configuration. Otherwise, the User-Name attribute
|
|
|
392 |
# in the proxied request will not match the user name
|
|
|
393 |
# hidden inside of the EAP packet, and the end server will
|
|
|
394 |
# reject the EAP request.
|
|
|
395 |
#
|
|
|
396 |
eap
|
|
|
397 |
|
|
|
398 |
#
|
|
|
399 |
# If the server tries to proxy a request and fails, then the
|
|
|
400 |
# request is processed through the modules in this section.
|
|
|
401 |
#
|
|
|
402 |
# The main use of this section is to permit robust proxying
|
|
|
403 |
# of accounting packets. The server can be configured to
|
|
|
404 |
# proxy accounting packets as part of normal processing.
|
|
|
405 |
# Then, if the home server goes down, accounting packets can
|
|
|
406 |
# be logged to a local "detail" file, for processing with
|
|
|
407 |
# radrelay. When the home server comes back up, radrelay
|
|
|
408 |
# will read the detail file, and send the packets to the
|
|
|
409 |
# home server.
|
|
|
410 |
#
|
|
|
411 |
# With this configuration, the server always responds to
|
|
|
412 |
# Accounting-Requests from the NAS, but only writes
|
|
|
413 |
# accounting packets to disk if the home server is down.
|
|
|
414 |
#
|
|
|
415 |
# Post-Proxy-Type Fail {
|
|
|
416 |
# detail
|
|
|
417 |
# }
|
|
|
418 |
|
|
|
419 |
}
|
|
|
420 |
|
|
|
421 |
} # inner-tunnel server block
|