RADIUS Deployments
Like the different controller’s deployments, there are also different ISE deployments.
Single site deployment
This is a deployment when there is only one site. On this site, all the communications are done by a single RADIUS cluster and the LDAP database. Since it is a single site, everything is centralized. The queries between the RADIUS and the LDAP server are local.
Distributed Autonomous sites
With autonomous sites, there are multiple branch offices and a main office. In the main office, there is the central LDAP database. In all the branch offices, there is a RADIUS cluster and a replicated LDAP database. The benefit is that the communication stays local between the supplicant, RADIUS client, RADIUS server, and the replicated LDAP database. There will be latency when the communication between the RADIUS server and the LDAP database goes across the WAN link, but also if the WAN links go down, the replicated LDAP database is still reachable. The downside is that every side needs its own RADIUS server and LDAP database, which is very expensive.
Centralized RADIUS and LDAP with distributed sites
In this scenario, the RADIUS server and LDAP database are centralized, the same with the previous example. The communication between RADIUS server and LDAP database are local and not across the WAN link. The downside is that the EAP traffic goes across the WAN link. If the WAN link goes down, new users cannot authenticate with the RADIUS server. A benefit is the cost because you don’t need a RADIUS server and LDAP server in each branch office.
Centralized LDAP and distributed RADIUS and sites
The last scenario is the scenario where the LDAP database is centralized. All the communication between the RADIUS server and the LDAP database go over the WAN link. As told in the previous scenario, when the link goes down, new clients cannot authenticate. All the authentication requests need to go over the WAN link and this can become a bottleneck, causing high latency and time-outs from the LDAP database.
RADIUS Proxy, realms and failover
It is possible to configure RADIUS as a proxy, not for LDAP queries to the LDAP database, but RADIUS to RADIUS proxy. It is possible to configure a RADIUS client (access point for example) as a RADIUS proxy and let the proxy forward the clients to the RADIUS server who query the LDAP database. Another option is that there is no LDAP database, but rather a centralized RADIUS server with a local database. A RADIUS server on a branch office functions as a proxy server and forwards all the traffic to the RADIUS server with the local database. It is also possible to let the RADIUS proxy on the local site proxy multiple RADIUS servers based on the domain name.
In a multi-tenant environment with the same infrastructure, it is possible that the RADIUS proxy uses the domain name (for example, RAATSWIFI/MarkRaats or MarkRaats@RAATSWIFI) to proxy it to the right RADIUS server. A real-life example is eduroam which is used in universities all over the world. I studied at Avans University in Breda and had an eduroam account. If I visited a university in the USA with eduroam deployed I would be able to use my Avans user account to connect to eduroam at the university in the USA.
The last thing in this paragraph is RADIUS failover. It is possible that the RADIUS server goes down. In this case, it would be nice if there is a second RADIUS server in another datacentre that can take over. You can configure a secondary RADIUS server in the RADIUS client. The RADIUS client will query the secondary server when the first one is unavailable.
Besides EAP authentication, it is also possible to authenticate based on MAC addresses. This is called MAC authenticate bypass (MAB). When the MAC address is in the allowed list, the RADIUS server will reply with a RADIUS Access-Accept. Another possibility is for guest accounts (Bring Your Own Device BYOD). ISE has captive web portal options.
RADIUS is based on UDP and MD5 algorithm, so this is a weakness in security. For this RADIUS is improved in RFC 6614. In this RFC RadSec (RADIUS security) is defined. RadSec uses TCP and TLS for a secure and reliable connections. Authentication, Authorisation, and Accounting use the same port TCP/2083.
RADIUS attributes
RADIUS server uses attribute-value pair (AVP) that contains the information that is needed. For example, an EAP-message (79) that is used to encapsulate EAP frames within the RADIUS packets. Another AVP is Message-Authenticator (80) that is used to protect the frames. It prevents it from modifying the frame by attackers. AVP 40 is already mentioned in an earlier blog, this is the Acct-Status-type that contains the value start, stop, or interim update.
Beside AVP there is also vendor-specific attributes (VSA). VSA create an additional 255 attributes that could be used by the vendor.
Attributes can be used for VLAN assignment. You don’t want to overhead your network, so in that case don’t use more than three or four SSIDs. You don’t want an SSID for all departments, like Sales, Marketing, ICT, Consultants and so on. The Access-Accept can respond with a VLAN tag in one of the AVPs (81, Tunnel-Private-Group-ID).
Role-based access control (RBAC) uses users, roles and permissions to authorize users. Also, other permissions can be assigned to those groups, like Layer 2 or Layer 3 permissions, VLANs, access lists or bandwidth permissions. When a user authenticates with 802.1X, attributes will assign the user to a specific role (based on an Active Directory group for example). In this role, the VLAN assignment is written down, as well as other settings like firewall rules. VSAs are used for role assignment. In most cases, attribute 11, named Filter-Id, is used for that.
