Dynamic User Profile Assignment via Captive Web Portal and Radius

  • 1
  • Question
  • Updated 5 years ago
  • Answered
Hi,
I'm trying to dynamically assign a VLAN to a user based upon the radius credentials they enter on a captive web portal after initial SSID connection.

I work in school and we're implementing BYOD - devices of which are not a member of our AD. When a faculty member connects to our BYOD SSID (initially in VLAN 35) and authenticates on the web portal they should be placed in VLAN 32.

However if any other user authenticates they'll remain in VLAN 35.

I have configured our radius server to return filter-id dependent on which user group authenticates and this appears to work. Filter-id is equal to the user group name (FWD_BYOD) which in turn has attribute number 32 assigned to it.

I am seeing the following behavior...

A pupil user connects to the SSID and is prompted for credentials on the web portal. They enter these credentials and remain on VLAN 35 and can web browse correctly. YAY!

However, a staff member connects to the SSID, enters their credentials and after being presented with the successful authentication page they look network access (cannot ping gateway or APs, the wireless device IP doesn't change). This leads me to hypothesize that the AP does in fact move the staff device into VLAN 32 (or another unknown VLAN) but the device fails to realise this and as such doesn't receive a new IP. I have attempted to force a renew and enter a static IP after authentication succeeds but still cannot regain network access so perhaps that disproves my hypothesis?

Does it sound like I'm following the right path here? Have I missed anything? Is it even possible to change VLAN after a device has authenticated and presented the web portal?

Many thanks,

Ryan
Photo of Ryan Powell

Ryan Powell

  • 17 Posts
  • 3 Reply Likes

Posted 5 years ago

  • 1
Photo of Ryan Powell

Ryan Powell

  • 17 Posts
  • 3 Reply Likes
Just to correct a mistake "look network access" in the 7th paragraph should read "lose network access"
Photo of Crowdie

Crowdie, Champ

  • 972 Posts
  • 272 Reply Likes
From my experience some operating systems, particularly Windows, do not react well to being "moved" from one VLAN to another. In some cases the "VLAN move" does not work at all and the device remains in the original VLAN.
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
Looks to me like you're not using the right RADIUS attribute.

The filter-id RADIUS attribute is not used to re-map the user to a different user profile or VLAN directly. The filter-id attribute is used by Aerohive to match against a local group configuration which is mapped to a user profile attribute within the Aerohive configuration (which specifies a default VLAN ID). To use filter-id, you would return a group name e.g. "students", create a local group in HiveManager called "students" with user profile attribute 32, say, which has default VLAN ID 32.

It is possible to directly return a user profile attribute from the RADIUS server. The attributes to do this are as follows (and they must all be returned):

Tunnel-Type = GRE (10)
Tunnel-Medium-Type = IPv4 (1)
Tunnel-Pvt-Group-Id =

Another alternative is to return a VLAN ID directly (overriding the default VLAN ID specified in the user profile):

Tunnel-Type = VLAN (13) [in NPS, this is under 'commonly used for 802.1x']
Tunnel-Pvt-Group-Id = VLAN ID
(and optionally also set the user profile via filter-id, otherwise it will just take the default user profile configured in the policy)

Aerohive are nice in giving you three different ways to do this - but nasty by confusing you and not documenting it properly :)

Whichever way you do it though, the client will be "hopping VLANs" from before and after the captive portal and as Crowdie mentions, this is unlikely to work because the OS doesn't know that the VLAN has changed. We would need a way to ask the client to perform a new DHCP request - no inherent mechanism exists to do this with a captive portal.

