Thursday, October 17, 2013

FSSO with Device based policies

While surfing on the web, I have stumbled upon a series of posts discussing FSSO implementation strategies (agent, pooling mode etc.) and the ways they affects computers used by IT personnel. A most common complaint describes a situation when a particular station may change authentication groups (in FSSO) because IT admins have used it to remotely access another AD bound device under different credentials.Simply put, working from a single station sitting behind a Fortigate unit with multiple RDP sessions active is a real pain for IT personnel.

Surely, multiple solutions exist. However, I would like to share a combined approach that allows to effectively distinguish between IT personnel only stations and user accessible devices. At the same time, the proposed approach ensures that devices not bound to domain but using the same corporate network may still be allowed and classified based on device type.

We will need:

Custom defined devices

1) In the User&Device --> Device Definition, click on Create New (on top of the list)

Notice that you may add multiple MAC addresses per device - a useful feature for VM machines that will share the same type of network access
2) Search for devices in the list of detected devices.
Note that if you want to detect and classify devices you should make sure that it is enabled on appropriate interface. Go to Network-->Interfaces--> Select appropriate interface and check for the option "Device Management."

Device Groups

We need to group our devices in one or many groups according to their permissions and other related info.
In User-->Device-->Device Groups, click on Create New (top left corner of the list). Name the group and add the devices that it should include.

Now, we are ready to modify firewall policies. Our goal is to make sure that the group we have created gets authentication before FSSO based on their MAC address and not on their FSSO associated credentials.

Firewall rules

Custom device group policy

Assuming that we have a set of servers that use WSUS and many other services accessing network that also act as ADs, we need to ensure that will not get blocked or capped. We need a new policy with the following configs:

  • Policy type: Firewall
  • Policy subtype: Device Identity
  • Incoming Interface: port on Fortigate unit used by our servers
  • Source address: servers or all or anything you usually use
  • Device: Server- the device group name associated with our server (see authentication rules)
  • etc. - all other configs as usual for internet access

Once the config is complete, make sure that the policy we have created is placed on the list before other policies that have the same combination of Incoming/Outgoing interfaces.

For example, we need to make sure that all users(system) directly logged onto our servers are not passing through FSSO when communication from port 7 to port 9.
In this example, our servers policy is first. FSSO policy is the second one. Third one is a generic per device type policy created to capture all devices that are not AD bound or authenticated otherwise.

Generic device policy

As we have stated earlier this third policy is something that we are actively using to create custom traffic shaping and filtering rules for guest devices. The idea is simple: we do not want 
  • iThings to use our network to get updates, 
  • all types of full-blown OSes to use torrents(it is not an issue on tablets etc.) or get updates,
  • we will monitor botnet behavior and limit certain websites only for some device types
  • etc.
In short we are looking to customize, per device, our rules. To make sure that all non FSSO users get to the third policy, we need to enable a "Skip this policy for unauthenticated user" feature in the second FSSO policy:

Now we can add a generic device policy:


We now have three policies:
  1. Used for our internal admin devices
  2. Used for FSSO AD authenticated users
  3. Used for any other device that was not captured by the first two policies


This method uses MAC address association. A malicious device that has spoofed a MAC address can pose as a server and will get the same rights. However, I hope that many other fail-safe tools exist on your network preventing impersonation.

Finally, if you have more ideas or have implemented it differently, please share!

Sunday, October 13, 2013

Adding OS definitions to Aerohive

In the default config, Aerohive has many OS objects. However, you will find that many are missing. In my install, I have found that all Blackberry devices were identified as Linux/unknown.


First, we need to get the list of DHCP fingerprints:

In this file, we will find the blocks of the info we need to add to our OS object list.

OS objects

OS objects can be found in Configuration --> Advanced configuration --> Common objects --> OS objects. A full config can be exported in the form of a text file. In fact, I strongly suggest to have a look at the way it is formatted before adding or modifying anything. Once you are familiar with the format and ready to add a new definition, you can use Import function to do so.

In our case, we would like to add Blackberry to the list. In the online dhcp_fingerprints.conf, we find the following:
[os 1101]
description=RIM BlackBerry

We format it according to the format found in Aerohive:

Now we can simply create a text file and import it into our config. Note however that there maybe conflicts in object definitions! When searching for Blackberry keyword in the dhcp_fingerprints.conf  you will find the following:
# 1,3,6,15 : 3 CONFLICTS with BlackBerry
[os 404]
description=OEMed Wireless Router

Of course this conflict will never appear unless we have such a device on the network and in our OS objects list. This could explain why Aerohive adds only most common objects in the default config.