If you do plan on using EAP-TLS, you need to uncomment certificate_file.
On Sun, 05 Dec 2004 16:05:20 -0600, Michael Griego <[EMAIL PROTECTED]> wrote:
> You haven't generated the certificate files for EAP-TLS. If you're
> using EAP-TLS, either run the scripts/certs.sh script as it says in the
> config file or manually generate your own certificates. If you are not
> going to be using EAP-TLS or any of its sub-types, then you can comment
> out the EAP-TLS and PEAP module configs.
>
> --Mike
>
>
>
>
> On Sun, 2004-12-05 at 15:59, ramirez wrote:
> >
> > Hi all,
> >
> > i have some problems starting Freeradius.
> > I'm using Freeradius 1.0.1 on Debian 3.1 and some Win2k Clients.
> > Compiling without errors.
> >
> > Here the Output
> >
> > linux:~# /usr/local/radius/sbin/rc.radiusd start
> > Starting FreeRADIUS:Sun Dec 5 21:43:58 2004 : Info: Starting -
> > reading configuration files ...
> > 3132:error:0906D06C:PEM routines:PEM_read_bio:no start
> > line:pem_lib.c:637:Expecting: CERTIFICATE
> > 3132:error:0200100E:system library:fopen:Bad
> > address:bss_file.c:278:fopen('','r')
> > 3132:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:280:
> > 3132:error:140AD002:SSL routines:SSL_CTX_use_certificate_file:system
> > lib:ssl_rsa.c:515:
> > radiusd
> > linux:~#
> >
> > And the eap.conf
> >
> >
> > #
> >
> > # 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 2004/04/15 18:34:41 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 = peap
> >
> > # 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 = whatever
> >
> > private_key_file = /etc/1x/r/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 = /etc/1x/r/cert-srv.pem
> >
> > # Trusted Root CA list
> >
> > CA_file = /etc/1x/r/demoCA/cacert.pem
> >
> > dh_file = /etc/1x/r/certs/dh
> >
> > random_file = /etc/1x/r/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
> >
> > #
> >
> > # 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.
> >
> > #
> >
> > # check_cert_cn = %{User-Name}
> >
> > }
> >
> > # 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 {
> >
> > }
> >
> > }
> >
> >
> >
> >
> >
> > Can anybody help me ??
> >
> >
> >
> > mfg Marcel Grossmann
> >
> >
>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>
--
Justin Guidroz
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
