X-Git-Url: http://ftp.carnet.hr/carnet-debian/scm?a=blobdiff_plain;f=files%2Fetc%2Ffreeradius%2Feap.conf.template;fp=files%2Fetc%2Ffreeradius%2Feap.conf.template;h=1280deb29afdbfc094245ef2dba59e992bdc8563;hb=014ea023f6634ce3ab867bc3c3ecf720b17b8769;hp=0000000000000000000000000000000000000000;hpb=d377040754883cac843416b724dd92ea8998b090;p=carnet-upgrade.git diff --git a/files/etc/freeradius/eap.conf.template b/files/etc/freeradius/eap.conf.template new file mode 100644 index 0000000..1280deb --- /dev/null +++ b/files/etc/freeradius/eap.conf.template @@ -0,0 +1,335 @@ +# -*- 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. +# +# $Id: eap.conf,v 1.4.4.4 2006/10/18 19:15:14 aland Exp $ +# + 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 = ttls + + # 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 + + # 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 { + #} + + # 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 + #} + + ## EAP-TLS + # + # To generate ctest certificates, run the script + # + # ../scripts/certs.sh + # + # The documents on http://www.freeradius.org/doc + # are old, but may be helpful. + # + # See also: + # + # http://www.dslreports.com/forum/remark,9286052~mode=flat + # + tls { + private_key_password = #PASSWORD# + private_key_file = ${raddbdir}/certs/cert-srv.pem + + # If Private key & Certificate are located in + # the same file, then private_key_file & + # certificate_file must contain the same file + # name. + certificate_file = ${raddbdir}/certs/cert-srv.pem + + # Trusted Root CA list + CA_file = ${raddbdir}/certs/root.pem + + dh_file = ${raddbdir}/certs/dh + random_file = /dev/urandom + + # + # This can never exceed the size of a RADIUS + # packet (4096 bytes), and is preferably half + # that, to accomodate 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 '. + # 'c_rehash' is OpenSSL's command. + # 3) Add 'CA_path=' + # to radiusd.conf's tls section. + # 4) uncomment the line below. + # 5) Restart radiusd + check_crl = yes + + # + # 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 cerficate verification will fail, + # rejecting the user. + # + # 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. + # + # check_cert_cn = %{User-Name} + # + # Set this option to specify the allowed + # TLS cipher suites. The format is listed + # in "man 1 ciphers". + # cipher_list = "DEFAULT" + } + + # 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. + # + # The TTLS 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-TTLS does not + # require a client certificate. + # + ttls { + # 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 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 + + # 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 = yes + } + + ################################################## + # + # !!!!! 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 + # + # 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. + # + # 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 + #} + + # + # 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 { + #} + } +