Chapter 9 RADIUS and LDAP

IN THIS CHAPTER, YOU WILL LEARN ABOUT THE FOLLOWING:

✓ LDAP

✓ RADIUS

• Authentication and authorization

• Accounting

• RADIUS configuration

• LDAP proxy

• RADIUS deployment models

• RADIUS proxy

• RADUS proxy and realms

• RADIUS failover

• WLAN devices as RADIUS servers

• Captive web portal and MAC authentication

• RadSec

✓ Attribute value pairs

• Vendor specific attributes

• VLAN assignment

• Role based access control

• LDAP attributes

In earlier chapters, you learned about the 802.1X authorization framework and the Extensible Authentication Protocol (EAP) that is used for enterprise WLAN security. 802.1X/EAP uses an authentication server to validate the credentials of a WLAN client and then to authorize access for the WLAN to network resources. The authentication server is normally a RADIUS server that directly communicates with an existing Lightweight Directory Access Protocol (LDAP) database. This chapter will provide an in-depth review of RADIUS and LDAP deployment scenarios for WLANs. You will also learn about how RADIUS attribute value pairs can be leveraged to provide different access policies for different groups of WLAN users and devices.

LDAP

Lightweight Directory Access Protocol (LDAP) is an application protocol for providing directory services over an IP network. The current version, LDAPv3, is defined in IETF RFC 4511. A directory service is an infrastructure used to share information about network resources such as files, folders, computers, users, groups, and so on. A directory service could be considered a database or data store, although a directory service is different when compared to relational databases. Distributed directory information services use a hierarchical structure that can be accessed and managed using LDAP. In most IP networks, LDAP is used to provide access to a data store of usernames and passwords. Applications such as RADIUS can be used to query an LDAP server to validate user or device credentials. LDAP sessions normally use TCP or UDP port 369; however, LDAP over SSL uses port 636.

Within an 802.1X authorization framework, the authentication server (AS) validates the credentials of a supplicant that is requesting access and notifies the authenticator that the supplicant has been authorized. The authentication server maintains a user database or may proxy with an external user database to authenticate user or device credentials. In almost all cases, a RADIUS server functions as the authentication server. The RADIUS server may hold a master native user database but usually will instead query to a preexisting external database.

Any LDAP-compliant database can be queried by the RADIUS authentication server. Active Directory is the most commonly used external LDAP database, but a RADIUS server can also query LDAP-compliant databases such as eDirectory or OpenLDAP. As shown in Figure 9.1, typically a RADIUS server performs authentication server duties and the RADIUS server initiates a proxy query to an LDAP-compliant database, such as Active Directory. This is referred to as proxy authentication.

FIGURE 9.1 Proxy authentication

LDAP can be used with numerous forms of directory service implementations. Some of the most widely deployed are as follows:

Active Directory Microsoft introduced Active Directory with Windows Server 2000 and has continued to enhance it with subsequent releases of its server OS platforms. Active Directory is a hierarchical directory service that is based on LDAP. Active Directory also incorporates a DNS-naming component based on the Internet DNS structure and uses Kerberos. Windows Active Directory is the most popular implementation of directory services in the enterprise.

eDirectory NetQ’s eDirectory was originally developed by Novell in 1993 and was known as Novell Directory Services (NDS). eDirectory supports multiple architectures, including Novell NetWare, Microsoft Windows, Red Hat Linux, and multiple types of Unix. eDirectory is a hierarchical, object-oriented database used to represent assets in an organization in a logical tree.

OpenLDAP OpenLDAP is an open source implementation of LDAP maintained by the OpenLDAP Foundation at www.OpenLDAP.org. OpenLDAP supports most modern-day computer architectures, including Windows and various forms of Linux and Unix.

Other flavors of LDAPv3-compliant directory services include Apple’s Open Directory and Apache Directory Server. Open Directory is the directory services framework used by Mac OS X and Mac OS X Server. Apache Directory Server is open source.

RADIUS

Remote Authentication Dial-in User Service (RADIUS) is a networking protocol that provides authentication, authorization, and accounting (AAA) capabilities for computers to connect to and use network services. RADIUS authentication and authorization is defined in IETF RFC 2865. Accounting is defined in IETF RFC 2866. RADIUS servers are sometimes referred to as AAA servers. RADIUS was developed back in 1991 as a client/server authentication and accounting protocol. It grew to be widely used by ISPs for dial-up users and later logically extended to VPN dial-up users. RADIUS developed critical mass and had the ability to extend, or rather broker, authentication to many different user databases. This includes LDAP, Active Directory, SQL databases, flat files, and native RADIUS users.

