path: root/roles/radius_server/templates/radiusd.conf.j2

prefix = /usr
exec_prefix = /usr
sysconfdir = /etc
localstatedir = /var
sbindir = /usr/sbin
logdir = ${localstatedir}/log/radius
raddbdir = ${sysconfdir}/raddb
radacctdir = ${logdir}/radacct

name = radiusd

confdir = ${raddbdir}
modconfdir = ${confdir}/mods-config
certdir = ${confdir}/certs
cadir   = ${confdir}/certs
run_dir = ${localstatedir}/run/${name}

db_dir = ${localstatedir}/lib/radiusd


libdir = /usr/lib64/freeradius


pidfile = ${run_dir}/${name}.pid


correct_escapes = true

max_request_time = 30


cleanup_delay = 5


max_requests = 16384


hostname_lookups = no

log {

	destination = files

	#
	colourise = yes


	#
	file = ${logdir}/radius.log

	
	syslog_facility = daemon

	#  Log the full User-Name attribute, as it was found in the request.
	#
	# allowed values: {no, yes}
	#
	stripped_names = no

	#  Log authentication requests to the log file.
	#
	#  allowed values: {no, yes}
	#
	auth = yes

	#  Log passwords with the authentication requests.
	#  auth_badpass  - logs password if it's rejected
	#  auth_goodpass - logs password if it's correct
	#
	#  allowed values: {no, yes}
	#
	auth_badpass = yes
	auth_goodpass = yes

	#  Log additional text at the end of the "Login OK" messages.
	#  for these to work, the "auth" and "auth_goodpass" or "auth_badpass"
	#  configurations above have to be set to "yes".
	#
	#  The strings below are dynamically expanded, which means that
	#  you can put anything you want in them.  However, note that
	#  this expansion can be slow, and can negatively impact server
	#  performance.
	#

	#  The message when the user exceeds the Simultaneous-Use limit.
	#
	msg_denied = "You are already logged in - access denied"
}

checkrad = ${sbindir}/checkrad

security {
	#  chroot: directory where the server does "chroot".
	#
	#  The chroot is done very early in the process of starting
	#  the server.  After the chroot has been performed it
	#  switches to the "user" listed below (which MUST be
	#  specified).  If "group" is specified, it switches to that
	#  group, too.  Any other groups listed for the specified
	#  "user" in "/etc/group" are also added as part of this
	#  process.
	#
	#  The current working directory (chdir / cd) is left
	#  *outside* of the chroot until all of the modules have been
	#  initialized.  This allows the "raddb" directory to be left
	#  outside of the chroot.  Once the modules have been
	#  initialized, it does a "chdir" to ${logdir}.  This means
	#  that it should be impossible to break out of the chroot.
	#
	#  If you are worried about security issues related to this
	#  use of chdir, then simply ensure that the "raddb" directory
	#  is inside of the chroot, end be sure to do "cd raddb"
	#  BEFORE starting the server.
	#
	#  If the server is statically linked, then the only files
	#  that have to exist in the chroot are ${run_dir} and
	#  ${logdir}.  If you do the "cd raddb" as discussed above,
	#  then the "raddb" directory has to be inside of the chroot
	#  directory, too.
	#
#	chroot = /path/to/chroot/directory

	# user/group: The name (or #number) of the user/group to run radiusd as.
	#
	#   If these are commented out, the server will run as the
	#   user/group that started it.  In order to change to a
	#   different user/group, you MUST be root ( or have root
	#   privileges ) to start the server.
	#
	#   We STRONGLY recommend that you run the server with as few
	#   permissions as possible.  That is, if you're not using
	#   shadow passwords, the user and group items below should be
	#   set to radius'.
	#
	#  NOTE that some kernels refuse to setgid(group) when the
	#  value of (unsigned)group is above 60000; don't use group
	#  "nobody" on these systems!
	#
	#  On systems with shadow passwords, you might have to set
	#  'group = shadow' for the server to be able to read the
	#  shadow password file.  If you can authenticate users while
	#  in debug mode, but not in daemon mode, it may be that the
	#  debugging mode server is running as a user that can read
	#  the shadow info, and the user listed below can not.
	#
	#  The server will also try to use "initgroups" to read
	#  /etc/groups.  It will join all groups where "user" is a
	#  member.  This can allow for some finer-grained access
	#  controls.
	#
	user = radiusd
	group = radiusd

	#  Core dumps are a bad thing.  This should only be set to
	#  'yes' if you're debugging a problem with the server.
	#
	#  allowed values: {no, yes}
	#
	allow_core_dumps = no

	#
	#  max_attributes: The maximum number of attributes
	#  permitted in a RADIUS packet.  Packets which have MORE
	#  than this number of attributes in them will be dropped.
	#
	#  If this number is set too low, then no RADIUS packets
	#  will be accepted.
	#
	#  If this number is set too high, then an attacker may be
	#  able to send a small number of packets which will cause
	#  the server to use all available memory on the machine.
	#
	#  Setting this number to 0 means "allow any number of attributes"
	max_attributes = 200

	#
	#  reject_delay: When sending an Access-Reject, it can be
	#  delayed for a few seconds.  This may help slow down a DoS
	#  attack.  It also helps to slow down people trying to brute-force
	#  crack a users password.
	#
	#  Setting this number to 0 means "send rejects immediately"
	#
	#  If this number is set higher than 'cleanup_delay', then the
	#  rejects will be sent at 'cleanup_delay' time, when the request
	#  is deleted from the internal cache of requests.
	#
	#  As of Version 3.0.5, "reject_delay" has sub-second resolution.
	#  e.g. "reject_delay =  1.4" seconds is possible.
	#
	#  Useful ranges: 1 to 5
	reject_delay = 1

	#
	#  status_server: Whether or not the server will respond
	#  to Status-Server requests.
	#
	#  When sent a Status-Server message, the server responds with
	#  an Access-Accept or Accounting-Response packet.
	#
	#  This is mainly useful for administrators who want to "ping"
	#  the server, without adding test users, or creating fake
	#  accounting packets.
	#
	#  It's also useful when a NAS marks a RADIUS server "dead".
	#  The NAS can periodically "ping" the server with a Status-Server
	#  packet.  If the server responds, it must be alive, and the
	#  NAS can start using it for real requests.
	#
	#  See also raddb/sites-available/status
	#
	status_server = yes


}

