A recent project provided an opportunity to learn a new way to handle webauth for repeat users. You know the story, many mobile devices (Apple specifically) cause heartburn for users that need to operate on the “guest” network all day or in some cases multiple days. They are constantly having to log in throughout the day. This customer wanted to provide a way for their employees to get internet access on their own devices, but wants them to login with their AD credentials. They also want the typical Guest scenario to work. So, when a provisioned Guest user gets the webauth page, they put in their sponsored credentials, accept the AUP, and away they go with internet access (only). But, if an employee logs in with their AD credentials, I introduce a new flow to the process: DRW. Device Registration Webauth is called only when AD credentials are used. I made a custom DRW portal that is very vanilla but automatically registers the employee’s device and gives them internet access (only).
My authz policy conditions look like this: Network Access:UseCase EQUALS Guest Flow AND AD1:ExternalGroups EQUALS domain.com/Users/Domain Users and then the Permissions (or authz profile) is EMP_DRW. My authz profile basically calls the ACLs, names the vlan, and includes Web Authentication: Device Registration, calls the redirect ACL, and manually calls the EMP_DRW custom device registration webauth portal I created. So, when there is a Guest Flow AND AD credentials in use, this new EMP_DRW portal gets called. I have the normal guest portal taking care of grabbing the AD credentials and having the user agree to the AUP. From there, they are given the success page which basically lets them know they are authenticated and then tells them that they will be redirected to the company’s website in a few seconds. I added a meta-refresh to accomplish that. Upon redirection, the user is redirected again to the EMP_DRW portal since they were using the Guest Flow AND they input AD credentials. The very simplified EMP_DRW portal registers their MAC address in the background, and forwards them to another success page that lets them know that their device has been registered and that they will be redirected to the company’s website in a few seconds.
The solution worked for this particular customer mainly because it is being used by employees – who are there day after day. The thing to keep in mind here is that when a device is registered, it is there until removed – there is no expiry. There is another use case at this same customer for employees who want to bring their own devices but get more than just internet access. In that use case, PEAP is required and the resulting access is greater than just internet access, but limited access nonetheless. They are also requiring posture assessment to determine the health of the endpoint with that use case.
There are some inherent issues with this solution. The main one being that you can’t keep an employee from using their credentials to register a ton of devices that don’t necessarily belong to an employee. The harm isn’t great though since the resulting access is internet only.
Just to be clear, this isn’t 100% original. I based the above use case on one that I heard about on a Cisco webex from Craig Hyps and Aaron Woland. I believe they did a similar use case for a large public venue for media personnel. The twist I gave it was that I’m not just using device registration for guest access – I’m using both the normal provisioned guest access but I added that if AD credentials are used, the DRW flow gets introduced.