Prior to RADIUS servers being used for WLAN security, many organizations already were maintaining a RADIUS infrastructure for dial-up users with a modem bank. Using RADIUS servers for WLAN security later became a logical choice. The IEEE 802.11-2012 standard does not dictate the use of a RADIUS server. However, the IEEE 802.11-2012 WLAN standard does dictate the use of the IEEE 802.1X-2004 standard for authentication and port control within an enterprise robust security network (RSN). As you learned in Chapter 4, “802.1X/EAP Authentication,” 802.1X is a port-based access control standard that defines the mechanisms necessary to authenticate and authorize devices to network resources. RADIUS servers are usually one of the main components of an 802.1X authorization framework.

Authentication and Authorization

RADIUS clients often get confused with Wi-Fi clients (supplicants). Instead, RADIUS clients are the devices that communicate directly with a RADIUS server using the RADIUS protocol. RADIUS clients are the authenticators within an 802.1X/EAP framework. To make things even more confusing, RADIUS clients are also sometimes referred to as the network access server (NAS). When discussing 802.1X/EAP, the terms authenticator, NAS, and RADIUS client are all synonymous.

As you learned in Chapter 4, when 802.1X/EAP security is used with WLANs, either an AP or a WLAN controller functions as the authenticator. As shown in Figure 9.2, all the RADIUS communications are between the RADIUS server and the AP, which is functioning as the RADIUS client. RADIUS packets are used to encapsulate EAP frames during the authentication exchange. Think of the RADIUS protocol as a transport mechanism for EAP authentication conversations between the supplicant and the authentication server. The RADIUS communications occur strictly between the RADIUS client (AP) and the RADIUS server.

FIGURE 9.2 RADIUS and 802.1X/EAP

The WLAN supplicant sends an EAP request to the AP to gain access to network resources. The AP then forwards the EAP request encapsulated in a RADIUS Access-Request packet to the RADIUS server. As shown in Figure 9.3, the RADIUS server can respond in three different ways:

RADIUS Access-Challenge The RADIUS server requests additional information from the user or device such as a secondary password, PIN, token, or hash response. Many flavors of EAP protect this information in an SSL/TLS tunnel between the supplicant and the authentication server, but remember that RADIUS communications are between the AP and the RADIUS server.

RADIUS Access-Accept The user or device is granted access. The Access-Accept packet can also contain RADIUS attributes, which can define exactly what type of access is granted to the user or device. RADIUS attributes will be discussed in greater detail later in this chapter.

RADIUS Access-Reject The user or device is denied access to all requested network resources. Access could be denied because of incorrect user credentials such as the password. The user account may also have expired or not exist.

FIGURE 9.3 RADIUS protocol communications

Accounting

RFC 2866 defines how the RADIUS protocol can be used to deliver accounting information from the RADIUS client to a RADIUS accounting server. Once again, an access point usually functions as the RADIUS client (also called NAS) when 802.1X/EAP is deployed for WLAN security. Accounting is used to track network access of users and devices. For example, an accounting trail can record information such as who authenticated, when they authenticated, session time, session activities, and much more.

As shown in Figure 9.4, after network access is granted to a user or device, a RADIUS Accounting-Request packet is sent by the RADIUS client to the RADIUS server to signal the start of the user network access. The packet contains an Acct-Status-Type attribute with the value of start. Some of the accounting information in the start packet includes the username, IP address, NAS information, and a unique session identifier. The AP that is functioning as the NAS will periodically send RADIUS Accounting-Request packets to update the RADIUS server about the active session. This packet contains an Acct-Status-Type attribute with the value interim-update. Information about the current session and data usage can then be tracked. When network access is concluded, the RADIUS client sends a final RADIUS Accounting-Request packet that contains an Acct-Status-Type attribute with the value stop to the RADIUS server. Information such as why the session was terminated and time of termination can be beneficial when troubleshooting 802.1X/EAP problems.

FIGURE 9.4 RADIUS accounting

RADIUS Configuration

When used within an 802.1X framework, a RADIUS server must be configured to communicate with the RADIUS client. The RADIUS server needs to be configured with the IP addresses of any APs functioning as authenticators along with a shared secret in order to communicate with the server. As shown in Figure 9.5, most enterprise RADIUS servers will allow you to designate the subnet on which the APs reside. The shared secret configured on both the authenticator and authentication server is not used for any past part of supplicant validation. The shared secret is only for the RADIUS client (AP)–to–RADIUS server communication link. Both the RADIUS client and the RADIUS authentication server should be configured to use UDP port 1812 for authentication communications and UDP port 1813 for accounting communications.

FIGURE 9.5 RADIUS server configuration

As also shown in Figure 9.5, the RADIUS server must also be configured for the flavors of the EAP protocol that will be used. A RADIUS server can support multiple types of EAP simultaneously; however, the selected EAP type must match on the WLAN supplicant if 802.1X/EAP authentication is to be successful. Most flavors of EAP use tunneled authentication and the proper certificates must also be selected. A server certificate must be installed on the RADIUS server and the Root CA certificate must also be designated. Remember that the Root CA certificate will also need to be provisioned on all the supplicants. As seen in Figure 9.6, the RADIUS server must also be configured for integration with an LDAP database such as Active Directory.

