Dilemna
Any network administrator has heard of BYOD a term that is very common now in any enterprise these days. More and more users are becoming aware of how to connect these devices to their internal networks, hopefully WEP isnt a part of anyones network these days, but they are aware that their username and password will also get them on the network. Networks such as college campuses or medical facilites have an open network with an acceptable use policy, which allows internal employees the ability to bypass proxy servers in order to check their social media sites or personal email. Once their personal lives' are squared away they hop back on the internal network and resume work...atleast we hope!
Introduction
As the workforce changes more and more users are starting to bring their own devices to the network. Not only are these devices used for their personal use, but also for productivity. In the end this can save companies from having to purchase, inventory and maintain these devices. Companies now a days allow users to bring their personal devices in the network and in most cases will compensate their employees a reasonable percentage of their data services if not 100 percent. Most cases a user already has a tablet or smartphone, so purchasing another device only adds to their collection and most prefer to have their personal device with them anyways.
Solution
Cisco ISE is a powerful appliance that can help organize BYOD devices and corporate assets. However for the scope of this document I am going to focus on one small component which is simple to configure and can really help tighten up policies based on the Network Administrator's delimna. Device registration web authentication is feature that was first available in Cisco ISE 1.1, this is a very intelligent feature in the way it statically assigns endpoints and doesnt involve a very complex configuration (in terms of ISE) in order to get the results that it was sought after. There are several use cases that can come to mind, however we will get the ball rolling on one and hope that it can help open up more scenarios for other networks. In the Network Administrator's dlimena, not only does this help statically assign the devices that come in through the guest portal but it doesn't involve the overhead of having a lobby administrator on staff. In the end this also gives the Network Administrator the ability to identify who his guest users are but he can also create another policy for his internal users as well and have them statically assigned to a different endpoint group. All that is left to do is to create the authorization policies so that each endpoint group can only access the network that was designed for them to connect through
Technical Background
The purpose of device registration web authentication gives administrators the ability to statically assign endpoints to a pre-defined endpoint identity group. This feature was released in ISE 1.1 and you will need to be running atleast 7.2.110 on your wireless controller in order to use this feature within your wireless deployment. The main reason is that with mac filtering enabled on an SSID previous versions will not let you use Radius NAC (Change of Authorization) in conjunction with one another.
The device registration web authentication feature doesnt require you to have dot1x turned on for your guests which doesnt add any overhead to our already over worked Network Administrator. Once you modify the open ssid with mac filtering in order ISE starts to receive data from the endpoints that are joining the guest network.
How it works?
When a device connects to the ssid mac filtering attempts to authenticate the device against ISE, based on most configuratoins when and endpoint isn't present, the client is still authentiated to our "captive portal" or default policy. The device registration web authentication portal is a simple AUP page that displays as if the client has connected successfully all they need to do is accept the page. However, this is where another step takes place. Once the user accepts the AUP they set a AUP condition to true which then statically assigns their endpoint to the endpoint group defined by our Network Administrator. Immediately after this endpoint change ISE then issues COA request to reauthenticate the user. Once the user reauthenticates they get placed in another rule which matches their endpoint group condition, lifts the previous url-redirection to the portal and then they are authorized to browse the web (all without impacting the user experience)!
How did the Network Administrator get this to work?
Configuration before the upgrade to 1.1
The network administrator had deployed ISE since it first hit the market. Therefore he had the following already configured:
- Network device entry in ISE for the wireless lan controller
- Wireless lan controller has the SSIDs configured for radius authentication and has the correct ACLs configured
- ISE is joined to the corporate Active Directory environment (however other database even internal will work in this example also)
- Authorization profiles for their internal users already already configured.
Configuring the DRW feature
Here are the configuration steps needed in order to get this to work:
- Create an endpoint group for example "GuestDevices" and another for "RegisteredDevices" <- I will explain this later
(Administration > Identity Management:Groups > Endpoint Identity Groups > Add
2. After this our Network Administrator then creates the device registration portals and maps the endpoint group to the portal.
Administration > Web Portal Management > Settings > Guest > Multi-Portal Configurations > Add
