Chetan Gaonker | 7f4bf74 | 2016-05-04 15:56:08 -0700 | [diff] [blame] | 1 | # -*- text -*- |
| 2 | ###################################################################### |
| 3 | # |
| 4 | # This is a virtual server that handles *only* inner tunnel |
| 5 | # requests for EAP-TTLS and PEAP types. |
| 6 | # |
| 7 | # $Id: 11b6c12d845a1e8287888b3f0a0748d810b2c184 $ |
| 8 | # |
| 9 | ###################################################################### |
| 10 | |
| 11 | server inner-tunnel { |
| 12 | |
| 13 | # |
| 14 | # This next section is here to allow testing of the "inner-tunnel" |
| 15 | # authentication methods, independently from the "default" server. |
| 16 | # It is listening on "localhost", so that it can only be used from |
| 17 | # the same machine. |
| 18 | # |
| 19 | # $ radtest USER PASSWORD 127.0.0.1:18120 0 testing123 |
| 20 | # |
| 21 | # If it works, you have configured the inner tunnel correctly. To check |
| 22 | # if PEAP will work, use: |
| 23 | # |
| 24 | # $ radtest -t mschap USER PASSWORD 127.0.0.1:18120 0 testing123 |
| 25 | # |
| 26 | # If that works, PEAP should work. If that command doesn't work, then |
| 27 | # |
| 28 | # FIX THE INNER TUNNEL CONFIGURATION SO THAT IT WORKS. |
| 29 | # |
| 30 | # Do NOT do any PEAP tests. It won't help. Instead, concentrate |
| 31 | # on fixing the inner tunnel configuration. DO NOTHING ELSE. |
| 32 | # |
| 33 | listen { |
| 34 | ipaddr = 127.0.0.1 |
| 35 | port = 18120 |
| 36 | type = auth |
| 37 | } |
| 38 | |
| 39 | |
| 40 | # Authorization. First preprocess (hints and huntgroups files), |
| 41 | # then realms, and finally look in the "users" file. |
| 42 | # |
| 43 | # The order of the realm modules will determine the order that |
| 44 | # we try to find a matching realm. |
| 45 | # |
| 46 | # Make *sure* that 'preprocess' comes before any realm if you |
| 47 | # need to setup hints for the remote radius server |
| 48 | authorize { |
| 49 | # |
| 50 | # The chap module will set 'Auth-Type := CHAP' if we are |
| 51 | # handling a CHAP request and Auth-Type has not already been set |
| 52 | chap |
| 53 | |
| 54 | # |
| 55 | # If the users are logging in with an MS-CHAP-Challenge |
| 56 | # attribute for authentication, the mschap module will find |
| 57 | # the MS-CHAP-Challenge attribute, and add 'Auth-Type := MS-CHAP' |
| 58 | # to the request, which will cause the server to then use |
| 59 | # the mschap module for authentication. |
| 60 | mschap |
| 61 | |
| 62 | # |
| 63 | # Pull crypt'd passwords from /etc/passwd or /etc/shadow, |
| 64 | # using the system API's to get the password. If you want |
| 65 | # to read /etc/passwd or /etc/shadow directly, see the |
| 66 | # passwd module, above. |
| 67 | # |
| 68 | # unix |
| 69 | |
| 70 | # |
| 71 | # Look for IPASS style 'realm/', and if not found, look for |
| 72 | # '@realm', and decide whether or not to proxy, based on |
| 73 | # that. |
| 74 | # IPASS |
| 75 | |
| 76 | # |
| 77 | # If you are using multiple kinds of realms, you probably |
| 78 | # want to set "ignore_null = yes" for all of them. |
| 79 | # Otherwise, when the first style of realm doesn't match, |
| 80 | # the other styles won't be checked. |
| 81 | # |
| 82 | # Note that proxying the inner tunnel authentication means |
| 83 | # that the user MAY use one identity in the outer session |
| 84 | # (e.g. "anonymous", and a different one here |
| 85 | # (e.g. "user@example.com"). The inner session will then be |
| 86 | # proxied elsewhere for authentication. If you are not |
| 87 | # careful, this means that the user can cause you to forward |
| 88 | # the authentication to another RADIUS server, and have the |
| 89 | # accounting logs *not* sent to the other server. This makes |
| 90 | # it difficult to bill people for their network activity. |
| 91 | # |
| 92 | suffix |
| 93 | # ntdomain |
| 94 | |
| 95 | # |
| 96 | # The "suffix" module takes care of stripping the domain |
| 97 | # (e.g. "@example.com") from the User-Name attribute, and the |
| 98 | # next few lines ensure that the request is not proxied. |
| 99 | # |
| 100 | # If you want the inner tunnel request to be proxied, delete |
| 101 | # the next few lines. |
| 102 | # |
| 103 | update control { |
| 104 | Proxy-To-Realm := LOCAL |
| 105 | } |
| 106 | |
| 107 | # |
| 108 | # This module takes care of EAP-MSCHAPv2 authentication. |
| 109 | # |
| 110 | # It also sets the EAP-Type attribute in the request |
| 111 | # attribute list to the EAP type from the packet. |
| 112 | # |
| 113 | # The example below uses module failover to avoid querying all |
| 114 | # of the following modules if the EAP module returns "ok". |
| 115 | # Therefore, your LDAP and/or SQL servers will not be queried |
| 116 | # for the many packets that go back and forth to set up TTLS |
| 117 | # or PEAP. The load on those servers will therefore be reduced. |
| 118 | # |
| 119 | eap { |
| 120 | ok = return |
| 121 | } |
| 122 | |
| 123 | # |
| 124 | # Read the 'users' file |
| 125 | files |
| 126 | |
| 127 | # |
| 128 | # Look in an SQL database. The schema of the database |
| 129 | # is meant to mirror the "users" file. |
| 130 | # |
| 131 | # See "Authorization Queries" in sql.conf |
| 132 | -sql |
| 133 | |
| 134 | # |
| 135 | # If you are using /etc/smbpasswd, and are also doing |
| 136 | # mschap authentication, the un-comment this line, and |
| 137 | # configure the 'etc_smbpasswd' module, above. |
| 138 | # etc_smbpasswd |
| 139 | |
| 140 | # |
| 141 | # The ldap module reads passwords from the LDAP database. |
| 142 | -ldap |
| 143 | |
| 144 | # |
| 145 | # Enforce daily limits on time spent logged in. |
| 146 | # daily |
| 147 | |
| 148 | expiration |
| 149 | logintime |
| 150 | |
| 151 | # |
| 152 | # If no other module has claimed responsibility for |
| 153 | # authentication, then try to use PAP. This allows the |
| 154 | # other modules listed above to add a "known good" password |
| 155 | # to the request, and to do nothing else. The PAP module |
| 156 | # will then see that password, and use it to do PAP |
| 157 | # authentication. |
| 158 | # |
| 159 | # This module should be listed last, so that the other modules |
| 160 | # get a chance to set Auth-Type for themselves. |
| 161 | # |
| 162 | pap |
| 163 | } |
| 164 | |
| 165 | |
| 166 | # Authentication. |
| 167 | # |
| 168 | # |
| 169 | # This section lists which modules are available for authentication. |
| 170 | # Note that it does NOT mean 'try each module in order'. It means |
| 171 | # that a module from the 'authorize' section adds a configuration |
| 172 | # attribute 'Auth-Type := FOO'. That authentication type is then |
| 173 | # used to pick the appropriate module from the list below. |
| 174 | # |
| 175 | |
| 176 | # In general, you SHOULD NOT set the Auth-Type attribute. The server |
| 177 | # will figure it out on its own, and will do the right thing. The |
| 178 | # most common side effect of erroneously setting the Auth-Type |
| 179 | # attribute is that one authentication method will work, but the |
| 180 | # others will not. |
| 181 | # |
| 182 | # The common reasons to set the Auth-Type attribute by hand |
| 183 | # is to either forcibly reject the user, or forcibly accept him. |
| 184 | # |
| 185 | authenticate { |
| 186 | # |
| 187 | # PAP authentication, when a back-end database listed |
| 188 | # in the 'authorize' section supplies a password. The |
| 189 | # password can be clear-text, or encrypted. |
| 190 | Auth-Type PAP { |
| 191 | pap |
| 192 | } |
| 193 | |
| 194 | # |
| 195 | # Most people want CHAP authentication |
| 196 | # A back-end database listed in the 'authorize' section |
| 197 | # MUST supply a CLEAR TEXT password. Encrypted passwords |
| 198 | # won't work. |
| 199 | Auth-Type CHAP { |
| 200 | chap |
| 201 | } |
| 202 | |
| 203 | # |
| 204 | # MSCHAP authentication. |
| 205 | Auth-Type MS-CHAP { |
| 206 | mschap |
| 207 | } |
| 208 | |
| 209 | # |
| 210 | # Pluggable Authentication Modules. |
| 211 | # pam |
| 212 | |
| 213 | # Uncomment it if you want to use ldap for authentication |
| 214 | # |
| 215 | # Note that this means "check plain-text password against |
| 216 | # the ldap database", which means that EAP won't work, |
| 217 | # as it does not supply a plain-text password. |
| 218 | # |
| 219 | # We do NOT recommend using this. LDAP servers are databases. |
| 220 | # They are NOT authentication servers. FreeRADIUS is an |
| 221 | # authentication server, and knows what to do with authentication. |
| 222 | # LDAP servers do not. |
| 223 | # |
| 224 | # Auth-Type LDAP { |
| 225 | # ldap |
| 226 | # } |
| 227 | |
| 228 | # |
| 229 | # Allow EAP authentication. |
| 230 | eap |
| 231 | } |
| 232 | |
| 233 | ###################################################################### |
| 234 | # |
| 235 | # There are no accounting requests inside of EAP-TTLS or PEAP |
| 236 | # tunnels. |
| 237 | # |
| 238 | ###################################################################### |
| 239 | |
| 240 | |
| 241 | # Session database, used for checking Simultaneous-Use. Either the radutmp |
| 242 | # or rlm_sql module can handle this. |
| 243 | # The rlm_sql module is *much* faster |
| 244 | session { |
| 245 | radutmp |
| 246 | |
| 247 | # |
| 248 | # See "Simultaneous Use Checking Queries" in sql.conf |
| 249 | # sql |
| 250 | } |
| 251 | |
| 252 | |
| 253 | # Post-Authentication |
| 254 | # Once we KNOW that the user has been authenticated, there are |
| 255 | # additional steps we can take. |
| 256 | post-auth { |
| 257 | # If you want privacy to remain, see the |
| 258 | # Chargeable-User-Identity attribute from RFC 4372. |
| 259 | # If you want to use it just uncomment the line below. |
| 260 | # cui-inner |
| 261 | |
| 262 | # |
| 263 | # If you want to have a log of authentication replies, |
| 264 | # un-comment the following line, and enable the |
| 265 | # 'detail reply_log' module. |
| 266 | # reply_log |
| 267 | |
| 268 | # |
| 269 | # After authenticating the user, do another SQL query. |
| 270 | # |
| 271 | # See "Authentication Logging Queries" in sql.conf |
| 272 | -sql |
| 273 | |
| 274 | # |
| 275 | # Instead of sending the query to the SQL server, |
| 276 | # write it into a log file. |
| 277 | # |
| 278 | # sql_log |
| 279 | |
| 280 | # |
| 281 | # Un-comment the following if you have set |
| 282 | # 'edir_account_policy_check = yes' in the ldap module sub-section of |
| 283 | # the 'modules' section. |
| 284 | # |
| 285 | # ldap |
| 286 | |
| 287 | # |
| 288 | # Access-Reject packets are sent through the REJECT sub-section of the |
| 289 | # post-auth section. |
| 290 | # |
| 291 | # Add the ldap module name (or instance) if you have set |
| 292 | # 'edir_account_policy_check = yes' in the ldap module configuration |
| 293 | # |
| 294 | Post-Auth-Type REJECT { |
| 295 | # log failed authentications in SQL, too. |
| 296 | -sql |
| 297 | attr_filter.access_reject |
| 298 | } |
| 299 | |
| 300 | # |
| 301 | # The example policy below updates the outer tunnel reply |
| 302 | # (usually Access-Accept) with the User-Name from the inner |
| 303 | # tunnel User-Name. Since this section is processed in the |
| 304 | # context of the inner tunnel, "request" here means "inner |
| 305 | # tunnel request", and "outer.reply" means "outer tunnel |
| 306 | # reply attributes". |
| 307 | # |
| 308 | # This example is most useful when the outer session contains |
| 309 | # a User-Name of "anonymous@....", or a MAC address. If it |
| 310 | # is enabled, the NAS SHOULD use the inner tunnel User-Name |
| 311 | # in subsequent accounting packets. This makes it easier to |
| 312 | # track user sessions, as they will all be based on the real |
| 313 | # name, and not on "anonymous". |
| 314 | # |
| 315 | # The problem with doing this is that it ALSO exposes the |
| 316 | # real user name to any intermediate proxies. People use |
| 317 | # "anonymous" identifiers outside of the tunnel for a very |
| 318 | # good reason: it gives them more privacy. Setting the reply |
| 319 | # to contain the real user name removes ALL privacy from |
| 320 | # their session. |
| 321 | # |
| 322 | # If you still want to use the inner tunnel User-Name then |
| 323 | # uncomment the section below, otherwise you may want |
| 324 | # to use Chargeable-User-Identity attribute from RFC 4372. |
| 325 | # See further on. |
| 326 | #update outer.reply { |
| 327 | # User-Name = "%{request:User-Name}" |
| 328 | #} |
| 329 | # |
| 330 | } |
| 331 | |
| 332 | # |
| 333 | # When the server decides to proxy a request to a home server, |
| 334 | # the proxied request is first passed through the pre-proxy |
| 335 | # stage. This stage can re-write the request, or decide to |
| 336 | # cancel the proxy. |
| 337 | # |
| 338 | # Only a few modules currently have this method. |
| 339 | # |
| 340 | pre-proxy { |
| 341 | # Uncomment the following line if you want to change attributes |
| 342 | # as defined in the preproxy_users file. |
| 343 | # files |
| 344 | |
| 345 | # Uncomment the following line if you want to filter requests |
| 346 | # sent to remote servers based on the rules defined in the |
| 347 | # 'attrs.pre-proxy' file. |
| 348 | # attr_filter.pre-proxy |
| 349 | |
| 350 | # If you want to have a log of packets proxied to a home |
| 351 | # server, un-comment the following line, and the |
| 352 | # 'detail pre_proxy_log' section, above. |
| 353 | # pre_proxy_log |
| 354 | } |
| 355 | |
| 356 | # |
| 357 | # When the server receives a reply to a request it proxied |
| 358 | # to a home server, the request may be massaged here, in the |
| 359 | # post-proxy stage. |
| 360 | # |
| 361 | post-proxy { |
| 362 | |
| 363 | # If you want to have a log of replies from a home server, |
| 364 | # un-comment the following line, and the 'detail post_proxy_log' |
| 365 | # section, above. |
| 366 | # post_proxy_log |
| 367 | |
| 368 | # Uncomment the following line if you want to filter replies from |
| 369 | # remote proxies based on the rules defined in the 'attrs' file. |
| 370 | # attr_filter.post-proxy |
| 371 | |
| 372 | # |
| 373 | # If you are proxying LEAP, you MUST configure the EAP |
| 374 | # module, and you MUST list it here, in the post-proxy |
| 375 | # stage. |
| 376 | # |
| 377 | # You MUST also use the 'nostrip' option in the 'realm' |
| 378 | # configuration. Otherwise, the User-Name attribute |
| 379 | # in the proxied request will not match the user name |
| 380 | # hidden inside of the EAP packet, and the end server will |
| 381 | # reject the EAP request. |
| 382 | # |
| 383 | eap |
| 384 | |
| 385 | # |
| 386 | # If the server tries to proxy a request and fails, then the |
| 387 | # request is processed through the modules in this section. |
| 388 | # |
| 389 | # The main use of this section is to permit robust proxying |
| 390 | # of accounting packets. The server can be configured to |
| 391 | # proxy accounting packets as part of normal processing. |
| 392 | # Then, if the home server goes down, accounting packets can |
| 393 | # be logged to a local "detail" file, for processing with |
| 394 | # radrelay. When the home server comes back up, radrelay |
| 395 | # will read the detail file, and send the packets to the |
| 396 | # home server. |
| 397 | # |
| 398 | # With this configuration, the server always responds to |
| 399 | # Accounting-Requests from the NAS, but only writes |
| 400 | # accounting packets to disk if the home server is down. |
| 401 | # |
| 402 | # Post-Proxy-Type Fail { |
| 403 | # detail |
| 404 | # } |
| 405 | |
| 406 | } |
| 407 | |
| 408 | } # inner-tunnel server block |