Freeradius set up help

Horchem Gary ghorchem at gary-springfield-mo.net
Mon Nov 9 23:53:52 CET 2009


I'm still having trouble here is my sites-available default file
"Authorization. First preprocess (hints and huntgroups files),
#  then realms, and finally look in the "users" file.
#
#  The order of the realm modules will determine the order that
#  we try to find a matching realm.
#
#  Make *sure* that 'preprocess' comes before any realm if you 
#  need to setup hints for the remote radius server
authorize {
    #
    #  The preprocess module takes care of sanitizing some bizarre
    #  attributes in the request, and turning them into attributes
    #  which are more standard.
    #
    #  It takes care of processing the 'raddb/hints' and the
    #  'raddb/huntgroups' files.
    #
    #  It also adds the %{Client-IP-Address} attribute to the request.
    preprocess

    #
    #  If you want to have a log of authentication requests,
    #  un-comment the following line, and the 'detail auth_log'
    #  section, above.
    auth_log

    #
    #  The chap module will set 'Auth-Type := CHAP' if we are
    #  handling a CHAP request and Auth-Type has not already been set
    chap

    #
    #  If the users are logging in with an MS-CHAP-Challenge
    #  attribute for authentication, the mschap module will find
    #  the MS-CHAP-Challenge attribute, and add 'Auth-Type := MS-CHAP'
    #  to the request, which will cause the server to then use
    #  the mschap module for authentication.
    mschap

    #
    #  If you have a Cisco SIP server authenticating against
    #  FreeRADIUS, uncomment the following line, and the 'digest'
    #  line in the 'authenticate' section.
#    digest

    #
    #  The WiMAX specification says that the Calling-Station-Id
    #  is 6 octets of the MAC.  This definition conflicts with
    #  RFC 3580, and all common RADIUS practices.  Un-commenting
    #  the "wimax" module here means that it will fix the
    #  Calling-Station-Id attribute to the normal format as
    #  specified in RFC 3580 Section 3.21
#    wimax

    #
    #  Look for IPASS style 'realm/', and if not found, look for
    #  '@realm', and decide whether or not to proxy, based on
    #  that.
#    IPASS

    #
    #  If you are using multiple kinds of realms, you probably
    #  want to set "ignore_null = yes" for all of them.
    #  Otherwise, when the first style of realm doesn't match,
    #  the other styles won't be checked.
    #
#    suffix
#    ntdomain

    #
    #  This module takes care of EAP-MD5, EAP-TLS, and EAP-LEAP
    #  authentication.
    #
    #  It also sets the EAP-Type attribute in the request
    #  attribute list to the EAP type from the packet.
    #
    #  As of 2.0, the EAP module returns "ok" in the authorize stage
    #  for TTLS and PEAP.  In 1.x, it never returned "ok" here, so
    #  this change is compatible with older configurations.
    #
    #  The example below uses module failover to avoid querying all
    #  of the following modules if the EAP module returns "ok".
    #  Therefore, your LDAP and/or SQL servers will not be queried
    #  for the many packets that go back and forth to set up TTLS
    #  or PEAP.  The load on those servers will therefore be reduced.
    #
    eap {
        ok = return
    }

    #
    #  Pull crypt'd passwords from /etc/passwd or /etc/shadow,
    #  using the system API's to get the password.  If you want
    #  to read /etc/passwd or /etc/shadow directly, see the
    #  passwd module in radiusd.conf.
    #
    unix

    #
    #  Read the 'users' file
    files

    #
    #  Look in an SQL database.  The schema of the database
    #  is meant to mirror the "users" file.
    #
    #  See "Authorization Queries" in sql.conf
#    sql

    #
    #  If you are using /etc/smbpasswd, and are also doing
    #  mschap authentication, the un-comment this line, and
    #  configure the 'etc_smbpasswd' module, above.
#    etc_smbpasswd

    #
    #  The ldap module will set Auth-Type to LDAP if it has not
    #  already been set
    ldap

    #
    #  Enforce daily limits on time spent logged in.
#    daily

    #
    # Use the checkval module
#    checkval

    expiration
    logintime

    #
    #  If no other module has claimed responsibility for
    #  authentication, then try to use PAP.  This allows the
    #  other modules listed above to add a "known good" password
    #  to the request, and to do nothing else.  The PAP module
    #  will then see that password, and use it to do PAP
    #  authentication.
    #
    #  This module should be listed last, so that the other modules
    #  get a chance to set Auth-Type for themselves.
    #
    pap

    #
    #  If "status_server = yes", then Status-Server messages are passed
    #  through the following section, and ONLY the following section.
    #  This permits you to do DB queries, for example.  If the modules
    #  listed here return "fail", then NO response is sent.
    #
#    Autz-Type Status-Server {
#
#    }
}


