383 |
franck |
1 |
######################################################################
|
|
|
2 |
#
|
|
|
3 |
# As of 2.0.0, FreeRADIUS supports virtual hosts using the
|
|
|
4 |
# "server" section, and configuration directives.
|
|
|
5 |
#
|
|
|
6 |
# Virtual hosts should be put into the "sites-available"
|
|
|
7 |
# directory. Soft links should be created in the "sites-enabled"
|
|
|
8 |
# directory to these files. This is done in a normal installation.
|
|
|
9 |
#
|
|
|
10 |
# $Id: alcasar-radius 445 2011-01-11 00:22:01Z franck $
|
|
|
11 |
#
|
|
|
12 |
######################################################################
|
|
|
13 |
#
|
|
|
14 |
# Read "man radiusd" before editing this file. See the section
|
|
|
15 |
# titled DEBUGGING. It outlines a method where you can quickly
|
|
|
16 |
# obtain the configuration you want, without running into
|
|
|
17 |
# trouble. See also "man unlang", which documents the format
|
|
|
18 |
# of this file.
|
|
|
19 |
#
|
|
|
20 |
# This configuration is designed to work in the widest possible
|
|
|
21 |
# set of circumstances, with the widest possible number of
|
|
|
22 |
# authentication methods. This means that in general, you should
|
|
|
23 |
# need to make very few changes to this file.
|
|
|
24 |
#
|
|
|
25 |
# The best way to configure the server for your local system
|
|
|
26 |
# is to CAREFULLY edit this file. Most attempts to make large
|
|
|
27 |
# edits to this file will BREAK THE SERVER. Any edits should
|
|
|
28 |
# be small, and tested by running the server with "radiusd -X".
|
|
|
29 |
# Once the edits have been verified to work, save a copy of these
|
|
|
30 |
# configuration files somewhere. (e.g. as a "tar" file). Then,
|
|
|
31 |
# make more edits, and test, as above.
|
|
|
32 |
#
|
|
|
33 |
# There are many "commented out" references to modules such
|
|
|
34 |
# as ldap, sql, etc. These references serve as place-holders.
|
|
|
35 |
# If you need the functionality of that module, then configure
|
|
|
36 |
# it in radiusd.conf, and un-comment the references to it in
|
|
|
37 |
# this file. In most cases, those small changes will result
|
|
|
38 |
# in the server being able to connect to the DB, and to
|
|
|
39 |
# authenticate users.
|
|
|
40 |
#
|
|
|
41 |
######################################################################
|
1 |
root |
42 |
|
383 |
franck |
43 |
#
|
|
|
44 |
# In 1.x, the "authorize", etc. sections were global in
|
|
|
45 |
# radiusd.conf. As of 2.0, they SHOULD be in a server section.
|
|
|
46 |
#
|
|
|
47 |
# The server section with no virtual server name is the "default"
|
|
|
48 |
# section. It is used when no server name is specified.
|
|
|
49 |
#
|
|
|
50 |
# We don't indent the rest of this file, because doing so
|
|
|
51 |
# would make it harder to read.
|
|
|
52 |
#
|
|
|
53 |
|
|
|
54 |
# Authorization. First preprocess (hints and huntgroups files),
|
|
|
55 |
# then realms, and finally look in the "users" file.
|
|
|
56 |
#
|
|
|
57 |
# The order of the realm modules will determine the order that
|
|
|
58 |
# we try to find a matching realm.
|
|
|
59 |
#
|
|
|
60 |
# Make *sure* that 'preprocess' comes before any realm if you
|
|
|
61 |
# need to setup hints for the remote radius server
|
|
|
62 |
authorize {
|
|
|
63 |
#
|
|
|
64 |
# The preprocess module takes care of sanitizing some bizarre
|
|
|
65 |
# attributes in the request, and turning them into attributes
|
|
|
66 |
# which are more standard.
|
|
|
67 |
#
|
|
|
68 |
# It takes care of processing the 'raddb/hints' and the
|
|
|
69 |
# 'raddb/huntgroups' files.
|
|
|
70 |
#
|
|
|
71 |
# It also adds the %{Client-IP-Address} attribute to the request.
|
|
|
72 |
preprocess
|
|
|
73 |
|
|
|
74 |
#
|
|
|
75 |
# If you want to have a log of authentication requests,
|
|
|
76 |
# un-comment the following line, and the 'detail auth_log'
|
|
|
77 |
# section, above.
|
|
|
78 |
# auth_log
|
|
|
79 |
|
|
|
80 |
#
|
|
|
81 |
# The chap module will set 'Auth-Type := CHAP' if we are
|
|
|
82 |
# handling a CHAP request and Auth-Type has not already been set
|
|
|
83 |
# chap
|
|
|
84 |
|
|
|
85 |
#
|
|
|
86 |
# If the users are logging in with an MS-CHAP-Challenge
|
|
|
87 |
# attribute for authentication, the mschap module will find
|
|
|
88 |
# the MS-CHAP-Challenge attribute, and add 'Auth-Type := MS-CHAP'
|
|
|
89 |
# to the request, which will cause the server to then use
|
|
|
90 |
# the mschap module for authentication.
|
|
|
91 |
# mschap
|
|
|
92 |
#
|
|
|
93 |
# If you have a Cisco SIP server authenticating against
|
|
|
94 |
# FreeRADIUS, uncomment the following line, and the 'digest'
|
|
|
95 |
# line in the 'authenticate' section.
|
|
|
96 |
# digest
|
|
|
97 |
|
|
|
98 |
#
|
|
|
99 |
# Look for IPASS style 'realm/', and if not found, look for
|
|
|
100 |
# '@realm', and decide whether or not to proxy, based on
|
|
|
101 |
# that.
|
|
|
102 |
# IPASS
|
|
|
103 |
|
|
|
104 |
#
|
|
|
105 |
# If you are using multiple kinds of realms, you probably
|
|
|
106 |
# want to set "ignore_null = yes" for all of them.
|
|
|
107 |
# Otherwise, when the first style of realm doesn't match,
|
|
|
108 |
# the other styles won't be checked.
|
|
|
109 |
#
|
|
|
110 |
# suffix
|
|
|
111 |
# ntdomain
|
|
|
112 |
|
|
|
113 |
#
|
|
|
114 |
# This module takes care of EAP-MD5, EAP-TLS, and EAP-LEAP
|
|
|
115 |
# authentication.
|
|
|
116 |
#
|
|
|
117 |
# It also sets the EAP-Type attribute in the request
|
|
|
118 |
# attribute list to the EAP type from the packet.
|
|
|
119 |
#
|
|
|
120 |
# As of 2.0, the EAP module returns "ok" in the authorize stage
|
|
|
121 |
# for TTLS and PEAP. In 1.x, it never returned "ok" here, so
|
|
|
122 |
# this change is compatible with older configurations.
|
|
|
123 |
#
|
|
|
124 |
# The example below uses module failover to avoid querying all
|
|
|
125 |
# of the following modules if the EAP module returns "ok".
|
|
|
126 |
# Therefore, your LDAP and/or SQL servers will not be queried
|
|
|
127 |
# for the many packets that go back and forth to set up TTLS
|
|
|
128 |
# or PEAP. The load on those servers will therefore be reduced.
|
|
|
129 |
#
|
|
|
130 |
# eap {
|
|
|
131 |
# ok = return
|
|
|
132 |
# }
|
|
|
133 |
|
|
|
134 |
#
|
|
|
135 |
# Pull crypt'd passwords from /etc/passwd or /etc/shadow,
|
|
|
136 |
# using the system API's to get the password. If you want
|
|
|
137 |
# to read /etc/passwd or /etc/shadow directly, see the
|
|
|
138 |
# passwd module in radiusd.conf.
|
|
|
139 |
#
|
|
|
140 |
# unix
|
|
|
141 |
|
|
|
142 |
#
|
|
|
143 |
# Read the 'users' file
|
|
|
144 |
# files
|
|
|
145 |
|
|
|
146 |
#
|
|
|
147 |
# Look in an SQL database. The schema of the database
|
|
|
148 |
# is meant to mirror the "users" file.
|
|
|
149 |
#
|
|
|
150 |
# See "Authorization Queries" in sql.conf
|
|
|
151 |
sql
|
|
|
152 |
noresetcounter
|
|
|
153 |
dailycounter
|
|
|
154 |
monthlycounter
|
|
|
155 |
#
|
|
|
156 |
# If you are using /etc/smbpasswd, and are also doing
|
|
|
157 |
# mschap authentication, the un-comment this line, and
|
|
|
158 |
# configure the 'etc_smbpasswd' module, above.
|
|
|
159 |
# etc_smbpasswd
|
|
|
160 |
|
|
|
161 |
#
|
|
|
162 |
# The ldap module will set Auth-Type to LDAP if it has not
|
|
|
163 |
# already been set
|
|
|
164 |
# ldap
|
|
|
165 |
|
|
|
166 |
#
|
|
|
167 |
# Enforce daily limits on time spent logged in.
|
|
|
168 |
# daily
|
|
|
169 |
|
|
|
170 |
#
|
|
|
171 |
# Use the checkval module
|
|
|
172 |
# checkval
|
|
|
173 |
|
|
|
174 |
expiration
|
|
|
175 |
logintime
|
|
|
176 |
|
|
|
177 |
#
|
|
|
178 |
# If no other module has claimed responsibility for
|
|
|
179 |
# authentication, then try to use PAP. This allows the
|
|
|
180 |
# other modules listed above to add a "known good" password
|
|
|
181 |
# to the request, and to do nothing else. The PAP module
|
|
|
182 |
# will then see that password, and use it to do PAP
|
|
|
183 |
# authentication.
|
|
|
184 |
#
|
|
|
185 |
# This module should be listed last, so that the other modules
|
|
|
186 |
# get a chance to set Auth-Type for themselves.
|
|
|
187 |
#
|
|
|
188 |
# pap
|
|
|
189 |
|
|
|
190 |
#
|
|
|
191 |
# If "status_server = yes", then Status-Server messages are passed
|
|
|
192 |
# through the following section, and ONLY the following section.
|
|
|
193 |
# This permits you to do DB queries, for example. If the modules
|
|
|
194 |
# listed here return "fail", then NO response is sent.
|
|
|
195 |
#
|
|
|
196 |
# Autz-Type Status-Server {
|
|
|
197 |
#
|
|
|
198 |
# }
|
|
|
199 |
}
|
|
|
200 |
|
|
|
201 |
|
|
|
202 |
# Authentication.
|
|
|
203 |
#
|
|
|
204 |
#
|
|
|
205 |
# This section lists which modules are available for authentication.
|
|
|
206 |
# Note that it does NOT mean 'try each module in order'. It means
|
|
|
207 |
# that a module from the 'authorize' section adds a configuration
|
|
|
208 |
# attribute 'Auth-Type := FOO'. That authentication type is then
|
|
|
209 |
# used to pick the apropriate module from the list below.
|
|
|
210 |
#
|
|
|
211 |
|
|
|
212 |
# In general, you SHOULD NOT set the Auth-Type attribute. The server
|
|
|
213 |
# will figure it out on its own, and will do the right thing. The
|
|
|
214 |
# most common side effect of erroneously setting the Auth-Type
|
|
|
215 |
# attribute is that one authentication method will work, but the
|
|
|
216 |
# others will not.
|
|
|
217 |
#
|
|
|
218 |
# The common reasons to set the Auth-Type attribute by hand
|
|
|
219 |
# is to either forcibly reject the user (Auth-Type := Reject),
|
|
|
220 |
# or to or forcibly accept the user (Auth-Type := Accept).
|
|
|
221 |
#
|
|
|
222 |
# Note that Auth-Type := Accept will NOT work with EAP.
|
|
|
223 |
#
|
|
|
224 |
# Please do not put "unlang" configurations into the "authenticate"
|
|
|
225 |
# section. Put them in the "post-auth" section instead. That's what
|
|
|
226 |
# the post-auth section is for.
|
|
|
227 |
#
|
|
|
228 |
authenticate {
|
|
|
229 |
# #
|
|
|
230 |
# # PAP authentication, when a back-end database listed
|
|
|
231 |
# # in the 'authorize' section supplies a password. The
|
|
|
232 |
# # password can be clear-text, or encrypted.
|
|
|
233 |
# Auth-Type PAP {
|
|
|
234 |
# pap
|
|
|
235 |
# }
|
|
|
236 |
#
|
|
|
237 |
# #
|
|
|
238 |
# # Most people want CHAP authentication
|
|
|
239 |
# # A back-end database listed in the 'authorize' section
|
|
|
240 |
# # MUST supply a CLEAR TEXT password. Encrypted passwords
|
|
|
241 |
# # won't work.
|
|
|
242 |
# Auth-Type CHAP {
|
|
|
243 |
# chap
|
|
|
244 |
# }
|
|
|
245 |
#
|
|
|
246 |
# #
|
|
|
247 |
# # MSCHAP authentication.
|
|
|
248 |
# Auth-Type MS-CHAP {
|
|
|
249 |
# mschap
|
|
|
250 |
# }
|
|
|
251 |
#
|
|
|
252 |
# #
|
|
|
253 |
# # If you have a Cisco SIP server authenticating against
|
|
|
254 |
# # FreeRADIUS, uncomment the following line, and the 'digest'
|
|
|
255 |
# # line in the 'authorize' section.
|
|
|
256 |
# digest
|
|
|
257 |
#
|
|
|
258 |
# #
|
|
|
259 |
# # Pluggable Authentication Modules.
|
|
|
260 |
# pam
|
|
|
261 |
#
|
|
|
262 |
# #
|
|
|
263 |
# # See 'man getpwent' for information on how the 'unix'
|
|
|
264 |
# # module checks the users password. Note that packets
|
|
|
265 |
# # containing CHAP-Password attributes CANNOT be authenticated
|
|
|
266 |
# # against /etc/passwd! See the FAQ for details.
|
|
|
267 |
# #
|
|
|
268 |
# unix
|
|
|
269 |
#
|
|
|
270 |
# # Uncomment it if you want to use ldap for authentication
|
|
|
271 |
# #
|
|
|
272 |
# # Note that this means "check plain-text password against
|
|
|
273 |
# # the ldap database", which means that EAP won't work,
|
|
|
274 |
# # as it does not supply a plain-text password.
|
|
|
275 |
# Auth-Type LDAP {
|
|
|
276 |
# ldap
|
|
|
277 |
# }
|
|
|
278 |
#
|
|
|
279 |
# #
|
|
|
280 |
# # Allow EAP authentication.
|
|
|
281 |
# eap
|
|
|
282 |
}
|
|
|
283 |
|
|
|
284 |
|
|
|
285 |
#
|
|
|
286 |
# Pre-accounting. Decide which accounting type to use.
|
|
|
287 |
#
|
|
|
288 |
preacct {
|
|
|
289 |
preprocess
|
|
|
290 |
|
|
|
291 |
#
|
|
|
292 |
# Ensure that we have a semi-unique identifier for every
|
|
|
293 |
# request, and many NAS boxes are broken.
|
|
|
294 |
# acct_unique
|
|
|
295 |
|
|
|
296 |
#
|
|
|
297 |
# Look for IPASS-style 'realm/', and if not found, look for
|
|
|
298 |
# '@realm', and decide whether or not to proxy, based on
|
|
|
299 |
# that.
|
|
|
300 |
#
|
|
|
301 |
# Accounting requests are generally proxied to the same
|
|
|
302 |
# home server as authentication requests.
|
|
|
303 |
# IPASS
|
|
|
304 |
# suffix
|
|
|
305 |
# ntdomain
|
|
|
306 |
|
|
|
307 |
#
|
|
|
308 |
# Read the 'acct_users' file
|
|
|
309 |
# files
|
|
|
310 |
}
|
|
|
311 |
|
|
|
312 |
#
|
|
|
313 |
# Accounting. Log the accounting data.
|
|
|
314 |
#
|
|
|
315 |
accounting {
|
|
|
316 |
#
|
|
|
317 |
# Create a 'detail'ed log of the packets.
|
|
|
318 |
# Note that accounting requests which are proxied
|
|
|
319 |
# are also logged in the detail file.
|
|
|
320 |
# detail
|
|
|
321 |
# daily
|
|
|
322 |
|
|
|
323 |
# Update the wtmp file
|
|
|
324 |
#
|
|
|
325 |
# If you don't use "radlast", you can delete this line.
|
|
|
326 |
# unix
|
|
|
327 |
|
|
|
328 |
#
|
|
|
329 |
# For Simultaneous-Use tracking.
|
|
|
330 |
#
|
|
|
331 |
# Due to packet losses in the network, the data here
|
|
|
332 |
# may be incorrect. There is little we can do about it.
|
|
|
333 |
# radutmp
|
|
|
334 |
sradutmp
|
|
|
335 |
|
|
|
336 |
# Return an address to the IP Pool when we see a stop record.
|
|
|
337 |
# main_pool
|
|
|
338 |
|
|
|
339 |
#
|
|
|
340 |
# Log traffic to an SQL database.
|
|
|
341 |
#
|
|
|
342 |
# See "Accounting queries" in sql.conf
|
|
|
343 |
sql
|
|
|
344 |
|
|
|
345 |
#
|
|
|
346 |
# Instead of sending the query to the SQL server,
|
|
|
347 |
# write it into a log file.
|
|
|
348 |
#
|
|
|
349 |
# sql_log
|
|
|
350 |
|
|
|
351 |
# Cisco VoIP specific bulk accounting
|
|
|
352 |
# pgsql-voip
|
|
|
353 |
|
|
|
354 |
# Filter attributes from the accounting response.
|
|
|
355 |
attr_filter.accounting_response
|
|
|
356 |
|
|
|
357 |
#
|
|
|
358 |
# See "Autz-Type Status-Server" for how this works.
|
|
|
359 |
#
|
|
|
360 |
# Acct-Type Status-Server {
|
|
|
361 |
#
|
|
|
362 |
# }
|
|
|
363 |
}
|
|
|
364 |
|
|
|
365 |
|
|
|
366 |
# Session database, used for checking Simultaneous-Use. Either the radutmp
|
|
|
367 |
# or rlm_sql module can handle this.
|
|
|
368 |
# The rlm_sql module is *much* faster
|
|
|
369 |
session {
|
|
|
370 |
# radutmp
|
|
|
371 |
|
|
|
372 |
#
|
|
|
373 |
# See "Simultaneous Use Checking Queries" in sql.conf
|
|
|
374 |
sql
|
|
|
375 |
}
|
|
|
376 |
|
|
|
377 |
|
|
|
378 |
# Post-Authentication
|
|
|
379 |
# Once we KNOW that the user has been authenticated, there are
|
|
|
380 |
# additional steps we can take.
|
|
|
381 |
post-auth {
|
|
|
382 |
# Get an address from the IP Pool.
|
|
|
383 |
# main_pool
|
|
|
384 |
|
|
|
385 |
#
|
|
|
386 |
# If you want to have a log of authentication replies,
|
|
|
387 |
# un-comment the following line, and the 'detail reply_log'
|
|
|
388 |
# section, above.
|
|
|
389 |
# reply_log
|
|
|
390 |
|
|
|
391 |
#
|
|
|
392 |
# After authenticating the user, do another SQL query.
|
|
|
393 |
#
|
|
|
394 |
# See "Authentication Logging Queries" in sql.conf
|
|
|
395 |
# sql
|
|
|
396 |
|
|
|
397 |
#
|
|
|
398 |
# Instead of sending the query to the SQL server,
|
|
|
399 |
# write it into a log file.
|
|
|
400 |
#
|
|
|
401 |
# sql_log
|
|
|
402 |
|
|
|
403 |
#
|
|
|
404 |
# Un-comment the following if you have set
|
|
|
405 |
# 'edir_account_policy_check = yes' in the ldap module sub-section of
|
|
|
406 |
# the 'modules' section.
|
|
|
407 |
#
|
|
|
408 |
# ldap
|
|
|
409 |
|
|
|
410 |
# exec
|
|
|
411 |
|
|
|
412 |
#
|
|
|
413 |
# Access-Reject packets are sent through the REJECT sub-section of the
|
|
|
414 |
# post-auth section.
|
|
|
415 |
#
|
|
|
416 |
# Add the ldap module name (or instance) if you have set
|
|
|
417 |
# 'edir_account_policy_check = yes' in the ldap module configuration
|
|
|
418 |
#
|
|
|
419 |
Post-Auth-Type REJECT {
|
|
|
420 |
attr_filter.access_reject
|
|
|
421 |
}
|
|
|
422 |
}
|
|
|
423 |
|
|
|
424 |
#
|
|
|
425 |
# When the server decides to proxy a request to a home server,
|
|
|
426 |
# the proxied request is first passed through the pre-proxy
|
|
|
427 |
# stage. This stage can re-write the request, or decide to
|
|
|
428 |
# cancel the proxy.
|
|
|
429 |
#
|
|
|
430 |
# Only a few modules currently have this method.
|
|
|
431 |
#
|
|
|
432 |
pre-proxy {
|
|
|
433 |
# attr_rewrite
|
|
|
434 |
|
|
|
435 |
# Uncomment the following line if you want to change attributes
|
|
|
436 |
# as defined in the preproxy_users file.
|
|
|
437 |
# files
|
|
|
438 |
|
|
|
439 |
# Uncomment the following line if you want to filter requests
|
|
|
440 |
# sent to remote servers based on the rules defined in the
|
|
|
441 |
# 'attrs.pre-proxy' file.
|
|
|
442 |
# attr_filter.pre-proxy
|
|
|
443 |
|
|
|
444 |
# If you want to have a log of packets proxied to a home
|
|
|
445 |
# server, un-comment the following line, and the
|
|
|
446 |
# 'detail pre_proxy_log' section, above.
|
|
|
447 |
# pre_proxy_log
|
|
|
448 |
}
|
|
|
449 |
|
|
|
450 |
#
|
|
|
451 |
# When the server receives a reply to a request it proxied
|
|
|
452 |
# to a home server, the request may be massaged here, in the
|
|
|
453 |
# post-proxy stage.
|
|
|
454 |
#
|
|
|
455 |
post-proxy {
|
|
|
456 |
|
|
|
457 |
# If you want to have a log of replies from a home server,
|
|
|
458 |
# un-comment the following line, and the 'detail post_proxy_log'
|
|
|
459 |
# section, above.
|
|
|
460 |
# post_proxy_log
|
|
|
461 |
|
|
|
462 |
# attr_rewrite
|
|
|
463 |
|
|
|
464 |
# Uncomment the following line if you want to filter replies from
|
|
|
465 |
# remote proxies based on the rules defined in the 'attrs' file.
|
|
|
466 |
# attr_filter.post-proxy
|
|
|
467 |
|
|
|
468 |
#
|
|
|
469 |
# If you are proxying LEAP, you MUST configure the EAP
|
|
|
470 |
# module, and you MUST list it here, in the post-proxy
|
|
|
471 |
# stage.
|
|
|
472 |
#
|
|
|
473 |
# You MUST also use the 'nostrip' option in the 'realm'
|
|
|
474 |
# configuration. Otherwise, the User-Name attribute
|
|
|
475 |
# in the proxied request will not match the user name
|
|
|
476 |
# hidden inside of the EAP packet, and the end server will
|
|
|
477 |
# reject the EAP request.
|
|
|
478 |
#
|
|
|
479 |
# eap
|
|
|
480 |
|
|
|
481 |
#
|
|
|
482 |
# If the server tries to proxy a request and fails, then the
|
|
|
483 |
# request is processed through the modules in this section.
|
|
|
484 |
#
|
|
|
485 |
# The main use of this section is to permit robust proxying
|
|
|
486 |
# of accounting packets. The server can be configured to
|
|
|
487 |
# proxy accounting packets as part of normal processing.
|
|
|
488 |
# Then, if the home server goes down, accounting packets can
|
|
|
489 |
# be logged to a local "detail" file, for processing with
|
|
|
490 |
# radrelay. When the home server comes back up, radrelay
|
|
|
491 |
# will read the detail file, and send the packets to the
|
|
|
492 |
# home server.
|
|
|
493 |
#
|
|
|
494 |
# With this configuration, the server always responds to
|
|
|
495 |
# Accounting-Requests from the NAS, but only writes
|
|
|
496 |
# accounting packets to disk if the home server is down.
|
|
|
497 |
#
|
|
|
498 |
# Post-Proxy-Type Fail {
|
|
|
499 |
# detail
|
|
|
500 |
# }
|
|
|
501 |
|
|
|
502 |
}
|
|
|
503 |
|