FIGURE 9.6 RADIUS and LDAP integration

LDAP Proxy

As previously mentioned, when 802.1X/EAP is the chosen WLAN security solution, the RADIUS server may use an internal native user database, but usually will instead query to a preexisting LDAP database. Any LDAP-compliant database can be queried by the RADIUS authentication server. The interaction between RADIUS and LDAP very often depends on the solution that is chosen. For example, Microsoft’s Network Policy Server (NPS) operates RADIUS as a service on the same hardware that houses Active Directory (AD).

When using a third-party RADIUS server, the server will need to be joined to the AD domain as a computer object. This will allow the RADIUS server to access the Active Directory user store in order to authenticate users. The RADIUS server can use a standard domain account to perform the LDAP queries between the RADIUS server and Active Directory. When RADIUS servers are integrated with other flavors of LDAPv3 directory services, an LDAP account will be needed by the RADIUS server to perform the queries.

There may be one or more user LDAP databases, and you should confirm support for the exact database technology. For example, if you are an ISP or hotspot provider, the user database may reside in a SQL server, which may limit the available choices of RADIUS server products that are applicable to your design requirements. Usually one database is specified to be the primary over the others and configured in a priority search order.

RADIUS Deployment Models

In almost all enterprise environments, RADIUS queries an existing LDAP database. Exactly how RADIUS and LDAP are deployed together depends on the how many locations and numbers of users exist within an organization. As with any type of network design, scaling and redundancy are important considerations when deploying RADIUS servers.

Single-Site Deployment

A single-site deployment is the simplest of all models. If your entire organization resides at a single location and is the hub of all communications, only a single RADIUS server or cluster of redundant servers is needed. The LDAP database also resides at the single-site location. Figure 9.7 depicts a single-site RADIUS deployment. Single-site deployments should be considered when

• All WLAN users are located at a single site.

• A central user/device database is located at the site.

• One or more RADIUS servers query to the onsite LDAP database.

• All EAP communications between the supplicant and the RADIUS server are local.

• All the LDAP queries between the RADIUS server and LDAP database are also local.

FIGURE 9.7 Single-site deployment

The benefits of a single-site deployment are that the RADIUS server(s) can locally proxy authentications against any type of backend authentication database, including Active Directory, LDAP, and others. Often in single-site deployments, the internal database of the RADIUS server is used instead of an LDAP database. However, even with a single-site deployment, because of performance and future scalability, we recommend that you use an external LDAP database on a separate server.

Distributed Autonomous Sites

If an organization has WLANs at multiple locations or different cities, RADIUS can be scaled in a number of ways to support the multiple sites. As shown in Figure 9.8, a distributed autonomous sites scenario can replicate the LDAP database from a central site to each autonomous site.

A distributed autonomous scenario is defined by the following:

• Multiple WLANs exist at different locations.

• The central authentication database is replicated to LDAP servers at each autonomous site.

• Each remote site has one or more RADIUS servers that proxy to the on-site LDAP database.

• EAP communications between the supplicant and the RADIUS server remain local.

• LDAP queries between the RADIUS server and the replicated LDAP databases are also local.

The main benefit to this scenario is that all of the wireless users authenticate against the local replicated LDAP database and do not have to authenticate across a WAN link. If the WAN link goes down, the users can still successfully authenticate and access the wireless network. However, if the WAN link goes down, replication between the authentication databases cannot occur. The downside to this deployment model is that it is very expensive.

FIGURE 9.8 Distributed autonomous sites

Distributed Sites, Centralized RADIUS and LDAP

Another approach to scaling RADIUS with multiple sites is to use a centralized authentication architecture. As shown in Figure 9.9, all RADIUS servers and the LDAP database are located at a central site, such as corporate headquarters.

FIGURE 9.9 Distributed sites; centralized RADIUS and LDAP

A distributed site with a centralized RADIUS and LDAP architecture is defined by the following:

• Multiple WLANs exist at different locations.

• The LDAP database is located at a central site.

• One or more RADIUS servers are also located at the central site, and they query the central authentication database.

• EAP communications between the supplicant and the RADIUS server occur across the WAN link.

• LDAP queries between the RADIUS server and LDAP database occur at the central location.

The main benefit to this design is cost, because RADIUS servers and database servers are not deployed at the remote locations. The biggest concern with this type of design model is if the WAN link goes down, no new wireless users can authenticate and the users would not be able to access the local wireless network. Performance bottlenecks can also occur that might affect latency. This design model can also negatively impact roaming for any WLAN clients that do not support fast secure roaming mechanisms such as opportunistic key caching (OKC) or fast BSS transition (FT). A typical 802.1X/EAP frame exchange between a supplicant and RADIUS server can take 700 ms but will very often take multiple seconds across a WAN link. If a WLAN client does not have fast secure roaming capabilities, it will have to reauthenticate across the WAN link every time the client roams.