#  Authentication.
#
#
#  This section lists which modules are available for authentication.
#  Note that it does NOT mean 'try each module in order'.  It means
#  that a module from the 'authorize' section adds a configuration
#  attribute 'Auth-Type := FOO'.  That authentication type is then
#  used to pick the apropriate module from the list below.
#

#  In general, you SHOULD NOT set the Auth-Type attribute.  The server
#  will figure it out on its own, and will do the right thing.  The
#  most common side effect of erroneously setting the Auth-Type
#  attribute is that one authentication method will work, but the
#  others will not.
#
#  The common reasons to set the Auth-Type attribute by hand
#  is to either forcibly reject the user (Auth-Type := Reject),
#  or to or forcibly accept the user (Auth-Type := Accept).
#
#  Note that Auth-Type := Accept will NOT work with EAP.
#
#  Please do not put "unlang" configurations into the "authenticate"
#  section.  Put them in the "post-auth" section instead.  That's what
#  the post-auth section is for.
#
authenticate {
    #
    #  PAP authentication, when a back-end database listed
    #  in the 'authorize' section supplies a password.  The
    #  password can be clear-text, or encrypted.
    Auth-Type PAP {
        pap
    }

    #
    #  Most people want CHAP authentication
    #  A back-end database listed in the 'authorize' section
    #  MUST supply a CLEAR TEXT password.  Encrypted passwords
    #  won't work.
    Auth-Type CHAP {
        chap
    }

    #
    #  MSCHAP authentication.
    Auth-Type MS-CHAP {
        mschap
    }

    #
    #  If you have a Cisco SIP server authenticating against
    #  FreeRADIUS, uncomment the following line, and the 'digest'
    #  line in the 'authorize' section.
#    digest

    #
    #  Pluggable Authentication Modules.
#    pam

    #
    #  See 'man getpwent' for information on how the 'unix'
    #  module checks the users password.  Note that packets
    #  containing CHAP-Password attributes CANNOT be authenticated
    #  against /etc/passwd!  See the FAQ for details.
    #  
    unix

    # Uncomment it if you want to use ldap for authentication
    #
    # Note that this means "check plain-text password against
    # the ldap database", which means that EAP won't work,
    # as it does not supply a plain-text password.
    Auth-Type LDAP {
        ldap
    }

    #
    #  Allow EAP authentication.
    eap
}


#
#  Pre-accounting.  Decide which accounting type to use.
#
preacct {
    preprocess

    #
    #  Ensure that we have a semi-unique identifier for every
    #  request, and many NAS boxes are broken.
    acct_unique

    #
    #  Look for IPASS-style 'realm/', and if not found, look for
    #  '@realm', and decide whether or not to proxy, based on
    #  that.
    #
    #  Accounting requests are generally proxied to the same
    #  home server as authentication requests.
#    IPASS
#    suffix
#    ntdomain

    #
    #  Read the 'acct_users' file
    files
}

