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
OR
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:
Conclusion
We now have three policies:
- Used for our internal admin devices
- Used for FSSO AD authenticated users
- Used for any other device that was not captured by the first two policies
Disadvantages
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!
