2.2 Networking series - Fortigate RSSO

Fortigate RSSO currently looks like a half backed system that was tailored for a a specific use case. It does not look like a new feature that was designed from ground up with users in mind.

To configure RSSO agent look here: http://docs.forticare.com/fos50hlp/50/index.html#page/FortiOS%205.0%20Help/RADIUS-SSO.063.05.html

To configure RSSO groups look here: http://docs.forticare.com/fos50hlp/50/index.html#page/FortiOS%25205.0%2520Help/RADIUS-SSO.063.08.html#ww1368148

An example of use: http://docs.forticare.com/fos50hlp/50/index.html#page/FortiOS%25205.0%2520Help/RADIUS-SSO.063.10.html#ww1369337

Currently, RSSO allows for following attributes:

rsso - enable/disable RADIUS based single sign on feature
rsso-radius-server-port - UDP port to listen on for RADIUS accounting packets
rsso-radius-response - enable/disable sending radius response packets
rsso-validate-request-secret - enable/disable validating RADIUS request shared secret
rsso-secret - RADIUS shared secret for responses / validating requests
rsso-endpoint-attribute - RADIUS Attribute used to hold End Point name
rsso-endpoint-block-attribute - RADIUS Attribute used to hold endpoint to block
sso-attribute - RADIUS Attribute used to match the single sign on group value
sso-attribute-key - key prefix for the single sign on group value in the 'sso-attribute'
rsso-context-timeout - timeout value for RADIUS server database entries (0 = infinite)
rsso-log-period - minimum time period to use for event logs
rsso-log-flags - events to log
rsso-flush-ip-session - enable/disable flush user IP sessions on RADIUS accounting stop

Following config should be used for our setup:
Enable in the interface port settings(Global-Network-Interface) the option to listen to accounting messages.  Then configure through CLI or a combination of Web Interface and CLI the following:

edit "RSSO_Agent"
set rsso enable
set rsso-radius-server-port 1813
set rsso-radius-response enable
set rsso-validate-request-secret enable
set rsso-secret ENC *****
set rsso-endpoint-attribute User-Name
set rsso-endpoint-block-attribute Called-Station-Id
set sso-attribute Vendor-Specific
set sso-attribute-key '6'
set rsso-context-timeout 28800
set rsso-log-period 0
set rsso-log-flags protocol-error profile-missing context-missing accounting-stop-missed accounting-event endpoint-block radiusd-other
set rsso-flush-ip-session disable
next

--- Set the shared secret between Radius server and Fortigate unit.

--- We need to classify the users based on their user names. Since we know that all our authentications come from a single AD service, a user that has two, three, four devices/sessions should have the same quota for all devices.
 
---- Remember that  our Aerohive units send Radius accounting packets to Fortigate. These packets contain Vendor specific attributes that contain group numbers.

However, we have been told by Fortigate support that two of them are there by mistake! That means that: sso-attribute-key and sso-attribute with value Vendor-Specific should not be available as options.This also means that Fortinet's implementation of Radius accounting parser is not feature complete and takes into account only basic attributes.

Moreover, the support states that:

1. "RSSO uses only build in parameter set, and cannot be used in the same policy with FSSO users. You can use it with two different rules with FSSO if you don't use FSSOguest users" - this means that FSSO-Guest and RSSO are not compatible and FSSO and RSSO need to be separated in different policies. 
2. "Web filter work for all users, but Quota work only for "authenticated" users. That's mean it will not work for RSSO users,until we will allow for RSSO users to be "authenticated" users in next releases, and will not work for BYOD non-authenticated users." - this means that users authenticated with RSSO are not authenticated at all! In fact, in the current release(FortiOS 5.0 Build 0128) RSSO seems to be totally useless functionality. What can it do?

UPDATE from 18 January 2013 taken from Fortinet support engineer message(as is) italics-original message, everything else - my comments:
"1. RSSO is nt really "authenticated" users, like FSSO or LDAP for now. This option allow you to assign specific IP's to corresponding groups. The only limitation between LDAP user and FSSO user is using quota.
Since it is not "authenticated", you cannot use it with FSSO users in the same policy. This is a new feature, and will be extended in next releases." - Now everything is clear! After three months of suffering we got it. It was never made to work as authentication method similar to FSSO, LDAP etc. It is simply a way for large providers to assign IPs based on Radius records. Why the documentation says nothing? Why your own engineers do not know nothing about it?
"2. The Vendor-Specific was added by mistake, and cannot work by design. For "Vendor-Specific" you need tree parameters:
a. Attribute - It's Vendor-Specific in our case.
b. VS Attribute - This is not exist in our firmware.
c. attribute key - Used for parsing Attribute parameter, if Radius send not "", but "Group=". In this case key will be "Group=".  This means that sso-attribute-key is simply a setting that strips the prefix string specified from the attribute value received by the unit. As the support says if the value is "Group=mobile" and the sso-attribute-key is "Group=", Fortigate will only store and register "mobile" as the value.
Since we cannot configure "VS Attribute", "Vendor-Specific" will never work. This option will be removed from our firmware." It took us three months and close to a 100 hours of testing with five L2 support engineers to get where we are now . Great customer support!

