Help PLease

Thu Mar 26 19:24:04 CET 2015

Alan, My inner tunnel file is not empty and has a bunch of configs in it.

server inner-tunnel {

        ntlm_auth

}

#

#  This next section is here to allow testing of the "inner-tunnel"

#  authentication methods, independently from the "default" server.

#  It is listening on "localhost", so that it can only be used from

#  the same machine.

#

#       $ radtest USER PASSWORD 127.0.0.1:18120 0 testing123

#

#  If it works, you have configured the inner tunnel correctly.  To check

#  if PEAP will work, use:

#

#       $ radtest -t mschap USER PASSWORD 127.0.0.1:18120 0 testing123

#

#  If that works, PEAP should work.  If that command doesn't work, then

#

#       FIX THE INNER TUNNEL CONFIGURATION UNTIL IT WORKS.

#

#  Do NOT keep testing PEAP.  It won't help.

#

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 {

        pap

        #  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 tthe 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 {

                ntlm_auth

#       }

        #

        #  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 {

                # log failed authentications in SQL, too.

#               sql

                attr_filter.access_reject

        }

        #

        #  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.

Adam Schappell
System Administrator II
Clearedge IT Solutions, LLC
10620 Guilford Road
Jessup, MD 20794
Office:443-212-4712
Fax:443-212-4809
www.ClearEdgeIT.com <http://www.clearedgeit.com/>

On Thu, Mar 26, 2015 at 2:11 PM, Alan DeKok <aland at deployingradius.com>
wrote:

> On Mar 26, 2015, at 12:57 PM, Adam Schappell <aschappell at clearedgeit.com>
> wrote:
>
> > Server tunnel is not empty though.
>
>   Yes, it is.  You’re looking at the wrong file.
>
> > File access permissions are setup
> > correctly. Im stuck guys :(
>
>   *Look* at the files.  Don’t assume they’re correct.  Look at every
> single aspect of them.
>
>   Odds are that raddb/sites-enabled/inner-tunnel is just an empty file,
> and NOT a symlink.
>
>   Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>