--- /dev/null
+#
+# 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 <CA certs&CRLs Directory>'.
+ # 'c_rehash' is OpenSSL's command.
+ # 3) Add 'CA_path=<CA certs&CRLs directory>'
+ # 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 {
+ }
+ }
+
# 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 <CA certs&CRLs Directory>'.
- # 'c_rehash' is OpenSSL's command.
- # 3) Add 'CA_path=<CA certs&CRLs directory>'
- # 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
#
projects / freeradius.git / commitdiff