Distributed Sites with RADIUS, Centralized LDAP

Probably a better design than the previous model is a mixture of a distributed and centralized authentication architecture. As shown in Figure 9.10, this scenario also uses an LDAP database at a central location. However, one or more RADIUS servers are deployed at each remote location.

FIGURE 9.10 Distributed sites with RADIUS, centralized LDAP

A distributed site with RADIUS, centralized LDAP architecture is defined by the following:

• Multiple WLANS exist at different locations.

• The LDAP database is located at a central site.

• One or more RADIUS servers are located at each remote site and proxy the LDAP queries to the central LDAP database.

• EAP communications between the supplicant and the RADIUS server are local.

• LDAP queries between the RADIUS servers and centralized LDAP database occur across the WAN link.

• LDAP credential caching on the RADIUS server might be an option.

The design can be more expensive than the previous model, but it offers more flexibility. Latency problems that might affect roaming are not as prevalent because the EAP authentication exchange is local and only the LDAP queries occur across the WAN link. The biggest concern with this type of design is if the WAN link goes down, no new wireless user can authenticate and they will not be able to access the WLAN.

However, some RADIUS servers also offer the capability to locally cache LDAP credentials after an initial authentication by a user. If the WAN link goes down, the RADIUS server will first attempt to query the centralized LDAP server but will eventually fall back to the locally cached LDAP credentials on the RADIUS server. When the WAN link goes back up, the RADIUS server will once again query the centralized database. Any new user that has not authenticated prior to the WAN link failure will still not be able to access the WLAN because they would not have a cached LDAP credential.

RADIUS Proxy

RADIUS servers can also be set up to proxy to authentication requests to other RADIUS servers. Do not confuse a RADIUS-to-RADIUS proxy with the RADIUS-to-LDAP proxy authentication discussed earlier. Consider a single-site deployment with a RADIUS server and LDAP database. Perhaps the vendor RADIUS solution requires that the IP addresses of the APs that are functioning as authenticators all be configured individually. Most APs receive their management IP address via DHCP. Most administrators do not want to configure static IP addresses on access points, nor do they want to enter multiple IP addresses of the authenticators in the RADIUS configuration. Perhaps the RADIUS server licensing restricts the number of allowed authenticators to 50 APs yet you have 200 APs that need to perform RADIUS communications.

Depending on the vendor, an AP, switch, or some other type of networking device might have the dual-function capability to operate as a RADIUS proxy. As shown in Figure 9.11, the majority of APs would send their RADIUS packets to a networking device that is functioning as a RADIUS proxy. The devices that are functioning as the proxies would then forward all RADIUS packets to the real RADIUS server. Only a single IP address of the RADIUS proxy device and a shared secret needs to be designated on the RADIUS server. Notice in Figure 9.11 that the RADIUS server will still query an LDAP database. Although a deployed RADIUS-to RADIUS proxy is possible, keep in mind that the LDAP proxy authentication from a RADIUS server to an LDAP database is much more common. Another scenario for a RADIUS-to-RADIUS proxy might be that the main RADIUS server was using a native user database and RADIUS servers at other locations were proxies to the central RADIUS server with the native database. The good news is that RADIUS can be deployed and scaled in the enterprise many different ways—including globally, which will be discussed in the next section.

FIGURE 9.11 RADIUS proxy

RADIUS Proxy and Realms

The RADIUS protocol can make use of networking realms, which identify where the RADIUS server should forward the RADIUS requests across the Internet and between ISPs. Realm naming formats are defined in RFC 4282.

As you just learned, a RADIUS server can be a proxy to one or more centralized RADIUS servers. A username can be in the form DOMAIN/username or username@domain. This is valuable information that can tell the first authentication server which final destination authentication server to request authentication from. In this case, domain is synonymous with the term realm as referred to previously.

For example, if an AP was configured in a regional office or subsidiary of a large enterprise, the AP might point to an authentication server located at that facility or perhaps in a nearby datacenter. If an employee with a common name, let’s say Charles, from the parent company was traveling on a business trip and visiting the subsidiary’s office, when Charles logged in with CWNP/charles, the authentication would know that it needed to contact the remote CWNP user account RADIUS server. In this situation, the first authentication server that the AP pointed to would have just performed a proxy authentication to the final authentication server where Charles’s user account resided.