Update from 09 May 2013: VendorSpecific sso-attribute is still in the latest built (v5.0,build0179 (GA Patch 2)) but it does not work.
Update from 28 May 2013: Confirmed with Fortinet support - the VendorSpecific attribute will be removed and will not work (the only question is when).

2. Networking series - Fortigate

Last time we looked at Aerohive Radius accounting message. This time we will be considering how Fortigate works.

We have the latest patch of version 5 FortiOS (FortiOS 5.0 Build 0128). This means that we have features such as:

• FSSO - Fortinet Single Sign On, is a feature that requires an agent/collector setup to be installed on every AD and DC in the netwrok in order to collect and forward user logins to Fortiage unit. It is not perfect and may miss, sometimes, a logout. However,  we never encountered a problem with a missed login.
• RSSO - Radius Single Sign On, is a feature that requires all accounting packets to be sent to Fortigate unit. This setup allows the unit use external Radius authentication server in order to classify users.
• FortiBar - A tool bar that appears on some user accessed webpages with additional information and actions. 

All of the above may be useful for our  project.

1.2 Networking series - Aerohive

As I stated earlier, Aerohive uses thick APs that in our setup act as Radius servers.

This means that they exchange auth/acc messages between the APs that must contain information on user classification. Given that info, we could, normally, redirect accounting messages to another server and use it as user identification.

In fact, Aerohive sends a standard accounting packet that has two vendor specific parameters.These parameters look in WireShark as:

AVP: l=12 t=Vendor-Specific(26) v=Aerohive Networks, Inc.(26928)
VSA: l=6 t=Unknown-Attribute(1): 00000001
Unknown-Attribute: 00000001

and

AVP: l=12 t=Vendor-Specific(26) v=Aerohive Networks, Inc.(26928)
VSA: l=6 t=Unknown-Attribute(6): 00000ffc
Unknown-Attribute: 00000ffc

One of these parameters, the second one, is of a particular interest to us.
In hex it looks like this: 1a 0c 00006930 06 06 00000ffc
Where:

• 1a 0c => Vendor specific attribute
• 00006930  => Vendor is Aerohive
• 06 => sub-type is Aerohive-User-Profile-Attribute
• 00000ffc => UPID value
   

This UPID value is the value we are looking for: it is a group to which a user belongs to!


A detailed Aerohive dictionary file that can be used in WireShark looks like this:
# -*- text -*-
#
#       The Aerohive Vendor-Specific dictionary.
#
#
VENDOR        Aerohive                26928   
BEGIN-VENDOR    Aerohive

ATTRIBUTE       Aerohive-User-Vlan                  1       integer   
ATTRIBUTE       Aerohive-Libsip-Patron-Info         3       octets encrypt=2
ATTRIBUTE       Aerohive-Libsip-Action              4       integer   
ATTRIBUTE       Aerohive-Libsip-Additional-Message  5       octets
ATTRIBUTE       Aerohive-User-Profile-Attribute     6       integer
ATTRIBUTE       Aerohive-PPSK-Request               201     octets
ATTRIBUTE       Aerohive-PPSK-PMK                   202     octets
ATTRIBUTE       Aerohive-IDM-Message                203     integer
ATTRIBUTE       Aerohive-NT-Identity                204     integer

#
#   Integer Translations
#

#   Aerohive-Libsip-Action Values

VALUE   Aerohive-Libsip-Action            Permit      0
VALUE   Aerohive-Libsip-Action            Restricted  1
VALUE   Aerohive-Libsip-Action            Deny        2


END-VENDOR    Aerohive   

1.1 Networking series - Setup

Some interesting and useful details on our config:

Our Fortigate unit uses FSSO plugin/software installed on our DC to get user ID's. It is also used to do traffic shaping and web filtering for all connections. The unit is installed on the edge and manages all traffic between various LAN's and two WLAN connections we have.

In the institution, we have WIFI available everywhere. We are using Aerohives APs. These are thick clients that can work without a controller and may also execute some additional roles. In our setup, the controller is used only for statistics and pushing new configs. Three access points are configured as redundant Radius Servers and one acts as an ActiveDirectory authenticator. 
This means that wireless network is very resilient and places little load on the AD: it will cash user login/group. At the same time, user profiles are modified in real time according to their behavior and device they are using. For example, an admin using a wireless device will be placed in a special group that has less access than his/her normal profile.


All this functions normally, until the moment we would like to use Fortigate unit to do some accounting/web quota on the users coming from wireless. The machines that belong to our institution are registered in AD. The machines that belong to users, are not. As a result web quota does not work.
Can we do it somehow? Can we optimize our network traffic and identify, at Fortigate, all users (even if it is their own device)?

1. Networking series - Purpose

I decided to post a few rants about some of our problems/solutions we have encountered on our network.

Our set-up:
Wired network is all gigabit managed Cisco switches with some security ensured by PacketFence.
Wireless network is composed of a series of  Aerohive AP's with a controller in a VM.
Edge security and many other things are managed by a Fortigate unit.

Now, all this works really nice until the moment you attempt to do something less common. For example, set web quotas for all users.

We have found that it is not as easy as it seemed and will probably never work as we hoped. The following posts will detail our findings.