Let's lift the hood for a second and take a look at what is happening when the user connected to 'employee-secure'. In this scenario, IT had enabled 802.1x with an authentication protocol known as PEAP or Protected Extensible Authentications Protocol. In the interests of not "nerding out" too much lets not define this further than to say PEAP provides a mechanism to leverage a user's existing Active Directory credentials to allow the network to verify the identity of the user attempting to connect. That is, a secure connection is established between the device and the network authentication server and a hashed version of the user credentials are exchanged to authenticate and authorize the user for network access.
The component in the network that ends up doing all the heavy lifting in this transaction is the network authentication server mentioned above. This server is what is commonly known as a AAA server. AAA standing for Authentication, Authorization and Accounting and leverages a protocol called RADIUS for communicating with network infrastructure like WiFi Access Points.
So how can a AAA server help solve some of the BYOD friction we've been discussing and remove the need to rely on changes in human behavior to affect security policy. It all starts with your selection of a AAA server and how well equipped that technology is to help you define business rules. These business rules become the backbone of your BYOD policy and allow IT to gain both visibility and control over personal mobile devices on their corporate network.
Traditionally AAA servers have been very utilitarian and transactional by nature, providing binary results for network authentication. For example, user name and password correct equals OK and user name and password wrong equal Not OK. The opportunity to get in the middle of that decision and leverage context of the transaction either didn't exist or required configuration or scripting beyond the patience of many a network administrator.
What sort of context are we talking about in a RADIUS transaction? It turns out there is a wealth of data that can be used as input into your business rules and can help shape the way different devices are admitting onto your network. Some examples of this context could be:
- is the user connected via wired or wireless,
- if wireless is the device in the foyer or a secure area,
- is the connection being attempted outside of normal business hours,
- is the user account in Active Directory or the guest database
And the one we have been looking at in the 'employee-secure' example:
- is the device attempting to authenticate using just user name and password (PEAP).
Building business rules to tame BYOD becomes a lot easier when you have the right technology at hand. A policy-enabled AAA server allows you to start building simple rules to address a common issue today; unknown employee-owned devices connecting to your corporate network. More importantly, these same rules will allow you to capture these unregistered devices and guide them through a BYOD friendly self-service workflow. We know users are going to attempt to connect to existing corporate WiFi networks, whether they be 802.1x PEAP based or just simple guest networks. Why try and change this behavior when policy-enabled AAA can actually take advantage of this situation and drive the user to self-enroll. Again, don't try to change user behavior; instead, have the technology leverage their existing behavior.
The following example shows a policy rule that is detecting a user authenticating with PEAP based authentication and is differentiating this from the second rule that is detecting authentication transactions based on EAP-TLS. This alternate 802.1x authentication method leverages unique client certificates per device instead of the users Active Directory credentials as is the case with PEAP.
As you can see, there are two distinct actions that are being enforced based on the policy differentiation between the PEAP and EAP-TLS transactions. If the user is authenticating with PEAP, the device in placed in a BYOD Provisioning state. On the other hand, if the device has already been provisioned with a TLS client certificate, we know this device has already enrolled and can be placed in a BYOD Limited Access Zone.
How does this policy rule change the way these devices are admitted onto the network? This is where RADIUS comes into play and is the language spoken to the network infrastructure to communicate business rules. The example above had two policy enforcement states of 'BYOD Provisioning' and 'BYOD Limited Access Zone'. The RADIUS protocol allows the AAA server to signal to the network how each device should be controlled after successfully authenticating.
For example, the 'BYOD Provisioning' state results in the WiFi Access Point quarantining the device and redirecting any attempts to browse to the Internet to a BYOD provisioning portal. From there this user can be further authorized for BYOD enrollment and provisioned with a corporate issued BYOD credential such as a TLS client certificate. Now this BYOD provisioning workflow could be hosted by a Mobile Device Management (MDM) platform or this could be a BYOD onboarding feature built right into your AAA server but this is a discussion for another day and another blog post. The question of how to provision the device for BYOD access isn't really the focus of this blog but moreover how policy enabled AAA can enable an employee self-managed workflow for BYOD enrollment.
Why is this important? We didn't have to change user behavior and were able to automatically detect the presence of an un-enrolled BYO device and guide it through the provisioning workflow. Secondly, the arrival of BYOD at your doorstep does not typically signal an increase in IT headcount to support these devices on your network. Being able to guide users to a workflow that auto provisions their device with all the required network settings, device settings and potentially even required business Apps, without needing to log a single help desk call has to be central in any BYOD planning exercise.
We recently met with a customer who had generously given away a couple of thousand tablets to their staff as a reward for a great financial year. This customer had investment in a device management solution that relied on sending out an invitation for the employees to enroll their device. When those users were faced with the choice of responding to this IT governance email or playing with their new tablet, you can guess which path they chose. To play with a tablet of course you have to feed it Internet and these tablets only have WiFi interfaces. Before their IT could do anything about it, there was a significant percentage of the tablets already connected to the WiFi network and accessing internal IT resources based on a blanket authentication policy that was only designed to handle corporate issued laptops. Deploying a policy enabled AAA solution will solve this customer issue by taking back control of the largest entry point for BYO devices, the corporate access layer network.
Policy enabled AAA is an essential part of any successful BYOD deployment and is the building blocks for other complimentary technologies like device profiling, MDM and mobile application policy management.
If you would like to learn more about Aruba's offering for policy enabled AAA please check out the ClearPass product line on the following link:
