Thursday, January 17, 2013

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:

To configure RSSO groups look here:

An example of use:

Currently, RSSO allows for following attributes:

rsso - enable/disable RADIUS based single sign on feature
- UDP port to listen on for RADIUS accounting packets
- enable/disable sending radius response packets
- enable/disable validating RADIUS request shared secret
- RADIUS shared secret for responses / validating requests
- RADIUS Attribute used to hold End Point name
- RADIUS Attribute used to hold endpoint to block
- RADIUS Attribute used to match the single sign on group value
- key prefix for the single sign on group value in the 'sso-attribute'
- timeout value for RADIUS server database entries (0 = infinite)
- minimum time period to use for event logs
- events to log
- 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


--- 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).


  1. Were you able to make use of the RSSO feature at all? My organization just paid for an 8 hour block of Fortinet Professional Services to setup RSSO. They haven't been able to get it to function.

    1. Short answer: NO
      Long answer: We where able to configure our Fortigate unit so that it can receive and properly interpret the records sent by our Radius server. However, authentication and everything related with it never worked and never will(at least for us with the current design). As I have mentioned in my previous posts, RSSO is not compatible with FSSO.

      However, it depends on what you are trying to do. Can you give me more info?

  2. Hi,

    I have been playing with getting RRSO to work for wireless clients, and I believe I understand why it doesn't work at the moment. From the documentation itself:-

    For RADIUS SSO to work, FortiOS needs to know the user’s endpoint identifier (usually IP address) and RADIUS user group. There are default RADIUS attributes where FortiOS expects this information, but you can change these attributes in the config user radius CLI command.

    The problem here is that RADIUS is not used to assign an IP address, only to authenticate the user to access the network. While you can change the RADIUS attribute used to resolve the IP, its no help because the IP is assigned by DHCP, which RADIUS has no visibility of. This results in the error:-

    RADIUS protocol error: parse error: Carrier Endpoint

    Looking at the RADIUS messages , the client IP is never included in them at all.

    It would only work in scenarios where RADIUS was being used to assign an IP address, such as PPP requests.

    I can make a guess as to what the single use scenario this was designed for. A large ISP in the UK will be using Fortigate for filtering their DSL users. This would be useful for them, as the PPP connection request could them be resolved to an IP and they can apply filtering based on DSL username. This becomes even more likely based on the recent UK legislation on "opt-in" to adult content.

    The only way this could work for wireless as far as I can see would be to use RADIUS to obtain the client MAC address and then use the DHCP database to resolve this to an IP, this would require the Fortigate to be the DHCP server, or use the local ARP table to resolve MAC's to IP's.

    Hope this makes sense.

    1. Hi,

      My Radius implementation (Aerohive) the same as the one from MS do send IPs and are IP aware. I have sniffed the ports or Fortigate and have confirmed that the acc. packet contains the IPs. Similarly, the log on Fortigate was showing the IPs and the MACs properly.

      Finally, note that Fortigate has confirmed a successful implementation of pure Radius authentication with MS Radius.

  3. Hi,
    just a simple question:

    the rsso-endpoint-attribute, according to the guide should be an IP Address, by default it points to calling-station-id which in my case (MS-RADIUS) is the MAC address of the calling station.

    Is my setup still working or I need to put in place something to retrieve the IP Address from the client, for instance Framed-IP-Address by setting this on my fortigate:

    set rsso-endpoint-attribute Framed-IP_Adress

    Best L.

    1. At the time I have tested the system(a few revision ago), Fortigate did not care about the content of the rsso-endpoint-attribute. As far as I can tell, it simply does a string match. Therefore, IP or MAC does not matter. I have tested both MAC and IP and as far as the RSSO user table goes both have worked.
      That being said, I have never tested this setup in a full blown working environment.

    2. If you are right how is the Fortigate able, once a packet flow, to correlate that particular packet with the class attribute in the accounting message it received previously from my Radius?

      Does it have a sort algorithmic intelligence to discern between various fields in the ip packet?


    3. You are partially correct. If you plan to use RSSO as the only authentication method you do need to set the rsso-endpoint-attribute to IP address.
      Note: As far as I have been told 6 months ago by Fortinet support, there are no plans to implement MAC address based flow control for firewall or any other related component.
      In our case, we were interested in a combination of FSSO and RSSO for quota management only. At that stage Fortinet support said that we have to change the rsso-endpoint-attribute to User-Name. This gave us a proper and clean RSSO table with all logged in users. However, I do not remember the exact format of that table(if IP's where there or not). I will need to run a test and see.
      In general, I find that RSSO is not well understood by the support team at Fortinet so I can share only the info I have and hope that it will help someone.

    4. Thank you, for your reply.
      In fact was I am planning, is to use RSSO together with the 802.1x port authentication so when people authenticate with my radius I am able, via the accounting message, to tell fortigate who are my groups (via the class attribute) and then subsequently write policy on based on RSSO authenticated group.