Freeradius set up help

Horchem Gary ghorchem at gary-springfield-mo.net
Tue Nov 10 04:10:06 CET 2009


let me try to send this again the last one I sent the list server said it was too large I found the file and uncommented any # ldap lines I tried to login again and got this logging error "++[eap] returns reject
Failed to authenticate the user.
Login incorrect: [ghorchem/<via Auth-Type = EAP>] (from client Server-3 port 0 via TLS tunnel)
} # server inner-tunnel
 here is my inner-tunnel config "}" inner-tunnel config: "######################################################################
#
#    This is a virtual server that handles *only* inner tunnel
#    requests for EAP-TTLS and PEAP types.
#
#    $Id$
#
######################################################################

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" did I miss something?



>>> <tnt at kalik.net> 11/9/2009 5:38 PM >>>
> Where in the file do I enable LDAP

Same place as in default one - authorize.

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/d8dd9f4e/attachment.html>


More information about the Freeradius-Users mailing list