05-21-2016 03:43 PM - edited 05-21-2016 03:48 PM
Hi,
I have set up a captive portal for services http and https. The captive portal works well and I get user-id/IP mapping in the logs. The rules are then applied based on the user group membership (AD). However, this user-id mapping does not work for all services and therefore some rules are not applied based on the user-id... The sessions are not marked as "captive portal" and therefore the rules do not apply. You can see this in the screenshot below. Can someone explains what's wrong ? I need the user-id/IP matching for all sessions from the same IP, not only the one that are http-service or https-service related.
Thank you for your help !
05-23-2016 12:46 AM
Hi
It appears you are looking at 2 different things
the captive portal should only hit once every X time for identification (the first time a user opens a browser in the morning and then every x minutes as per your config), identify the user and then keep that user 'logged on' for a certain amount of time (you can configure this time in the Captive portal configuration). after that the user's sessions should not show up as captive portal, since the user to ip mapping is still active and all sessions originating from that IP address should be identified as that user.
If this is not happening, there could be an other issue. How did you set the timers? by default the idle timer is 15 minutes (if no traffic is seen for 15 minutes and 1 second, the user to IP mapping is removed) and the session timer is 60 minutes (after 60 minutes, present captive portal/NTLM again)
is ssl decryption enabled? since these are ssl sessions decryption would be required to allow captive portal to be served. it is also possible the connections in your screenshot were unable to be decrypted, do the details of the session show you any more information ? (there is a small magnifying glass to the left of the log entry)
05-23-2016 08:05 AM
Captive portal not working with HTTPS Sessions
Follow the below procedure to get the user name always for the captive portal users
Remedy for this is to implement ssl decryption with a way described below
Prerequisite:
-------------------
Knowledge of ssl decryption.
Knowledge of captive portal.
Non working scenario.
1- Unknow user from the wireless zone tries visiting https://www.google.com
2- Since its a SSL session, the captive portal page may not trigger.
3- Firewall was unable to know who was the user as he does not got a CP page.
use ssl decyption
Working screnario
---------------------
>Decryption policy 1 says no decrypt to wireless known users.
>Decryption policy 2 says decrypt all the traffic from comming from wireless zone.
1- Unknown user from the wireless zone tries visiting https://www.google.gom.
2- Decryption policy 2 triggers and provides a CP page.
3 - Unknown user again tries visiting any other https site, the CP page was prompted again because of Decryption policy number 2.
4- User enters his credentials and is a part group captive-portal-grp ( we are using AD for authenticating CP users )
5- Now the firewall is aware of the user and decryption rule number #1 will trigger and will not decrypt any further traffic from the known user and user will not get a certificate warning page.
6- Security policy also needed in place based on group and zone individually. ( create a group specific policy on the top and a zone specific below that )
05-23-2016 08:09 AM
If you are unable to see the below link follow the detailes mentioed above
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!
