RSSO with NPS and 802.1x

[CourtKPrin]

I want to create Fortigate policies that apply different web filtering to members of AD security groups, based on student grade levels. I have followed the Technical Tip: Configuring Radius Single Sign-On using NPS 2019. The students are able to connect to the wireless network, authenticate using 802.x, and placed in a specific VLAN. I'm struggling with passing the Network Policy's Class value (TestRSSO) from the NPS to the Fortigate. Where would this information show up when it's working, because I don't think it is.

Would FSSO be a better option for this?

[CourtKPrin]

I'm now thinking the article is only for when using FortiWifi, which we're not using. We are using third-party wifi (Mist). Any articles or suggestions how to configure FSSO or RSSO to get the group info?

[gfleming]

Third-party APs are fine. It's the FortiGate that is receiving the RADIUS info in the end.

You just need a user group on FortiGate that matches the Radius Attribute Value you are sending for the respecitive student classes.

If a student in grade 11 authenticates and attribute "grade11" is passed, they will automatically be put into the the "grade11" group on the Fortigate which you can use to restrict or allow access in firewall policies.

[Markus_M · Accepted solution]

Hi CourtKPrin,

RSSO is perfectly fine. It supports logon, ip change and logoff.

Just needs to be set properly:

https://docs.fortinet.com/document/fortigate/6.2.12/cookbook/85730/radius-single-sign-on-rsso-agent

https://community.fortinet.com/t5/FortiAP/Technical-Tip-Radius-Single-Sign-On-RSSO/ta-p/191223

What is not often understood is that these parts:

        set rsso-endpoint-attribute <attribute>
        set sso-attribute <attribute>

are a mapping instruction on FortiGate. In words:

FortiGate, you take the information of what user name this is (value) from this attribute (name).

FortiGate, you take the information of what group name this is (value) from this attribute (name).

You can freely specify what the user identifying attribute name should be and what the grouping attribute should be.

If unsure, create a packet capture on the FortiGate for port 1813 and see the accounting type start packets for the respective attribute names, that contain the username.

Best regards,

Markus

[CourtKPrin]

I think I have the RSSO agent configured correctly, but it's not working correctly...

edit "RSSO Agent"
set timeout 5
set radius-coa disable
set h3c-compatibility disable
set username-case-sensitive disable
unset group-override-attr-type
set password-renewal enable
set password-encoding auto
set acct-all-servers disable
set switch-controller-acct-fast-framedip-detect 2
set interface-select-method auto
unset switch-controller-service-type
set rsso enable
set rsso-radius-server-port 1813
set rsso-radius-response enable
set rsso-validate-request-secret enable
set rsso-secret removed

set rsso-endpoint-attribute User-Name
unset rsso-endpoint-block-attribute
set sso-attribute Class
set sso-attribute-key ''
set sso-attribute-value-override enable
set rsso-context-timeout 28800
set rsso-log-period 0
set rsso-log-flags protocol-error profile-missing accounting-stop-missed accounting-event endpoint-block radiusd-other
set rsso-flush-ip-session disable
set rsso-ep-one-ip-only disable

The user group:

edit "TestRSSO"
set group-type rsso
set authtimeout 0
set sso-attribute-value "TestRSSO"
next

I have an NPS Network Policy with a Radius attribute Class with the "TestRSSO" value. When I log in and 802.1x authenticate, I match this policy.

[Debbie_FTNT]

Hey CourtKPrin,

the RSSO Agent configuration looks fine.

However, RSSO works on RADIUS Accounting messages - the FortiGate has to receive  accounting messages about the users, and with the correct attributes in place. The Wifi solution probably has to generate those Accounting Messages, and send them to the FortiGate.
The FortiGate can act as an accounting server in this instance, and pull relevant information from the messages; users will be considered authenticated with the Accounting-Start message, and either time out if no Interim-Update is received or will be logged off on an Accounting-Stop message.

Did you verify that the accounting messages are generated and received by FortiGate?

[CourtKPrin]

I used Wireshark on the NPS and saw the accounting-start messages sent to the Fortigate. I see two AVPs for Class. One is the expected TestRSSO and the other is unexpected. I'm guessing the second Class is coming from our Wifi solution.

[CourtKPrin]

Here is a redacted entry from the radius server logs showing the concatenated class attribute (in red). I have no idea where the text before the pipe is coming from or what it is.

"RADIUSSERVER","IAS",02/13/2023,16:35:39,1,"test06","COMPANY\test06","xx-xx-xx-06-3E-F1:SSID1","xx-xx-xx-95-BD-E8",,,,"x.x.x.139",,0,"x.x.x.139","APClient",,,19,"CONNECT 0Mbps 802.11b",,2,5,"TestNetworkPolicy",0,"311 1 10.1.1.33 01/20/2023 05:02:26 1339627|TestRSSO",,,,,,,,,"xxxxxxxxxxBF1375",,,,,,"xxxxxxxxxx47ED07",,,,,,,,,,,,,,,,,,,"Secure Wireless Connections",1,,,,

[CourtKPrin]

Found that the Class attribute data includes the radius ip, Service-Reboot-Time, and vendor code, serial number, 311 is probably Microsoft. I still don't know what triggers NPS to send this class and maybe NPS sends it by default. If so, how does Fortigate parse two class attribute values?

[Debbie_FTNT]

Hey CourtKPrin,

If the accounting message contains two instances of the class attribute, it should parse both of them and try to match them to groups - users can be members of multiple groups, and this could be reflected with multiple class attribute instances in the accounting message. Class attribute instances the FortiGate can't match to a group should be ignored, as far as I know.