What I’m about to show you is an amazing method for assigning users to their correct groups in FortiGate firewalls. We can apply different security profiles to individual groups, all through one 802.1x login.
This example is using Ruckus Wireless, but will work exactly the same for any Wi-Fi vendor.
It works by using 802.1x WPA2/AES logins on the Wi-Fi, and passing the users information to the FortiGate via Radius accounting. Then, use Radius Single Sign On (RSSO) groups on the FortiGate to collect the username/group are to the Ruckus by the Windows NPS server. There are lots of moving parts, but it really is simple. I had difficulty finding good documentation about Fortigate’s RSSO profiles – but in practice they work great.
The goal of this project/entry is to that your FortiGate knows the username, IP and group (if assigned) of the user who just authenticated to the wireless network. Once you know these things, you can apply different Unified Threat Management (UTM) policies to users with RSSO groups in the FortiGate firewall.
There are many good use cases for this – for example, a school network. I set this up recently for a school that has students and faculty authenticate through the same Ruckus controller, but to different 802.1x WLANs (SSIDs: Student and Faculty). The FortiGate can then apply correct policies to each user (student or faculty) and therefore lock down student web surfing much more than a faculty member. You might be wondering why you couldn’t just use captive portal on the FortiGate,with LDAP groups. I would say you could, but that is another step users have to take, and this is “Single Sign On” for a reason.
Here is what you need to make all this happen: Wi-Fi using 802.1x, NPS (or any radius server), FortiGate – that’s it.
I am going to assume that we already have Ruckus Wireless using 802.1x and NPS with no problems.
At first I had trouble setting this up, because I thought that that the NPS server should send the Radius accounting info to the FortiGate. That’s wrong. The controller is the device that knows about the authentication, and therefore needs to pass that on to the FortiGate.
That means you have a AAA server setup on the controller for 802.1x authentication, and a AAA radius accounting server pointing to the FortiGate.
Radius Accounting Between Ruckus and Fortigate
First we need to create the connection between Ruckus and Fortigate via Radius accounting.
Next on the FortiGate, create an RSSO profile for the Ruckus system.
Feel free to name this whatever, but the PSK has to match what you created on the Ruckus system. By default, the RSSO profile uses the class variable to match users, but you can change what to match. For example, you could match by NAS-Port, User-Name, Class, etc.
So, you can modify many of these settings in the CLI. Below are the settings I used:
config user radius
set rsso enable
set rsso-secret ENC eoTXOqectoW0sjb5lLVW/7rr3BB0DocxlKeW64yfoIq7NTblyMc1TT9/V2M8m2LJmotwNrDYS+hOBSWV68wWULjuT88tOZHli7Nqqe8k5hoK4iHmLuG6x9R7apR9b+JU6O48mY8jiUaf48pY8wamagNdOALtrew6k+yWFzfd7gzo+qgag2sOI+Q46GnI1ybGPo6YQQ==
set rsso-endpoint-attribute User-Name
Next, modify NPS to send the values that you will match on the FortiGate. In this example, I am saying that if any domain users authenticate through the ZoneDirector, then send the IP/Username/”Tag” to the FortiGate so it knows who to apply the correct firewall policy to. The “Tag” I am sending is the Class Variable of “Domain Users”. Something to note: this is not the given Active Directory group, but a variable I am assigning that just references the group. I could say “Social media” if I wanted, then match on that.
Modify the Microsoft NPS policies to reflect what you need.
Remember, we are working off the assumption that your 802.1x is up and working, and NPS is great. So, how do you match a variable from NPS on the FortiGate? You could really use a variety of different variables. For now, use the class variable. To assign the class variable, modify the Network Policy in NPS that you want to apply to a certain criteria.
Modify your “Connections to Wireless via AD Authentication” policy. Then once you edit the policy and go to the Settings tab, there will be a few attributes already listed. You might have some already or not. Add the “Class” variable, and then assign it to whichever value you want to match in the firewall group. In this case, I am setting my value to Domain Users.
Select “Class” from the list of attributes that comes up, and it will ask for the string that you want to set. This is the keyword you will use to match the user to group in the firewall, just like using an FSSO group and matching the domain group. This might be students vs. teachers, Domain users, whatever.
Press OK, and now you have the variable added. You can confirm as seen below:
Great, now the hard part’s done. From there, have some users log in to wireless, and see if you get correct RSSO users found in your firewall. You can check this by navigating in the firewall to User & Device –> Monitor –> Firewall.
Awesome, it found my username and my IP, but my group is blank. How can you apply a policy to user if they have no group? The answer: it’s just the same as the FSSO. If you do not have a firewall policy that references the Radius group you created, then there won’t be a group, filtering, anything. So create a new firewall policy and select your RSSO group as the source group. In my example, the group is called Radius Domain Users.
To show a policy example check out below: My domain FSSO is above my RSSO policy.
Using RSSO and 802.1x is awesome. It allows you to use a nearly single pane of glass aspect and have your firewall and wireless both be able to know who the user is just by their Wi-Fi login. Also, using 802.1x for wireless authentication and key management is very secure. Having users known on wireless no matter what device can really be beneficial in reporting, either through FortiCloud of FAZ.