<html><head><meta http-equiv=Content-Type content="text/html; charset=windows-1250"><META name="Author" content="Novell GroupWise WebAccess"></head><body style='font-family: Tahoma, sans-serif; font-size: 13px; '>I'm still having trouble here is my sites-available default file<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 preprocess module takes care of sanitizing some bizarre<br> # attributes in the request, and turning them into attributes<br> # which are more standard.<br> #<br> # It takes care of processing the 'raddb/hints' and the<br> # 'raddb/huntgroups' files.<br> #<br> # It also adds the %{Client-IP-Address} attribute to the request.<br> preprocess<br><br> #<br> # If you want to have a log of authentication requests,<br> # un-comment the following line, and the 'detail auth_log'<br> # section, above.<br> auth_log<br><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> # If you have a Cisco SIP server authenticating against<br> # FreeRADIUS, uncomment the following line, and the 'digest'<br> # line in the 'authenticate' section.<br># digest<br><br> #<br> # The WiMAX specification says that the Calling-Station-Id<br> # is 6 octets of the MAC. This definition conflicts with<br> # RFC 3580, and all common RADIUS practices. Un-commenting<br> # the "wimax" module here means that it will fix the<br> # Calling-Station-Id attribute to the normal format as<br> # specified in RFC 3580 Section 3.21<br># wimax<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># suffix<br># ntdomain<br><br> #<br> # This module takes care of EAP-MD5, EAP-TLS, and EAP-LEAP<br> # 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> # As of 2.0, the EAP module returns "ok" in the authorize stage<br> # for TTLS and PEAP. In 1.x, it never returned "ok" here, so<br> # this change is compatible with older configurations.<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> # 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 in radiusd.conf.<br> #<br> unix<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> # If "status_server = yes", then Status-Server messages are passed<br> # through the following section, and ONLY the following section.<br> # This permits you to do DB queries, for example. If the modules<br> # listed here return "fail", then NO response is sent.<br> #<br># Autz-Type Status-Server {<br>#<br># }<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 (Auth-Type := Reject),<br># or to or forcibly accept the user (Auth-Type := Accept).<br>#<br># Note that Auth-Type := Accept will NOT work with EAP.<br>#<br># Please do not put "unlang" configurations into the "authenticate"<br># section. Put them in the "post-auth" section instead. That's what<br># the post-auth section is for.<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> # If you have a Cisco SIP server authenticating against<br> # FreeRADIUS, uncomment the following line, and the 'digest'<br> # line in the 'authorize' section.<br># digest<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># Pre-accounting. Decide which accounting type to use.<br>#<br>preacct {<br> preprocess<br><br> #<br> # Ensure that we have a semi-unique identifier for every<br> # request, and many NAS boxes are broken.<br> acct_unique<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> #<br> # Accounting requests are generally proxied to the same<br> # home server as authentication requests.<br># IPASS<br># suffix<br># ntdomain<br><br> #<br> # Read the 'acct_users' file<br> files<br>}<br><br>#<br># Accounting. Log the accounting data.<br>#<br>accounting {<br> #<br> # Create a 'detail'ed log of the packets.<br> # Note that accounting requests which are proxied<br> # are also logged in the detail file.<br> detail<br> daily<br><br> # Update the wtmp file<br> #<br> # If you don't use "radlast", you can delete this line.<br> unix<br><br> #<br> # For Simultaneous-Use tracking.<br> #<br> # Due to packet losses in the network, the data here<br> # may be incorrect. There is little we can do about it.<br> radutmp<br># sradutmp<br><br> # Return an address to the IP Pool when we see a stop record.<br># main_pool<br><br> #<br> # Log traffic to an SQL database.<br> #<br> # See "Accounting 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> # Cisco VoIP specific bulk accounting<br># pgsql-voip<br><br> # Filter attributes from the accounting response.<br> attr_filter.accounting_response<br><br> #<br> # See "Autz-Type Status-Server" for how this works.<br> #<br># Acct-Type Status-Server {<br>#<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> # Get an address from the IP Pool.<br># main_pool<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> exec<br><br> #<br> # Calculate the various WiMAX keys. In order for this to work,<br> # you will need to define the WiMAX NAI, usually via<br> #<br> # update request {<br> # WiMAX-MN-NAI = "%{User-Name}"<br> # }<br> #<br> # If you want various keys to be calculated, you will need to<br> # update the reply with "template" values. The module will see<br> # this, and replace the template values with the correct ones<br> # taken from the cryptographic calculations. e.g.<br> #<br> # update reply {<br> # WiMAX-FA-RK-Key = 0x00<br> # WiMAX-MSK = "%{EAP-MSK}"<br> # }<br> #<br> # You may want to delete the MS-MPPE-*-Keys from the reply,<br> # as some WiMAX clients behave badly when those attributes<br> # are included. See "raddb/modules/wimax", configuration<br> # entry "delete_mppe_keys" for more information.<br> #<br># wimax<br><br> # If the WiMAX module did it's work, you may want to do more<br> # things here, like delete the MS-MPPE-*-Key attributes.<br> #<br> # if (updated) {<br> # update reply {<br> # MS-MPPE-Recv-Key !* 0x00<br> # MS-MPPE-Send-Key !* 0x00<br> # }<br> # }<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>#<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>}" and my inner-tunnel file<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"<br><br>and my ldap config file<br><br>"# Lightweight Directory Access Protocol (LDAP)<br>#<br># This module definition allows you to use LDAP for<br># authorization and authentication.<br>#<br># See raddb/sites-available/default for reference to the<br># ldap module in the authorize and authenticate sections.<br>#<br># However, LDAP can be used for authentication ONLY when the<br># Access-Request packet contains a clear-text User-Password<br># attribute. LDAP authentication will NOT work for any other<br># authentication method.<br>#<br># This means that LDAP servers don't understand EAP. If you<br># force "Auth-Type = LDAP", and then send the server a<br># request containing EAP authentication, then authentication<br># WILL NOT WORK.<br>#<br># The solution is to use the default configuration, which does<br># work.<br>#<br># Setting "Auth-Type = LDAP" is ALMOST ALWAYS WRONG. We<br># really can't emphasize this enough.<br># <br>ldap {<br> #<br> # Note that this needs to match the name in the LDAP<br> # server certificate, if you're using ldaps.<br> server = "192.168.2.2"<br> #identity = "cn=admin,ou=admins,o=missouri"<br> #password = GOLDFLOOR59!<br> basedn = "o=missouri"<br> filter = "(uid=%{Stripped-User-Name:-%{User-Name}})"<br> #base_filter = "(objectclass=radiusprofile)"<br><br> # How many connections to keep open to the LDAP server.<br> # This saves time over opening a new LDAP socket for<br> # every authentication request.<br> ldap_connections_number = 5<br><br> # seconds to wait for LDAP query to finish. default: 20<br> timeout = 4<br><br> # seconds LDAP server has to process the query (server-side<br> # time limit). default: 20<br> #<br> # LDAP_OPT_TIMELIMIT is set to this value.<br> timelimit = 3<br><br> #<br> # seconds to wait for response of the server. (network<br> # failures) default: 10<br> #<br> # LDAP_OPT_NETWORK_TIMEOUT is set to this value.<br> net_timeout = 1<br><br> #<br> # This subsection configures the tls related items<br> # that control how FreeRADIUS connects to an LDAP<br> # server. It contains all of the "tls_*" configuration<br> # entries used in older versions of FreeRADIUS. Those<br> # configuration entries can still be used, but we recommend<br> # using these.<br> #<br> tls {<br> # Set this to 'yes' to use TLS encrypted connections<br> # to the LDAP database by using the StartTLS extended<br> # operation.<br> # <br> # The StartTLS operation is supposed to be<br> # used with normal ldap connections instead of<br> # using ldaps (port 689) connections<br> start_tls = no<br><br> # cacertfile = /path/to/cacert.pem<br> # cacertdir = /path/to/ca/dir/<br> # certfile = /path/to/radius.crt<br> # keyfile = /path/to/radius.key<br> # randfile = /path/to/rnd<br><br> # Certificate Verification requirements. Can be:<br> # "never" (don't even bother trying)<br> # "allow" (try, but don't fail if the cerificate<br> # can't be verified)<br> # "demand" (fail if the certificate doesn't verify.)<br> #<br> # The default is "allow"<br> # require_cert = "allow"<br> }<br><br> # default_profile = "cn=radprofile,ou=wirelessusers,o=missouri"<br> # profile_attribute = "radiusProfileDn"<br> # access_attr = "dialupAccess"<br><br> # Mapping of RADIUS dictionary attributes to LDAP<br> # directory attributes.<br> dictionary_mapping = ${confdir}/ldap.attrmap<br><br> # Set password_attribute = nspmPassword to get the<br> # user's password from a Novell eDirectory<br> # backend. This will work ONLY IF FreeRADIUS has been<br> # built with the --with-edir configure option.<br> #<br> # See also the following links:<br> #<br> # http://www.novell.com/coolsolutions/appnote/16745.html<br> # https://secure-support.novell.com/KanisaPlatform/Publishing/558/3009668_f.SAL_Public.html<br> #<br> # Novell may require TLS encrypted sessions before returning<br> # the user's password.<br> #<br> # password_attribute = nspmPassword<br><br> # Un-comment the following to disable Novell<br> # eDirectory account policy check and intruder<br> # detection. This will work *only if* FreeRADIUS is<br> # configured to build with --with-edir option.<br> #<br> edir_account_policy_check = yes<br><br> #<br> # Group membership checking. Disabled by default.<br> #<br> # groupname_attribute = cn<br> # groupmembership_filter = "(|(&(objectClass=GroupOfNames)(member=%{control:Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{control:Ldap-UserDn})))"<br> # groupmembership_attribute = radiusGroupName<br><br> # compare_check_items = yes<br> # do_xlat = yes<br> # access_attr_used_for_allow = yes<br><br> #<br> # By default, if the packet contains a User-Password,<br> # and no other module is configured to handle the<br> # authentication, the LDAP module sets itself to do<br> # LDAP bind for authentication.<br> #<br> # THIS WILL ONLY WORK FOR PAP AUTHENTICATION.<br> #<br> # THIS WILL NOT WORK FOR CHAP, MS-CHAP, or 802.1x (EAP). <br> #<br> # You can disable this behavior by setting the following<br> # configuration entry to "no".<br> #<br> # allowed values: {no, yes}<br> # set_auth_type = yes<br><br> # ldap_debug: debug flag for LDAP SDK<br> # (see OpenLDAP documentation). Set this to enable<br> # huge amounts of LDAP debugging on the screen.<br> # You should only use this if you are an LDAP expert.<br> #<br> # default: 0x0000 (no debugging messages)<br> # Example:(LDAP_DEBUG_FILTER+LDAP_DEBUG_CONNS)<br> #ldap_debug = 0x0028 <br>}"<br><br>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"<br><br><br><br><br><br>>>> <tnt@kalik.net> 11/09/09 11:22 AM >>><br>> Hello i'm trying to setup Freeradius to do wireless authcation when I try<br>> to connect I get my peap certficte then it says "incorrect username or<br>> password" below is the debug output<br>...<br><br>> server inner-tunnel {<br>> +- entering group authorize {...}<br>> ++[chap] returns noop<br>> ++[mschap] returns noop<br>> ++[unix] returns notfound<br>> ++[control] returns notfound<br>> [eap] EAP packet type response id 109 length 67<br>> [eap] No EAP Start, assuming it's an on-going EAP conversation<br>> ++[eap] returns updated<br>> ++[files] returns noop<br>> ++[expiration] returns noop<br>> ++[logintime] returns noop<br>> ++[pap] returns noop<br>> Found Auth-Type = EAP<br>> +- entering group authenticate {...}<br>> [eap] Request found, released from the list<br>> [eap] EAP/mschapv2<br>> [eap] processing type mschapv2<br>> [mschapv2] +- entering group MS-CHAP {...}<br>> [mschap] No Cleartext-Password configured. Cannot create LM-Password.<br>> [mschap] No Cleartext-Password configured. Cannot create NT-Password.<br>> [mschap] Told to do MS-CHAPv2 for ghorchem with NT-Password<br>> [mschap] FAILED: No NT/LM-Password. Cannot perform authentication.<br>> [mschap] FAILED: MS-CHAP2-Response is incorrect<br>> ++[mschap] returns reject<br><br>Where is your password? If it's in ldap, you haven't enabled ldap in<br>inner-tunnel virtual server.<br><br>Ivan Kalik<br>Kalik Informatika ISP<br><br>-<br>List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html<br></body></html>