#
#  Accounting.  Log the accounting data.
#
accounting {
    #
    #  Create a 'detail'ed log of the packets.
    #  Note that accounting requests which are proxied
    #  are also logged in the detail file.
    detail
    daily

    #  Update the wtmp file
    #
    #  If you don't use "radlast", you can delete this line.
    unix

    #
    #  For Simultaneous-Use tracking.
    #
    #  Due to packet losses in the network, the data here
    #  may be incorrect.  There is little we can do about it.
    radutmp
#    sradutmp

    #  Return an address to the IP Pool when we see a stop record.
#    main_pool

    #
    #  Log traffic to an SQL database.
    #
    #  See "Accounting queries" in sql.conf
#    sql

    #
    #  Instead of sending the query to the SQL server,
    #  write it into a log file.
    #
#    sql_log

    #  Cisco VoIP specific bulk accounting
#    pgsql-voip

    #  Filter attributes from the accounting response.
    attr_filter.accounting_response

    #
    #  See "Autz-Type Status-Server" for how this works.
    #
#    Acct-Type Status-Server {
#
#    }
}


#  Session database, used for checking Simultaneous-Use. Either the radutmp 
#  or rlm_sql module can handle this.
#  The rlm_sql module is *much* faster
session {
    radutmp

    #
    #  See "Simultaneous Use Checking Queries" in sql.conf
#    sql
}


#  Post-Authentication
#  Once we KNOW that the user has been authenticated, there are
#  additional steps we can take.
post-auth {
    #  Get an address from the IP Pool.
#    main_pool

    #
    #  If you want to have a log of authentication replies,
    #  un-comment the following line, and the 'detail reply_log'
    #  section, above.
    reply_log

    #
    #  After authenticating the user, do another SQL query.
    #
    #  See "Authentication Logging Queries" in sql.conf
#    sql

    #
    #  Instead of sending the query to the SQL server,
    #  write it into a log file.
    #
#    sql_log

    #
    #  Un-comment the following if you have set
    #  'edir_account_policy_check = yes' in the ldap module sub-section of
    #  the 'modules' section.
    #
    ldap

    exec

    #
    #  Calculate the various WiMAX keys.  In order for this to work,
    #  you will need to define the WiMAX NAI, usually via
    #
    #    update request {
    #           WiMAX-MN-NAI = "%{User-Name}"
    #    }
    #
    #  If you want various keys to be calculated, you will need to
    #  update the reply with "template" values.  The module will see
    #  this, and replace the template values with the correct ones
    #  taken from the cryptographic calculations.  e.g.
    #
    #     update reply {
    #        WiMAX-FA-RK-Key = 0x00
    #        WiMAX-MSK = "%{EAP-MSK}"
    #    }
    #
    #  You may want to delete the MS-MPPE-*-Keys from the reply,
    #  as some WiMAX clients behave badly when those attributes
    #  are included.  See "raddb/modules/wimax", configuration
    #  entry "delete_mppe_keys" for more information.
    #
#    wimax

    #  If the WiMAX module did it's work, you may want to do more
    #  things here, like delete the MS-MPPE-*-Key attributes.
    #
    #    if (updated) {
    #        update reply {
    #            MS-MPPE-Recv-Key !* 0x00
    #            MS-MPPE-Send-Key !* 0x00
    #        }
    #    }

    #
    #  Access-Reject packets are sent through the REJECT sub-section of the
    #  post-auth section.
    #
    #  Add the ldap module name (or instance) if you have set 
    #  'edir_account_policy_check = yes' in the ldap module configuration
    #
    Post-Auth-Type REJECT {
        ldap
    }
}

#
#  When the server decides to proxy a request to a home server,
#  the proxied request is first passed through the pre-proxy
#  stage.  This stage can re-write the request, or decide to
#  cancel the proxy.
#
#  Only a few modules currently have this method.
#
pre-proxy {
#    attr_rewrite

    #  Uncomment the following line if you want to change attributes
    #  as defined in the preproxy_users file.
#    files

    #  Uncomment the following line if you want to filter requests
    #  sent to remote servers based on the rules defined in the
    #  'attrs.pre-proxy' file.
#    attr_filter.pre-proxy

    #  If you want to have a log of packets proxied to a home
    #  server, un-comment the following line, and the
    #  'detail pre_proxy_log' section, above.
#    pre_proxy_log
}