When a domain is used, we commonly refer to this as a realm-based authentication. This method of authentication allows a user to authenticate to a realm or sub-realm. When a RADIUS server receives an AAA request for a username containing a realm, the server will reference a table of configured realms. If the realm is known, the server will then proxy the request to the home RADIUS server for that domain. As shown in Figure 9.12, the realm in this case is the domain being sent in the supplicant identity. Authentication of the user is directed to a RADIUS server for CompanyX based on the domain value supplied.

FIGURE 9.12 Realm-based authentication

RADIUS Failover

Networking Design 101 dictates redundancy for network services. In the enterprise, multiple RADIUS servers should be deployed for redundancy purposes. As shown in Figure 9.13, when deploying an AP or WLAN controller as a RADIUS client, you can configure multiple RADIUS servers. The first server in the list is usually considered the primary server. When a RADIUS server is determined to be unavailable based on the method used by the WLAN infrastructure, it will move to the next server in the priority list.

FIGURE 9.13 RADIUS failover

Typically, a hold-down timer will be enacted that monitors the availability of that RADIUS server until it is considered stable in order to be sent authentication or accounting transactions again. Depending on the settings or logic of the authenticator functionality in the AP or WLAN controller, the original RADIUS server may not revert to the primary role automatically. Even if the other servers are geographically far away, resulting in added latency, this may not cause any other problem other than slowness of all RADIUS transactions as long as the network connection is still reliable. We highly recommend that you monitor for RADIUS failover events on your APs and WLAN controllers.

WLAN Devices as RADIUS Servers

Enterprise WLAN vendors offer solutions where either a standalone AP or a WLAN controller can dual-function as a RADIUS server and perform direct LDAP queries, thus eliminating the need for an external RADIUS server. Additionally some switch vendors also offer dual-functionality where an access layer switch might also operate as a RADIUS server. These solutions are often popular when there are multiple locations. Cost savings can be realized in distributed sites with RADIUS and centralized architecture. Keep in mind that the number of simultaneous RADIUS authentications that a dual-function device can handle will be much smaller than a dedicated RADIUS server such as Microsoft NPS or Cisco ACS. Additionally, since the main function of either a standalone AP or a WLAN controller is not RADIUS, these devices most often support advanced RADIUS server features.

Captive Web Portal and MAC Authentication

Most of the discussion in this chapter has revolved around using RADIUS with 802.1X/EAP authentication for strong WLAN security. However, a RADIUS server can also be used to authorize WLAN users and devices with weak authentication methods such as captive web portal authentication and MAC address authentication.

RADIUS servers are often used with a captive portal web page to authenticate guest users for guest WLANs. A captive web portal solution will query a RADIUS server with a username and password using a weak authentication protocol such as MS-CHAPv2. The native database of the RADIUS server is normally used to validate the guest users. Captive web portal authentication is also often used together with bring your own device (BYOD) solutions for validating employee credentials. The employee database would most likely be Active Directory, which would in turn be queried by the RADIUS server. More detailed information about captive web portal authentication can be found in Chapter 10, “Bring Your Own Device (BYOD) and Guest Access.”

A RADIUS server can also be used for simple authentication of 802.11 devices based on an allowed list of MAC addresses. When an 802.11 client device attempts to associate, an AP queries the RADIUS server with a RADIUS Access-Request message. The RADIUS server can admit or deny the device based on the WLAN client MAC address, responding with either a RADIUS Access-Accept message or a RADIUS Access-Reject message.

MAC authentication does not require client-side configuration and is typically used with legacy WLAN devices that might not support PSK or 802.1X/EAP. Because MAC addresses can be very easily spoofed, MAC authentication is rarely used by itself for WLAN security. However, MAC authentication is sometimes bound together with either captive web portal authentication or 802.1X/EAP. Combining MAC authentication along with 802.1X/EAP could be considered a simple method of multifactor authentication.

RadSec

The RADIUS protocol depends on the unreliable transport protocol UDP using port 1812 and has some potential security weaknesses. RADIUS is based on the MD5 algorithm, which has been proven to be insecure. Therefore, the IETF RFC 6614 defines Transport Layer Security (TLS) for RADIUS. The defined protocol is often called RadSec or RADIUS over TLS. RadSec is the next-generation RADIUS transport that relies on TCP and TLS for reliable and secure transport with integrity verification.

The main focus of RadSec is to provide a means of securing the communication between RADIUS/TCP peers using TLS encryption. The default destination port number for RadSec is TCP/2083. Authentication, accounting, and dynamic authorization changes do not require separate ports. RadSec can be used for RADIUS packets that traverse through different administrative domains and networks. The academia roaming access service, eduroam, has already begun to use RadSec globally.

Attribute-Value Pairs

