Fortiauthenticator RSSO - multi VDOM

[kvn180]

Hi,

We have Clearpass as internal RADIUS server and send all logons via accounting to FortiAuthenticator. This includes both corporate as visitor logons. They are marked using a filter-id.

FortiAuthenticator then forwards to the FortiGate management VDOM but it doesn't leak to the corporate and guest VDOM's. How should I configure that? Ideally, accounting messages are forwarded to their domain only.

Thanks

[xsilver_FTNT]

Hi kvn180,

it depends what do you do with RADIUS accounting on FAC.

Basically you have two options:

1. use this RADIUS accounting source in FSSO and make the FSSO user records from those RADIUS ones you receive from Clearpass

2. do RADIUS proxy on FAC. and forward the records from Clearpass again as RADIUS accounting from FAC to FGT

In this second option, why do you send those messages to FAC and not to FGT directly (duplicitely) ?

The FGT will receive the RADIUS accounting on some interface, probably management VDOM one, so how about to have rsso enabled in RADIUS config in each VDOM and respective user group filtering per AVP Filter-Id (as you mentioned it delimit guests from users) ?

Regards,

Tomas

[kvn180]

Hi Thomas, thanks for you reply.

You suggest to receive accounting on a management VDOM interface and enable RSSO on all other VDOM's. So I did but no users enter the guest VDOM. I opened a case for this one and will share it here.

Can you add more detail on how to filter by filter-ID? I don't see that option in the GUI.

[xsilver_FTNT]

Hi,

you have some RADIUS server config in the VDOM ...

config user radius     edit "RAD_R27_UNIX_RSSO"         set rsso enable         set rsso-radius-response enable         set rsso-secret ENC rEkdk1AQbVV/DTAsYA5hpP7mW53as2iWQB==         set rsso-endpoint-block-attribute Called-Station-Id

        set sso-attribute Filter-Id     next end

.. default value for sso-attribute is Class, this is the AVP where we expect to have delimiting value specifying user profile (on Carrir FortiOS) or user group membership (on FortiOS). This is then on FortiOS used in group definition ...

config user group     edit "RSSO_R27"         set group-type rsso <---         set sso-attribute-value "rsso-test" <--- !! this is the string we expect to be seen in Accounting Type Start/Stop and included AVP as set in RADIUS server (in above case it's Filter-ID, in default it's Class AVP).     next end

Keep in mind that above mentioned group match is on exact string, case sensitive.

Mechanics are very similar to normal RADIUS group match done on Access-Accept, but this time in RSSO done on Accounting Start/Stop Types.

I've described regular Access-Accept based RADIUS Group match in this KB: http://kb.fortinet.com/kb...amp;externalId=FD36464

Best regards,

Tomas

[kvn180]

Hi,

That's indeed what my config looks like:

config user radius     edit "RSSO Agent"         set rsso enable         set rsso-radius-response enable         set rsso-validate-request-secret enable         set rsso-secret ENC sqdsqdqsdqsdsqdqdsqdqsd         set rsso-endpoint-attribute User-Name         set rsso-endpoint-block-attribute Calling-Station-Id         set sso-attribute Filter-Id

config user group     edit "dummy"         set group-type rsso         set sso-attribute-value "dummy"     next     edit "POA-MOBILITY"         set group-type rsso         set sso-attribute-value "POA-MOBILITY"

Packet capture:

RADIUS Protocol     Code: Accounting-Request (4)     Packet identifier: 0x69 (105)     Length: 380     Authenticator: 6a530ae45b9a434d8cb766f4d20b1745     [The response to this request is in frame 46]     Attribute Value Pairs         AVP: l=27 t=User-Name(1): xxx@xxx.com         AVP: l=6 t=NAS-IP-Address(4): 1.1.1.1         AVP: l=6 t=NAS-Port(5): 0         AVP: l=6 t=NAS-Port-Type(61): Wireless-802.11(19)         AVP: l=31 t=Acct-Session-Id(44): xxxxx-597F1519         AVP: l=6 t=Event-Timestamp(55): Jul 31, 2017 14:25:53.000000000 Romance (zomertijd)         AVP: l=25 t=Acct-Multi-Session-Id(50): 34F39AF7223355-0002174090         AVP: l=6 t=Framed-IP-Address(8): 2.2.2.2         AVP: l=14 t=Calling-Station-Id(31): 34F39AD78569         AVP: l=14 t=Called-Station-Id(30): 001A1235689         AVP: l=58 t=Class(25): a1e6973d992e4d5b9aa1213e74a49bfbc30b000000000000...         AVP: l=6 t=Acct-Delay-Time(41): 0         AVP: l=17 t=Vendor-Specific(26) v=Aruba Networks Inc(14823)         AVP: l=22 t=Vendor-Specific(26) v=Aruba Networks Inc(14823)         AVP: l=34 t=Vendor-Specific(26) v=Aruba Networks Inc(14823)         AVP: l=13 t=Vendor-Specific(26) v=Aruba Networks Inc(14823)         AVP: l=12 t=Vendor-Specific(26) v=Aruba Networks Inc(14823)         AVP: l=14 t=Vendor-Specific(26) v=Aruba Networks Inc(14823)         AVP: l=6 t=Acct-Status-Type(40): Interim-Update(3)         AVP: l=6 t=Acct-Input-Octets(42): 3921423         AVP: l=6 t=Acct-Output-Octets(43): 34159052         AVP: l=6 t=Acct-Input-Packets(47): 21539         AVP: l=6 t=Acct-Output-Packets(48): 32871         AVP: l=6 t=Acct-Session-Time(46): 3256         AVP: l=7 t=Filter-Id(11): dummy

These requests are responded by the firewall every time. Our support partner is currently looking into this as well.

The users show when forwarded directly to the trust VDOM, but they're not shared with other domains. Same goes for management VDOM. And when forwarding directly to the guest VDOM, no users are shown.

[xsilver_FTNT]

Hi,

I would suggest to open a support ticket, attach full FortiGate's config, the RADIUS captures and describe clearly intended design of which VDOMs should see which users/RADIUS acct data. As many details as possible. So we on support team can make clear idea about the design/situation and intended authentication flows.

Best regards,

Tomas