#
#  When the server receives a reply to a request it proxied
#  to a home server, the request may be massaged here, in the
#  post-proxy stage.
#
post-proxy {

    #  If you want to have a log of replies from a home server,
    #  un-comment the following line, and the 'detail post_proxy_log'
    #  section, above.
#    post_proxy_log

#    attr_rewrite

    #  Uncomment the following line if you want to filter replies from
    #  remote proxies based on the rules defined in the 'attrs' file.
#    attr_filter.post-proxy

    #
    #  If you are proxying LEAP, you MUST configure the EAP
    #  module, and you MUST list it here, in the post-proxy
    #  stage.
    #
    #  You MUST also use the 'nostrip' option in the 'realm'
    #  configuration.  Otherwise, the User-Name attribute
    #  in the proxied request will not match the user name
    #  hidden inside of the EAP packet, and the end server will
    #  reject the EAP request.
    #
    eap

    #
    #  If the server tries to proxy a request and fails, then the
    #  request is processed through the modules in this section.
    #
    #  The main use of this section is to permit robust proxying
    #  of accounting packets.  The server can be configured to
    #  proxy accounting packets as part of normal processing.
    #  Then, if the home server goes down, accounting packets can
    #  be logged to a local "detail" file, for processing with
    #  radrelay.  When the home server comes back up, radrelay
    #  will read the detail file, and send the packets to the
    #  home server.
    #
    #  With this configuration, the server always responds to
    #  Accounting-Requests from the NAS, but only writes
    #  accounting packets to disk if the home server is down.
    #
#    Post-Proxy-Type Fail {
#            detail
#    }

}" and my inner-tunnel file

"server inner-tunnel {

#
#  Un-comment the next section to perform test on the inner tunnel
#  without needing an outer tunnel session.  The tests will not be
#  exactly the same as when TTLS or PEAP are used, but they will
#  be close enough for many tests.
#
#listen {
#       ipaddr = 127.0.0.1
#       port = 18120
#       type = auth
#}


#  Authorization. First preprocess (hints and huntgroups files),
#  then realms, and finally look in the "users" file.
#
#  The order of the realm modules will determine the order that
#  we try to find a matching realm.
#
#  Make *sure* that 'preprocess' comes before any realm if you 
#  need to setup hints for the remote radius server
authorize {
    #
    #  The chap module will set 'Auth-Type := CHAP' if we are
    #  handling a CHAP request and Auth-Type has not already been set
    chap

    #
    #  If the users are logging in with an MS-CHAP-Challenge
    #  attribute for authentication, the mschap module will find
    #  the MS-CHAP-Challenge attribute, and add 'Auth-Type := MS-CHAP'
    #  to the request, which will cause the server to then use
    #  the mschap module for authentication.
    mschap

    #
    #  Pull crypt'd passwords from /etc/passwd or /etc/shadow,
    #  using the system API's to get the password.  If you want
    #  to read /etc/passwd or /etc/shadow directly, see the
    #  passwd module, above.
    #
    unix

    #
    #  Look for IPASS style 'realm/', and if not found, look for
    #  '@realm', and decide whether or not to proxy, based on
    #  that.
#    IPASS

    #
    #  If you are using multiple kinds of realms, you probably
    #  want to set "ignore_null = yes" for all of them.
    #  Otherwise, when the first style of realm doesn't match,
    #  the other styles won't be checked.
    #
    #  Note that proxying the inner tunnel authentication means
    #  that the user MAY use one identity in the outer session
    #  (e.g. "anonymous", and a different one here
    #  (e.g. "user at example.com").  The inner session will then be
    #  proxied elsewhere for authentication.  If you are not
    #  careful, this means that the user can cause you to forward
    #  the authentication to another RADIUS server, and have the
    #  accounting logs *not* sent to the other server.  This makes
    #  it difficult to bill people for their network activity.
    #
#    suffix
#    ntdomain

    #
    #  The "suffix" module takes care of stripping the domain
    #  (e.g. "@example.com") from the User-Name attribute, and the
    #  next few lines ensure that the request is not proxied.
    #
    #  If you want the inner tunnel request to be proxied, delete
    #  the next few lines.
    #
    update control {
           Proxy-To-Realm := LOCAL
    }

    #
    #  This module takes care of EAP-MSCHAPv2 authentication.
    #
    #  It also sets the EAP-Type attribute in the request
    #  attribute list to the EAP type from the packet.
    #
    #  The example below uses module failover to avoid querying all
    #  of the following modules if the EAP module returns "ok".
    #  Therefore, your LDAP and/or SQL servers will not be queried
    #  for the many packets that go back and forth to set up TTLS
    #  or PEAP.  The load on those servers will therefore be reduced.
    #
    eap {
        ok = return
    }

    #
    #  Read the 'users' file
    files

    #
    #  Look in an SQL database.  The schema of the database
    #  is meant to mirror the "users" file.
    #
    #  See "Authorization Queries" in sql.conf
#    sql

    #
    #  If you are using /etc/smbpasswd, and are also doing
    #  mschap authentication, the un-comment this line, and
    #  configure the 'etc_smbpasswd' module, above.
#    etc_smbpasswd

    #
    #  The ldap module will set Auth-Type to LDAP if it has not
    #  already been set
    ldap

    #
    #  Enforce daily limits on time spent logged in.
#    daily

    #
    # Use the checkval module
#    checkval

    expiration
    logintime

    #
    #  If no other module has claimed responsibility for
    #  authentication, then try to use PAP.  This allows the
    #  other modules listed above to add a "known good" password
    #  to the request, and to do nothing else.  The PAP module
    #  will then see that password, and use it to do PAP
    #  authentication.
    #
    #  This module should be listed last, so that the other modules
    #  get a chance to set Auth-Type for themselves.
    #
    pap
}


