Subversion Repositories ALCASAR

Rev

Details | Last modification | View Log

Rev Author Line No. Line
1279 richard 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 845 2012-03-29 21:17:03Z richard $
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
######################################################################
42
 
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
#		fail = 1
166
#	}
167
 
168
	#
169
	#  Enforce daily limits on time spent logged in.
170
#	daily
171
 
172
	#
173
	# Use the checkval module
174
#	checkval
175
 
176
	expiration
177
	logintime
178
 
179
	#
180
	#  If no other module has claimed responsibility for
181
	#  authentication, then try to use PAP.  This allows the
182
	#  other modules listed above to add a "known good" password
183
	#  to the request, and to do nothing else.  The PAP module
184
	#  will then see that password, and use it to do PAP
185
	#  authentication.
186
	#
187
	#  This module should be listed last, so that the other modules
188
	#  get a chance to set Auth-Type for themselves.
189
	#
190
#	pap
191
 
192
	#
193
	#  If "status_server = yes", then Status-Server messages are passed
194
	#  through the following section, and ONLY the following section.
195
	#  This permits you to do DB queries, for example.  If the modules
196
	#  listed here return "fail", then NO response is sent.
197
	#
198
#	Autz-Type Status-Server {
199
#
200
#	}
201
	update coa {
202
		User-Name = "%{User-Name}"
203
		Acct-Session-Id = "%{Acct-Session-Id}"
204
		NAS-IP-Address = "%{NAS-IP-Address}"
205
	}
206
}
207
 
208
 
209
#  Authentication.
210
#
211
#
212
#  This section lists which modules are available for authentication.
213
#  Note that it does NOT mean 'try each module in order'.  It means
214
#  that a module from the 'authorize' section adds a configuration
215
#  attribute 'Auth-Type := FOO'.  That authentication type is then
216
#  used to pick the apropriate module from the list below.
217
#
218
 
219
#  In general, you SHOULD NOT set the Auth-Type attribute.  The server
220
#  will figure it out on its own, and will do the right thing.  The
221
#  most common side effect of erroneously setting the Auth-Type
222
#  attribute is that one authentication method will work, but the
223
#  others will not.
224
#
225
#  The common reasons to set the Auth-Type attribute by hand
226
#  is to either forcibly reject the user (Auth-Type := Reject),
227
#  or to or forcibly accept the user (Auth-Type := Accept).
228
#
229
#  Note that Auth-Type := Accept will NOT work with EAP.
230
#
231
#  Please do not put "unlang" configurations into the "authenticate"
232
#  section.  Put them in the "post-auth" section instead.  That's what
233
#  the post-auth section is for.
234
#
235
authenticate {
236
#	#
237
#	#  PAP authentication, when a back-end database listed
238
#	#  in the 'authorize' section supplies a password.  The
239
#	#  password can be clear-text, or encrypted.
240
#	Auth-Type PAP {
241
#		pap
242
#	}
243
#
244
#	#
245
#	#  Most people want CHAP authentication
246
#	#  A back-end database listed in the 'authorize' section
247
#	#  MUST supply a CLEAR TEXT password.  Encrypted passwords
248
#	#  won't work.
249
#	Auth-Type CHAP {
250
#		chap
251
#	}
252
#
253
#	#
254
#	#  MSCHAP authentication.
255
#	Auth-Type MS-CHAP {
256
#		mschap
257
#	}
258
#
259
#	#
260
#	#  If you have a Cisco SIP server authenticating against
261
#	#  FreeRADIUS, uncomment the following line, and the 'digest'
262
#	#  line in the 'authorize' section.
263
#	digest
264
#
265
#	#
266
#	#  Pluggable Authentication Modules.
267
#	pam
268
#
269
#	#
270
#	#  See 'man getpwent' for information on how the 'unix'
271
#	#  module checks the users password.  Note that packets
272
#	#  containing CHAP-Password attributes CANNOT be authenticated
273
#	#  against /etc/passwd!  See the FAQ for details.
274
#	#
275
#	unix
276
#
277
#	# Uncomment it if you want to use ldap for authentication
278
#	#
279
#	# Note that this means "check plain-text password against
280
#	# the ldap database", which means that EAP won't work,
281
#	# as it does not supply a plain-text password.
282
#	Auth-Type LDAP {
283
#		ldap
284
#	}
285
#
286
#	#
287
#	#  Allow EAP authentication.
288
#	eap
289
}
290
 
291
 
292
#
293
#  Pre-accounting.  Decide which accounting type to use.
294
#
295
preacct {
296
	preprocess
297
 
298
	#
299
	#  Ensure that we have a semi-unique identifier for every
300
	#  request, and many NAS boxes are broken.
301
#	acct_unique
302
 
303
	#
304
	#  Look for IPASS-style 'realm/', and if not found, look for
305
	#  '@realm', and decide whether or not to proxy, based on
306
	#  that.
307
	#
308
	#  Accounting requests are generally proxied to the same
309
	#  home server as authentication requests.
310
#	IPASS
311
#	suffix
312
#	ntdomain
313
 
314
	#
315
	#  Read the 'acct_users' file
316
#	files
317
}
318
 
