<HTML><HEAD>
<META content="text/html; charset=utf-8" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.18852"></HEAD>
<BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Segoe UI">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<BR>Failed to authenticate the user.<BR>Login incorrect: [ghorchem/<via Auth-Type = EAP>] (from client Server-3 port 0 via TLS tunnel)<BR>} # server inner-tunnel<BR> here is my inner-tunnel config "}" inner-tunnel config: "######################################################################<BR>#<BR># This is a virtual server that handles *only* inner tunnel<BR># requests for EAP-TTLS and PEAP types.<BR>#<BR># $Id$<BR>#<BR>######################################################################<BR><BR>server inner-tunnel {<BR><BR>#<BR># Un-comment the next section to perform test on the inner tunnel<BR># without needing an outer tunnel session. The tests will not be<BR># exactly the same as when TTLS or PEAP are used, but they will<BR># be close enough for many tests.<BR>#<BR>#listen {<BR># ipaddr = 127.0.0.1<BR># port = 18120<BR># type = auth<BR>#}<BR><BR><BR># Authorization. First preprocess (hints and huntgroups files),<BR># then realms, and finally look in the "users" file.<BR>#<BR># The order of the realm modules will determine the order that<BR># we try to find a matching realm.<BR>#<BR># Make *sure* that 'preprocess' comes before any realm if you <BR># need to setup hints for the remote radius server<BR>authorize {<BR> #<BR> # The chap module will set 'Auth-Type := CHAP' if we are<BR> # handling a CHAP request and Auth-Type has not already been set<BR> chap<BR><BR> #<BR> # If the users are logging in with an MS-CHAP-Challenge<BR> # attribute for authentication, the mschap module will find<BR> # the MS-CHAP-Challenge attribute, and add 'Auth-Type := MS-CHAP'<BR> # to the request, which will cause the server to then use<BR> # the mschap module for authentication.<BR> mschap<BR><BR> #<BR> # Pull crypt'd passwords from /etc/passwd or /etc/shadow,<BR> # using the system API's to get the password. If you want<BR> # to read /etc/passwd or /etc/shadow directly, see the<BR> # passwd module, above.<BR> #<BR> unix<BR><BR> #<BR> # Look for IPASS style 'realm/', and if not found, look for<BR> # '@realm', and decide whether or not to proxy, based on<BR> # that.<BR># IPASS<BR><BR> #<BR> # If you are using multiple kinds of realms, you probably<BR> # want to set "ignore_null = yes" for all of them.<BR> # Otherwise, when the first style of realm doesn't match,<BR> # the other styles won't be checked.<BR> #<BR> # Note that proxying the inner tunnel authentication means<BR> # that the user MAY use one identity in the outer session<BR> # (e.g. "anonymous", and a different one here<BR> # (e.g. "user@example.com"). The inner session will then be<BR> # proxied elsewhere for authentication. If you are not<BR> # careful, this means that the user can cause you to forward<BR> # the authentication to another RADIUS server, and have the<BR> # accounting logs *not* sent to the other server. This makes<BR> # it difficult to bill people for their network activity.<BR> #<BR># suffix<BR># ntdomain<BR><BR> #<BR> # The "suffix" module takes care of stripping the domain<BR> # (e.g. "@example.com") from the User-Name attribute, and the<BR> # next few lines ensure that the request is not proxied.<BR> #<BR> # If you want the inner tunnel request to be proxied, delete<BR> # the next few lines.<BR> #<BR> update control {<BR> Proxy-To-Realm := LOCAL<BR> }<BR><BR> #<BR> # This module takes care of EAP-MSCHAPv2 authentication.<BR> #<BR> # It also sets the EAP-Type attribute in the request<BR> # attribute list to the EAP type from the packet.<BR> #<BR> # The example below uses module failover to avoid querying all<BR> # of the following modules if the EAP module returns "ok".<BR> # Therefore, your LDAP and/or SQL servers will not be queried<BR> # for the many packets that go back and forth to set up TTLS<BR> # or PEAP. The load on those servers will therefore be reduced.<BR> #<BR> eap {<BR> ok = return<BR> }<BR><BR> #<BR> # Read the 'users' file<BR> files<BR><BR> #<BR> # Look in an SQL database. The schema of the database<BR> # is meant to mirror the "users" file.<BR> #<BR> # See "Authorization Queries" in sql.conf<BR># sql<BR><BR> #<BR> # If you are using /etc/smbpasswd, and are also doing<BR> # mschap authentication, the un-comment this line, and<BR> # configure the 'etc_smbpasswd' module, above.<BR># etc_smbpasswd<BR><BR> #<BR> # The ldap module will set Auth-Type to LDAP if it has not<BR> # already been set<BR> ldap<BR><BR> #<BR> # Enforce daily limits on time spent logged in.<BR># daily<BR><BR> #<BR> # Use the checkval module<BR># checkval<BR><BR> expiration<BR> logintime<BR><BR> #<BR> # If no other module has claimed responsibility for<BR> # authentication, then try to use PAP. This allows the<BR> # other modules listed above to add a "known good" password<BR> # to the request, and to do nothing else. The PAP module<BR> # will then see that password, and use it to do PAP<BR> # authentication.<BR> #<BR> # This module should be listed last, so that the other modules<BR> # get a chance to set Auth-Type for themselves.<BR> #<BR> pap<BR>}<BR><BR><BR># Authentication.<BR>#<BR>#<BR># This section lists which modules are available for authentication.<BR># Note that it does NOT mean 'try each module in order'. It means<BR># that a module from the 'authorize' section adds a configuration<BR># attribute 'Auth-Type := FOO'. That authentication type is then<BR># used to pick the apropriate module from the list below.<BR>#<BR><BR># In general, you SHOULD NOT set the Auth-Type attribute. The server<BR># will figure it out on its own, and will do the right thing. The<BR># most common side effect of erroneously setting the Auth-Type<BR># attribute is that one authentication method will work, but the<BR># others will not.<BR>#<BR># The common reasons to set the Auth-Type attribute by hand<BR># is to either forcibly reject the user, or forcibly accept him.<BR>#<BR>authenticate {<BR> #<BR> # PAP authentication, when a back-end database listed<BR> # in the 'authorize' section supplies a password. The<BR> # password can be clear-text, or encrypted.<BR> Auth-Type PAP {<BR> pap<BR> }<BR><BR> #<BR> # Most people want CHAP authentication<BR> # A back-end database listed in the 'authorize' section<BR> # MUST supply a CLEAR TEXT password. Encrypted passwords<BR> # won't work.<BR> Auth-Type CHAP {<BR> chap<BR> }<BR><BR> #<BR> # MSCHAP authentication.<BR> Auth-Type MS-CHAP {<BR> mschap<BR> }<BR><BR> #<BR> # Pluggable Authentication Modules.<BR># pam<BR><BR> #<BR> # See 'man getpwent' for information on how the 'unix'<BR> # module checks the users password. Note that packets<BR> # containing CHAP-Password attributes CANNOT be authenticated<BR> # against /etc/passwd! See the FAQ for details.<BR> # <BR> unix<BR><BR> # Uncomment it if you want to use ldap for authentication<BR> #<BR> # Note that this means "check plain-text password against<BR> # the ldap database", which means that EAP won't work,<BR> # as it does not supply a plain-text password.<BR> Auth-Type LDAP {<BR> ldap<BR> }<BR><BR> #<BR> # Allow EAP authentication.<BR> eap<BR>}<BR><BR>######################################################################<BR>#<BR># There are no accounting requests inside of EAP-TTLS or PEAP<BR># tunnels.<BR>#<BR>######################################################################<BR><BR><BR># Session database, used for checking Simultaneous-Use. Either the radutmp <BR># or rlm_sql module can handle this.<BR># The rlm_sql module is *much* faster<BR>session {<BR> radutmp<BR><BR> #<BR> # See "Simultaneous Use Checking Queries" in sql.conf<BR># sql<BR>}<BR><BR><BR># Post-Authentication<BR># Once we KNOW that the user has been authenticated, there are<BR># additional steps we can take.<BR>post-auth {<BR> # Note that we do NOT assign IP addresses here.<BR> # If you try to assign IP addresses for EAP authentication types,<BR> # it WILL NOT WORK. You MUST use DHCP.<BR><BR> #<BR> # If you want to have a log of authentication replies,<BR> # un-comment the following line, and the 'detail reply_log'<BR> # section, above.<BR> reply_log<BR><BR> #<BR> # After authenticating the user, do another SQL query.<BR> #<BR> # See "Authentication Logging Queries" in sql.conf<BR># sql<BR><BR> #<BR> # Instead of sending the query to the SQL server,<BR> # write it into a log file.<BR> #<BR># sql_log<BR><BR> #<BR> # Un-comment the following if you have set<BR> # 'edir_account_policy_check = yes' in the ldap module sub-section of<BR> # the 'modules' section.<BR> #<BR> ldap<BR><BR> #<BR> # Access-Reject packets are sent through the REJECT sub-section of the<BR> # post-auth section.<BR> #<BR> # Add the ldap module name (or instance) if you have set <BR> # 'edir_account_policy_check = yes' in the ldap module configuration<BR> #<BR> Post-Auth-Type REJECT {<BR> ldap<BR> }<BR><BR> #<BR> # The example policy below updates the outer tunnel reply<BR> # (usually Access-Accept) with the User-Name from the inner<BR> # tunnel User-Name. Since this section is processed in the<BR> # context of the inner tunnel, "request" here means "inner<BR> # tunnel request", and "outer.reply" means "outer tunnel<BR> # reply attributes".<BR> #<BR> # This example is most useful when the outer session contains<BR> # a User-Name of "anonymous@....", or a MAC address. If it<BR> # is enabled, the NAS SHOULD use the inner tunnel User-Name<BR> # in subsequent accounting packets. This makes it easier to<BR> # track user sessions, as they will all be based on the real<BR> # name, and not on "anonymous".<BR> #<BR> # The problem with doing this is that it ALSO exposes the<BR> # real user name to any intermediate proxies. People use<BR> # "anonymous" identifiers outside of the tunnel for a very<BR> # good reason: it gives them more privacy. Setting the reply<BR> # to contain the real user name removes ALL privacy from<BR> # their session.<BR> #<BR> # If you want privacy to remain, see the<BR> # Chargeable-User-Identity attribute from RFC 4372. In order<BR> # to use that attribute, you will have to allocate a<BR> # per-session identifier for the user, and store it in a<BR> # long-term database (e.g. SQL). You should also use that<BR> # attribute INSTEAD of the configuration below.<BR> #<BR> #update outer.reply {<BR> # User-Name = "%{request:User-Name}"<BR> #}<BR><BR>}<BR><BR>#<BR># When the server decides to proxy a request to a home server,<BR># the proxied request is first passed through the pre-proxy<BR># stage. This stage can re-write the request, or decide to<BR># cancel the proxy.<BR>#<BR># Only a few modules currently have this method.<BR>#<BR>pre-proxy {<BR># attr_rewrite<BR><BR> # Uncomment the following line if you want to change attributes<BR> # as defined in the preproxy_users file.<BR># files<BR><BR> # Uncomment the following line if you want to filter requests<BR> # sent to remote servers based on the rules defined in the<BR> # 'attrs.pre-proxy' file.<BR># attr_filter.pre-proxy<BR><BR> # If you want to have a log of packets proxied to a home<BR> # server, un-comment the following line, and the<BR> # 'detail pre_proxy_log' section, above.<BR># pre_proxy_log<BR>}<BR><BR>#<BR># When the server receives a reply to a request it proxied<BR># to a home server, the request may be massaged here, in the<BR># post-proxy stage.<BR>#<BR>post-proxy {<BR><BR> # If you want to have a log of replies from a home server,<BR> # un-comment the following line, and the 'detail post_proxy_log'<BR> # section, above.<BR># post_proxy_log<BR><BR># attr_rewrite<BR><BR> # Uncomment the following line if you want to filter replies from<BR> # remote proxies based on the rules defined in the 'attrs' file.<BR># attr_filter.post-proxy<BR><BR> #<BR> # If you are proxying LEAP, you MUST configure the EAP<BR> # module, and you MUST list it here, in the post-proxy<BR> # stage.<BR> #<BR> # You MUST also use the 'nostrip' option in the 'realm'<BR> # configuration. Otherwise, the User-Name attribute<BR> # in the proxied request will not match the user name<BR> # hidden inside of the EAP packet, and the end server will<BR> # reject the EAP request.<BR> #<BR> eap<BR><BR> #<BR> # If the server tries to proxy a request and fails, then the<BR> # request is processed through the modules in this section.<BR> #<BR> # The main use of this section is to permit robust proxying<BR> # of accounting packets. The server can be configured to<BR> # proxy accounting packets as part of normal processing.<BR> # Then, if the home server goes down, accounting packets can<BR> # be logged to a local "detail" file, for processing with<BR> # radrelay. When the home server comes back up, radrelay<BR> # will read the detail file, and send the packets to the<BR> # home server.<BR> #<BR> # With this configuration, the server always responds to<BR> # Accounting-Requests from the NAS, but only writes<BR> # accounting packets to disk if the home server is down.<BR> #<BR># Post-Proxy-Type Fail {<BR># detail<BR># }<BR><BR>}<BR><BR>} # inner-tunnel server block" did I miss something?<BR><BR><BR><BR>>>> <tnt@kalik.net> 11/9/2009 5:38 PM >>><BR>> Where in the file do I enable LDAP<BR><BR>Same place as in default one - authorize.<BR><BR>Ivan Kalik<BR>Kalik Informatika ISP<BR><BR>-<BR>List info/subscribe/unsubscribe? See <A href="http://www.freeradius.org/list/users.html">http://www.freeradius.org/list/users.html</A><BR></BODY></HTML>