#  Authentication.
#
#
#  This section lists which modules are available for authentication.
#  Note that it does NOT mean 'try each module in order'.  It means
#  that a module from the 'authorize' section adds a configuration
#  attribute 'Auth-Type := FOO'.  That authentication type is then
#  used to pick the apropriate module from the list below.
#

#  In general, you SHOULD NOT set the Auth-Type attribute.  The server
#  will figure it out on its own, and will do the right thing.  The
#  most common side effect of erroneously setting the Auth-Type
#  attribute is that one authentication method will work, but the
#  others will not.
#
#  The common reasons to set the Auth-Type attribute by hand
#  is to either forcibly reject the user, or forcibly accept him.
#
authenticate {
    #
    #  PAP authentication, when a back-end database listed
    #  in the 'authorize' section supplies a password.  The
    #  password can be clear-text, or encrypted.
    Auth-Type PAP {
        pap
    }

    #
    #  Most people want CHAP authentication
    #  A back-end database listed in the 'authorize' section
    #  MUST supply a CLEAR TEXT password.  Encrypted passwords
    #  won't work.
    Auth-Type CHAP {
        chap
    }

    #
    #  MSCHAP authentication.
    Auth-Type MS-CHAP {
        mschap
    }

    #
    #  Pluggable Authentication Modules.
#    pam

    #
    #  See 'man getpwent' for information on how the 'unix'
    #  module checks the users password.  Note that packets
    #  containing CHAP-Password attributes CANNOT be authenticated
    #  against /etc/passwd!  See the FAQ for details.
    #  
    unix

    # Uncomment it if you want to use ldap for authentication
    #
    # Note that this means "check plain-text password against
    # the ldap database", which means that EAP won't work,
    # as it does not supply a plain-text password.
    Auth-Type LDAP {
        ldap
    }

    #
    #  Allow EAP authentication.
    eap
}

######################################################################
#
#    There are no accounting requests inside of EAP-TTLS or PEAP
#    tunnels.
#
######################################################################


#  Session database, used for checking Simultaneous-Use. Either the radutmp 
#  or rlm_sql module can handle this.
#  The rlm_sql module is *much* faster
session {
    radutmp

    #
    #  See "Simultaneous Use Checking Queries" in sql.conf
#    sql
}


