Forwarding is configured via
In the case of "multi-layer" EAP protocols such as TTLS or PEAP, the actual "internal" authentication can be performed by a separate RADIUS server. Thus an existing RADIUS server can continue to be operated to provide user tables, even though it is not EAP(/TLS) capable itself. In this situation the TLS/TTLS/PEAP tunnel is managed from the LCOS RADIUS server.
The configuration of multi-layer protocols of this type is an element of a general method for the forwarding of RADIUS requests, whereby a LCOS RADIUS server can also be used as a RADIUS proxy. The concept of "realms" is the basis for request forwarding and the proxy function. A realm is a character string which defines the validity of a series of user accounts. The device considers the following parts of a user name to be the realm:
- Mail domain
- User@company.com: company.com is the realm and is separated from the name of the user by an @ character.
- MS computer authentication
- company\user: company is the realm and is separated from the name of the user by a backslash ("\"). This form of authentication is used for a Windows login, for example.
- MS domain
- Host/user.company.com: If the user name starts with the string host/ and the rest of the name contains at least one dot/period, the device considers everything after the first dot to be the realm (in this case company.com).
The realm can be seen as a pointer to the RADIUS server where the user account is managed. The realm is removed from the string prior to the search of the RADIUS server's user table. Realms allow entire networks which are mutually trustworthy to work with common RADIUS servers located in partner networks, and to authenticate users who move between these networks. The LCOS RADIUS server stores any connected RADIUS servers along with their associated realms in a forwarding table. The realm is searched for in this table in connection with the communicated user name. If no entry is found, the request is answered with an access reject. An empty realm is treated as a local request, i.e. the LCOS RADIUS server searches its own user tables and generates its response accordingly.
To support the processing of realms the LCOS RADIUS server uses two special realms:
- Default realm
- This realm is used where a realm is communicated for which no specific forwarding server has been defined. Importantly, an entry for the default realm itself must be present in the forwarding table.
- Empty realm
- This realm is used when no realm is communicated, but the user name only.
In the default state the forwarding table has no entries, i.e. the default and empty realms are empty. This means that all requests are treated as local requests and any realms which are communicated are ignored. To operate the LCOS RADIUS server purely as a forwarding server or RADIUS proxy, the default and empty realms must be set to a value that corresponds with a server defined in the forwarding table.
Please note that the forwarding of RADIUS requests does not alter the user name. No realm is added, changed or removed. The next server may not be the last one in the forwarding chain, and the realm information may be required by that server to ensure that forwarding is carried out correctly. Only the active RADIUS server which processes the request resolves the realm from the user name, and only then is a search made of the table containing the user accounts. Accordingly the LCOS RADIUS server resolves the realm from the user name for processing requests locally.
The processing of tunneled EAP requests using TTLS and PEAP makes use of a special EAP tunnel server, which is also in the form of a realm. Here you select a realm that will not conflict with other realms. If no EAP tunnel server is defined then the LCOS RADIUS server forwards the request to itself, meaning that both the internal and the external EAP authentications are handled by the LCOS RADIUS server itself.
If necessary, set up the Forwarding server.
- Realm
- Character string identifying the forwarding destination.
- Backup profile
- Alternative forwarding server in case the first forwarding server is not available.
- Authentication server and accounting server
-
You can configure parameters for the two possible RADIUS applications (access management and accounting) so that the router can forward RADIUS queries to an external RADIUS server.
If no forwarding is required for the access management or accounting, leave the corresponding address field empty.
- Server address
- IP address of the RADIUS server to which the request is to be forwarded.
- Port
- The same port number must be set for the port that is configured in the corresponding RADIUS server. This is usually 1812 for access management and 1813 for accounting.
- Attribute values
-
Here you can assign user-defined values to RADIUS attributes. The individual name-value pairs must have the form <Name>=<Value>, and they are separated by semicolons.
<Name> identifies the RADIUS attribute by its name or number. The associated attribute names can be found in the corresponding RADIUS RFCs. Attribute names can be abbreviated as long as the identifiers are unequivocal.
As the number of characters is limited, the name can abbreviated. The abbreviation must be unique, however. Examples:
- NAS-Port=1234 is not allowed, because the attribute is not unique (NAS-Port, NAS-Port-Id or NAS-Port-Type).
- NAS-Id=ABCD is allowed, because the attribute is unique (NAS-Identifier).
- %n – replaced by the configured device name.
- %e – replaced with the serial number of the device as displayed in the device system info.
- %% – replaced by a single % character.
- %{name} – replaced by the original value of the corresponding RADIUS attribute. Any new / re-definitions within this attribute list are ignored. The identifier can be truncated as long as it remains unique.
- Secret
- The key (secret) must also match the one configured in the RADIUS server so that this router can authenticate against it.
- Source address
- Here you have the option to configure a sender address for the device to use in place of the one that would otherwise be used automatically for this target address.
- Protocol
- Protocol for communication between the internal RADIUS server and the forwarding server.
