#######################################################################
#
#  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
		}
	}