#  Post-Authentication
#  Once we KNOW that the user has been authenticated, there are
#  additional steps we can take.
post-auth {
    # Note that we do NOT assign IP addresses here.
    # If you try to assign IP addresses for EAP authentication types,
    # it WILL NOT WORK.  You MUST use DHCP.

    #
    #  If you want to have a log of authentication replies,
    #  un-comment the following line, and the 'detail reply_log'
    #  section, above.
    reply_log

    #
    #  After authenticating the user, do another SQL query.
    #
    #  See "Authentication Logging Queries" in sql.conf
#    sql

    #
    #  Instead of sending the query to the SQL server,
    #  write it into a log file.
    #
#    sql_log

    #
    #  Un-comment the following if you have set
    #  'edir_account_policy_check = yes' in the ldap module sub-section of
    #  the 'modules' section.
    #
    ldap

    #
    #  Access-Reject packets are sent through the REJECT sub-section of the
    #  post-auth section.
    #
    #  Add the ldap module name (or instance) if you have set 
    #  'edir_account_policy_check = yes' in the ldap module configuration
    #
    Post-Auth-Type REJECT {
        ldap
    }

    #
    #  The example policy below updates the outer tunnel reply
    #  (usually Access-Accept) with the User-Name from the inner
    #  tunnel User-Name.  Since this section is processed in the
    #  context of the inner tunnel, "request" here means "inner
    #  tunnel request", and "outer.reply" means "outer tunnel
    #  reply attributes".
    #
    #  This example is most useful when the outer session contains
    #  a User-Name of "anonymous at ....", or a MAC address.  If it
    #  is enabled, the NAS SHOULD use the inner tunnel User-Name
    #  in subsequent accounting packets.  This makes it easier to
    #  track user sessions, as they will all be based on the real
    #  name, and not on "anonymous".
    #
    #  The problem with doing this is that it ALSO exposes the
    #  real user name to any intermediate proxies.  People use
    #  "anonymous" identifiers outside of the tunnel for a very
    #  good reason: it gives them more privacy.  Setting the reply
    #  to contain the real user name removes ALL privacy from
    #  their session.
    #
    #  If you want privacy to remain, see the
    #  Chargeable-User-Identity attribute from RFC 4372.  In order
    #  to use that attribute, you will have to allocate a
    #  per-session identifier for the user, and store it in a
    #  long-term database (e.g. SQL).  You should also use that
    #  attribute INSTEAD of the configuration below.
    #
    #update outer.reply {
    #    User-Name = "%{request:User-Name}"
    #}

}

#
#  When the server decides to proxy a request to a home server,
#  the proxied request is first passed through the pre-proxy
#  stage.  This stage can re-write the request, or decide to
#  cancel the proxy.
#
#  Only a few modules currently have this method.
#
pre-proxy {
#    attr_rewrite

    #  Uncomment the following line if you want to change attributes
    #  as defined in the preproxy_users file.
#    files

    #  Uncomment the following line if you want to filter requests
    #  sent to remote servers based on the rules defined in the
    #  'attrs.pre-proxy' file.
#    attr_filter.pre-proxy

    #  If you want to have a log of packets proxied to a home
    #  server, un-comment the following line, and the
    #  'detail pre_proxy_log' section, above.
#    pre_proxy_log
}

