...
The clients are configured within Radiator using the <Client>-clause:
| Code Block |
|---|
<Client 192.168.10.200> |
...
Secret 6.6obaFkm&RNs666 |
...
Identifier ACCESSPOINT1 IdenticalClients 192.168.10.201 |
...
RequireMessageAuthenticator </Client> |
In this example there is a client definition for 192.168.10.200, an Access-Point. The "secret" is a series of (at best 16) characters that are used to encrypt the credentials sent in the RADIUS-request.
...
If more then one Client is to use this same secret and identifier definition, the IdenticalClients statement can be used. If there are many clients with different IP-addresses, there is also the possibility for a "catch-all" client. This is the default client that is used after all other client definitions didn't match. Define this client as:
| Code Block |
|---|
<Client DEFAULT> |
If this kind of configuration is used, it is worth filtering with firewall-rules on RADIUS packets. There are only a few places where a RADIUS-request should come from; the management VLAN with the NAS-devices (switches and access-points), and the RADIUS infrastructure where unknown requests can be sent to.
...
Another important part is the hostname to which the request should be forwarded. Multiple hostnames can be defined here for redundancy reasons: if the first host does not respond within three seconds, the second one is tried instead. The UDP ports to which the RADIUS-request should be forwarded can be defined in this "AuthBy RADIUS" clause as well.
| Code Block |
|---|
<Handler Client-Identifier=/^(?!Proxy-Identifier$)/> |
...
<AuthBy RADIUS> Host 192.87.36.3 |
...
Secret super_secret! AuthPort 1812 AcctPort 1813 StripFromReply Tunnel-Type, Tunnel-Medium-Type, |
...
Tunnel-Private-Group-ID |
...
AddToReply Tunnel-Type=1:VLAN, Tunnel-Medium-Type=1:Ether_802, |
...
Tunnel-Private-Group-ID=1:909 |
...
</AuthBy> |
...
</Handler> |
For a "Host", both the IP-address and FQDN can be used. The choice is more or less a personal preference of the RADIUS administrator, but be aware that the hostnames are only looked up once at the Radiator (re)start. If the lookup fails, the Host cannot be used until the next restart. This can represent a problem at a power outage, where for instance the DNS server is not yet available even though Radiator is.
...
In this example the AuthBy-definition is outside the Handler, and is referred to using the Identifier. (This is useful if the AuthBy-definition is reused in another Handler, for instance.)<AuthBy FILE>
Identifier ID4-TLS
Filename
| Code Block |
|---|
<AuthBy FILE> Identifier ID4-TLS Filename %D/TLS-users |
...
EAPType TLS EAPTLS_CAFile %D/cert/institution-ca-chain.pem |
...
EAPTLS_CertificateFile %D/cert/radius-server-cert.pem |
...
EAPTLS_CertificateType |
...
PEM EAPTLS_PrivateKeyFile %D/cert/radius-server-key.pem |
...
EAPTLS_PrivateKeyPassword (the secret that secures the private-key) |
...
EAPTLS_MaxFragmentSize |
...
1024 AutoMPPEKeys SSLeayTrace 1 StripFromReply Tunnel-Type,Tunnel-Medium-Type,Tunnel-Private-Group-ID |
...
AddToReply Tunnel-Type=1:VLAN,Tunnel-Medium-Type=1:Ether_802,Tunnel- Private-Group-ID=1:909,User-Name=%u |
...
</AuthBy> |
In this AuthBy-clause there is an EAPTLS file defined that lists every employee. In this way, the users that can access the infrastructure using EAP-TLS are controlled.
...
The last part of the AuthBy-definition shows how to assign a proper VLAN.
| Code Block |
|---|
<Handler Realm=instituion.cc, EAP-Message=/.+/> |
...
AuthBy ID4-TLS |
...
</Handler> |
The Handler above shows the referral to the AuthBy-definition and some filtering mechanisms to filter out the proper requests. If more things need to be filtered on, they can be added to this handler, as follows:
| Code Block |
|---|
NAS-Port-Type=/^(Wireless-IEEE-802-11|Ethernet)$/ |
In this way, only requests with the proper NAS-Port-Types are allowed. For Accounting purposes, a new handler should be defined in this case, that filters on:
| Code Block |
|---|
"Request-Type=Accounting-Request" |
since the request does not match the Handler that filters on the EAP-Message.
...
Technically, three backend cases need to be considered for deployment:
Backend stores passwords in... | PEAP-MSCHAPv2? | TTLS? |
|---|---|---|
plain text or reversibly encrypted | Yes | Yes (TTLS-PAP, TTLS-MSCHAPv2) |
NT-Hash | Yes | Yes (TTLS-PAP, TTLS-MSCHAPv2) |
other irreversible encryption | No | Yes (TTLS-PAP) |
Where both options are possible, we suggest the following order of preference: TTLS-MSCHAPv2, PEAP- MSCHAPv2, TTLS-PAP (in descending order of preference).
...
| Code Block |
|---|
<Handler Realm=group_1>
<AuthBy FILE>
Filename %D/users
EAPType TTLS, PEAP
EAPTLS_CAFile %D/root.pem
EAPTLS_CertificateFile %D/server.pem
EAPTLS_CertificateType PEM
EAPTLS_PrivateKeyFile %D/server.pem
EAPTLS_PrivateKeyPassword serverkey
EAPTLS_MaxFragmentSize 1024
EAPAnonymous anonymous@group1
AutoMPPEKeys
</AuthBy>
</Handler>
|
Sample configuration file
...