From 39a20479d43819e422078cce075cb9e93169dfab Mon Sep 17 00:00:00 2001 From: aland Date: Mon, 15 Mar 2004 19:10:47 +0000 Subject: [PATCH] Moved EAP section to its own configuration file, as it was getting large --- raddb/eap.conf | 266 ++++++++++++++++++++++++++++++++++++++++++++++++++ raddb/radiusd.conf.in | 266 +------------------------------------------------- 2 files changed, 269 insertions(+), 263 deletions(-) create mode 100644 raddb/eap.conf diff --git a/raddb/eap.conf b/raddb/eap.conf new file mode 100644 index 0000000..ed66f55 --- /dev/null +++ b/raddb/eap.conf @@ -0,0 +1,266 @@ +# +# 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 { + # 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 + + # 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 + # + # 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 = whatever + # 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/demoCA/cacert.pem + + # dh_file = ${raddbdir}/certs/dh + # random_file = ${raddbdir}/certs/random + + # + # 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 + #} + + # 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 = no + + # 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 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 + #} + + # + # 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 { + } + } + diff --git a/raddb/radiusd.conf.in b/raddb/radiusd.conf.in index 9bb6e53..32bce23 100644 --- a/raddb/radiusd.conf.in +++ b/raddb/radiusd.conf.in @@ -607,270 +607,10 @@ modules { # Extensible Authentication Protocol # - # For all EAP related authentications - # - # 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. + # For all EAP related authentications. + # Now in another file, because it is very large. # - 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 - - # 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 - # - # 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 = whatever - # 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/demoCA/cacert.pem - - # dh_file = ${raddbdir}/certs/dh - # random_file = ${raddbdir}/certs/random - - # - # 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 - #} - - # 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 = no - - # 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 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 - #} - - # - # 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 { - } - } +$INCLUDE ${confdir}/eap.conf # Microsoft CHAP authentication # -- 2.1.4