Skip to main content
tanr
tanr
New Member
September 29, 2016
Question

Interface Captive Portal No Longer Allows 'Use groups from policies for captive portal'?

  • September 29, 2016
  • 2 replies
  • 7152 views

Hi All,

 

I've got a set of FortiGate 5.4.1 user groups that refer to RADIUS user groups from a FortiAuthenticator 4.1.1.

 

I can, per wired interface (not wifi SSID), set the Security Mode to Captive Portal and select the FGT user groups.  This then forces users on that interface to the captive portal to authenticate, and should only allow users for the groups listed.  This all seems to work.

 

I was going to test out the documented setting for interfaces with captive portals of "Use Groups from Policies" instead of having to listing out the groups at the interface level: http://help.fortinet.com/fos50hlp/54/Content/FortiOS/fortigate-authentication-54/CaptivePortals.htm.

 

However, this doesn't appear to be an option, either in the CLI or the GUI.  Anybody know if this has been removed?  Or maybe it's only available with certain restrictions on the security policies?

 

I should explain that I'm exploring these options as I try to find a reasonable way to have users on a particular vlan authenticate to the RADIUS server (FortiAuthenticator) but still allow other devices (a printer and scanner) to do MAC-based authentication.  It doesn't look like the FAC's support for 802.1X MAC Authentication Bypass works for this case, as it requires 802.1X and it is too heavy handed -- applying to an entire RADIUS client, as opposed to a user group.  Though I could certainly be misreading the docs on this!  I don't have an AD server or LDAP.

 

So the reason I was looking at the "Use Groups from Policies for Captive Portal" option was that it would allow me to have two policies: One with just the hardware devices listed (MAC-based auth automatically with no user group to validate), the other with the user group.  This would (theoretically) allow the MAC-based authentication and also do the user authentication.

 

Open to suggestions on this!  Thanks.

2 replies

tanr
tanrAuthor
New Member
September 30, 2016

I've found a method to work around this, at least for my case.

 

I set the (vlan) interface to have Security Mode: Captive Portal and add the appropriate FortiGate user groups, that include my matching RADIUS user groups from the FortiAuthenticator.  Note that by setting the FAC user group to have the RADIUS attribute Fortinet-Group-Name I can then make the FGT user group that includes the FAC RADIUS server name that group so that all its users are automatically included, without needing to have matching user names on the FGT.

 

For security policies on that source interface that need to have users authenticate to the captive portal and only allow those groups, I set the source subnet and add the matching FGT user groups.  Users will have to authenticate to the captive portal

 

For security policies on that source interface that allow MAC-based authentication (for printers and scanners in this case) I've given aliases to the appropriate Devices on the FGT that include their MAC addresses.  With these policies I set the source subnet, no matching FGT user groups, and the Device aliases that I want to be able to bypass authentication by their MAC address.

 

To turn off the captive portal check for that policy, edit it in the CLI and:

 

  set captive-portal-exempt enable

 

This all works.  It's not as clean as I'd like, since some checks are on the FortiGate and some on the FortiAuthenticator, but it gets the job done.  It doesn't directly allow me to have different security policy rules on the same interface with different user groups authenticating for different subnets unless I allow all those groups on the interface itself, but its usable.

 

If anybody has suggestions on how to do this in a cleaner manner, let me know!

tanr
tanrAuthor
New Member
October 1, 2016

I'm stuck on one other detail of this.

 

In order to have the https redirect to the local captive portal not give a certificate warning, I've done the following:

 

- Set the FGT to have a DNS service (recursive) on the vlan interface for these users, with the associated DNS Database including an A record with a FQDN set to the FGT's IP (which is what is used for captive portal).

- Have the authentication certificate (set in User and Device, Authentication Settings) signed by our local root CA, with a wildcard CN that correctly covers the authentication URLs that will be used for the various vlans.

- Edited the policy rule that includes HTTP and HTTPS wan access for the zone including this vlan to have auth-redirect-addr set to the FQDN of the captive portal for this vlan.

 

Per https://stuff.purdon.ca/?page_id=171 and http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD30760&sliceId=1&docTypeID and https://forum.fortinet.com/tm.aspx?m=132904 this should work, and it almost does.

 

What happens, though, is that the security policy auth-redirect-addr seems to get completely ignored, and the user instead gets redirected to the IP, which of course fails the certificate check.  I can manually change the IP (with its port and extra magic numbers) to use the FQDN instead, which gives me the captive portal with a beautiful green lock icon and no certificate error.

 

What I've tried so far, without success:

- Set interface Security Mode to Captive Portal, External, set the URL to the FQDN   this attempts to navigate to the URL, but then times out

- Moved the test-vlan_to_wan access security policy to the top of the list to have it hit first

- Set the security policy auth-cert to the cert being used in case this caused a problem

- Used the same cert that is being used for ssl-inspection

- Turned off SSL inspection for the policy

 

A partial workaround is that I can set the top level auth-portal address to one of my captive portal URLs.

[ul]
  • Set the top level auth-portal address to my URL config firewall auth-portal   set portal-addr <CaptivePortalAddr>[/ul]

    This works, with or without the security policy having auth-redirect-addr set.  I get no certificate errors, unless user is going from a white-listed HTTPS site to the captive portal.  However, it gives me only one possible captive portal URL to use, which doesn't solve my issue, where I need one of these per vlan.

     

    So, my real problem appears to be that I can't get auth-redirect-addr in the firewall security policy to work.

    Any ideas what I may be missing? Is there some other requirement for auth-redirect-addr to work?

    Could this be a problem with zones, or security policy rules (ie with multiple wan destination interfaces)? Some different way to specify an external captive portal URL for the interface as the local URL that works?

     

    Any suggestions welcome.

    • Terms & ConditionsAccessibility statement
    Thought Leadership. Security Summit. Thursday, November 12th, PGA National Resort, Palm Beach Gardens, FL.
    Thought Leadership. Security Summit. Thursday, October 8th. Disney's Grand Californian Hotel & SPA, Anaheim, CA.
    Security Operations Summit: Modernize SecOps. Operate AI-Native.AMER: November 4 | 9:00 AM PST. India and SAARC: November 5 | 10:00 AM IST. EMEA: November 5 | 10:30 AM CET. APAC: November 5 | 11:00 AM SGT