Table of Contents Table of contents: Radiator® AAA Server <AuthBy NTLM> 3.74 - <AuthBy NTLM> <Route> 3.76 - <Route>

3.75. <AuthBy DNSROAM>

This clause proxies RADIUS requests to remote RADIUS and/or RadSec servers based on the Realm in the User-Name. The appropriate server to send to and the protocol to use is discovered through DNS lookups configured through the Resolver clause. For more information, see Section 3.117. <Resolver>. You must include a <Resolver> clause in your configuration if you intend to use <AuthBy DNSROAM>.
AuthBy DNSROAM is intended to make it easy to set up a secure, reliable, low maintenance RADIUS/RadSec federation. A RADIUS federation (sometimes called a RADIUS mesh) is a set of RADIUS servers, operated by a set of independent but cooperating organisations. The goal is to permit users who belong to one organisation to be able to use RADIUS-controlled resources at another organisation. A typical example is for a group of Universities to cooperate to permit a user from one University to connect to the wireless network at any other University in the group using their home user name and password. Radiator also permits RADIUS requests to be sent to another Radiator server through RadSec. RadSec provides secure, encrypted, reliable transport of RADIUS requests, with optional mutual authentication of RadSec client and server. For more information about RadSec protocol, see RadSec white paper Opens in new window.
Using AuthBy DNSROAM and DNS to hold information about the target server for each Realm permits convenient and scalable administration of the routing topology within a RADIUS/RadSec mesh.
DNSROAM cooperates well with existing RADIUS infrastructure, and can interoperate with other RADIUS servers and clients, as well as other RadSec servers and clients. It supports hardwired preconfigured RADIUS and RadSec routes as well as DNS discovered routes. It can provide a default fallback, so that Realms that are neither discovered nor hardwired can be forwarded to some catchall server (or dropped). It supports forwarding to IPv4 and/or IPv6 addresses. RadSec can use TCP or SCTP protocol for transport over IPv4 or IPv6. DNSROAM supports discovering RADIUS proxy servers as well as RadSec proxy servers.
The <AuthBy DNSROAM> clause can contain one or more <Route> subclauses which specify hardwired target servers for certain Realms or a DEFAULT fallback server. <Route> subclauses can specify RADIUS or RadSec target servers.
A sample configuration file showing how to use <Resolver>, <AuthBy DNSROAM> and <Route> clauses together can be found in goodies/dnsroam.cfg in your Radiator distribution.
AuthBy DNSROAM uses the following algorithm when it receives a RADIUS request for handling:
  1. Extract the Realm from the User-Name in the RADIUS request. (The user name and/or realm can be configured to be rewritten by patterns in the enclosing Handler or Client clause).
  2. Look for a preconfigured target server <Route> subclause for that Realm.
  3. If no preconfigured target server <Route> subclause is found for that Realm, try to discover a target server name or address using DNS (more below on exactly how this is done).
  4. If no target server is preconfigured or discovered, try to find a DEFAULT preconfigured target server <Route> subclause.
  5. If there is still no target server found, redespatch to the Handler system for handling if RedespatchIfNotarget configuration parameter is set.
  6. If the request is not redespatched, log and drop the request.
  7. If the target server is a RadSec server (Protocol=radsec) establish a RadSec connection to the target server (using a private AuthBy RADSEC clause), and if so configured, set up TLS tunnel and perform mutual authentication based on PKI certificates.
  8. If the target server is a RADIUS server (Protocol=radius) forward the request using RADIUS protocol over UDP (using a private AuthBy RADIUS clause).
  9. When a reply is received from the target server, send the reply back to wherever the request originally came from (there may be multiple proxying hops until the request reaches the home RADIUS server for that Realm).
AuthBy DNSROAM creates private AuthBy RADIUS and/or AuthBy RADSEC clauses to implement each discovered and hardwired RADIUS and RadSec Route. The default values for the parameters for these private clauses are obtained from the enclosing <Route> and/or <AuthBy DNSROAM> clauses, and can be overridden by <Route> clause parameters and parameters discovered from DNS by the <Resolver> clause. Both AuthBy RADIUS and AuthBy RADSEC require a shared secret. The default for AuthBy DNSROAM is radsec as required by the RadSec RFC. For more information about Route and Resolver, see Section 3.76. <Route> and Section 3.117. <Resolver>.
AuthBy DNSROAM supports TLS. For more information about TLS parameters, see Section 3.11. TLS configuration.
AuthBy DNSROAM understands also the same parameters as <AuthBy xxxxxx>. For more information, see Section 3.32. <AuthBy xxxxxx>.

3.75.1. RewriteTargetRealm

This optional parameter can be used to specify one or more rewriting rules which will be used to rewrite the Realm name used by Resolver to discover the appropriate target server.
# Find the target server for users@uninett.no by looking up 
# as if it were @no.eduroam.org
RewriteTargetRealm s/uninett.no/no.eduroam.org/
You can also set up a default realm that will be used if there is no realm in the user name after rewriting by having the last RewriteTargetRealm like this:
RewriteTargetRealm s/^$/default.realm.com/

3.75.2. RedespatchIfNoTarget

For a given request, if Resolver does not find a target and there is no explicit Route, and no Route with Realm DEFAULT and this flag is set, the request will be redespatched to the Handler system for handling. This allows for a flexible fallback in the case where DNSROAM cannot find how to route a request. The redespatched request will have the attribute OSC-Environment-Identifier set to the AuthBy DNSROAM’s Identifier value or DNSROAM if the Identifier is not set.
To create a fallback to multiple target hosts, configure AuthBy DNSROAM without default realm Route and with RedespatchIfNoTarget set. Then create a <Handler ExistsInRequest=OSC-Environment-Identifier> to match the redespatched requests. This Handler can have, for example, AuthBy RADSEC clause with two hosts which are used if DNSROAM cannot route the request.

3.75.3. HandleAcctStatusTypes

This optional parameter specifies a list of Acct-Status-Type attribute values that will be processed in Accounting requests. The value is a comma-separated list of valid Acct-Status-Type attribute values including, Start, Stop, Alive, Modem-Start, Modem-Stop, Cancel, Accounting-On and Accounting-Off. See your dictionary for a full list.
If HandleAcctStatusTypes is specified and an Accounting request has an Acct-Status-Type not mentioned in HandleAcctStatusTypes, then the request will be ACCEPTed but not otherwise processed by the enclosing clause. The default is to handle all Acct-Status-Type values.
# Only process Start and Stop requests, ACCEPT and acknowledge everything else
HandleAcctStatusTypes Start,Stop

3.75.4. <Route> parameters

Any of the following <Route> parameters may be placed in <AuthBy DNSROAM> as defaults for the enclosed <Route> clauses:

3.75.5. <AuthBy RADIUS> parameters

Any of the following <AuthBy RADIUS> parameters may be placed in <AuthBy DNSROAM> as defaults for any RADIUS proxy. These defaults can be overridden for individual Routes in the <Route> clause, and can be overridden by automatically discovered Routes. For more information, see Section 3.42. <AuthBy RADIUS>.

3.75.6. <AuthBy RADSEC> parameters

Any of the following <AuthBy RADSEC> parameters may be placed in <AuthBy DNSROAM> as defaults for any RADSEC proxy. These defaults can be overridden for individual Routes in the <Route> clause, and can be overridden by automatically discovered Routes. For more information, see Section 3.71. <AuthBy RADSEC>.
Table of Contents Table of contents: Radiator® AAA Server <AuthBy NTLM> 3.74 - <AuthBy NTLM> <Route> 3.76 - <Route>