proxy_requests  = yes
$INCLUDE proxy.conf


$INCLUDE clients.conf


thread pool {
	#  Number of servers to start initially --- should be a reasonable
	#  ballpark figure.
	start_servers = 5

	#  Limit on the total number of servers running.
	#
	#  If this limit is ever reached, clients will be LOCKED OUT, so it
	#  should NOT BE SET TOO LOW.  It is intended mainly as a brake to
	#  keep a runaway server from taking the system with it as it spirals
	#  down...
	#
	#  You may find that the server is regularly reaching the
	#  'max_servers' number of threads, and that increasing
	#  'max_servers' doesn't seem to make much difference.
	#
	#  If this is the case, then the problem is MOST LIKELY that
	#  your back-end databases are taking too long to respond, and
	#  are preventing the server from responding in a timely manner.
	#
	#  The solution is NOT do keep increasing the 'max_servers'
	#  value, but instead to fix the underlying cause of the
	#  problem: slow database, or 'hostname_lookups=yes'.
	#
	#  For more information, see 'max_request_time', above.
	#
	max_servers = 32

	#  Server-pool size regulation.  Rather than making you guess
	#  how many servers you need, FreeRADIUS dynamically adapts to
	#  the load it sees, that is, it tries to maintain enough
	#  servers to handle the current load, plus a few spare
	#  servers to handle transient load spikes.
	#
	#  It does this by periodically checking how many servers are
	#  waiting for a request.  If there are fewer than
	#  min_spare_servers, it creates a new spare.  If there are
	#  more than max_spare_servers, some of the spares die off.
	#  The default values are probably OK for most sites.
	#
	min_spare_servers = 3
	max_spare_servers = 10

	#  When the server receives a packet, it places it onto an
	#  internal queue, where the worker threads (configured above)
	#  pick it up for processing.  The maximum size of that queue
	#  is given here.
	#
	#  When the queue is full, any new packets will be silently
	#  discarded.
	#
	#  The most common cause of the queue being full is that the
	#  server is dependent on a slow database, and it has received
	#  a large "spike" of traffic.  When that happens, there is
	#  very little you can do other than make sure the server
	#  receives less traffic, or make sure that the database can
	#  handle the load.
	#
#	max_queue_size = 65536

	#  There may be memory leaks or resource allocation problems with
	#  the server.  If so, set this value to 300 or so, so that the
	#  resources will be cleaned up periodically.
	#
	#  This should only be necessary if there are serious bugs in the
	#  server which have not yet been fixed.
	#
	#  '0' is a special value meaning 'infinity', or 'the servers never
	#  exit'
	max_requests_per_server = 0

	#  Automatically limit the number of accounting requests.
	#  This configuration item tracks how many requests per second
	#  the server can handle.  It does this by tracking the
	#  packets/s received by the server for processing, and
	#  comparing that to the packets/s handled by the child
	#  threads.
	#

	#  If the received PPS is larger than the processed PPS, *and*
	#  the queue is more than half full, then new accounting
	#  requests are probabilistically discarded.  This lowers the
	#  number of packets that the server needs to process.  Over
	#  time, the server will "catch up" with the traffic.
	#
	#  Throwing away accounting packets is usually safe and low
	#  impact.  The NAS will retransmit them in a few seconds, or
	#  even a few minutes.  Vendors should read RFC 5080 Section 2.2.1
	#  to see how accounting packets should be retransmitted.  Using
	#  any other method is likely to cause network meltdowns.
	#
	auto_limit_acct = no
}


