mirror of
https://github.com/pentoo/pentoo-overlay
synced 2026-04-22 06:41:01 +02:00
199 lines
5.5 KiB
Text
199 lines
5.5 KiB
Text
#######################################################################
|
|
#
|
|
# 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 types NOT listed here may be supported via the "eap2" module.
|
|
# See experimental.conf for documentation.
|
|
#
|
|
#######################################################################
|
|
|
|
# For WPE, you might want to fix /etc/raddb/certs/ca.cnf:
|
|
# policy = policy_anything
|
|
|
|
eap {
|
|
default_eap_type = peap
|
|
timer_expire = 60
|
|
ignore_unknown_eap_types = no
|
|
cisco_accounting_username_bug = yes
|
|
max_sessions = 4096
|
|
|
|
md5 {
|
|
}
|
|
|
|
leap {
|
|
}
|
|
|
|
gtc {
|
|
auth_type = PAP
|
|
}
|
|
|
|
tls {
|
|
certdir = ${confdir}/certs
|
|
cadir = ${confdir}/certs
|
|
|
|
private_key_password = whatever
|
|
private_key_file = ${certdir}/server.pem
|
|
certificate_file = ${certdir}/server.pem
|
|
CA_file = ${cadir}/ca.pem
|
|
dh_file = ${certdir}/dh
|
|
random_file = ${certdir}/random
|
|
CA_path = ${cadir}
|
|
cipher_list = "DEFAULT"
|
|
|
|
cache {
|
|
enable = no
|
|
lifetime = 24 # hours
|
|
max_entries = 255
|
|
}
|
|
|
|
verify {
|
|
}
|
|
|
|
ocsp {
|
|
enable = no
|
|
override_cert_url = yes
|
|
url = "http://127.0.0.1/ocsp/"
|
|
}
|
|
}
|
|
|
|
ttls {
|
|
}
|
|
|
|
##################################################
|
|
#
|
|
# !!!!! 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.
|
|
#
|
|
# The PEAP module needs the TLS module to be installed
|
|
# and configured, in order to use the TLS tunnel
|
|
# inside of the EAP packet. You will still need to
|
|
# configure the TLS module, even if you do not want
|
|
# to deploy EAP-TLS in your network. Users will not
|
|
# be able to request EAP-TLS, as it requires them to
|
|
# have a client certificate. EAP-PEAP does not
|
|
# require a client certificate.
|
|
#
|
|
#
|
|
# You can make PEAP require a client cert by setting
|
|
#
|
|
# EAP-TLS-Require-Client-Cert = Yes
|
|
#
|
|
# in the control items for a request.
|
|
#
|
|
peap {
|
|
# 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 = no
|
|
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"
|
|
}
|
|
|
|
#
|
|
# 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 = no
|
|
}
|
|
}
|