An attribute is a portion of information that determines the properties of a field or tag in a database. Attributes usually come in name/value pairs like name="value". An attribute-value pair (AVP) is a representation of data in computer systems and applications. An attributevalue pair can be used to store and provide data in a database—for example, an attribute called last name followed by its value pair, which is the actual last name of a person. The IETF designates an original set of 255 standard RADIUS attributes that can be used to communicate AAA information between a RADIUS client and a RADIUS server. The attributevalue pairs (AVPs) carry data in the RADIUS request and response packets. Figure 9.14 shows a packet capture of a RADIUS Access-Accept packet with a series of AVPs.

FIGURE 9.14 RADIUS attribute-value pairs

RFC 3579 defines how the EAP protocol is supported with RADIUS using attributes. To support EAP within RADIUS, two standard attributes are used:

(79) EAP-Message This attribute is used to encapsulate EAP frames with RADIUS packets. Only one EAP frame can be encapsulated within a single RADIUS packet. A RADIUS client such as an access point or WLAN controller forwards the EAP-Message attributes within a RADIUS Access-Request packet to the RADIUS server. The RADIUS server can return EAP-Message attributes in Access-Challenge, Access-Accept, and Access-Reject packets.

(80) Message-Authenticator An attacker could potentially spoof the EAP-Success, EAP-Failure, and other EAP frames. This attribute prevents attackers from modifying EAP within a RADIUS packet using per-packet data integrity checks. Therefore, the Message-Authenticator attribute must be used to protect all Access-Request, Access-Challenge, Access-Accept, and Access-Reject packets containing an EAP-Message attribute.

While most of the RADIUS attributes are used for authentication and authorization purposes, some are specifically dedicated for use with RADIUS accounting. As mentioned earlier in this chapter, RADIUS accounting packets use the (40) Acct-Status-Type attribute with values of start, stop, or interim update.

Vendor-Specific Attributes

RADIUS vendor-specific attributes (VSAs) are derived from the IETF attribute (26) Vendor-Specific. This attribute allows a vendor to create any additional 255 attributes however they wish. Data that is not defined in standard IETF RADIUS attributes can be encapsulated in the (26) Vendor-Specific attribute. This allows vendors to support their own extended attributes otherwise not suitable for general use. VSAs allow RADIUS client vendors, such as the manufacturers of access points and switches, to support their own proprietary RADIUS attributes. The vendors typically offer free VSA dictionary files, which can be easily imported into most popular commercial RADIUS servers as well as the open source FreeRADIUS.

VLAN Assignment

A common WLAN design strategy is to link a single user VLAN to a unique SSID. Most WLAN vendors allow a radio to broadcast as many as 16 SSIDs. However, broadcasting 16 SSIDs is a bad practice because of the Layer 2 overhead created by the 802.11 management and control frames for each SSID. The broadcast of 16 SSIDs will result in degraded performance. The best practice is to never broadcast more than 3 or 4 SSIDs.

What if you want your employees segmented into multiple VLANs? Can a single employee SSID be mapped to multiple VLANs? RADIUS attributes can be leveraged for VLAN assignment when using 802.1X/EAP authentication on the employee SSID. As you have already learned, when a RADIUS server provides a successful response to an authentication request, the Access-Accept response can contain a series of attribute-value pairs (AVPs). One of the most popular uses of RADIUS AVPs is assigning users to VLANs, based on the identity of the user authenticating. Instead of segmenting users to different SSIDs that are each mapped to a unique user VLAN, all the users can be associated to a single SSID and assigned to different VLANs.

RADIUS servers can be configured with different access policies for different groups of users. The RADIUS access policies are usually mapped to different LDAP groups. Figure 9.15 shows a RADIUS server access policy defined for a specific LDAP group. The access policy uses three standard IETF RADIUS attributes to assign a specific VLAN to an authenticated user. Notice that the (81) Tunnel-Private-Group-ID attribute has a value of 10. Upon authentication, any user that belongs to the LDAP group mapped to this policy will join VLAN 10.

FIGURE 9.15 RADIUS AVPs for VLAN assignment

Role-Based Access Control

Using RADIUS attributes for user VLAN assignment has been a network design strategy for many years. However, RADIUS attributes can be further leveraged to assign different groups of users to all kinds of different user traffic settings, including VLANs, firewall policies, bandwidth policies, and much more.

Role-based access control (RBAC) is an approach to restricting system access to authorized users. The majority of enterprise WLAN vendor solutions have RBAC capabilities. The three main components of an RBAC approach are users, roles, and permissions. Separate roles can be created, such as the sales role or the marketing role. User traffic permissions can be defined as Layer 2 permissions (MAC filters), VLANs, Layer 3 permissions (access control lists), Layers 4–7 permissions (stateful firewall rules), and bandwidth permissions. All these permissions can also be time based. The user traffic permissions are mapped to the roles. Some WLAN vendors use the term roles whereas other vendors use the term user profiles.