319
#
320
#  Accounting.  Log the accounting data.
321
#
322
accounting {
323
	#
324
	#  Create a 'detail'ed log of the packets.
325
	#  Note that accounting requests which are proxied
326
	#  are also logged in the detail file.
327
#	detail
328
#	daily
329
 
330
	#  Update the wtmp file
331
	#
332
	#  If you don't use "radlast", you can delete this line.
333
#	unix
334
 
335
	#
336
	#  For Simultaneous-Use tracking.
337
	#
338
	#  Due to packet losses in the network, the data here
339
	#  may be incorrect.  There is little we can do about it.
340
#	radutmp
341
	sradutmp
342
 
343
	#  Return an address to the IP Pool when we see a stop record.
344
#	main_pool
345
 
346
	#
347
	#  Log traffic to an SQL database.
348
	#
349
	#  See "Accounting queries" in sql.conf
350
	sql
351
 
352
	#
353
	#  Instead of sending the query to the SQL server,
354
	#  write it into a log file.
355
	#
356
#	sql_log
357
 
358
	#  Cisco VoIP specific bulk accounting
359
#	pgsql-voip
360
 
361
	#  Filter attributes from the accounting response.
362
	attr_filter.accounting_response
363
 
364
	#
365
	#  See "Autz-Type Status-Server" for how this works.
366
	#
367
#	Acct-Type Status-Server {
368
#
369
#	}
370
}
371
 
372
 
373
#  Session database, used for checking Simultaneous-Use. Either the radutmp
374
#  or rlm_sql module can handle this.
375
#  The rlm_sql module is *much* faster
376
session {
377
#	radutmp
378
 
379
	#
380
	#  See "Simultaneous Use Checking Queries" in sql.conf
381
	sql
382
}
383
 
384
 
385
#  Post-Authentication
386
#  Once we KNOW that the user has been authenticated, there are
387
#  additional steps we can take.
388
post-auth {
389
	#  Get an address from the IP Pool.
390
#	main_pool
391
 
392
	#
393
	#  If you want to have a log of authentication replies,
394
	#  un-comment the following line, and the 'detail reply_log'
395
	#  section, above.
396
#	reply_log
397
 
398
	#
399
	#  After authenticating the user, do another SQL query.
400
	#
401
	#  See "Authentication Logging Queries" in sql.conf
402
#	sql
403
 
404
	#
405
	#  Instead of sending the query to the SQL server,
406
	#  write it into a log file.
407
	#
408
#	sql_log
409
 
410
	#
411
	#  Un-comment the following if you have set
412
	#  'edir_account_policy_check = yes' in the ldap module sub-section of
413
	#  the 'modules' section.
414
	#
415
#	ldap
416
 
417
#	exec
418
 
419
	#
420
	#  Access-Reject packets are sent through the REJECT sub-section of the
421
	#  post-auth section.
422
	#
423
	#  Add the ldap module name (or instance) if you have set
424
	#  'edir_account_policy_check = yes' in the ldap module configuration
425
	#
426
	Post-Auth-Type REJECT {
427
		attr_filter.access_reject
428
	}
429
}
430
 
431
#
432
#  When the server decides to proxy a request to a home server,
433
#  the proxied request is first passed through the pre-proxy
434
#  stage.  This stage can re-write the request, or decide to
435
#  cancel the proxy.
436
#
437
#  Only a few modules currently have this method.
438
#
439
pre-proxy {
440
#	attr_rewrite
441
 
442
	#  Uncomment the following line if you want to change attributes
443
	#  as defined in the preproxy_users file.
444
#	files
445
 
446
	#  Uncomment the following line if you want to filter requests
447
	#  sent to remote servers based on the rules defined in the
448
	#  'attrs.pre-proxy' file.
449
#	attr_filter.pre-proxy
450
 
451
	#  If you want to have a log of packets proxied to a home
452
	#  server, un-comment the following line, and the
453
	#  'detail pre_proxy_log' section, above.
454
#	pre_proxy_log
455
}
456
 
457
#
458
#  When the server receives a reply to a request it proxied
459
#  to a home server, the request may be massaged here, in the
460
#  post-proxy stage.
461
#
462
post-proxy {
463
 
464
	#  If you want to have a log of replies from a home server,
465
	#  un-comment the following line, and the 'detail post_proxy_log'
466
	#  section, above.
467
#	post_proxy_log
468
 
469
#	attr_rewrite
470
 
471
	#  Uncomment the following line if you want to filter replies from
472
	#  remote proxies based on the rules defined in the 'attrs' file.
473
#	attr_filter.post-proxy
474
 
475
	#
476
	#  If you are proxying LEAP, you MUST configure the EAP
477
	#  module, and you MUST list it here, in the post-proxy
478
	#  stage.
479
	#
480
	#  You MUST also use the 'nostrip' option in the 'realm'
481
	#  configuration.  Otherwise, the User-Name attribute
482
	#  in the proxied request will not match the user name
483
	#  hidden inside of the EAP packet, and the end server will
484
	#  reject the EAP request.
485
	#
486
#	eap
487
 
488
	#
489
	#  If the server tries to proxy a request and fails, then the
490
	#  request is processed through the modules in this section.
491
	#
492
	#  The main use of this section is to permit robust proxying
493
	#  of accounting packets.  The server can be configured to
494
	#  proxy accounting packets as part of normal processing.
495
	#  Then, if the home server goes down, accounting packets can
496
	#  be logged to a local "detail" file, for processing with
497
	#  radrelay.  When the home server comes back up, radrelay
498
	#  will read the detail file, and send the packets to the
499
	#  home server.
500
	#
501
	#  With this configuration, the server always responds to
502
	#  Accounting-Requests from the NAS, but only writes
503
	#  accounting packets to disk if the home server is down.
504
	#
505
#	Post-Proxy-Type Fail {
506
#			detail
507
#	}
508
 
509
}
510