Identity Awareness and Captive Portal - SOLVED

[TheGrave]

I'm having hard times figuring the relation beween HTTPS Inspection and Identity Awareness, and also how is Captive Portal supposed to function. I'm running R80.20, let me describe you the behaviours I notice:

1) Unless I enable HTTPS Inspection my AppC & URLF policy rule that matches as a source an Access Role and as a service either http/https or a ceratain website collection (e.g. Facebook, YouTube) does not function properly. I'm not sure whether it's a feature or a bug but actions like Ask/Inform/Drop with message simply do not work unless HTTPS Inspection is enabled. This proves to be the case for non-SSL sites as well, e.g. http://neverssl.com. I understand the dependency of matching URL collections like Facebok and YouTube on HTTPS Inspection (which SHOULD be documented in admin guides not shovelled down some sk) but I don't understand why plain HTTP does not function as expected with modern browsers (latest Edge and Firefox). Perhaps because Captive Portal must redirect a non-https website to an https-website? Some crappy code in R80.20? Go figure.

2) With HTTPS Inspection turned on everything works as expected for both HTTP and HTTPS but then comes the case of having an accept rule with "Enable Identity Captive Portal". Now this beautiful checkbox puts a requirement on the rule to use an access role either as a source or destination (destination doesn't make much sense to me but anyway). Now, if you create an access role object if you do not place any restrictions on it it will match pretty much every user (logged in to a domain, non-domain user, anybody) so in theory all traffic should go to Captive Portal, right? No, it doesn't. If I put a restriction on e.g. IP and user group from AD I see in the logs the identity of the user is known but still no redirection to Captive Portal. It wouldn't make much sense anyway, right? You already know who the user is, why redirect it to enter user and pass again? So I'm kinda missing the idea behind this scenario completely (a scenario quoted in many admin guides, study materials, etc.). Again, I'm not sure why redirection doesn't take place, could be a bug. Don't have an R80.40 to test at the moment.

[Chris_Atkinson]

Hi , which JHF version is installed and are you working the symptoms with TAC in parallel?

[TheGrave]

117 on SMS, 101 on GWs. I'll try to upgrade but I'm facing some issues.

This is a lab environment on trial licenses so no support contracts here.

[Chris_Atkinson]

Amongst other things you definitely will want the SNI improvements from T118 and above.

[TheGrave]

I upgraded both SMS and GWs to the latest JHF, same story - I can only get it to work for HTTP but not HTTPS (at least now they have a warning for apps that require HTTPS Inspection). I verified HTTPS Inspection is working fine by itself but not with Identity Awareness (e.g. access role in the Source field). When I use a network object in the source field AppC works fine so everything by itself seems to be OK until I mix AppC with IA - for some reason rule gets bypassed. The only restriction I impose in the access rule is that the user should be an AD member of a certain group. I left only browser-based auth enabled for IA, AD integration works fine and I'm logging with a non-domain user (on a domain PC). I'm kinda baffled here.

[Chris_Atkinson]

Are you able to share some screenshots of the policy/rule and access role config please?

[TheGrave]

Solved. Seems like the initial DB for AppC and URLF was pretty much next to empty (or corrupted?) as it couldn't catch stuff like Facebook and YouTube. God knows why automatic updates were not working either as Internet connectivity was fine and I managed to update the DB manually. I was only thinking my rules are matching conditionally but in reality the cleanup rule (which had an action of Accept) was introducing the confusion.