When a user authenticates using 802.1X/EAP, RADIUS attributes can be used to assign users to a specific role automatically. All users can associate to the same SSID but be assigned to unique roles. This method is often used to assign users from certain Active Directory (AD) groups into predefined roles created on a WLAN controller or access point. Each role has unique access restrictions. Once users are assigned to roles, they inherit the user traffic permissions of whatever roles they have been assigned.

Figure 9.16 depicts a RADIUS server with three unique access policies mapped to three different Active Directory groups. For example, user-2 belongs to the marketing AD group. Based on the RADIUS access policy for that AD group, when user-2 authenticates, the RADIUS server will send the AP a RADIUS packet with an attribute that contains a value relevant to Role-B, which has been configured on the AP. The user-2 WLAN client will then be assigned to VLAN 20, firewall-policy-B, and a bandwidth policy of 4 Mbps.

FIGURE 9.16 RADIUS attributes for role assignment

WLAN vendors often use VSAs for role assignment, but the standard IETF RADIUS attribute (11) Filter-Id is also often used for role assignment of user traffic permissions.

LDAP Attributes

As previously mentioned, WLAN vendors offer solutions where either a standalone AP or a WLAN controller can dual-function as a RADIUS server and perform direct LDAP queries, thus eliminating the need for an external RADIUS server. However, these dual-function devices most often do not offer extensive support for RADIUS attributes. You have just learned that RADIUS attributes can be leveraged for server-based role assignment of user traffic settings. The end result is that different groups of users and devices can be assigned to different VLANs, firewall policies, and so forth while connected to the same SSID. Can this be accomplished without RADIUS attributes? The answer is yes, because LDAP attributes can also be used for server-based role assignment of user traffic settings. For example, Active Directory queries return the memberOf attribute, which is a list of AD groups to which a user belongs. Access policies can be configured on the WLAN device to assign roles based on AD group values from the memberOf attribute.

Summary

The RADIUS protocol has been around since 1991 and predates 802.11 technology. However, RADIUS is a key component of 802.1X/EAP security that is widely used in enterprise WLAN deployments. RADIUS servers almost always function as the authentication server that validates the credentials of a WLAN supplicant. RADIUS attributes can be used to transport EAP frames and for server-based role assignment for user traffic settings.

RADIUS can fully integrate with any type of LDAP database. Because both RADIUS and LDAP are mature technologies, multiple deployment models exist for both scalability and redundancy. RADIUS can be used with 802.1X/EAP security as well as with captive web portal and MAC authentication.

Exam Essentials

Define LDAP and directory services. Understand that LDAP is an application protocol for providing directory services over an IP network. A directory service is an infrastructure used to share information about network resources.

Explain the relationship between RADIUS and LDAP. Understand that an LDAP-compliant database can be queried by the RADIUS authentication server. 802.1X supplicant credentials can reside in an LDAP database.

Understand how the RADIUS protocol is used for AAA. Explain how RADIUS provides authentication, authorization, and accounting (AAA) capabilities for computers to connect to and use network services.

Describe RADIUS and LDAP deployment models. Explain the many different ways RADIUS and LDAP can be deployed together to provide scalability and redundancy.

Understand RADIUS attributes. Describe how standard RADIUS attributes can be used to communicate AAA information between a RADIUS client and a RADIUS server. Describe how attributes can be used for server-based role assignment of user traffic settings.

Review Questions

1. The ACME Company has over 300 WLAN users communicating through 25 access points using Generic Routing Encapsulation (GRE) to tunnel all 802.11 user traffic back to a central WLAN controller capable of role-based access control (RBAC). What type of access restrictions can be placed on the users after authentication?

A. UDP

B. TCP

C. Bandwidth

D. Time-of-day

E. All of the above

2. What type of database can be integrated with a RADIUS server for proxy authentication?

A. eDirectory

B. Active Directory

C. SQL

D. Open Directory

E. All of the above

3. What ports can be used by a RADIUS server for LDAP queries to an LDAP database server? (Choose all that apply.)

A. UDP 1812

B. UDP 1813

C. TCP 369

D. TCP 636

E. TCP 2083

4. Kenny has been tasked with designing an 802.1X/EAP solution for the corporate WLAN. The company headquarters and datacenter reside in London. Employees need secure WLAN access at 15 remote offices in other European cities. Kenny needs a solution that is cost-efficient but should provide secure WLAN connectivity for the majority of users if a remote WAN link goes down. Which of these RADIUS deployment models best meets his requirements? (Choose the best answer.)

A. Single-site deployment

B. Distributed autonomous sites

C. Distributed sites, centralized RADIUS and LDAP

D. Distributed sites with RADIUS, centralized LDAP

E. Distributed sites with RADIUS proxy, centralized RADIUS and LDAP

5. What port needs to be open on a firewall to permit RadSec protocol authentication and accounting traffic?

A. UDP 1812

B. UDP 1813

C. TCP 369

D. TCP 636

E. TCP 2083

