Configure freeradius
parent
c7a4049903
commit
44a6022885
|
|
@ -0,0 +1,4 @@
|
|||
---
|
||||
glob_freeradius:
|
||||
realm: crans
|
||||
proxy_to: FEDEREZ
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
- name: Restart freeradius
|
||||
systemd:
|
||||
name: freeradius
|
||||
state: restarted
|
||||
|
|
@ -23,6 +23,28 @@
|
|||
retries: 3
|
||||
until: apt_result is succeeded
|
||||
|
||||
- name: Deploy freeradius configuration
|
||||
template:
|
||||
src: "freeradius/3.0/{{ item }}.j2"
|
||||
dest: "/etc/freeradius/3.0/{{ item }}"
|
||||
owner: freerad
|
||||
group: freerad
|
||||
mode: '0640'
|
||||
loop:
|
||||
- radiusd.conf
|
||||
- clients.conf
|
||||
- sites-enabled/default
|
||||
- sites-enabled/inner-tunnel
|
||||
- mods-enabled/eap
|
||||
- mods-enabled/python3
|
||||
notify: Restart freeradius
|
||||
|
||||
- name: Bring auth.py from re2o
|
||||
file:
|
||||
src: /var/www/re2o/freeradius_utils/auth.py
|
||||
dest: /etc/freeradius/3.0/auth.py
|
||||
notify: Restart freeradius
|
||||
|
||||
- name: Symlink radius certificates
|
||||
file:
|
||||
src: /etc/letsencrypt/live/crans.org/{{ item }}
|
||||
|
|
|
|||
|
|
@ -0,0 +1,44 @@
|
|||
{{ ansible_header | comment }}
|
||||
|
||||
# -*- text -*-
|
||||
##
|
||||
## clients.conf -- client configuration directives
|
||||
##
|
||||
## $Id: 76b300d3c55f1c5c052289b76bf28ac3a370bbb2 $
|
||||
|
||||
#######################################################################
|
||||
#
|
||||
# Define RADIUS clients (usually a NAS, Access Point, etc.).
|
||||
|
||||
#
|
||||
# Defines a RADIUS client.
|
||||
#
|
||||
# '127.0.0.1' is another name for 'localhost'. It is enabled by default,
|
||||
# to allow testing of the server after an initial installation. If you
|
||||
# are not going to be permitting RADIUS queries from localhost, we suggest
|
||||
# that you delete, or comment out, this entry.
|
||||
#
|
||||
#
|
||||
|
||||
#
|
||||
# Each client has a "short name" that is used to distinguish it from
|
||||
# other clients.
|
||||
#
|
||||
# In version 1.x, the string after the word "client" was the IP
|
||||
# address of the client. In 2.0, the IP address is configured via
|
||||
# the "ipaddr" or "ipv6addr" fields. For compatibility, the 1.x
|
||||
# format is still accepted.
|
||||
#
|
||||
|
||||
client switches_v4 {
|
||||
ipaddr = {{ freeradius.infra_switch }}
|
||||
secret = {{ freeradius.secret_switch }}
|
||||
virtual_server = radius-filaire
|
||||
}
|
||||
|
||||
client bornes_v4 {
|
||||
ipaddr = {{ freeradius.infra_bornes }}
|
||||
secret = {{ freeradius.secret_bornes }}
|
||||
virtual_server = radius-wifi
|
||||
|
||||
}
|
||||
|
|
@ -0,0 +1,927 @@
|
|||
{{ ansible_header | comment }}
|
||||
|
||||
# -*- text -*-
|
||||
##
|
||||
## eap.conf -- Configuration for EAP types (PEAP, TTLS, etc.)
|
||||
##
|
||||
## $Id: f67cbdbff9b6560cec9f68da1adb82b59723d2ef $
|
||||
|
||||
#######################################################################
|
||||
#
|
||||
# Whatever you do, do NOT set 'Auth-Type := EAP'. The server
|
||||
# is smart enough to figure this out on its own. The most
|
||||
# common side effect of setting 'Auth-Type := EAP' is that the
|
||||
# users then cannot use ANY other authentication method.
|
||||
#
|
||||
eap {
|
||||
# Invoke the default supported EAP type when
|
||||
# EAP-Identity response is received.
|
||||
#
|
||||
# The incoming EAP messages DO NOT specify which EAP
|
||||
# type they will be using, so it MUST be set here.
|
||||
#
|
||||
# For now, only one default EAP type may be used at a time.
|
||||
#
|
||||
# If the EAP-Type attribute is set by another module,
|
||||
# then that EAP type takes precedence over the
|
||||
# default type configured here.
|
||||
#
|
||||
default_eap_type = md5
|
||||
|
||||
# A list is maintained to correlate EAP-Response
|
||||
# packets with EAP-Request packets. After a
|
||||
# configurable length of time, entries in the list
|
||||
# expire, and are deleted.
|
||||
#
|
||||
timer_expire = 60
|
||||
|
||||
# There are many EAP types, but the server has support
|
||||
# for only a limited subset. If the server receives
|
||||
# a request for an EAP type it does not support, then
|
||||
# it normally rejects the request. By setting this
|
||||
# configuration to "yes", you can tell the server to
|
||||
# instead keep processing the request. Another module
|
||||
# MUST then be configured to proxy the request to
|
||||
# another RADIUS server which supports that EAP type.
|
||||
#
|
||||
# If another module is NOT configured to handle the
|
||||
# request, then the request will still end up being
|
||||
# rejected.
|
||||
ignore_unknown_eap_types = no
|
||||
|
||||
# Cisco AP1230B firmware 12.2(13)JA1 has a bug. When given
|
||||
# a User-Name attribute in an Access-Accept, it copies one
|
||||
# more byte than it should.
|
||||
#
|
||||
# We can work around it by configurably adding an extra
|
||||
# zero byte.
|
||||
cisco_accounting_username_bug = no
|
||||
|
||||
#
|
||||
# Help prevent DoS attacks by limiting the number of
|
||||
# sessions that the server is tracking. For simplicity,
|
||||
# this is taken from the "max_requests" directive in
|
||||
# radiusd.conf.
|
||||
max_sessions = ${max_requests}
|
||||
|
||||
# Supported EAP-types
|
||||
|
||||
#
|
||||
# We do NOT recommend using EAP-MD5 authentication
|
||||
# for wireless connections. It is insecure, and does
|
||||
# not provide for dynamic WEP keys.
|
||||
#
|
||||
md5 {
|
||||
}
|
||||
|
||||
#
|
||||
# EAP-pwd -- secure password-based authentication
|
||||
#
|
||||
# pwd {
|
||||
# group = 19
|
||||
|
||||
#
|
||||
# server_id = theserver@example.com
|
||||
|
||||
# This has the same meaning as for TLS.
|
||||
# fragment_size = 1020
|
||||
|
||||
# The virtual server which determines the
|
||||
# "known good" password for the user.
|
||||
# Note that unlike TLS, only the "authorize"
|
||||
# section is processed. EAP-PWD requests can be
|
||||
# distinguished by having a User-Name, but
|
||||
# no User-Password, CHAP-Password, EAP-Message, etc.
|
||||
# virtual_server = "inner-tunnel"
|
||||
# }
|
||||
|
||||
# Cisco LEAP
|
||||
#
|
||||
# We do not recommend using LEAP in new deployments. See:
|
||||
# http://www.securiteam.com/tools/5TP012ACKE.html
|
||||
#
|
||||
# Cisco LEAP uses the MS-CHAP algorithm (but not
|
||||
# the MS-CHAP attributes) to perform it's authentication.
|
||||
#
|
||||
# As a result, LEAP *requires* access to the plain-text
|
||||
# User-Password, or the NT-Password attributes.
|
||||
# 'System' authentication is impossible with LEAP.
|
||||
#
|
||||
leap {
|
||||
}
|
||||
|
||||
# Generic Token Card.
|
||||
#
|
||||
# Currently, this is only permitted inside of EAP-TTLS,
|
||||
# or EAP-PEAP. The module "challenges" the user with
|
||||
# text, and the response from the user is taken to be
|
||||
# the User-Password.
|
||||
#
|
||||
# Proxying the tunneled EAP-GTC session is a bad idea,
|
||||
# the users password will go over the wire in plain-text,
|
||||
# for anyone to see.
|
||||
#
|
||||
gtc {
|
||||
# The default challenge, which many clients
|
||||
# ignore..
|
||||
#challenge = "Password: "
|
||||
|
||||
# The plain-text response which comes back
|
||||
# is put into a User-Password attribute,
|
||||
# and passed to another module for
|
||||
# authentication. This allows the EAP-GTC
|
||||
# response to be checked against plain-text,
|
||||
# or crypt'd passwords.
|
||||
#
|
||||
# If you say "Local" instead of "PAP", then
|
||||
# the module will look for a User-Password
|
||||
# configured for the request, and do the
|
||||
# authentication itself.
|
||||
#
|
||||
auth_type = PAP
|
||||
}
|
||||
|
||||
## Common TLS configuration for TLS-based EAP types
|
||||
#
|
||||
# See raddb/certs/README for additional comments
|
||||
# on certificates.
|
||||
#
|
||||
# If OpenSSL was not found at the time the server was
|
||||
# built, the "tls", "ttls", and "peap" sections will
|
||||
# be ignored.
|
||||
#
|
||||
# If you do not currently have certificates signed by
|
||||
# a trusted CA you may use the 'snakeoil' certificates.
|
||||
# Included with the server in raddb/certs.
|
||||
#
|
||||
# If these certificates have not been auto-generated:
|
||||
# cd raddb/certs
|
||||
# make
|
||||
#
|
||||
# These test certificates SHOULD NOT be used in a normal
|
||||
# deployment. They are created only to make it easier
|
||||
# to install the server, and to perform some simple
|
||||
# tests with EAP-TLS, TTLS, or PEAP.
|
||||
#
|
||||
# See also:
|
||||
#
|
||||
# http://www.dslreports.com/forum/remark,9286052~mode=flat
|
||||
#
|
||||
# Note that you should NOT use a globally known CA here!
|
||||
# e.g. using a Verisign cert as a "known CA" means that
|
||||
# ANYONE who has a certificate signed by them can
|
||||
# authenticate via EAP-TLS! This is likely not what you want.
|
||||
tls-config tls-common {
|
||||
private_key_file = ${certdir}/letsencrypt/privkey.pem
|
||||
|
||||
# If Private key & Certificate are located in
|
||||
# the same file, then private_key_file &
|
||||
# certificate_file must contain the same file
|
||||
# name.
|
||||
#
|
||||
# If ca_file (below) is not used, then the
|
||||
# certificate_file below MUST include not
|
||||
# only the server certificate, but ALSO all
|
||||
# of the CA certificates used to sign the
|
||||
# server certificate.
|
||||
certificate_file = ${certdir}/letsencrypt/privkey.pem
|
||||
|
||||
# Trusted Root CA list
|
||||
#
|
||||
# ALL of the CA's in this list will be trusted
|
||||
# to issue client certificates for authentication.
|
||||
#
|
||||
# In general, you should use self-signed
|
||||
# certificates for 802.1x (EAP) authentication.
|
||||
# In that case, this CA file should contain
|
||||
# *one* CA certificate.
|
||||
#
|
||||
ca_file = ${certdir}/ca.crt
|
||||
|
||||
# OpenSSL will automatically create certificate chains,
|
||||
# unless we tell it to not do that. The problem is that
|
||||
# it sometimes gets the chains right from a certificate
|
||||
# signature view, but wrong from the clients view.
|
||||
#
|
||||
# When setting "auto_chain = no", the server certificate
|
||||
# file MUST include the full certificate chain.
|
||||
# auto_chain = yes
|
||||
|
||||
#
|
||||
# If OpenSSL supports TLS-PSK, then we can use
|
||||
# a PSK identity and (hex) password. When the
|
||||
# following two configuration items are specified,
|
||||
# then certificate-based configuration items are
|
||||
# not allowed. e.g.:
|
||||
#
|
||||
# private_key_password
|
||||
# private_key_file
|
||||
# certificate_file
|
||||
# ca_file
|
||||
# ca_path
|
||||
#
|
||||
# For now, the identity is fixed, and must be the
|
||||
# same on the client. The passphrase must be a hex
|
||||
# value, and can be up to 256 hex digits.
|
||||
#
|
||||
# Future versions of the server may be able to
|
||||
# look up the shared key (hexphrase) based on the
|
||||
# identity.
|
||||
#
|
||||
# psk_identity = "test"
|
||||
# psk_hexphrase = "036363823"
|
||||
|
||||
#
|
||||
# For DH cipher suites to work, you have to
|
||||
# run OpenSSL to create the DH file first:
|
||||
#
|
||||
# openssl dhparam -out certs/dh 2048
|
||||
#
|
||||
dh_file = ${certdir}/dh
|
||||
|
||||
#
|
||||
# If your system doesn't have /dev/urandom,
|
||||
# you will need to create this file, and
|
||||
# periodically change its contents.
|
||||
#
|
||||
# For security reasons, FreeRADIUS doesn't
|
||||
# write to files in its configuration
|
||||
# directory.
|
||||
#
|
||||
# random_file = /dev/urandom
|
||||
|
||||
#
|
||||
# This can never exceed the size of a RADIUS
|
||||
# packet (4096 bytes), and is preferably half
|
||||
# that, to accommodate other attributes in
|
||||
# RADIUS packet. On most APs the MAX packet
|
||||
# length is configured between 1500 - 1600
|
||||
# In these cases, fragment size should be
|
||||
# 1024 or less.
|
||||
#
|
||||
# fragment_size = 1024
|
||||
|
||||
# include_length is a flag which is
|
||||
# by default set to yes If set to
|
||||
# yes, Total Length of the message is
|
||||
# included in EVERY packet we send.
|
||||
# If set to no, Total Length of the
|
||||
# message is included ONLY in the
|
||||
# First packet of a fragment series.
|
||||
#
|
||||
# include_length = yes
|
||||
|
||||
|
||||
# Check the Certificate Revocation List
|
||||
#
|
||||
# 1) Copy CA certificates and CRLs to same directory.
|
||||
# 2) Execute 'c_rehash <CA certs&CRLs Directory>'.
|
||||
# 'c_rehash' is OpenSSL's command.
|
||||
# 3) uncomment the lines below.
|
||||
# 5) Restart radiusd
|
||||
# check_crl = yes
|
||||
|
||||
# Check if intermediate CAs have been revoked.
|
||||
# check_all_crl = yes
|
||||
|
||||
ca_path = ${cadir}
|
||||
|
||||
# Accept an expired Certificate Revocation List
|
||||
#
|
||||
# allow_expired_crl = no
|
||||
|
||||
#
|
||||
# If check_cert_issuer is set, the value will
|
||||
# be checked against the DN of the issuer in
|
||||
# the client certificate. If the values do not
|
||||
# match, the certificate verification will fail,
|
||||
# rejecting the user.
|
||||
#
|
||||
# This check can be done more generally by checking
|
||||
# the value of the TLS-Client-Cert-Issuer attribute.
|
||||
# This check can be done via any mechanism you
|
||||
# choose.
|
||||
#
|
||||
# check_cert_issuer = "/C=GB/ST=Berkshire/L=Newbury/O=My Company Ltd"
|
||||
|
||||
#
|
||||
# If check_cert_cn is set, the value will
|
||||
# be xlat'ed and checked against the CN
|
||||
# in the client certificate. If the values
|
||||
# do not match, the certificate verification
|
||||
# will fail rejecting the user.
|
||||
#
|
||||
# This check is done only if the previous
|
||||
# "check_cert_issuer" is not set, or if
|
||||
# the check succeeds.
|
||||
#
|
||||
# In 2.1.10 and later, this check can be done
|
||||
# more generally by checking the value of the
|
||||
# TLS-Client-Cert-CN attribute. This check
|
||||
# can be done via any mechanism you choose.
|
||||
#
|
||||
# check_cert_cn = %{User-Name}
|
||||
#
|
||||
# Set this option to specify the allowed
|
||||
# TLS cipher suites. The format is listed
|
||||
# in "man 1 ciphers".
|
||||
#
|
||||
# For EAP-FAST, use "ALL:!EXPORT:!eNULL:!SSLv2"
|
||||
#
|
||||
cipher_list = "DEFAULT"
|
||||
|
||||
# If enabled, OpenSSL will use server cipher list
|
||||
# (possibly defined by cipher_list option above)
|
||||
# for choosing right cipher suite rather than
|
||||
# using client-specified list which is OpenSSl default
|
||||
# behavior. Having it set to yes is a current best practice
|
||||
# for TLS
|
||||
cipher_server_preference = no
|
||||
|
||||
#
|
||||
# You can selectively disable TLS versions for
|
||||
# compatability with old client devices.
|
||||
#
|
||||
# If your system has OpenSSL 1.1.0 or greater, do NOT
|
||||
# use these. Instead, set tls_min_version and
|
||||
# tls_max_version.
|
||||
#
|
||||
# disable_tlsv1_2 = no
|
||||
# disable_tlsv1_1 = no
|
||||
# disable_tlsv1 = no
|
||||
|
||||
#
|
||||
# Set min / max TLS version. Mainly for Debian
|
||||
# "trusty", which disables older versions of TLS, and
|
||||
# requires the application to manually enable them.
|
||||
#
|
||||
# If you are running Debian trusty, you should set
|
||||
# these options, otherwise older clients will not be
|
||||
# able to connect.
|
||||
#
|
||||
# Allowed values are "1.0", "1.1", and "1.2".
|
||||
#
|
||||
# The values must be in quotes.
|
||||
#
|
||||
tls_min_version = "1.0"
|
||||
tls_max_version = "1.2"
|
||||
|
||||
|
||||
#
|
||||
# Elliptical cryptography configuration
|
||||
#
|
||||
# Only for OpenSSL >= 0.9.8.f
|
||||
#
|
||||
ecdh_curve = "prime256v1"
|
||||
|
||||
#
|
||||
# Session resumption / fast reauthentication
|
||||
# cache.
|
||||
#
|
||||
# The cache contains the following information:
|
||||
#
|
||||
# session Id - unique identifier, managed by SSL
|
||||
# User-Name - from the Access-Accept
|
||||
# Stripped-User-Name - from the Access-Request
|
||||
# Cached-Session-Policy - from the Access-Accept
|
||||
#
|
||||
# The "Cached-Session-Policy" is the name of a
|
||||
# policy which should be applied to the cached
|
||||
# session. This policy can be used to assign
|
||||
# VLANs, IP addresses, etc. It serves as a useful
|
||||
# way to re-apply the policy from the original
|
||||
# Access-Accept to the subsequent Access-Accept
|
||||
# for the cached session.
|
||||
#
|
||||
# On session resumption, these attributes are
|
||||
# copied from the cache, and placed into the
|
||||
# reply list.
|
||||
#
|
||||
# You probably also want "use_tunneled_reply = yes"
|
||||
# when using fast session resumption.
|
||||
#
|
||||
cache {
|
||||
#
|
||||
# Enable it. The default is "no". Deleting the entire "cache"
|
||||
# subsection also disables caching.
|
||||
#
|
||||
# As of version 3.0.14, the session cache requires the use
|
||||
# of the "name" and "persist_dir" configuration items, below.
|
||||
#
|
||||
# The internal OpenSSL session cache has been permanently
|
||||
# disabled.
|
||||
#
|
||||
# You can disallow resumption for a particular user by adding the
|
||||
# following attribute to the control item list:
|
||||
#
|
||||
# Allow-Session-Resumption = No
|
||||
#
|
||||
# If "enable = no" below, you CANNOT enable resumption for just one
|
||||
# user by setting the above attribute to "yes".
|
||||
#
|
||||
enable = no
|
||||
|
||||
#
|
||||
# Lifetime of the cached entries, in hours. The sessions will be
|
||||
# deleted/invalidated after this time.
|
||||
#
|
||||
lifetime = 1 # hours
|
||||
|
||||
#
|
||||
# Internal "name" of the session cache. Used to
|
||||
# distinguish which TLS context sessions belong to.
|
||||
#
|
||||
# The server will generate a random value if unset.
|
||||
# This will change across server restart so you MUST
|
||||
# set the "name" if you want to persist sessions (see
|
||||
# below).
|
||||
#
|
||||
#name = "EAP module"
|
||||
|
||||
#
|
||||
# Simple directory-based storage of sessions.
|
||||
# Two files per session will be written, the SSL
|
||||
# state and the cached VPs. This will persist session
|
||||
# across server restarts.
|
||||
#
|
||||
# The default directory is ${logdir}, for historical
|
||||
# reasons. You should ${db_dir} instead. And check
|
||||
# the value of db_dir in the main radiusd.conf file.
|
||||
# It should not point to ${raddb}
|
||||
#
|
||||
# The server will need write perms, and the directory
|
||||
# should be secured from anyone else. You might want
|
||||
# a script to remove old files from here periodically:
|
||||
#
|
||||
# find ${logdir}/tlscache -mtime +2 -exec rm -f {} \;
|
||||
#
|
||||
# This feature REQUIRES "name" option be set above.
|
||||
#
|
||||
#persist_dir = "${logdir}/tlscache"
|
||||
}
|
||||
|
||||
#
|
||||
# As of version 2.1.10, client certificates can be
|
||||
# validated via an external command. This allows
|
||||
# dynamic CRLs or OCSP to be used.
|
||||
#
|
||||
# This configuration is commented out in the
|
||||
# default configuration. Uncomment it, and configure
|
||||
# the correct paths below to enable it.
|
||||
#
|
||||
# If OCSP checking is enabled, and the OCSP checks fail,
|
||||
# the verify section is not run.
|
||||
#
|
||||
# If OCSP checking is disabled, the verify section is
|
||||
# run on successful certificate validation.
|
||||
#
|
||||
verify {
|
||||
# If the OCSP checks succeed, the verify section
|
||||
# is run to allow additional checks.
|
||||
#
|
||||
# If you want to skip verify on OCSP success,
|
||||
# uncomment this configuration item, and set it
|
||||
# to "yes".
|
||||
# skip_if_ocsp_ok = no
|
||||
|
||||
# A temporary directory where the client
|
||||
# certificates are stored. This directory
|
||||
# MUST be owned by the UID of the server,
|
||||
# and MUST not be accessible by any other
|
||||
# users. When the server starts, it will do
|
||||
# "chmod go-rwx" on the directory, for
|
||||
# security reasons. The directory MUST
|
||||
# exist when the server starts.
|
||||
#
|
||||
# You should also delete all of the files
|
||||
# in the directory when the server starts.
|
||||
# tmpdir = /tmp/radiusd
|
||||
|
||||
# The command used to verify the client cert.
|
||||
# We recommend using the OpenSSL command-line
|
||||
# tool.
|
||||
#
|
||||
# The ${..ca_path} text is a reference to
|
||||
# the ca_path variable defined above.
|
||||
#
|
||||
# The %{TLS-Client-Cert-Filename} is the name
|
||||
# of the temporary file containing the cert
|
||||
# in PEM format. This file is automatically
|
||||
# deleted by the server when the command
|
||||
# returns.
|
||||
# client = "/path/to/openssl verify -CApath ${..ca_path} %{TLS-Client-Cert-Filename}"
|
||||
}
|
||||
|
||||
#
|
||||
# OCSP Configuration
|
||||
# Certificates can be verified against an OCSP
|
||||
# Responder. This makes it possible to immediately
|
||||
# revoke certificates without the distribution of
|
||||
# new Certificate Revocation Lists (CRLs).
|
||||
#
|
||||
ocsp {
|
||||
#
|
||||
# Enable it. The default is "no".
|
||||
# Deleting the entire "ocsp" subsection
|
||||
# also disables ocsp checking
|
||||
#
|
||||
enable = no
|
||||
|
||||
#
|
||||
# The OCSP Responder URL can be automatically
|
||||
# extracted from the certificate in question.
|
||||
# To override the OCSP Responder URL set
|
||||
# "override_cert_url = yes".
|
||||
#
|
||||
override_cert_url = yes
|
||||
|
||||
#
|
||||
# If the OCSP Responder address is not extracted from
|
||||
# the certificate, the URL can be defined here.
|
||||
#
|
||||
url = "http://127.0.0.1/ocsp/"
|
||||
|
||||
#
|
||||
# If the OCSP Responder can not cope with nonce
|
||||
# in the request, then it can be disabled here.
|
||||
#
|
||||
# For security reasons, disabling this option
|
||||
# is not recommended as nonce protects against
|
||||
# replay attacks.
|
||||
#
|
||||
# Note that Microsoft AD Certificate Services OCSP
|
||||
# Responder does not enable nonce by default. It is
|
||||
# more secure to enable nonce on the responder than
|
||||
# to disable it in the query here.
|
||||
# See http://technet.microsoft.com/en-us/library/cc770413%28WS.10%29.aspx
|
||||
#
|
||||
# use_nonce = yes
|
||||
|
||||
#
|
||||
# Number of seconds before giving up waiting
|
||||
# for OCSP response. 0 uses system default.
|
||||
#
|
||||
# timeout = 0
|
||||
|
||||
#
|
||||
# Normally an error in querying the OCSP
|
||||
# responder (no response from server, server did
|
||||
# not understand the request, etc) will result in
|
||||
# a validation failure.
|
||||
#
|
||||
# To treat these errors as 'soft' failures and
|
||||
# still accept the certificate, enable this
|
||||
# option.
|
||||
#
|
||||
# Warning: this may enable clients with revoked
|
||||
# certificates to connect if the OCSP responder
|
||||
# is not available. Use with caution.
|
||||
#
|
||||
# softfail = no
|
||||
}
|
||||
}
|
||||
|
||||
## EAP-TLS
|
||||
#
|
||||
# As of Version 3.0, the TLS configuration for TLS-based
|
||||
# EAP types is above in the "tls-config" section.
|
||||
#
|
||||
tls {
|
||||
# Point to the common TLS configuration
|
||||
tls = tls-common
|
||||
|
||||
#
|
||||
# As part of checking a client certificate, the EAP-TLS
|
||||
# sets some attributes such as TLS-Client-Cert-CN. This
|
||||
# virtual server has access to these attributes, and can
|
||||
# be used to accept or reject the request.
|
||||
#
|
||||
# virtual_server = check-eap-tls
|
||||
}
|
||||
|
||||
|
||||
## EAP-TTLS
|
||||
#
|
||||
# The TTLS module implements the EAP-TTLS protocol,
|
||||
# which can be described as EAP inside of Diameter,
|
||||
# inside of TLS, inside of EAP, inside of RADIUS...
|
||||
#
|
||||
# Surprisingly, it works quite well.
|
||||
#
|
||||
ttls {
|
||||
# Which tls-config section the TLS negotiation parameters
|
||||
# are in - see EAP-TLS above for an explanation.
|
||||
#
|
||||
# In the case that an old configuration from FreeRADIUS
|
||||
# v2.x is being used, all the options of the tls-config
|
||||
# section may also appear instead in the 'tls' section
|
||||
# above. If that is done, the tls= option here (and in
|
||||
# tls above) MUST be commented out.
|
||||
#
|
||||
tls = tls-common
|
||||
|
||||
# The tunneled EAP session needs a default EAP type
|
||||
# which is separate from the one for the non-tunneled
|
||||
# EAP module. Inside of the TTLS tunnel, we recommend
|
||||
# using EAP-MD5. If the request does not contain an
|
||||
# EAP conversation, then this configuration entry is
|
||||
# ignored.
|
||||
#
|
||||
default_eap_type = md5
|
||||
|
||||
# The tunneled authentication request does not usually
|
||||
# contain useful attributes like 'Calling-Station-Id',
|
||||
# etc. These attributes are outside of the tunnel,
|
||||
# and normally unavailable to the tunneled
|
||||
# authentication request.
|
||||
#
|
||||
# By setting this configuration entry to 'yes',
|
||||
# any attribute which is NOT in the tunneled
|
||||
# authentication request, but which IS available
|
||||
# outside of the tunnel, is copied to the tunneled
|
||||
# request.
|
||||
#
|
||||
# allowed values: {no, yes}
|
||||
#
|
||||
copy_request_to_tunnel = yes
|
||||
|
||||
#
|
||||
# As of version 3.0.5, this configuration item
|
||||
# is deprecated. Instead, you should use
|
||||
#
|
||||
# update outer.session-state {
|
||||
# ...
|
||||
#
|
||||
# }
|
||||
#
|
||||
# This will cache attributes for the final Access-Accept.
|
||||
#
|
||||
# The reply attributes sent to the NAS are usually
|
||||
# based on the name of the user 'outside' of the
|
||||
# tunnel (usually 'anonymous'). If you want to send
|
||||
# the reply attributes based on the user name inside
|
||||
# of the tunnel, then set this configuration entry to
|
||||
# 'yes', and the reply to the NAS will be taken from
|
||||
# the reply to the tunneled request.
|
||||
#
|
||||
# allowed values: {no, yes}
|
||||
#
|
||||
use_tunneled_reply = no
|
||||
|
||||
#
|
||||
# The inner tunneled request can be sent
|
||||
# through a virtual server constructed
|
||||
# specifically for this purpose.
|
||||
#
|
||||
# If this entry is commented out, the inner
|
||||
# tunneled request will be sent through
|
||||
# the virtual server that processed the
|
||||
# outer requests.
|
||||
#
|
||||
virtual_server = "inner-tunnel"
|
||||
|
||||
# This has the same meaning, and overwrites, the
|
||||
# same field in the "tls" configuration, above.
|
||||
# The default value here is "yes".
|
||||
#
|
||||
# include_length = yes
|
||||
|
||||
#
|
||||
# Unlike EAP-TLS, EAP-TTLS does not require a client
|
||||
# certificate. However, you can require one by setting the
|
||||
# following option. You can also override this option by
|
||||
# setting
|
||||
#
|
||||
# EAP-TLS-Require-Client-Cert = Yes
|
||||
#
|
||||
# in the control items for a request.
|
||||
#
|
||||
# Note that the majority of supplicants do not support using a
|
||||
# client certificate with EAP-TTLS, so this option is unlikely
|
||||
# to be usable for most people.
|
||||
#
|
||||
# require_client_cert = yes
|
||||
}
|
||||
|
||||
|
||||
## EAP-PEAP
|
||||
#
|
||||
|
||||
##################################################
|
||||
#
|
||||
# !!!!! WARNINGS for Windows compatibility !!!!!
|
||||
#
|
||||
##################################################
|
||||
#
|
||||
# If you see the server send an Access-Challenge,
|
||||
# and the client never sends another Access-Request,
|
||||
# then
|
||||
#
|
||||
# STOP!
|
||||
#
|
||||
# The server certificate has to have special OID's
|
||||
# in it, or else the Microsoft clients will silently
|
||||
# fail. See the "scripts/xpextensions" file for
|
||||
# details, and the following page:
|
||||
#
|
||||
# http://support.microsoft.com/kb/814394/en-us
|
||||
#
|
||||
# For additional Windows XP SP2 issues, see:
|
||||
#
|
||||
# http://support.microsoft.com/kb/885453/en-us
|
||||
#
|
||||
#
|
||||
# If is still doesn't work, and you're using Samba,
|
||||
# you may be encountering a Samba bug. See:
|
||||
#
|
||||
# https://bugzilla.samba.org/show_bug.cgi?id=6563
|
||||
#
|
||||
# Note that we do not necessarily agree with their
|
||||
# explanation... but the fix does appear to work.
|
||||
#
|
||||
##################################################
|
||||
|
||||
#
|
||||
# The tunneled EAP session needs a default EAP type
|
||||
# which is separate from the one for the non-tunneled
|
||||
# EAP module. Inside of the TLS/PEAP tunnel, we
|
||||
# recommend using EAP-MS-CHAPv2.
|
||||
#
|
||||
peap {
|
||||
# Which tls-config section the TLS negotiation parameters
|
||||
# are in - see EAP-TLS above for an explanation.
|
||||
#
|
||||
# In the case that an old configuration from FreeRADIUS
|
||||
# v2.x is being used, all the options of the tls-config
|
||||
# section may also appear instead in the 'tls' section
|
||||
# above. If that is done, the tls= option here (and in
|
||||
# tls above) MUST be commented out.
|
||||
#
|
||||
tls = tls-common
|
||||
|
||||
# The tunneled EAP session needs a default
|
||||
# EAP type which is separate from the one for
|
||||
# the non-tunneled EAP module. Inside of the
|
||||
# PEAP tunnel, we recommend using MS-CHAPv2,
|
||||
# as that is the default type supported by
|
||||
# Windows clients.
|
||||
#
|
||||
default_eap_type = mschapv2
|
||||
|
||||
# The PEAP module also has these configuration
|
||||
# items, which are the same as for TTLS.
|
||||
#
|
||||
copy_request_to_tunnel = yes
|
||||
|
||||
#
|
||||
# As of version 3.0.5, this configuration item
|
||||
# is deprecated. Instead, you should use
|
||||
#
|
||||
# update outer.session-state {
|
||||
# ...
|
||||
#
|
||||
# }
|
||||
#
|
||||
# This will cache attributes for the final Access-Accept.
|
||||
#
|
||||
use_tunneled_reply = no
|
||||
|
||||
# When the tunneled session is proxied, the
|
||||
# home server may not understand EAP-MSCHAP-V2.
|
||||
# Set this entry to "no" to proxy the tunneled
|
||||
# EAP-MSCHAP-V2 as normal MSCHAPv2.
|
||||
#
|
||||
# proxy_tunneled_request_as_eap = yes
|
||||
|
||||
#
|
||||
# The inner tunneled request can be sent
|
||||
# through a virtual server constructed
|
||||
# specifically for this purpose.
|
||||
#
|
||||
# If this entry is commented out, the inner
|
||||
# tunneled request will be sent through
|
||||
# the virtual server that processed the
|
||||
# outer requests.
|
||||
#
|
||||
virtual_server = "inner-tunnel"
|
||||
|
||||
# This option enables support for MS-SoH
|
||||
# see doc/SoH.txt for more info.
|
||||
# It is disabled by default.
|
||||
#
|
||||
# soh = yes
|
||||
|
||||
#
|
||||
# The SoH reply will be turned into a request which
|
||||
# can be sent to a specific virtual server:
|
||||
#
|
||||
# soh_virtual_server = "soh-server"
|
||||
|
||||
#
|
||||
# Unlike EAP-TLS, PEAP does not require a client certificate.
|
||||
# However, you can require one by setting the following
|
||||
# option. You can also override this option by setting
|
||||
#
|
||||
# EAP-TLS-Require-Client-Cert = Yes
|
||||
#
|
||||
# in the control items for a request.
|
||||
#
|
||||
# Note that the majority of supplicants do not support using a
|
||||
# client certificate with PEAP, so this option is unlikely to
|
||||
# be usable for most people.
|
||||
#
|
||||
# require_client_cert = yes
|
||||
}
|
||||
|
||||
#
|
||||
# This takes no configuration.
|
||||
#
|
||||
# Note that it is the EAP MS-CHAPv2 sub-module, not
|
||||
# the main 'mschap' module.
|
||||
#
|
||||
# Note also that in order for this sub-module to work,
|
||||
# the main 'mschap' module MUST ALSO be configured.
|
||||
#
|
||||
# This module is the *Microsoft* implementation of MS-CHAPv2
|
||||
# in EAP. There is another (incompatible) implementation
|
||||
# of MS-CHAPv2 in EAP by Cisco, which FreeRADIUS does not
|
||||
# currently support.
|
||||
#
|
||||
mschapv2 {
|
||||
# Prior to version 2.1.11, the module never
|
||||
# sent the MS-CHAP-Error message to the
|
||||
# client. This worked, but it had issues
|
||||
# when the cached password was wrong. The
|
||||
# server *should* send "E=691 R=0" to the
|
||||
# client, which tells it to prompt the user
|
||||
# for a new password.
|
||||
#
|
||||
# The default is to behave as in 2.1.10 and
|
||||
# earlier, which is known to work. If you
|
||||
# set "send_error = yes", then the error
|
||||
# message will be sent back to the client.
|
||||
# This *may* help some clients work better,
|
||||
# but *may* also cause other clients to stop
|
||||
# working.
|
||||
#
|
||||
send_error = yes
|
||||
|
||||
# Server identifier to send back in the challenge.
|
||||
# This should generally be the host name of the
|
||||
# RADIUS server. Or, some information to uniquely
|
||||
# identify it.
|
||||
# identity = "FreeRADIUS"
|
||||
}
|
||||
|
||||
## EAP-FAST
|
||||
#
|
||||
# The FAST module implements the EAP-FAST protocol
|
||||
#
|
||||
# fast {
|
||||
# Point to the common TLS configuration
|
||||
#
|
||||
# tls = tls-common
|
||||
|
||||
#
|
||||
# If 'cipher_list' is set here, it will over-ride the
|
||||
# 'cipher_list' configuration from the 'tls-common'
|
||||
# configuration. The EAP-FAST module has it's own
|
||||
# over-ride for 'cipher_list' because the
|
||||
# specifications mandata a different set of ciphers
|
||||
# than are used by the other EAP methods.
|
||||
#
|
||||
# cipher_list though must include "ADH" for anonymous provisioning.
|
||||
# This is not as straight forward as appending "ADH" alongside
|
||||
# "DEFAULT" as "DEFAULT" contains "!aNULL" so instead it is
|
||||
# recommended "ALL:!EXPORT:!eNULL:!SSLv2" is used
|
||||
#
|
||||
# Note - for OpenSSL 1.1.0 and above you may need
|
||||
# to add ":@SECLEVEL=0"
|
||||
#
|
||||
# cipher_list = "ALL:!EXPORT:!eNULL:!SSLv2"
|
||||
|
||||
# PAC lifetime in seconds (default: seven days)
|
||||
#
|
||||
# pac_lifetime = 604800
|
||||
|
||||
# Authority ID of the server
|
||||
#
|
||||
# if you are running a cluster of RADIUS servers, you should make
|
||||
# the value chosen here (and for "pac_opaque_key") the same on all
|
||||
# your RADIUS servers. This value should be unique to your
|
||||
# installation. We suggest using a domain name.
|
||||
#
|
||||
# authority_identity = "1234"
|
||||
|
||||
# PAC Opaque encryption key (must be exactly 32 bytes in size)
|
||||
#
|
||||
# This value MUST be secret, and MUST be generated using
|
||||
# a secure method, such as via 'openssl rand -hex 32'
|
||||
#
|
||||
# pac_opaque_key = "0123456789abcdef0123456789ABCDEF"
|
||||
|
||||
# Same as for TTLS, PEAP, etc.
|
||||
#
|
||||
# virtual_server = inner-tunnel
|
||||
# }
|
||||
}
|
||||
|
|
@ -0,0 +1,67 @@
|
|||
{{ ansible_header | comment }}
|
||||
|
||||
#
|
||||
# Make sure the PYTHONPATH environmental variable contains the
|
||||
# directory(s) for the modules listed below.
|
||||
#
|
||||
# Uncomment any func_* which are included in your module. If
|
||||
# rlm_python is called for a section which does not have
|
||||
# a function defined, it will return NOOP.
|
||||
#
|
||||
python3 re2o {
|
||||
|
||||
# Path to the python modules
|
||||
#
|
||||
# Note that due to limitations on Python, this configuration
|
||||
# item is GLOBAL TO THE SERVER. That is, you cannot have two
|
||||
# instances of the python module, each with a different path.
|
||||
#
|
||||
python_path = /etc/freeradius/3.0:/usr/lib/python3.7:/usr/lib/python3.7/dist-packages:/usr/local/lib/python3.7/site-packages:/usr/lib/python3.7/lib-dynload:/usr/local/lib/python3.7/dist-packages
|
||||
|
||||
module = auth
|
||||
|
||||
|
||||
# Pass all VPS lists as a 6-tuple to the callbacks
|
||||
# (request, reply, config, state, proxy_req, proxy_reply)
|
||||
# pass_all_vps = no
|
||||
|
||||
# Pass all VPS lists as a dictionary to the callbacks
|
||||
# Keys: "request", "reply", "config", "session-state", "proxy-request",
|
||||
# "proxy-reply"
|
||||
# This option prevales over "pass_all_vps"
|
||||
# pass_all_vps_dict = no
|
||||
|
||||
|
||||
mod_instantiate = ${.module}
|
||||
func_instantiate = instantiate
|
||||
|
||||
mod_detach = ${.module}
|
||||
func_detach = detach
|
||||
|
||||
mod_authorize = ${.module}
|
||||
func_authorize = authorize
|
||||
|
||||
mod_preacct = ${.module}
|
||||
func_preacct = dummy_fun
|
||||
|
||||
mod_accounting = ${.module}
|
||||
func_accounting = dummy_fun
|
||||
|
||||
mod_checksimul = ${.module}
|
||||
func_checksimul = dummy_fun
|
||||
|
||||
mod_pre_proxy = ${.module}
|
||||
func_pre_proxy = dummy_fun
|
||||
|
||||
mod_post_proxy = ${.module}
|
||||
func_post_proxy = dummy_fun
|
||||
|
||||
mod_post_auth = ${.module}
|
||||
func_post_auth = post_auth
|
||||
|
||||
mod_recv_coa = ${.module}
|
||||
func_recv_coa = dummy_fun
|
||||
|
||||
mod_send_coa = ${.module}
|
||||
func_send_coa = dummy_fun
|
||||
}
|
||||
|
|
@ -0,0 +1,896 @@
|
|||
{{ ansible_header | comment }}
|
||||
|
||||
# -*- text -*-
|
||||
##
|
||||
## radiusd.conf -- FreeRADIUS server configuration file - 3.0.21
|
||||
##
|
||||
## http://www.freeradius.org/
|
||||
## $Id: e8aee3c00193127177cd65e31156c1d0f4b124d3 $
|
||||
##
|
||||
|
||||
######################################################################
|
||||
#
|
||||
# The format of this (and other) configuration file is
|
||||
# documented in "man unlang". There are also READMEs in many
|
||||
# subdirectories:
|
||||
#
|
||||
# raddb/README.rst
|
||||
# How to upgrade from v2.
|
||||
#
|
||||
# raddb/mods-available/README.rst
|
||||
# How to use mods-available / mods-enabled.
|
||||
# All of the modules are in individual files,
|
||||
# along with configuration items and full documentation.
|
||||
#
|
||||
# raddb/sites-available/README
|
||||
# virtual servers, "listen" sections, clients, etc.
|
||||
# The "sites-available" directory contains many
|
||||
# worked examples of common configurations.
|
||||
#
|
||||
# raddb/certs/README
|
||||
# How to create certificates for EAP or RadSec.
|
||||
#
|
||||
# Every configuration item in the server is documented
|
||||
# extensively in the comments in the example configuration
|
||||
# files.
|
||||
#
|
||||
# Before editing this (or any other) configuration file, PLEASE
|
||||
# read "man radiusd". See the section titled DEBUGGING. It
|
||||
# outlines a method where you can quickly create the
|
||||
# configuration you want, with minimal effort.
|
||||
#
|
||||
# Run the server in debugging mode, and READ the output.
|
||||
#
|
||||
# $ radiusd -X
|
||||
#
|
||||
# We cannot emphasize this point strongly enough. The vast
|
||||
# majority of problems can be solved by carefully reading the
|
||||
# debugging output, which includes warnings about common issues,
|
||||
# and suggestions for how they may be fixed.
|
||||
#
|
||||
# There may be a lot of output, but look carefully for words like:
|
||||
# "warning", "error", "reject", or "failure". The messages there
|
||||
# will usually be enough to guide you to a solution.
|
||||
#
|
||||
# More documentation on "radiusd -X" is available on the wiki:
|
||||
# https://wiki.freeradius.org/radiusd-X
|
||||
#
|
||||
# If you are going to ask a question on the mailing list, then
|
||||
# explain what you are trying to do, and include the output from
|
||||
# debugging mode (radiusd -X). Failure to do so means that all
|
||||
# of the responses to your question will be people telling you
|
||||
# to "post the output of radiusd -X".
|
||||
#
|
||||
# Guidelines for posting to the mailing list are on the wiki:
|
||||
# https://wiki.freeradius.org/list-help
|
||||
#
|
||||
# Please read those guidelines before posting to the list.
|
||||
#
|
||||
# Further documentation is available in the "doc" directory
|
||||
# of the server distribution, or on the wiki at:
|
||||
# https://wiki.freeradius.org/
|
||||
#
|
||||
# New users to RADIUS should read the Technical Guide. That guide
|
||||
# explains how RADIUS works, how FreeRADIUS works, and what each
|
||||
# part of a RADIUS system does. It is not just "configure FreeRADIUS"!
|
||||
# https://networkradius.com/doc/FreeRADIUS-Technical-Guide.pdf
|
||||
#
|
||||
# More documentation on dictionaries, modules, unlang, etc. is also
|
||||
# available on the Network RADIUS web site:
|
||||
# https://networkradius.com/freeradius-documentation/
|
||||
#
|
||||
|
||||
######################################################################
|
||||
|
||||
prefix = /usr
|
||||
exec_prefix = /usr
|
||||
sysconfdir = /etc
|
||||
localstatedir = /var
|
||||
sbindir = ${exec_prefix}/sbin
|
||||
logdir = /var/log/freeradius
|
||||
raddbdir = /etc/freeradius/3.0
|
||||
radacctdir = ${logdir}/radacct
|
||||
|
||||
#
|
||||
# name of the running server. See also the "-n" command-line option.
|
||||
name = freeradius
|
||||
|
||||
# Location of config and logfiles.
|
||||
confdir = ${raddbdir}
|
||||
modconfdir = ${confdir}/mods-config
|
||||
certdir = ${confdir}/certs
|
||||
cadir = ${confdir}/certs
|
||||
run_dir = ${localstatedir}/run/${name}
|
||||
|
||||
# Should likely be ${localstatedir}/lib/radiusd
|
||||
db_dir = ${raddbdir}
|
||||
|
||||
#
|
||||
# libdir: Where to find the rlm_* modules.
|
||||
#
|
||||
# This should be automatically set at configuration time.
|
||||
#
|
||||
# If the server builds and installs, but fails at execution time
|
||||
# with an 'undefined symbol' error, then you can use the libdir
|
||||
# directive to work around the problem.
|
||||
#
|
||||
# The cause is usually that a library has been installed on your
|
||||
# system in a place where the dynamic linker CANNOT find it. When
|
||||
# executing as root (or another user), your personal environment MAY
|
||||
# be set up to allow the dynamic linker to find the library. When
|
||||
# executing as a daemon, FreeRADIUS MAY NOT have the same
|
||||
# personalized configuration.
|
||||
#
|
||||
# To work around the problem, find out which library contains that symbol,
|
||||
# and add the directory containing that library to the end of 'libdir',
|
||||
# with a colon separating the directory names. NO spaces are allowed.
|
||||
#
|
||||
# e.g. libdir = /usr/local/lib:/opt/package/lib
|
||||
#
|
||||
# You can also try setting the LD_LIBRARY_PATH environment variable
|
||||
# in a script which starts the server.
|
||||
#
|
||||
# If that does not work, then you can re-configure and re-build the
|
||||
# server to NOT use shared libraries, via:
|
||||
#
|
||||
# ./configure --disable-shared
|
||||
# make
|
||||
# make install
|
||||
#
|
||||
libdir = /usr/lib/freeradius
|
||||
|
||||
# pidfile: Where to place the PID of the RADIUS server.
|
||||
#
|
||||
# The server may be signalled while it's running by using this
|
||||
# file.
|
||||
#
|
||||
# This file is written when ONLY running in daemon mode.
|
||||
#
|
||||
# e.g.: kill -HUP `cat /var/run/radiusd/radiusd.pid`
|
||||
#
|
||||
pidfile = ${run_dir}/${name}.pid
|
||||
|
||||
#
|
||||
# correct_escapes: use correct backslash escaping
|
||||
#
|
||||
# Prior to version 3.0.5, the handling of backslashes was a little
|
||||
# awkward, i.e. "wrong". In some cases, to get one backslash into
|
||||
# a regex, you had to put 4 in the config files.
|
||||
#
|
||||
# Version 3.0.5 fixes that. However, for backwards compatibility,
|
||||
# the new method of escaping is DISABLED BY DEFAULT. This means
|
||||
# that upgrading to 3.0.5 won't break your configuration.
|
||||
#
|
||||
# If you don't have double backslashes (i.e. \\) in your configuration,
|
||||
# this won't matter to you. If you do have them, fix that to use only
|
||||
# one backslash, and then set "correct_escapes = true".
|
||||
#
|
||||
# You can check for this by doing:
|
||||
#
|
||||
# $ grep '\\\\' $(find raddb -type f -print)
|
||||
#
|
||||
correct_escapes = true
|
||||
|
||||
# panic_action: Command to execute if the server dies unexpectedly.
|
||||
#
|
||||
# FOR PRODUCTION SYSTEMS, ACTIONS SHOULD ALWAYS EXIT.
|
||||
# AN INTERACTIVE ACTION MEANS THE SERVER IS NOT RESPONDING TO REQUESTS.
|
||||
# AN INTERACTICE ACTION MEANS THE SERVER WILL NOT RESTART.
|
||||
#
|
||||
# THE SERVER MUST NOT BE ALLOWED EXECUTE UNTRUSTED PANIC ACTION CODE
|
||||
# PATTACH CAN BE USED AS AN ATTACK VECTOR.
|
||||
#
|
||||
# The panic action is a command which will be executed if the server
|
||||
# receives a fatal, non user generated signal, i.e. SIGSEGV, SIGBUS,
|
||||
# SIGABRT or SIGFPE.
|
||||
#
|
||||
# This can be used to start an interactive debugging session so
|
||||
# that information regarding the current state of the server can
|
||||
# be acquired.
|
||||
#
|
||||
# The following string substitutions are available:
|
||||
# - %e The currently executing program e.g. /sbin/radiusd
|
||||
# - %p The PID of the currently executing program e.g. 12345
|
||||
#
|
||||
# Standard ${} substitutions are also allowed.
|
||||
#
|
||||
# An example panic action for opening an interactive session in GDB would be:
|
||||
#
|
||||
#panic_action = "gdb %e %p"
|
||||
#
|
||||
# Again, don't use that on a production system.
|
||||
#
|
||||
# An example panic action for opening an automated session in GDB would be:
|
||||
#
|
||||
#panic_action = "gdb -silent -x ${raddbdir}/panic.gdb %e %p 2>&1 | tee ${logdir}/gdb-${name}-%p.log"
|
||||
#
|
||||
# That command can be used on a production system.
|
||||
#
|
||||
|
||||
# max_request_time: The maximum time (in seconds) to handle a request.
|
||||
#
|
||||
# Requests which take more time than this to process may be killed, and
|
||||
# a REJECT message is returned.
|
||||
#
|
||||
# WARNING: If you notice that requests take a long time to be handled,
|
||||
# then this MAY INDICATE a bug in the server, in one of the modules
|
||||
# used to handle a request, OR in your local configuration.
|
||||
#
|
||||
# This problem is most often seen when using an SQL database. If it takes
|
||||
# more than a second or two to receive an answer from the SQL database,
|
||||
# then it probably means that you haven't indexed the database. See your
|
||||
# SQL server documentation for more information.
|
||||
#
|
||||
# Useful range of values: 5 to 120
|
||||
#
|
||||
max_request_time = 30
|
||||
|
||||
# cleanup_delay: The time to wait (in seconds) before cleaning up
|
||||
# a reply which was sent to the NAS.
|
||||
#
|
||||
# The RADIUS request is normally cached internally for a short period
|
||||
# of time, after the reply is sent to the NAS. The reply packet may be
|
||||
# lost in the network, and the NAS will not see it. The NAS will then
|
||||
# re-send the request, and the server will respond quickly with the
|
||||
# cached reply.
|
||||
#
|
||||
# If this value is set too low, then duplicate requests from the NAS
|
||||
# MAY NOT be detected, and will instead be handled as separate requests.
|
||||
#
|
||||
# If this value is set too high, then the server will cache too many
|
||||
# requests, and some new requests may get blocked. (See 'max_requests'.)
|
||||
#
|
||||
# Useful range of values: 2 to 30
|
||||
#
|
||||
cleanup_delay = 5
|
||||
|
||||
# max_requests: The maximum number of requests which the server keeps
|
||||
# track of. This should be 256 multiplied by the number of clients.
|
||||
# e.g. With 4 clients, this number should be 1024.
|
||||
#
|
||||
# If this number is too low, then when the server becomes busy,
|
||||
# it will not respond to any new requests, until the 'cleanup_delay'
|
||||
# time has passed, and it has removed the old requests.
|
||||
#
|
||||
# If this number is set too high, then the server will use a bit more
|
||||
# memory for no real benefit.
|
||||
#
|
||||
# If you aren't sure what it should be set to, it's better to set it
|
||||
# too high than too low. Setting it to 1000 per client is probably
|
||||
# the highest it should be.
|
||||
#
|
||||
# Useful range of values: 256 to infinity
|
||||
#
|
||||
max_requests = 16384
|
||||
|
||||
# hostname_lookups: Log the names of clients or just their IP addresses
|
||||
# e.g., www.freeradius.org (on) or 206.47.27.232 (off).
|
||||
#
|
||||
# The default is 'off' because it would be overall better for the net
|
||||
# if people had to knowingly turn this feature on, since enabling it
|
||||
# means that each client request will result in AT LEAST one lookup
|
||||
# request to the nameserver. Enabling hostname_lookups will also
|
||||
# mean that your server may stop randomly for 30 seconds from time
|
||||
# to time, if the DNS requests take too long.
|
||||
#
|
||||
# Turning hostname lookups off also means that the server won't block
|
||||
# for 30 seconds, if it sees an IP address which has no name associated
|
||||
# with it.
|
||||
#
|
||||
# allowed values: {no, yes}
|
||||
#
|
||||
hostname_lookups = no
|
||||
|
||||
#
|
||||
# Logging section. The various "log_*" configuration items
|
||||
# will eventually be moved here.
|
||||
#
|
||||
log {
|
||||
#
|
||||
# Destination for log messages. This can be one of:
|
||||
#
|
||||
# files - log to "file", as defined below.
|
||||
# syslog - to syslog (see also the "syslog_facility", below.
|
||||
# stdout - standard output
|
||||
# stderr - standard error.
|
||||
#
|
||||
# The command-line option "-X" over-rides this option, and forces
|
||||
# logging to go to stdout.
|
||||
#
|
||||
destination = syslog
|
||||
|
||||
#
|
||||
# Highlight important messages sent to stderr and stdout.
|
||||
#
|
||||
# Option will be ignored (disabled) if output if TERM is not
|
||||
# an xterm or output is not to a TTY.
|
||||
#
|
||||
colourise = yes
|
||||
|
||||
#
|
||||
# The logging messages for the server are appended to the
|
||||
# tail of this file if destination == "files"
|
||||
#
|
||||
# If the server is running in debugging mode, this file is
|
||||
# NOT used.
|
||||
#
|
||||
file = ${logdir}/radius.log
|
||||
|
||||
#
|
||||
# Which syslog facility to use, if ${destination} == "syslog"
|
||||
#
|
||||
# The exact values permitted here are OS-dependent. You probably
|
||||
# don't want to change this.
|
||||
#
|
||||
syslog_facility = daemon
|
||||
|
||||
# Log the full User-Name attribute, as it was found in the request.
|
||||
#
|
||||
# allowed values: {no, yes}
|
||||
#
|
||||
stripped_names = no
|
||||
|
||||
# Log all (accept and reject) authentication results to the log file.
|
||||
#
|
||||
# This is the same as setting "auth_accept = yes" and
|
||||
# "auth_reject = yes"
|
||||
#
|
||||
# allowed values: {no, yes}
|
||||
#
|
||||
auth = yes
|
||||
|
||||
# Log Access-Accept results to the log file.
|
||||
#
|
||||
# This is only used if "auth = no"
|
||||
#
|
||||
# allowed values: {no, yes}
|
||||
#
|
||||
# auth_accept = no
|
||||
|
||||
# Log Access-Reject results to the log file.
|
||||
#
|
||||
# This is only used if "auth = no"
|
||||
#
|
||||
# allowed values: {no, yes}
|
||||
#
|
||||
# auth_reject = no
|
||||
|
||||
# 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.
|
||||
#
|
||||
msg_goodpass = "IP du Nas: %{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}"
|
||||
msg_badpass = "IP du Nas: %{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}"
|
||||
|
||||
# The message when the user exceeds the Simultaneous-Use limit.
|
||||
#
|
||||
msg_denied = "You are already logged in - access denied"
|
||||
}
|
||||
|
||||
# The program to execute to do concurrency checks.
|
||||
checkrad = ${sbindir}/checkrad
|
||||
|
||||
#
|
||||
# ENVIRONMENT VARIABLES
|
||||
#
|
||||
# You can reference environment variables using an expansion like
|
||||
# `$ENV{PATH}`. However it is sometimes useful to be able to also set
|
||||
# environment variables. This section lets you do that.
|
||||
#
|
||||
# The main purpose of this section is to allow administrators to keep
|
||||
# RADIUS-specific configuration in the RADIUS configuration files.
|
||||
# For example, if you need to set an environment variable which is
|
||||
# used by a module. You could put that variable into a shell script,
|
||||
# but that's awkward. Instead, just list it here.
|
||||
#
|
||||
# Note that these environment variables are set AFTER the
|
||||
# configuration file is loaded. So you cannot set FOO here, and
|
||||
# expect to reference it via `$ENV{FOO}` in another configuration file.
|
||||
# You should instead just use a normal configuration variable for
|
||||
# that.
|
||||
#
|
||||
ENV {
|
||||
#
|
||||
# Set environment varable `FOO` to value '/bar/baz'.
|
||||
#
|
||||
# NOTE: Note that you MUST use '='. You CANNOT use '+=' to append
|
||||
# values.
|
||||
#
|
||||
# FOO = '/bar/baz'
|
||||
|
||||
#
|
||||
# Delete environment variable `BAR`.
|
||||
#
|
||||
# BAR
|
||||
|
||||
#
|
||||
# `LD_PRELOAD` is special. It is normally set before the
|
||||
# application runs, and is interpreted by the dynamic linker.
|
||||
# Which means you cannot set it inside of an application, and
|
||||
# expect it to load libraries.
|
||||
#
|
||||
# Since this functionality is useful, we extend it here.
|
||||
#
|
||||
# You can set
|
||||
#
|
||||
# LD_PRELOAD = /path/to/library.so
|
||||
#
|
||||
# and the server will load the named libraries. Multiple
|
||||
# libraries can be loaded by specificing multiple individual
|
||||
# `LD_PRELOAD` entries.
|
||||
#
|
||||
#
|
||||
# LD_PRELOAD = /path/to/library1.so
|
||||
# LD_PRELOAD = /path/to/library2.so
|
||||
}
|
||||
|
||||
# SECURITY CONFIGURATION
|
||||
#
|
||||
# There may be multiple methods of attacking on the server. This
|
||||
# section holds the configuration items which minimize the impact
|
||||
# of those attacks
|
||||
#
|
||||
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 = freerad
|
||||
group = freerad
|
||||
|
||||
# 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 CONFIGURATION
|
||||
#
|
||||
# proxy_requests: Turns proxying of RADIUS requests on or off.
|
||||
#
|
||||
# The server has proxying turned on by default. If your system is NOT
|
||||
# set up to proxy requests to another server, then you can turn proxying
|
||||
# off here. This will save a small amount of resources on the server.
|
||||
#
|
||||
# If you have proxying turned off, and your configuration files say
|
||||
# to proxy a request, then an error message will be logged.
|
||||
#
|
||||
# To disable proxying, change the "yes" to "no", and comment the
|
||||
# $INCLUDE line.
|
||||
#
|
||||
# allowed values: {no, yes}
|
||||
#
|
||||
proxy_requests = yes
|
||||
$INCLUDE proxy.conf
|
||||
|
||||
|
||||
# CLIENTS CONFIGURATION
|
||||
#
|
||||
# Client configuration is defined in "clients.conf".
|
||||
#
|
||||
|
||||
# The 'clients.conf' file contains all of the information from the old
|
||||
# 'clients' and 'naslist' configuration files. We recommend that you
|
||||
# do NOT use 'client's or 'naslist', although they are still
|
||||
# supported.
|
||||
#
|
||||
# Anything listed in 'clients.conf' will take precedence over the
|
||||
# information from the old-style configuration files.
|
||||
#
|
||||
$INCLUDE clients.conf
|
||||
|
||||
|
||||
# THREAD POOL CONFIGURATION
|
||||
#
|
||||
# The thread pool is a long-lived group of threads which
|
||||
# take turns (round-robin) handling any incoming requests.
|
||||
#
|
||||
# You probably want to have a few spare threads around,
|
||||
# so that high-load situations can be handled immediately. If you
|
||||
# don't have any spare threads, then the request handling will
|
||||
# be delayed while a new thread is created, and added to the pool.
|
||||
#
|
||||
# You probably don't want too many spare threads around,
|
||||
# otherwise they'll be sitting there taking up resources, and
|
||||
# not doing anything productive.
|
||||
#
|
||||
# The numbers given below should be adequate for most situations.
|
||||
#
|
||||
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
|
||||
|
||||
# Clean up old threads periodically. For no reason other than
|
||||
# it might be useful.
|
||||
#
|
||||
# '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
|
||||
}
|
||||
|
||||
######################################################################
|
||||
#
|
||||
# SNMP notifications. Uncomment the following line to enable
|
||||
# snmptraps. Note that you MUST also configure the full path
|
||||
# to the "snmptrap" command in the "trigger.conf" file.
|
||||
#
|
||||
#$INCLUDE trigger.conf
|
||||
|
||||
# MODULE CONFIGURATION
|
||||
#
|
||||
# The names and configuration of each module is located in this section.
|
||||
#
|
||||
# After the modules are defined here, they may be referred to by name,
|
||||
# in other sections of this configuration file.
|
||||
#
|
||||
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.
|
||||
#
|
||||
|
||||
#
|
||||
# Some modules have ordering issues. e.g. "sqlippool" uses
|
||||
# the configuration from "sql". In that case, the "sql"
|
||||
# module must be read off of disk before the "sqlippool".
|
||||
# However, the directory inclusion below just reads the
|
||||
# directory from start to finish. Which means that the
|
||||
# modules are read off of disk randomly.
|
||||
#
|
||||
# As of 3.0.18, you can list individual modules *before* the
|
||||
# directory inclusion. Those modules will be loaded first.
|
||||
# Then, when the directory is read, those modules will be
|
||||
# skipped and not read twice.
|
||||
#
|
||||
# $INCLUDE mods-enabled/sql
|
||||
|
||||
#
|
||||
# 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/
|
||||
}
|
||||
|
||||
# Instantiation
|
||||
#
|
||||
# This section sets the instantiation order of the modules. listed
|
||||
# here will get started up BEFORE the sections like authorize,
|
||||
# authenticate, etc. get examined.
|
||||
#
|
||||
# This section is not strictly needed. When a section like authorize
|
||||
# refers to a module, the module is automatically loaded and
|
||||
# initialized. However, some modules may not be listed in any of the
|
||||
# processing sections, so they should be listed here.
|
||||
#
|
||||
# Also, listing modules here ensures that you have control over
|
||||
# the order in which they are initialized. If one module needs
|
||||
# something defined by another module, you can list them in order
|
||||
# here, and ensure that the configuration will be OK.
|
||||
#
|
||||
# After the modules listed here have been loaded, all of the modules
|
||||
# in the "mods-enabled" directory will be loaded. Loading the
|
||||
# "mods-enabled" directory means that unlike Version 2, you usually
|
||||
# don't need to list modules here.
|
||||
#
|
||||
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
|
||||
#}
|
||||
}
|
||||
|
||||
######################################################################
|
||||
#
|
||||
# Policies are virtual modules, similar to those defined in the
|
||||
# "instantiate" section above.
|
||||
#
|
||||
# Defining a policy in one of the policy.d files means that it can be
|
||||
# referenced in multiple places as a *name*, rather than as a series of
|
||||
# conditions to match, and actions to take.
|
||||
#
|
||||
# Policies are something like subroutines in a normal language, but
|
||||
# they cannot be called recursively. They MUST be defined in order.
|
||||
# If policy A calls policy B, then B MUST be defined before A.
|
||||
#
|
||||
######################################################################
|
||||
policy {
|
||||
$INCLUDE policy.d/
|
||||
}
|
||||
|
||||
######################################################################
|
||||
#
|
||||
# Load virtual servers.
|
||||
#
|
||||
# This next $INCLUDE line loads files in the directory that
|
||||
# match the regular expression: /[a-zA-Z0-9_.]+/
|
||||
#
|
||||
# It allows you to define new virtual servers simply by placing
|
||||
# a file into the raddb/sites-enabled/ directory.
|
||||
#
|
||||
$INCLUDE sites-enabled/
|
||||
|
||||
######################################################################
|
||||
#
|
||||
# All of the other configuration sections like "authorize {}",
|
||||
# "authenticate {}", "accounting {}", have been moved to the
|
||||
# the file:
|
||||
#
|
||||
# raddb/sites-available/default
|
||||
#
|
||||
# This is the "default" virtual server that has the same
|
||||
# configuration as in version 1.0.x and 1.1.x. The default
|
||||
# installation enables this virtual server. You should
|
||||
# edit it to create policies for your local site.
|
||||
#
|
||||
# For more documentation on virtual servers, see:
|
||||
#
|
||||
# raddb/sites-available/README
|
||||
#
|
||||
######################################################################
|
||||
|
|
@ -0,0 +1,741 @@
|
|||
{{ ansible_header | comment }}
|
||||
|
||||
######################################################################
|
||||
#
|
||||
# As of 2.0.0, FreeRADIUS supports virtual hosts using the
|
||||
# "server" section, and configuration directives.
|
||||
#
|
||||
# Virtual hosts should be put into the "sites-available"
|
||||
# directory. Soft links should be created in the "sites-enabled"
|
||||
# directory to these files. This is done in a normal installation.
|
||||
#
|
||||
# If you are using 802.1X (EAP) authentication, please see also
|
||||
# the "inner-tunnel" virtual server. You will likely have to edit
|
||||
# that, too, for authentication to work.
|
||||
#
|
||||
# $Id: c60c0ba4c8728fac10b190dbb3b752f9df317c07 $
|
||||
#
|
||||
######################################################################
|
||||
#
|
||||
# Read "man radiusd" before editing this file. See the section
|
||||
# titled DEBUGGING. It outlines a method where you can quickly
|
||||
# obtain the configuration you want, without running into
|
||||
# trouble. See also "man unlang", which documents the format
|
||||
# of this file.
|
||||
#
|
||||
# This configuration is designed to work in the widest possible
|
||||
# set of circumstances, with the widest possible number of
|
||||
# authentication methods. This means that in general, you should
|
||||
# need to make very few changes to this file.
|
||||
#
|
||||
# The best way to configure the server for your local system
|
||||
# is to CAREFULLY edit this file. Most attempts to make large
|
||||
# edits to this file will BREAK THE SERVER. Any edits should
|
||||
# be small, and tested by running the server with "radiusd -X".
|
||||
# Once the edits have been verified to work, save a copy of these
|
||||
# configuration files somewhere. (e.g. as a "tar" file). Then,
|
||||
# make more edits, and test, as above.
|
||||
#
|
||||
# There are many "commented out" references to modules such
|
||||
# as ldap, sql, etc. These references serve as place-holders.
|
||||
# If you need the functionality of that module, then configure
|
||||
# it in radiusd.conf, and un-comment the references to it in
|
||||
# this file. In most cases, those small changes will result
|
||||
# in the server being able to connect to the DB, and to
|
||||
# authenticate users.
|
||||
#
|
||||
######################################################################
|
||||
|
||||
server default {
|
||||
#
|
||||
# If you want the server to listen on additional addresses, or on
|
||||
# additional ports, you can use multiple "listen" sections.
|
||||
#
|
||||
# Each section make the server listen for only one type of packet,
|
||||
# therefore authentication and accounting have to be configured in
|
||||
# different sections.
|
||||
#
|
||||
# The server ignore all "listen" section if you are using '-i' and '-p'
|
||||
# on the command line.
|
||||
#
|
||||
listen {
|
||||
# Type of packets to listen for.
|
||||
# Allowed values are:
|
||||
# auth listen for authentication packets
|
||||
# acct listen for accounting packets
|
||||
# proxy IP to use for sending proxied packets
|
||||
# detail Read from the detail file. For examples, see
|
||||
# raddb/sites-available/copy-acct-to-home-server
|
||||
# status listen for Status-Server packets. For examples,
|
||||
# see raddb/sites-available/status
|
||||
# coa listen for CoA-Request and Disconnect-Request
|
||||
# packets. For examples, see the file
|
||||
# raddb/sites-available/coa
|
||||
#
|
||||
type = auth
|
||||
|
||||
# Note: "type = proxy" lets you control the source IP used for
|
||||
# proxying packets, with some limitations:
|
||||
#
|
||||
# * A proxy listener CANNOT be used in a virtual server section.
|
||||
# * You should probably set "port = 0".
|
||||
# * Any "clients" configuration will be ignored.
|
||||
#
|
||||
# See also proxy.conf, and the "src_ipaddr" configuration entry
|
||||
# in the sample "home_server" section. When you specify the
|
||||
# source IP address for packets sent to a home server, the
|
||||
# proxy listeners are automatically created.
|
||||
|
||||
# ipaddr/ipv4addr/ipv6addr - IP address on which to listen.
|
||||
# If multiple ones are listed, only the first one will
|
||||
# be used, and the others will be ignored.
|
||||
#
|
||||
# The configuration options accept the following syntax:
|
||||
#
|
||||
# ipv4addr - IPv4 address (e.g.192.0.2.3)
|
||||
# - wildcard (i.e. *)
|
||||
# - hostname (radius.example.com)
|
||||
# Only the A record for the host name is used.
|
||||
# If there is no A record, an error is returned,
|
||||
# and the server fails to start.
|
||||
#
|
||||
# ipv6addr - IPv6 address (e.g. 2001:db8::1)
|
||||
# - wildcard (i.e. *)
|
||||
# - hostname (radius.example.com)
|
||||
# Only the AAAA record for the host name is used.
|
||||
# If there is no AAAA record, an error is returned,
|
||||
# and the server fails to start.
|
||||
#
|
||||
# ipaddr - IPv4 address as above
|
||||
# - IPv6 address as above
|
||||
# - wildcard (i.e. *), which means IPv4 wildcard.
|
||||
# - hostname
|
||||
# If there is only one A or AAAA record returned
|
||||
# for the host name, it is used.
|
||||
# If multiple A or AAAA records are returned
|
||||
# for the host name, only the first one is used.
|
||||
# If both A and AAAA records are returned
|
||||
# for the host name, only the A record is used.
|
||||
#
|
||||
# ipv4addr = *
|
||||
# ipv6addr = *
|
||||
ipaddr = *
|
||||
|
||||
# Port on which to listen.
|
||||
# Allowed values are:
|
||||
# integer port number (1812)
|
||||
# 0 means "use /etc/services for the proper port"
|
||||
port = 0
|
||||
|
||||
# Some systems support binding to an interface, in addition
|
||||
# to the IP address. This feature isn't strictly necessary,
|
||||
# but for sites with many IP addresses on one interface,
|
||||
# it's useful to say "listen on all addresses for eth0".
|
||||
#
|
||||
# If your system does not support this feature, you will
|
||||
# get an error if you try to use it.
|
||||
#
|
||||
# interface = eth0
|
||||
|
||||
# Per-socket lists of clients. This is a very useful feature.
|
||||
#
|
||||
# The name here is a reference to a section elsewhere in
|
||||
# radiusd.conf, or clients.conf. Having the name as
|
||||
# a reference allows multiple sockets to use the same
|
||||
# set of clients.
|
||||
#
|
||||
# If this configuration is used, then the global list of clients
|
||||
# is IGNORED for this "listen" section. Take care configuring
|
||||
# this feature, to ensure you don't accidentally disable a
|
||||
# client you need.
|
||||
#
|
||||
# See clients.conf for the configuration of "per_socket_clients".
|
||||
#
|
||||
# clients = per_socket_clients
|
||||
|
||||
#
|
||||
# Set the default UDP receive buffer size. In most cases,
|
||||
# the default values set by the kernel are fine. However, in
|
||||
# some cases the NASes will send large packets, and many of
|
||||
# them at a time. It is then possible to overflow the
|
||||
# buffer, causing the kernel to drop packets before they
|
||||
# reach FreeRADIUS. Increasing the size of the buffer will
|
||||
# avoid these packet drops.
|
||||
#
|
||||
# recv_buff = 65536
|
||||
|
||||
#
|
||||
# Connection limiting for sockets with "proto = tcp".
|
||||
#
|
||||
# This section is ignored for other kinds of sockets.
|
||||
#
|
||||
limit {
|
||||
#
|
||||
# Limit the number of simultaneous TCP connections to the socket
|
||||
#
|
||||
# The default is 16.
|
||||
# Setting this to 0 means "no limit"
|
||||
max_connections = 16
|
||||
|
||||
# The per-socket "max_requests" option does not exist.
|
||||
|
||||
#
|
||||
# The lifetime, in seconds, of a TCP connection. After
|
||||
# this lifetime, the connection will be closed.
|
||||
#
|
||||
# Setting this to 0 means "forever".
|
||||
lifetime = 0
|
||||
|
||||
#
|
||||
# The idle timeout, in seconds, of a TCP connection.
|
||||
# If no packets have been received over the connection for
|
||||
# this time, the connection will be closed.
|
||||
#
|
||||
# Setting this to 0 means "no timeout".
|
||||
#
|
||||
# We STRONGLY RECOMMEND that you set an idle timeout.
|
||||
#
|
||||
idle_timeout = 30
|
||||
}
|
||||
}
|
||||
|
||||
#
|
||||
# This second "listen" section is for listening on the accounting
|
||||
# port, too.
|
||||
#
|
||||
listen {
|
||||
ipaddr = *
|
||||
# ipv6addr = ::
|
||||
port = 0
|
||||
type = acct
|
||||
# interface = eth0
|
||||
# clients = per_socket_clients
|
||||
|
||||
limit {
|
||||
# The number of packets received can be rate limited via the
|
||||
# "max_pps" configuration item. When it is set, the server
|
||||
# tracks the total number of packets received in the previous
|
||||
# second. If the count is greater than "max_pps", then the
|
||||
# new packet is silently discarded. This helps the server
|
||||
# deal with overload situations.
|
||||
#
|
||||
# The packets/s counter is tracked in a sliding window. This
|
||||
# means that the pps calculation is done for the second
|
||||
# before the current packet was received. NOT for the current
|
||||
# wall-clock second, and NOT for the previous wall-clock second.
|
||||
#
|
||||
# Useful values are 0 (no limit), or 100 to 10000.
|
||||
# Values lower than 100 will likely cause the server to ignore
|
||||
# normal traffic. Few systems are capable of handling more than
|
||||
# 10K packets/s.
|
||||
#
|
||||
# It is most useful for accounting systems. Set it to 50%
|
||||
# more than the normal accounting load, and you can be sure that
|
||||
# the server will never get overloaded
|
||||
#
|
||||
# max_pps = 0
|
||||
|
||||
# Only for "proto = tcp". These are ignored for "udp" sockets.
|
||||
#
|
||||
# idle_timeout = 0
|
||||
# lifetime = 0
|
||||
# max_connections = 0
|
||||
}
|
||||
}
|
||||
|
||||
# IPv6 versions of the above - read their full config to understand options
|
||||
listen {
|
||||
type = auth
|
||||
ipv6addr = :: # any. ::1 == localhost
|
||||
port = 0
|
||||
# interface = eth0
|
||||
# clients = per_socket_clients
|
||||
limit {
|
||||
max_connections = 16
|
||||
lifetime = 0
|
||||
idle_timeout = 30
|
||||
}
|
||||
}
|
||||
|
||||
listen {
|
||||
ipv6addr = ::
|
||||
port = 0
|
||||
type = acct
|
||||
# interface = eth0
|
||||
# clients = per_socket_clients
|
||||
|
||||
limit {
|
||||
# max_pps = 0
|
||||
# idle_timeout = 0
|
||||
# lifetime = 0
|
||||
# max_connections = 0
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
# Virtual server to handle RADIUS queries from a wifi AP. It is well commented out
|
||||
# to understand exactly what it does by reading this configuration file.
|
||||
# The virtual server to handle RADIUS queries from switches won't be as commented.
|
||||
|
||||
server radius-wifi {
|
||||
|
||||
# Authorization. First preprocess (hints and huntgroups files),
|
||||
# then realms, and finally look in the "users" file.
|
||||
#
|
||||
# Any changes made here should also be made to the "inner-tunnel"
|
||||
# virtual server.
|
||||
#
|
||||
# The order of the realm modules will determine the order that
|
||||
# we try to find a matching realm.
|
||||
#
|
||||
# Make *sure* that 'preprocess' comes before any realm if you
|
||||
# need to setup hints for the remote radius server
|
||||
authorize {
|
||||
|
||||
|
||||
# Makes Calling-Station-ID conform to what RFC3580 says should
|
||||
# be provided by 802.1X authenticators.
|
||||
# See policy.d/canonicalization for the definition of the rewrite_calling_station_id policy
|
||||
rewrite_calling_station_id
|
||||
|
||||
{% if freeradius.proxy_to is defined %}
|
||||
# Handles RADIUS Proxy to {{ freeradius.proxy_to }} REALM
|
||||
if (User-Name =~ /^(.*)@(.*)/){
|
||||
if (User-Name !~ /^(.*)@(.*){{ freeradius.realm }}(.*)/){
|
||||
update control{
|
||||
Proxy-To-Realm := '{{ freeradius.proxy_to }}'
|
||||
}
|
||||
}
|
||||
|
||||
# If the User-Name has {{ freeradius.realm }} realm, then do not proxy.
|
||||
if ("%{request:User-Name}" =~ /^(.*)@(.*){{ freeradius.realm }}(.*)/){
|
||||
update request{
|
||||
Stripped-User-Name := "%{1}"
|
||||
}
|
||||
}
|
||||
}
|
||||
{% endif %}
|
||||
|
||||
#
|
||||
# Take a User-Name, and perform some checks on it, for spaces and other
|
||||
# invalid characters. If the User-Name appears invalid, reject the
|
||||
# request.
|
||||
#
|
||||
# See policy.d/filter for the definition of the filter_username policy.
|
||||
#
|
||||
filter_username
|
||||
|
||||
#
|
||||
# The preprocess module takes care of sanitizing some bizarre
|
||||
# attributes in the request, and turning them into attributes
|
||||
# which are more standard.
|
||||
#
|
||||
# It takes care of processing the 'raddb/mods-config/preprocess/hints'
|
||||
# and the 'raddb/mods-config/preprocess/huntgroups' files.
|
||||
preprocess
|
||||
|
||||
#
|
||||
# Look for realms in user@domain format
|
||||
suffix
|
||||
|
||||
#
|
||||
# This module takes care of EAP-MD5, EAP-TLS, and EAP-LEAP
|
||||
# authentication.
|
||||
#
|
||||
# It also sets the EAP-Type attribute in the request
|
||||
# attribute list to the EAP type from the packet.
|
||||
#
|
||||
# The EAP module returns "ok" or "updated" if it is not yet ready
|
||||
# to authenticate the user. The configuration below checks for
|
||||
# "ok", and stops processing the "authorize" section if so.
|
||||
#
|
||||
# Any LDAP and/or SQL servers will not be queried for the
|
||||
# initial set of packets that go back and forth to set up
|
||||
# TTLS or PEAP.
|
||||
#
|
||||
# The "updated" check is commented out for compatibility with
|
||||
# previous versions of this configuration, but you may wish to
|
||||
# uncomment it as well; this will further reduce the number of
|
||||
# LDAP and/or SQL queries for TTLS or PEAP.
|
||||
#
|
||||
eap {
|
||||
ok = return
|
||||
# updated = return
|
||||
}
|
||||
|
||||
#
|
||||
expiration
|
||||
logintime
|
||||
|
||||
#
|
||||
# If no other module has claimed responsibility for
|
||||
# authentication, then try to use PAP. This allows the
|
||||
# other modules listed above to add a "known good" password
|
||||
# to the request, and to do nothing else. The PAP module
|
||||
# will then see that password, and use it to do PAP
|
||||
# authentication.
|
||||
#
|
||||
# This module should be listed last, so that the other modules
|
||||
# get a chance to set Auth-Type for themselves.
|
||||
#
|
||||
pap
|
||||
|
||||
}
|
||||
|
||||
# Authentication.
|
||||
#
|
||||
#
|
||||
# This section lists which modules are available for authentication.
|
||||
# Note that it does NOT mean 'try each module in order'. It means
|
||||
# that a module from the 'authorize' section adds a configuration
|
||||
# attribute 'Auth-Type := FOO'. That authentication type is then
|
||||
# used to pick the appropriate module from the list below.
|
||||
#
|
||||
|
||||
# In general, you SHOULD NOT set the Auth-Type attribute. The server
|
||||
# will figure it out on its own, and will do the right thing. The
|
||||
# most common side effect of erroneously setting the Auth-Type
|
||||
# attribute is that one authentication method will work, but the
|
||||
# others will not.
|
||||
#
|
||||
# The common reasons to set the Auth-Type attribute by hand
|
||||
# is to either forcibly reject the user (Auth-Type := Reject),
|
||||
# or to or forcibly accept the user (Auth-Type := Accept).
|
||||
#
|
||||
# Note that Auth-Type := Accept will NOT work with EAP.
|
||||
#
|
||||
# Please do not put "unlang" configurations into the "authenticate"
|
||||
# section. Put them in the "post-auth" section instead. That's what
|
||||
# the post-auth section is for.
|
||||
#
|
||||
authenticate {
|
||||
#
|
||||
# PAP authentication, when a back-end database listed
|
||||
# in the 'authorize' section supplies a password. The
|
||||
# password can be clear-text, or encrypted.
|
||||
Auth-Type PAP {
|
||||
pap
|
||||
}
|
||||
|
||||
#
|
||||
# Most people want CHAP authentication
|
||||
# A back-end database listed in the 'authorize' section
|
||||
# MUST supply a CLEAR TEXT password. Encrypted passwords
|
||||
# won't work.
|
||||
Auth-Type CHAP {
|
||||
chap
|
||||
}
|
||||
|
||||
#
|
||||
# MSCHAP authentication.
|
||||
Auth-Type MS-CHAP {
|
||||
mschap
|
||||
}
|
||||
|
||||
#
|
||||
# For old names, too.
|
||||
#
|
||||
mschap
|
||||
|
||||
#
|
||||
# Allow EAP authentication.
|
||||
eap
|
||||
|
||||
#
|
||||
# The older configurations sent a number of attributes in
|
||||
# Access-Challenge packets, which wasn't strictly correct.
|
||||
# If you want to filter out these attributes, uncomment
|
||||
# the following lines.
|
||||
#
|
||||
# Auth-Type eap {
|
||||
# eap {
|
||||
# handled = 1
|
||||
# }
|
||||
# if (handled && (Response-Packet-Type == Access-Challenge)) {
|
||||
# attr_filter.access_challenge.post-auth
|
||||
# handled # override the "updated" code from attr_filter
|
||||
# }
|
||||
# }
|
||||
}
|
||||
|
||||
#
|
||||
# Pre-accounting. Decide which accounting type to use.
|
||||
#
|
||||
preacct {
|
||||
preprocess
|
||||
|
||||
#
|
||||
# Session start times are *implied* in RADIUS.
|
||||
# The NAS never sends a "start time". Instead, it sends
|
||||
# a start packet, *possibly* with an Acct-Delay-Time.
|
||||
# The server is supposed to conclude that the start time
|
||||
# was "Acct-Delay-Time" seconds in the past.
|
||||
#
|
||||
# The code below creates an explicit start time, which can
|
||||
# then be used in other modules. It will be *mostly* correct.
|
||||
# Any errors are due to the 1-second resolution of RADIUS,
|
||||
# and the possibility that the time on the NAS may be off.
|
||||
#
|
||||
# The start time is: NOW - delay - session_length
|
||||
#
|
||||
|
||||
# update request {
|
||||
# &FreeRADIUS-Acct-Session-Start-Time = "%{expr: %l - %{%{Acct-Session-Time}:-0} - %{%{Acct-Delay-Time}:-0}}"
|
||||
# }
|
||||
|
||||
|
||||
#
|
||||
# Ensure that we have a semi-unique identifier for every
|
||||
# request, and many NAS boxes are broken.
|
||||
acct_unique
|
||||
|
||||
#
|
||||
# Look for IPASS-style 'realm/', and if not found, look for
|
||||
# '@realm', and decide whether or not to proxy, based on
|
||||
# that.
|
||||
#
|
||||
# Accounting requests are generally proxied to the same
|
||||
# home server as authentication requests.
|
||||
# IPASS
|
||||
suffix
|
||||
# ntdomain
|
||||
|
||||
#
|
||||
# Read the 'acct_users' file
|
||||
files
|
||||
}
|
||||
|
||||
#
|
||||
# Accounting. Log the accounting data.
|
||||
#
|
||||
accounting {
|
||||
#
|
||||
# Create a 'detail'ed log of the packets.
|
||||
# Note that accounting requests which are proxied
|
||||
# are also logged in the detail file.
|
||||
detail
|
||||
|
||||
# Update the wtmp file
|
||||
#
|
||||
# If you don't use "radlast", you can delete this line.
|
||||
unix
|
||||
|
||||
# For Exec-Program and Exec-Program-Wait
|
||||
exec
|
||||
}
|
||||
|
||||
|
||||
# Session database, used for checking Simultaneous-Use. Either the radutmp
|
||||
# or rlm_sql module can handle this.
|
||||
# The rlm_sql module is *much* faster
|
||||
session {
|
||||
}
|
||||
|
||||
|
||||
# Post-Authentication
|
||||
# Once we KNOW that the user has been authenticated, there are
|
||||
# additional steps we can take.
|
||||
post-auth {
|
||||
#
|
||||
# If you need to have a State attribute, you can
|
||||
# add it here. e.g. for later CoA-Request with
|
||||
# State, and Service-Type = Authorize-Only.
|
||||
#
|
||||
# if (!&reply:State) {
|
||||
# update reply {
|
||||
# State := "0x%{randstr:16h}"
|
||||
# }
|
||||
# }
|
||||
|
||||
#
|
||||
# For EAP-TTLS and PEAP, add the cached attributes to the reply.
|
||||
# The "session-state" attributes are automatically cached when
|
||||
# an Access-Challenge is sent, and automatically retrieved
|
||||
# when an Access-Request is received.
|
||||
#
|
||||
# The session-state attributes are automatically deleted after
|
||||
# an Access-Reject or Access-Accept is sent.
|
||||
#
|
||||
# If both session-state and reply contain a User-Name attribute, remove
|
||||
# the one in the reply if it is just a copy of the one in the request, so
|
||||
# we don't end up with two User-Name attributes.
|
||||
|
||||
if (session-state:User-Name && reply:User-Name && request:User-Name && (reply:User-Name == request:User-Name)) {
|
||||
update reply {
|
||||
&User-Name !* ANY
|
||||
}
|
||||
}
|
||||
update {
|
||||
&reply: += &session-state:
|
||||
}
|
||||
|
||||
#
|
||||
# If you want to have a log of authentication replies,
|
||||
# un-comment the following line, and enable the
|
||||
# 'detail reply_log' module.
|
||||
# reply_log
|
||||
|
||||
#
|
||||
# Un-comment the following if you want to modify the user's object
|
||||
# in LDAP after a successful login.
|
||||
#
|
||||
# ldap
|
||||
|
||||
# For Exec-Program and Exec-Program-Wait
|
||||
exec
|
||||
|
||||
|
||||
# If there is a client certificate (EAP-TLS, sometimes PEAP
|
||||
# and TTLS), then some attributes are filled out after the
|
||||
# certificate verification has been performed. These fields
|
||||
# MAY be available during the authentication, or they may be
|
||||
# available only in the "post-auth" section.
|
||||
#
|
||||
# The first set of attributes contains information about the
|
||||
# issuing certificate which is being used. The second
|
||||
# contains information about the client certificate (if
|
||||
# available).
|
||||
#
|
||||
# update reply {
|
||||
# Reply-Message += "%{TLS-Cert-Serial}"
|
||||
# Reply-Message += "%{TLS-Cert-Expiration}"
|
||||
# Reply-Message += "%{TLS-Cert-Subject}"
|
||||
# Reply-Message += "%{TLS-Cert-Issuer}"
|
||||
# Reply-Message += "%{TLS-Cert-Common-Name}"
|
||||
# Reply-Message += "%{TLS-Cert-Subject-Alt-Name-Email}"
|
||||
#
|
||||
# Reply-Message += "%{TLS-Client-Cert-Serial}"
|
||||
# Reply-Message += "%{TLS-Client-Cert-Expiration}"
|
||||
# Reply-Message += "%{TLS-Client-Cert-Subject}"
|
||||
# Reply-Message += "%{TLS-Client-Cert-Issuer}"
|
||||
# Reply-Message += "%{TLS-Client-Cert-Common-Name}"
|
||||
# Reply-Message += "%{TLS-Client-Cert-Subject-Alt-Name-Email}"
|
||||
# }
|
||||
|
||||
# Remove reply message if the response contains an EAP-Message
|
||||
remove_reply_message_if_eap
|
||||
|
||||
#
|
||||
# Access-Reject packets are sent through the REJECT sub-section of the
|
||||
# post-auth section.
|
||||
#
|
||||
# Add the ldap module name (or instance) if you have set
|
||||
# 'edir = yes' in the ldap module configuration
|
||||
#
|
||||
# The "session-state" attributes are not available here.
|
||||
#
|
||||
Post-Auth-Type REJECT {
|
||||
# TO REMOVE ?
|
||||
# log failed authentications in SQL, too.
|
||||
-sql
|
||||
attr_filter.access_reject
|
||||
|
||||
# Insert EAP-Failure message if the request was
|
||||
# rejected by policy instead of because of an
|
||||
# authentication failure
|
||||
eap
|
||||
|
||||
# Remove reply message if the response contains an EAP-Message
|
||||
remove_reply_message_if_eap
|
||||
}
|
||||
|
||||
#
|
||||
# Filter access challenges.
|
||||
#
|
||||
Post-Auth-Type Challenge {
|
||||
# remove_reply_message_if_eap
|
||||
# attr_filter.access_challenge.post-auth
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
#
|
||||
# When the server decides to proxy a request to a home server,
|
||||
# the proxied request is first passed through the pre-proxy
|
||||
# stage. This stage can re-write the request, or decide to
|
||||
# cancel the proxy.
|
||||
#
|
||||
# Only a few modules currently have this method.
|
||||
#
|
||||
pre-proxy {
|
||||
}
|
||||
|
||||
#
|
||||
# When the server receives a reply to a request it proxied
|
||||
# to a home server, the request may be massaged here, in the
|
||||
# post-proxy stage.
|
||||
#
|
||||
post-proxy {
|
||||
|
||||
# If you want to have a log of replies from a home server,
|
||||
# un-comment the following line, and the 'detail post_proxy_log'
|
||||
# section, above.
|
||||
# post_proxy_log
|
||||
|
||||
# Uncomment the following line if you want to filter replies from
|
||||
# remote proxies based on the rules defined in the 'attrs' file.
|
||||
# attr_filter.post-proxy
|
||||
|
||||
#
|
||||
# If you are proxying LEAP, you MUST configure the EAP
|
||||
# module, and you MUST list it here, in the post-proxy
|
||||
# stage.
|
||||
#
|
||||
# You MUST also use the 'nostrip' option in the 'realm'
|
||||
# configuration. Otherwise, the User-Name attribute
|
||||
# in the proxied request will not match the user name
|
||||
# hidden inside of the EAP packet, and the end server will
|
||||
# reject the EAP request.
|
||||
#
|
||||
eap
|
||||
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
|
||||
# Virtual server to handle RADIUS queries from a switch. See the above virtual server
|
||||
# to have precise comments about what it does.
|
||||
server radius-filaire{
|
||||
authorize{
|
||||
# Call the re2o module to authorize the request
|
||||
re2o
|
||||
expiration
|
||||
logintime
|
||||
pap
|
||||
}
|
||||
authenticate{
|
||||
Auth-Type PAP{
|
||||
pap
|
||||
}
|
||||
Auth-Type CHAP{
|
||||
chap
|
||||
}
|
||||
Auth-Type MS-CHAP{
|
||||
mschap
|
||||
}
|
||||
digest
|
||||
eap
|
||||
|
||||
}
|
||||
preacct{
|
||||
preprocess
|
||||
acct_unique
|
||||
suffix
|
||||
files
|
||||
}
|
||||
accounting{
|
||||
}
|
||||
session{
|
||||
}
|
||||
post-auth{
|
||||
re2o
|
||||
exec
|
||||
}
|
||||
pre-proxy{
|
||||
}
|
||||
post-proxy{
|
||||
eap
|
||||
}
|
||||
}
|
||||
|
|
@ -0,0 +1,306 @@
|
|||
{{ ansible_header | comment }}
|
||||
|
||||
# -*- text -*-
|
||||
######################################################################
|
||||
#
|
||||
# This is a virtual server that handles *only* inner tunnel
|
||||
# requests for EAP-TTLS and PEAP types.
|
||||
#
|
||||
# $Id: 10eeb55db7a1129ea62f2195c17b286eb4acd1d2 $
|
||||
#
|
||||
######################################################################
|
||||
|
||||
server inner-tunnel {
|
||||
|
||||
#
|
||||
# This next section is here to allow testing of the "inner-tunnel"
|
||||
# authentication methods, independently from the "default" server.
|
||||
# It is listening on "localhost", so that it can only be used from
|
||||
# the same machine.
|
||||
#
|
||||
# $ radtest USER PASSWORD 127.0.0.1:18120 0 testing123
|
||||
#
|
||||
# If it works, you have configured the inner tunnel correctly. To check
|
||||
# if PEAP will work, use:
|
||||
#
|
||||
# $ radtest -t mschap USER PASSWORD 127.0.0.1:18120 0 testing123
|
||||
#
|
||||
# If that works, PEAP should work. If that command doesn't work, then
|
||||
#
|
||||
# FIX THE INNER TUNNEL CONFIGURATION SO THAT IT WORKS.
|
||||
#
|
||||
# Do NOT do any PEAP tests. It won't help. Instead, concentrate
|
||||
# on fixing the inner tunnel configuration. DO NOTHING ELSE.
|
||||
#
|
||||
listen {
|
||||
ipaddr = 127.0.0.1
|
||||
port = 18120
|
||||
type = auth
|
||||
}
|
||||
|
||||
|
||||
# Authorization. First preprocess (hints and huntgroups files),
|
||||
# then realms, and finally look in the "users" file.
|
||||
#
|
||||
# The order of the realm modules will determine the order that
|
||||
# we try to find a matching realm.
|
||||
#
|
||||
# Make *sure* that 'preprocess' comes before any realm if you
|
||||
# need to setup hints for the remote radius server
|
||||
|
||||
# See sites-enabled/default for the comments
|
||||
authorize {
|
||||
# Get rid of the realm part
|
||||
if ("%{request:User-Name}" =~ /^(.*)@{{ freeradius.realm }}(.*)/){
|
||||
update request{
|
||||
Stripped-User-Name := "%{1}"
|
||||
}
|
||||
}
|
||||
#
|
||||
# Take a User-Name, and perform some checks on it, for spaces and other
|
||||
# invalid characters. If the User-Name appears invalid, reject the
|
||||
# request.
|
||||
#
|
||||
# See policy.d/filter for the definition of the filter_username policy.
|
||||
#
|
||||
filter_username
|
||||
|
||||
# Call the authorize function from re2o module
|
||||
re2o
|
||||
|
||||
#
|
||||
# Do checks on outer / inner User-Name, so that users
|
||||
# can't spoof us by using incompatible identities
|
||||
#
|
||||
# filter_inner_identity
|
||||
|
||||
#
|
||||
# The chap module will set 'Auth-Type := CHAP' if we are
|
||||
# handling a CHAP request and Auth-Type has not already been set
|
||||
chap
|
||||
|
||||
#
|
||||
# If the users are logging in with an MS-CHAP-Challenge
|
||||
# attribute for authentication, the mschap module will find
|
||||
# the MS-CHAP-Challenge attribute, and add 'Auth-Type := MS-CHAP'
|
||||
# to the request, which will cause the server to then use
|
||||
# the mschap module for authentication.
|
||||
mschap
|
||||
|
||||
|
||||
#
|
||||
# Look for realms in user@domain format
|
||||
#
|
||||
# Note that proxying the inner tunnel authentication means
|
||||
# that the user MAY use one identity in the outer session
|
||||
# (e.g. "anonymous", and a different one here
|
||||
# (e.g. "user@example.com"). The inner session will then be
|
||||
# proxied elsewhere for authentication. If you are not
|
||||
# careful, this means that the user can cause you to forward
|
||||
# the authentication to another RADIUS server, and have the
|
||||
# accounting logs *not* sent to the other server. This makes
|
||||
# it difficult to bill people for their network activity.
|
||||
#
|
||||
suffix
|
||||
# ntdomain
|
||||
|
||||
#
|
||||
# The "suffix" module takes care of stripping the domain
|
||||
# (e.g. "@example.com") from the User-Name attribute, and the
|
||||
# next few lines ensure that the request is not proxied.
|
||||
#
|
||||
# If you want the inner tunnel request to be proxied, delete
|
||||
# the next few lines.
|
||||
#
|
||||
update control {
|
||||
&Proxy-To-Realm := LOCAL
|
||||
}
|
||||
|
||||
#
|
||||
# This module takes care of EAP-MSCHAPv2 authentication.
|
||||
#
|
||||
# It also sets the EAP-Type attribute in the request
|
||||
# attribute list to the EAP type from the packet.
|
||||
#
|
||||
# The example below uses module failover to avoid querying all
|
||||
# of the following modules if the EAP module returns "ok".
|
||||
# Therefore, your LDAP and/or SQL servers will not be queried
|
||||
# for the many packets that go back and forth to set up TTLS
|
||||
# or PEAP. The load on those servers will therefore be reduced.
|
||||
#
|
||||
eap {
|
||||
ok = return
|
||||
}
|
||||
|
||||
expiration
|
||||
logintime
|
||||
|
||||
#
|
||||
# If no other module has claimed responsibility for
|
||||
# authentication, then try to use PAP. This allows the
|
||||
# other modules listed above to add a "known good" password
|
||||
# to the request, and to do nothing else. The PAP module
|
||||
# will then see that password, and use it to do PAP
|
||||
# authentication.
|
||||
#
|
||||
# This module should be listed last, so that the other modules
|
||||
# get a chance to set Auth-Type for themselves.
|
||||
#
|
||||
pap
|
||||
}
|
||||
|
||||
|
||||
# Authentication.
|
||||
authenticate {
|
||||
Auth-Type PAP {
|
||||
pap
|
||||
}
|
||||
|
||||
Auth-Type CHAP {
|
||||
chap
|
||||
}
|
||||
|
||||
Auth-Type MS-CHAP {
|
||||
mschap
|
||||
}
|
||||
|
||||
mschap
|
||||
|
||||
#
|
||||
# Allow EAP authentication.
|
||||
eap
|
||||
}
|
||||
|
||||
######################################################################
|
||||
#
|
||||
# There are no accounting requests inside of EAP-TTLS or PEAP
|
||||
# tunnels.
|
||||
#
|
||||
######################################################################
|
||||
|
||||
|
||||
# Session database, used for checking Simultaneous-Use. Either the radutmp
|
||||
# or rlm_sql module can handle this.
|
||||
# The rlm_sql module is *much* faster
|
||||
session {
|
||||
radutmp
|
||||
|
||||
#
|
||||
# See "Simultaneous Use Checking Queries" in `mods-config/sql/main/$driver/queries.conf`
|
||||
# sql
|
||||
}
|
||||
|
||||
|
||||
# Post-Authentication
|
||||
# Once we KNOW that the user has been authenticated, there are
|
||||
# additional steps we can take.
|
||||
#
|
||||
# Note that the last packet of the inner-tunnel authentication
|
||||
# MAY NOT BE the last packet of the outer session. So updating
|
||||
# the outer reply MIGHT work, and sometimes MIGHT NOT. The
|
||||
# exact functionality depends on both the inner and outer
|
||||
# authentication methods.
|
||||
#
|
||||
# If you need to send a reply attribute in the outer session,
|
||||
# the ONLY safe way is to set "use_tunneled_reply = yes", and
|
||||
# then update the inner-tunnel reply.
|
||||
post-auth {
|
||||
# If you want privacy to remain, see the
|
||||
# Chargeable-User-Identity attribute from RFC 4372.
|
||||
# If you want to use it just uncomment the line below.
|
||||
# cui-inner
|
||||
|
||||
#
|
||||
# If you want the Access-Accept to contain the inner
|
||||
# User-Name, uncomment the following lines.
|
||||
#
|
||||
# update outer.session-state {
|
||||
# User-Name := &User-Name
|
||||
# }
|
||||
|
||||
#
|
||||
# If you want to have a log of authentication replies,
|
||||
# un-comment the following line, and enable the
|
||||
# 'detail reply_log' module.
|
||||
# reply_log
|
||||
|
||||
#
|
||||
# After authenticating the user, do another SQL query.
|
||||
#
|
||||
# See "Authentication Logging Queries" in `mods-config/sql/main/$driver/queries.conf`
|
||||
-sql
|
||||
|
||||
|
||||
#
|
||||
# Instead of "use_tunneled_reply", change this "if (0)" to an
|
||||
# "if (1)".
|
||||
#
|
||||
if (0) {
|
||||
#
|
||||
# These attributes are for the inner-tunnel only,
|
||||
# and MUST NOT be copied to the outer reply.
|
||||
#
|
||||
update reply {
|
||||
User-Name !* ANY
|
||||
Message-Authenticator !* ANY
|
||||
EAP-Message !* ANY
|
||||
Proxy-State !* ANY
|
||||
MS-MPPE-Encryption-Types !* ANY
|
||||
MS-MPPE-Encryption-Policy !* ANY
|
||||
MS-MPPE-Send-Key !* ANY
|
||||
MS-MPPE-Recv-Key !* ANY
|
||||
}
|
||||
|
||||
#
|
||||
# Copy the inner reply attributes to the outer
|
||||
# session-state list. The post-auth policy will take
|
||||
# care of copying the outer session-state list to the
|
||||
# outer reply.
|
||||
#
|
||||
update {
|
||||
&outer.session-state: += &reply:
|
||||
}
|
||||
}
|
||||
|
||||
#
|
||||
# Access-Reject packets are sent through the REJECT sub-section of the
|
||||
# post-auth section.
|
||||
#
|
||||
# Add the ldap module name (or instance) if you have set
|
||||
# 'edir = yes' in the ldap module configuration
|
||||
#
|
||||
Post-Auth-Type REJECT {
|
||||
# log failed authentications in SQL, too.
|
||||
-sql
|
||||
attr_filter.access_reject
|
||||
|
||||
#
|
||||
# Let the outer session know which module failed, and why.
|
||||
#
|
||||
update outer.session-state {
|
||||
&Module-Failure-Message := &request:Module-Failure-Message
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
#
|
||||
# When the server decides to proxy a request to a home server,
|
||||
# the proxied request is first passed through the pre-proxy
|
||||
# stage. This stage can re-write the request, or decide to
|
||||
# cancel the proxy.
|
||||
#
|
||||
# Only a few modules currently have this method.
|
||||
#
|
||||
pre-proxy {
|
||||
}
|
||||
|
||||
#
|
||||
# When the server receives a reply to a request it proxied
|
||||
# to a home server, the request may be massaged here, in the
|
||||
# post-proxy stage.
|
||||
#
|
||||
post-proxy {
|
||||
eap
|
||||
}
|
||||
|
||||
} # inner-tunnel server block
|
||||
Loading…
Reference in New Issue