modules {
	#
	#  Each module has a configuration as follows:
	#
	#	name [ instance ] {
	#		config_item = value
	#		...
	#	}
	#
	#  The 'name' is used to load the 'rlm_name' library
	#  which implements the functionality of the module.
	#
	#  The 'instance' is optional.  To have two different instances
	#  of a module, it first must be referred to by 'name'.
	#  The different copies of the module are then created by
	#  inventing two 'instance' names, e.g. 'instance1' and 'instance2'
	#
	#  The instance names can then be used in later configuration
	#  INSTEAD of the original 'name'.  See the 'radutmp' configuration
	#  for an example.
	#

	#
	#  As of 3.0, modules are in mods-enabled/.  Files matching
	#  the regex /[a-zA-Z0-9_.]+/ are loaded.  The modules are
	#  initialized ONLY if they are referenced in a processing
	#  section, such as authorize, authenticate, accounting,
	#  pre/post-proxy, etc.
	#
	$INCLUDE mods-enabled/
}

instantiate {
	#
	# We list the counter module here so that it registers
	# the check_name attribute before any module which sets
	# it
#	daily

	# subsections here can be thought of as "virtual" modules.
	#
	# e.g. If you have two redundant SQL servers, and you want to
	# use them in the authorize and accounting sections, you could
	# place a "redundant" block in each section, containing the
	# exact same text.  Or, you could uncomment the following
	# lines, and list "redundant_sql" in the authorize and
	# accounting sections.
	#
	#  The "virtual" module defined here can also be used with
	#  dynamic expansions, under a few conditions:
	#
	#  * The section is "redundant", or "load-balance", or
	#    "redundant-load-balance"
	#  * The section contains modules ONLY, and no sub-sections
	#  * all modules in the section are using the same rlm_
	#    driver, e.g. They are all sql, or all ldap, etc.
	#
	#  When those conditions are satisfied, the server will
	#  automatically register a dynamic expansion, using the
	#  name of the "virtual" module.  In the example below,
	#  it will be "redundant_sql".  You can then use this expansion
	#  just like any other:
	#
	#	update reply {
	#		Filter-Id := "%{redundant_sql: ... }"
	#	}
	#
	#  In this example, the expansion is done via module "sql1",
	#  and if that expansion fails, using module "sql2".
	#
	#  For best results, configure the "pool" subsection of the
	#  module so that "retry_delay" is non-zero.  That will allow
	#  the redundant block to quickly ignore all "down" SQL
	#  databases.  If instead we have "retry_delay = 0", then
	#  every time the redundant block is used, the server will try
	#  to open a connection to every "down" database, causing
	#  problems.
	#
	#redundant redundant_sql {
	#	sql1
	#	sql2
	#}
}

policy {
	$INCLUDE policy.d/
}
$INCLUDE sites-enabled/
$INCLUDE  /etc/raddb/mods-available/sql
$INCLUDE /etc/raddb/mods-available/sqlippool