6. Which RADIUS attribute is used to protect encapsulated EAP frames within RADIUS packets?

A. (11) Filter-Id

B. (26) Vendor-Specific

C. (40) Acct-Status-Type

D. (79) EAP-Message

E. (80) Message-Authenticator

7. Which of these terms best describes the capability of a RADIUS server to forward the RADIUS requests across the Internet between different ISPs or different companies?

A. Machine authentication

B. LDAP authentication

C. User authentication

D. Realm-based authentication

E. Domain authentication

8. During an 802.1X/EAP authentication process, which LDAP attribute is used to assign users that belong to different Active Directory groups into distinctive roles with unique user traffic policies? (Choose all that apply.)

A. objectClass

B. userPrincipalName

C. userCert

D. memberOf

E. objectCategory

F. userSharedFolder

9. Which RADIUS attribute is used in RADIUS packets that traverse through a firewall via UDP port 1813?

A. (11) Filter-Id

B. (26) Vendor-Specific

C. (40) Acct-Status-Type

D. (79) EAP-Message

E. (80) Message-Authenticator

F. memberOf

10. Which of these enterprise RADIUS deployment models is the most cost-efficient but will result in all 802.1X supplicants not being able to connect to the WLAN should a remote WAN link goes down? (Choose the best answer.)

A. Single-site deployment

B. Distributed autonomous sites

C. Distributed sites, centralized RADIUS and LDAP

D. Distributed sites with RADIUS, centralized LDAP

11. Within an 802.1X infrastructure framework, what is the name of the device that communicates directly with a RADIUS server using the RADIUS protocol? (Choose all that apply.)

A. Authenticator

B. RADIUS ports

C. Network access server

D. LDAP integration

E. RADIUS client

F. Supplicant

12. Which RADIUS packets can be sent from a RADIUS server to an access point when 802.1X/EAP is the deployed WLAN security solution? (Choose all that apply.)

A. RADIUS Access-Request

B. RADIUS Access-Challenge

C. RADIUS Access-Accept

D. RADIUS Access-Reject

13. Bob has been tasked with designing an 802.1X/EAP solution for the corporate WLAN. The company headquarters and datacenter reside in Denver. Employees need secure WLAN access at 15 remote offices in other cities. Which of these RADIUS deployment models guarantees secure WLAN connectivity even if a remote WAN link goes down? (Choose the best answer.)

A. Single-site deployment

B. Distributed autonomous sites

C. Distributed sites, centralized RADIUS and LDAP

D. Distributed sites with RADIUS, centralized LDAP

E. Distributed sites with RADIUS proxy, centralized RADIUS and LDAP

14. Which RADIUS attribute is used to encapsulate EAP frames within RADIUS packets?

A. (11) Filter-Id

B. (26) Vendor-Specific

C. (40) Acct-Status-Type

D. (79) EAP-Message

E. (80) Message-Authenticator

15. Which of these enterprise RADIUS deployment models is the most cost-efficient but may negatively impact fast secure roaming of WLAN clients? (Choose the best answer.)

A. Single-site deployment

B. Distributed autonomous sites

C. Distributed sites, centralized RADIUS and LDAP

D. Distributed sites with RADIUS, centralized LDAP

E. Distributed sites with RADIUS proxy, centralized RADIUS and LDAP

16. Which of these authentication methods are supported by RADIUS and can be used for WLAN security? (Choose all that apply.)

A. Hologram authentication

B. Captive web portal authentication

C. MAC authentication

D. TSA authentication

E. 802.1X/EAP authentication

17. When configuring an 802.1X/EAP solution, what must be configured on the RADIUS server for RADIUS protocol communications with an access point? (Choose all that apply.)

A. NAS IP addresses

B. Digital certificates

C. EAP protocols

D. LDAP integration settings

E. Authentication and authorization ports

F. Shared secret

18. Which of these authentication methods does not require any WLAN client configuration and is sometimes bound together with other authentication methods?

A. Hologram authentication

B. Captive web portal authentication

C. MAC authentication

D. TSA authentication

E. 802.1X/EAP authentication

19. In which of these enterprise RADIUS deployments do the EAP communications not traverse across a WAN link? (Choose all that apply.)

A. Single-site deployment

B. Distributed autonomous sites

C. Distributed sites, centralized RADIUS and LDAP

D. Distributed sites with RADIUS, centralized LDAP

E. Distributed sites with RADIUS proxy, centralized RADIUS and LDAP

20. During an 802.1X/EAP authentication process, which RADIUS attributes might be used to assign users that are members of different Active Directory groups to distinctive roles with unique user traffic policies? (Choose all that apply.)

A. (11) Filter-Id

B. (26) Vendor-Specific

C. (40) Acct-Status-Type

D. (79) EAP-Message

E. (80) Message-Authenticator

F. memberOf