#
#  When the server receives a reply to a request it proxied
#  to a home server, the request may be massaged here, in the
#  post-proxy stage.
#
post-proxy {

    #  If you want to have a log of replies from a home server,
    #  un-comment the following line, and the 'detail post_proxy_log'
    #  section, above.
#    post_proxy_log

#    attr_rewrite

    #  Uncomment the following line if you want to filter replies from
    #  remote proxies based on the rules defined in the 'attrs' file.
#    attr_filter.post-proxy

    #
    #  If you are proxying LEAP, you MUST configure the EAP
    #  module, and you MUST list it here, in the post-proxy
    #  stage.
    #
    #  You MUST also use the 'nostrip' option in the 'realm'
    #  configuration.  Otherwise, the User-Name attribute
    #  in the proxied request will not match the user name
    #  hidden inside of the EAP packet, and the end server will
    #  reject the EAP request.
    #
    eap

    #
    #  If the server tries to proxy a request and fails, then the
    #  request is processed through the modules in this section.
    #
    #  The main use of this section is to permit robust proxying
    #  of accounting packets.  The server can be configured to
    #  proxy accounting packets as part of normal processing.
    #  Then, if the home server goes down, accounting packets can
    #  be logged to a local "detail" file, for processing with
    #  radrelay.  When the home server comes back up, radrelay
    #  will read the detail file, and send the packets to the
    #  home server.
    #
    #  With this configuration, the server always responds to
    #  Accounting-Requests from the NAS, but only writes
    #  accounting packets to disk if the home server is down.
    #
#    Post-Proxy-Type Fail {
#            detail
#    }

}

} # inner-tunnel server block"

and my ldap config file

"# Lightweight Directory Access Protocol (LDAP)
#
#  This module definition allows you to use LDAP for
#  authorization and authentication.
#
#  See raddb/sites-available/default for reference to the
#  ldap module in the authorize and authenticate sections.
#
#  However, LDAP can be used for authentication ONLY when the
#  Access-Request packet contains a clear-text User-Password
#  attribute.  LDAP authentication will NOT work for any other
#  authentication method.
#
#  This means that LDAP servers don't understand EAP.  If you
#  force "Auth-Type = LDAP", and then send the server a
#  request containing EAP authentication, then authentication
#  WILL NOT WORK.
#
#  The solution is to use the default configuration, which does
#  work.
#
#  Setting "Auth-Type = LDAP" is ALMOST ALWAYS WRONG.  We
#  really can't emphasize this enough.
#    
ldap {
    #
    #  Note that this needs to match the name in the LDAP
    #  server certificate, if you're using ldaps.
    server = "192.168.2.2"
    #identity = "cn=admin,ou=admins,o=missouri"
    #password = GOLDFLOOR59!
    basedn = "o=missouri"
    filter = "(uid=%{Stripped-User-Name:-%{User-Name}})"
    #base_filter = "(objectclass=radiusprofile)"

    #  How many connections to keep open to the LDAP server.
    #  This saves time over opening a new LDAP socket for
    #  every authentication request.
    ldap_connections_number = 5

    # seconds to wait for LDAP query to finish. default: 20
    timeout = 4

    #  seconds LDAP server has to process the query (server-side
    #  time limit). default: 20
    #
    #  LDAP_OPT_TIMELIMIT is set to this value.
    timelimit = 3

    #
    #  seconds to wait for response of the server. (network
    #   failures) default: 10
    #
    #  LDAP_OPT_NETWORK_TIMEOUT is set to this value.
    net_timeout = 1

    #
    #  This subsection configures the tls related items
    #  that control how FreeRADIUS connects to an LDAP
    #  server.  It contains all of the "tls_*" configuration
    #  entries used in older versions of FreeRADIUS.  Those
    #  configuration entries can still be used, but we recommend
    #  using these.
    #
    tls {
        # Set this to 'yes' to use TLS encrypted connections
        # to the LDAP database by using the StartTLS extended
        # operation.
        #            
        # The StartTLS operation is supposed to be
        # used with normal ldap connections instead of
        # using ldaps (port 689) connections
        start_tls = no

        # cacertfile    = /path/to/cacert.pem
        # cacertdir        = /path/to/ca/dir/
        # certfile        = /path/to/radius.crt
        # keyfile        = /path/to/radius.key
        # randfile        = /path/to/rnd

        #  Certificate Verification requirements.  Can be:
        #    "never" (don't even bother trying)
        #    "allow" (try, but don't fail if the cerificate
        #        can't be verified)
        #    "demand" (fail if the certificate doesn't verify.)
        #
        #    The default is "allow"
        # require_cert    = "allow"
    }

    # default_profile = "cn=radprofile,ou=wirelessusers,o=missouri"
    # profile_attribute = "radiusProfileDn"
    # access_attr = "dialupAccess"

    # Mapping of RADIUS dictionary attributes to LDAP
    # directory attributes.
    dictionary_mapping = ${confdir}/ldap.attrmap

    #  Set password_attribute = nspmPassword to get the
    #  user's password from a Novell eDirectory
    #  backend. This will work ONLY IF FreeRADIUS has been
    #  built with the --with-edir configure option.
    #
    #  See also the following links:
    #
    #  http://www.novell.com/coolsolutions/appnote/16745.html
    #  https://secure-support.novell.com/KanisaPlatform/Publishing/558/3009668_f.SAL_Public.html
    #
    #  Novell may require TLS encrypted sessions before returning
    #  the user's password.
    #
    # password_attribute = nspmPassword

    #  Un-comment the following to disable Novell
    #  eDirectory account policy check and intruder
    #  detection. This will work *only if* FreeRADIUS is
    #  configured to build with --with-edir option.
    #
    edir_account_policy_check = yes

    #
    #  Group membership checking.  Disabled by default.
    #
    # groupname_attribute = cn
    # groupmembership_filter = "(|(&(objectClass=GroupOfNames)(member=%{control:Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{control:Ldap-UserDn})))"
    # groupmembership_attribute = radiusGroupName

    # compare_check_items = yes
    # do_xlat = yes
    # access_attr_used_for_allow = yes

    #
    #  By default, if the packet contains a User-Password,
    #  and no other module is configured to handle the
    #  authentication, the LDAP module sets itself to do
    #  LDAP bind for authentication.
    #
    #  THIS WILL ONLY WORK FOR PAP AUTHENTICATION.
    #
    #  THIS WILL NOT WORK FOR CHAP, MS-CHAP, or 802.1x (EAP). 
    #
    #  You can disable this behavior by setting the following
    #  configuration entry to "no".
    #
    #  allowed values: {no, yes}
    # set_auth_type = yes

    #  ldap_debug: debug flag for LDAP SDK
    #  (see OpenLDAP documentation).  Set this to enable
    #  huge amounts of LDAP debugging on the screen.
    #  You should only use this if you are an LDAP expert.
    #
    #    default: 0x0000 (no debugging messages)
    #    Example:(LDAP_DEBUG_FILTER+LDAP_DEBUG_CONNS)
    #ldap_debug = 0x0028 
}"

