Captive Portal and computers in hibernation

[LCMember4427]

Hi,

We use VM-100 at a high school and frequently we switch on captive portal to impose access restrictions for certain classes.  We use AD group names in policies to target users.

However, despite enabling CP it appears that quite a few students who are members of classes being restricted never get up the CP auth dialog.  Hence they continue to have free access to the internet. 

I assume that this might be that CP is not popping up when they already have open browser sessions, OR if they just minutes ago have closed their computer so it has gone into hibernation and when they re-open it they can continue with their former sessions.

Am I correct in assuming this?  Please comment. 

Does it exist a way to have CP pop up its auth dialog for *everyone* from the moment CP is enabled so we can be sure that each user is treated via the appropriate policy according to the user's AD group membership?

regards Tor

[gwesson]

Captive Portal is strictly for authenticating users, it isn't something that can be used like an acceptable use policy. If there are users who have already authenticated, meaning you have a user-ip-mapping for them, then that user will not get the captive portal.

Ideally all your users should be authenticated by having the firewall (or dedicated User-ID Agent) scan the logs on the domain controller to map the users' IPs.

I'm not sure how you're leveraging CP to do this, because generally if you want to restrict users or groups, you can do that with a security policy.

[LCMember4427]

Thanks for your comments.  I have the appropriate user agent communicating with AD and also security policies using group names to filter traffic.  But the problem is that some clients slips through by some reason.

Where / how can I see the list of these user-IP mappings?  That might help me to see who is missing or when they get added...

[gwesson]

You can run these CLI commands, depending on what you want to show

> show user ip-user-mapping all
> show user ip-user-mapping-mp all
> show user ip-user-mapping ip 192.0.2.1
> show user ip-user-mapping ip 192.0.2.1/24

The first shows the mapping on the dataplane, the second on the management plane. The 3rd and 4th are for specific IPs or subnets.

Since you already have the mapping configured, captive portal should work for any web traffic. Even if the CP doesn't trigger, the policy is still checking the user and so it should fail to match the rule if it's user/group based.

You may want to review the traffic logs for one of those sessions to see what user it did show up as.

If the log shows no user and the policy that it shows is only user-based it should not match.

If your policy is group-based, then the user-id part is likely working, which would explain the lack of a CP. If this is the case, you'll want to make sure your group-mapping (Device tab > User Identification > Group Mapping Settings tab) has the correct mappings configured and that the number of groups you're using there does not exceed the device maximum. 

[LCMember4427]

Great!!

Thanks for mentioning this.  Now I understand a lot more. 

Does it also exist a user-to-group mapping list?  I use mostly groupnames in the security policies and in some tests I just conducted the mapped user does not get a hit on the policy using a usergroup he actually is a member of.

This worked nicely before and I hope I can be able to fully track down what is going wrong now .-)

regards Tor

[gwesson · Accepted solution]

Just make sure that:

1. The user is in the group when you look at the DC.

2. You have that group added to the group-mapping section I mentioned earlier.

3. You do not have more than the device limit on the number of groups.

You can show group mappings with:

> show user user-ids all
> show user user-ids match-user UserNameInQuestion

[LCMember4427]

Thanks a lot!