One possible solution for this which I think some vendors have tried (though not Aerohive as far as I am aware) is for the AP to disassociate the client after logging in through the captive portal and "hope" that they it quickly reconnects (at which point the AP's cached user session would bypass the CWP and put them on the "right" VLAN immediately so they will get the "right" IP address via DHCP) - unfortunately there's no reliable way to ensure the client reconnects automatically to the same SSID (it's entirely down to the client's configuration, preference order for networks etc.), so this would not be a robust solution anyway. VLAN assignment works well with 802.1x where the authentication happens BEFORE the client is connected to the network (and where there's a mechanism for the RADIUS server to pass information DIRECTLY to the client) - with captive portal it's somewhat problematic to say the least as the client is oblivious to what is going on.

Have you considered instead of changing the VLANs, using two different user profiles with different firewall policies to allow different network access? This works well and we use this in many customers to deny students access to "staff" networks (or even to specific applications with the layer-7 inspection functions now available).
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
Sorry, I misread your original post and you are returning the group name.

That being the case, ignore the first half of my response!
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
An issue with using firewall policies alone is that Layer 2 isolation is not achieved so the security issues that exist at that level of abstraction when mixing clients of a different categorisation/classification remain.

I think it is important to always be mindful of that and to make an informed choice as to whether that is important or not to have the isolation based on the environment and requirements. Personally, I always use VLANs but then never use a captive portal in the first place so would not touch on the potential issues Roberto mentions with clients.

(The point he raises could indeed make it a conceptual deal breaker to change the VLAN if there are significant compatibility concerns.)

Many people argue, however, that if you are using a captive portal, you have already exposed yourself to so many other things that it is not a big deal when considered in context - I have to agree.
Photo of Ryan Powell

Ryan Powell

  • 17 Posts
  • 3 Reply Likes
Roberto - I agree with you that some how dis-associating and re-associating the client within a certain cache period would be the way forward. Any thoughts if Aerohive support this natively?

All - I've done some additional investigation and I'm not so sure now that the client is indeed moved VLAN after authenticating on the web portal. In client monitor I can see the device and it shows the successfully authenticated user's name against it. However the VLAN number hasn't changed.

Piecing together the various forum posts and official documentation I've read, I am returning the following attributes from NPS:

Tunnel-Type: VLANs
Tunnel-Medium-Type: IPv4
Tunnel-pvt-Group-ID: 32 (The desired VLAN number)
Filter-Id: FWD_Corp (the local user group name)

Does the above sound right? Any ideas why client monitor would still show the client as being in VLAN 35 even after successfully authenticating?

Thanks
Photo of Ryan Powell

Ryan Powell

  • 17 Posts
  • 3 Reply Likes
Further to the original response.

I'd like to segregate devices based on authenticating user due to our filtering system...

We have a collection of iPads and teacher personal laptops. Teaching staff require the use of YouTube and various other websites that by default are blocked to children. The proxy supports different profiles based on the originating IP of the request - hence the desire to separate devices into different VLANs.

The complication (if it isn't already) is that both teachers and children could use the same iPad, so the only way of differentiating between these is the captive web portal.

I had originally thought about using .11x wireless authentication at the point of association but we then run the risk that staff credentials will remain within the iPad (or laptop) wireless supplicant.
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
Hi Ryan,

There is a solution for you. This is what you need to do:

You will need three VLANs for this. The first VLAN is used only for the authentication process. The DHCP leases on this VLAN should be very short (say 10 seconds).

In the CWP settings, under "Optional Advanced Configuration", check the check box to override the registration VLAN and set it to the VLAN you've created above.

In the SSIDs list in the policy, under User Profiles, select your two user profiles you want to assign to teachers and students, setting one of them as the default.

In your RADIUS server, you need to get the user profile reassigned, not just overriding the VLAN ID:

Tunnel-Type = GRE (10)
Tunnel-Medium-Type = IPv4 (1)
Tunnel-Pvt-Group-Id = {User Profile Attribute number, not group name}

The short lease time on the registration VLAN means that the client should do a new DHCP process. The way DHCP works means that this will take a short while. The client will be trying to renew the registration VLAN DHCP lease by unicast to the DHCP server; when the lease expires it will do a full DHCP DISCOVER and should get an IP on the final VLAN. It should therefore be fairly seamless to the client, though knowing Apple's many bugs in the past with wireless and DHCP, I couldn't guarantee it!

Regards,
Roberto
Photo of Ryan Powell

Ryan Powell

  • 17 Posts
  • 3 Reply Likes
Hi Roberto,

Thanks for the response. I've configured the SSID as you've described. The client no longer loses network access after authenticating but the client doesn't move VLAN either. They remain in the guest VLAN, and get re-prompted by the CWP every few minutes.

Client monitor now lists the correct VLAN ID but as I say, the client doesn't physically change VLANs.

Any ideas what may be causing that?

Many thanks.
Ryan
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
How is your DHCP environment configured? Are you using DHCP relay or do you have a DHCP server interface in each VLAN? Note that this functionality requires an external DHCP server - you cannot use the inbuilt one on the AP. It may be that the DHCP lease on the registration subnet is being successfully renewed even after the client is moved to a different VLAN, or it could be that the DHCP server is offerring an address from the wrong scope (there was a bug in Windows 2003 DHCP server that would cause this for example).

It would be useful to get a remote sniffer capture on the AP's Ethernet interface so you can see the DHCP interactions directly. What does the Client Monitor show regarding DHCP.

If I get a chance, I'll set this up in our lab, as I'm interested in the detailed mechanics of it - we haven't had a customer with this requirement up til now, but I'd be willing to be we get a requirement in the next couple of weeks now!
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
OK, I tested in the lab.

Using the method above, the user profile is set but the VLAN ID does not seem to change from the "override" VLAN configured in the CWP settings (as evidenced from a "show station" on the AP). Difficult to say if this is a bug or working "as designed" as the documentation is not very comprehensive.

So instead, I configured an additional "dummy" user profile that is set as the default user profile for the SSID - this profile (and therefore the associated VLAN) is used during the "walled garden" pre-authentication phase, and we can have a short DHCP lease in that subnet. The other two user profiles ("staff" and "teachers") are defined as available user profiles for the SSID.

With this configuration (and using the RADIUS settings in my post above, returning the user profile attribute number directly), when the user authenticated they got moved to the correct user profile AND VLAN.

When the DHCP lease expires, the client does a new DISCOVER and gets an IP in the correct VLAN and away we go.

The problem is you will need a DHCP server that has the ability to set lease times in seconds, whereas most only allow you to set 1 minute as the minimum lease time.

Also, you need to be aware of some iOS bugs that caused devices to retain an old IP address instead of renewing it as it should - hopefully these are all fixed now.

Finally, some clients (Windows 7/8 for example) will, when they get their new IP address, re-display the "The network requires additional credentials" message, even though you've already logged on. This could cause some confusion for users I suppose.

I think that although it does work, it's not going to give a completely smooth user experience, and some devices might not behave as you'd like...
Photo of Ryan Powell

Ryan Powell

  • 17 Posts
  • 3 Reply Likes
Hi,

Sorry for the long reply. We've been short staffed this week and it's made 'fiddling' with the wireless difficult.

I'll try and conduct some tests this afternoon and let you know what I find.

Regards,
Ryan