What did I do wrong when I try to log on to the wireless network it still shows the PEAP certficte but it still says "incorrect username or password"





>>> <tnt at kalik.net> 11/09/09 11:22 AM >>>
> Hello i'm trying to setup Freeradius to do wireless authcation when I try
> to connect I get my peap certficte then it says "incorrect username or
> password" below is the debug output
...

> server inner-tunnel {
> +- entering group authorize {...}
> ++[chap] returns noop
> ++[mschap] returns noop
> ++[unix] returns notfound
> ++[control] returns notfound
> [eap] EAP packet type response id 109 length 67
> [eap] No EAP Start, assuming it's an on-going EAP conversation
> ++[eap] returns updated
> ++[files] returns noop
> ++[expiration] returns noop
> ++[logintime] returns noop
> ++[pap] returns noop
> Found Auth-Type = EAP
> +- entering group authenticate {...}
> [eap] Request found, released from the list
> [eap] EAP/mschapv2
> [eap] processing type mschapv2
> [mschapv2] +- entering group MS-CHAP {...}
> [mschap] No Cleartext-Password configured.  Cannot create LM-Password.
> [mschap] No Cleartext-Password configured.  Cannot create NT-Password.
> [mschap] Told to do MS-CHAPv2 for ghorchem with NT-Password
> [mschap] FAILED: No NT/LM-Password.  Cannot perform authentication.
> [mschap] FAILED: MS-CHAP2-Response is incorrect
> ++[mschap] returns reject

Where is your password? If it's in ldap, you haven't enabled ldap in
inner-tunnel virtual server.

Ivan Kalik
Kalik Informatika ISP

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20091109/c2800401/attachment.html>


More information about the Freeradius-Users mailing list