Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
tyua
New Contributor

SSO RADIUS

I have WiFi controller HP, wireless users are identified by the RADIUS server (Windows NPS). I want to see these WiFi users on FortiGate, is this possible?

Thank you!

1 Solution
xsilver_FTNT

not truly for FortiAPs, basically RADIUS server is the one who should send RADIUS Accounting-Requests (type Start and Stop especially), and FortiGate/FortiAuthenticator or standalone FSSO Collector can build SSO records based on received data.

 

So user access WiFi, WLC auth user through RADIUS server, which sends Accounting Start to FortiGate, which builds (R)SSO user record (sometimes called end-point-database), and based on received AVP is user bonded to rsso type of firewall user group. Such group can then be used in IBP (identity based policy) to restrict/auth/log traffic/access to protected resources.

 

Any RADIUS server compliant to standards and capable of sending standard Accounting data to configured recepients can be used. Access this way authenticated can originat form any source like WiFi (through WLC auth mechanisms), or port based authentication on switches/routers/other-firewalls .. almost limitless and working as those sources authenticate on RADIUS server.

Tomas Stribrny - NASDAQ:FTNT - Fortinet Inc. - TAC Staff Engineer
AAA, MFA, VoIP and other Fortinet stuff

View solution in original post

9 REPLIES 9
xsilver_FTNT
Staff
Staff

Hi Tyua,

yes, seems to be possible and it looks like this might help you:

http://cookbook.fortinet.com/rsso-wifi-access-control/

Best regards,

Tomas

Tomas Stribrny - NASDAQ:FTNT - Fortinet Inc. - TAC Staff Engineer
AAA, MFA, VoIP and other Fortinet stuff

tyua

xsilver wrote:

yes, seems to be possible and it looks like this might help you:

http://cookbook.fortinet.com/rsso-wifi-access-control/

 

I think it is only for FortiAP. 

But I have the HP MSM760 Access Controller.

xsilver_FTNT

not truly for FortiAPs, basically RADIUS server is the one who should send RADIUS Accounting-Requests (type Start and Stop especially), and FortiGate/FortiAuthenticator or standalone FSSO Collector can build SSO records based on received data.

 

So user access WiFi, WLC auth user through RADIUS server, which sends Accounting Start to FortiGate, which builds (R)SSO user record (sometimes called end-point-database), and based on received AVP is user bonded to rsso type of firewall user group. Such group can then be used in IBP (identity based policy) to restrict/auth/log traffic/access to protected resources.

 

Any RADIUS server compliant to standards and capable of sending standard Accounting data to configured recepients can be used. Access this way authenticated can originat form any source like WiFi (through WLC auth mechanisms), or port based authentication on switches/routers/other-firewalls .. almost limitless and working as those sources authenticate on RADIUS server.

Tomas Stribrny - NASDAQ:FTNT - Fortinet Inc. - TAC Staff Engineer
AAA, MFA, VoIP and other Fortinet stuff

tyua

Thank you xsilver_FTNT.

I created a RSSO-Agent on FortiGate and configured on the RADIUS server (NPS) redirection Accounting-Reguests to FortiGate.

But in the Fortigate logs I see the recording: - RADIUS accounting event - RADIUS start or interim-update packet received with missing or invalid profile specified

I also created the dump Accounting-Requests, and I see that Request Start no contains attribute Framed-IP-Address.

xsilver_FTNT

sorry for late reply, I was on vacation.

 

on FortiGate pay attention to 'sso-attribute' in RADIUS server config (default AVP is 'Class'), and to 'sso-attribute-value' in user group (group-type rsso) config.

 

To match user into profile/group, this attribute has to be present, and it's value has to match to the one in group config.

 

It's a basic string match as in RADIUS based group match.Idea is very similar to standard group match, but differs in ability to define which AVP we are looking into and we can also define key prefixes and more. For standard RADIUS group match see this KB http://kb.fortinet.com/kb/microsites/microsite.do?cmd=displayKC&docType=kc&externalId=FD36464

 

Tomas Stribrny - NASDAQ:FTNT - Fortinet Inc. - TAC Staff Engineer
AAA, MFA, VoIP and other Fortinet stuff

tyua

Sorry, I do not understand.

If you are not difficult to see that I have

 

My devices : FortiGate interface - "10.50.0.25" Windows Server NPS - "10.0.9.33" HP MSM760 WiFi controller - "10.0.1.250"

 

on Fortigaye I have:

config user radius
    edit "RSSO Agent"
        set rsso enable
        set rsso-radius-response enable
        set rsso-validate-request-secret enable
        set rsso-secret ENC ----
        set rsso-endpoint-attribute User-Name
 set sso-attribute Filter-Id
    next
    edit "RSSO_Server"
        set server "10.0.9.33"
        set secret ENC ----
        set auth-type ms_chap_v2
        set source-ip 10.50.0.25
            config accounting-server
                edit 1
                    set status enable
                    set server "10.0.9.33"
                    set secret ENC ----
                    set source-ip 10.50.0.25
                next
            end
    next
end


config user group
    edit "RSSO_Group"
        set group-type rsso
        set sso-attribute-value "unrestricted"
    next
end

 

 

on NPS:

 

1. Remote Radius Server.

2. Connection Request Policy

3. Network Policy

 

on WiFi controller:

Authentication with Radius - "10.0.9.33"

 

Captured packets.

https://dl.dropboxusercon...67913/sniffer_1_1.pcap

xsilver_FTNT

I see that 'RSSO Agent' has 'sso-attribute' = Filter-Id

and user group has sso-attribute-value "unrestricted"

but I haven't found any occurence of "unrestricted" string in provided .pcap

none of the packets from NPS 10.0.9.33 showed "Filter-Id" AVP within the other AVPs listed.

check somehow on NPS if you are really hitting right policy as last screenshot suggest that this NPS might be right one, but might not be used and so attributes set sent back to FGT

Tomas Stribrny - NASDAQ:FTNT - Fortinet Inc. - TAC Staff Engineer
AAA, MFA, VoIP and other Fortinet stuff

tyua

I am hitting right policy, it can be seen from the eventlog

 

What am I doing wrong? 

xsilver_FTNT

dig in NPS, all looks good but sniffer proof that there is no Filter-Id AVP and expected content, so match on FGT side wont work. And will not work till you fix NPS and it starts to send mentioned AVP in accounting packets.

Tomas Stribrny - NASDAQ:FTNT - Fortinet Inc. - TAC Staff Engineer
AAA, MFA, VoIP and other Fortinet stuff

Labels
Top Kudoed Authors