Fortiauthenticator 802.1x and Radius SSO to FSSO

[krzysztofp]

I'm trying to get 802.1x working for computer and user authentication via 802.1x, and this part just works.

I can even configure it working with just one LDAP server, where i use dnshostname on remote computer import group for username and certificate binding.

What i struggle with is pushing the authentication/accounting information to FSSO. I can make it work for either users, or either computers, but it seems to not be working for both.

Do i really need to have a separate Radius server just to be able to have information from both users and computers forwarded to FSSO?

[Anthony_E]

Hello,

Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible.

Thanks,

[gfleming]

RSSO and FSSO are two mechanisms to accomplish roughly the same thing. You likely don't need both of them at the same time.

FSSO will work by essentially parsing AD logs and matching user logons with IP addresses. It's not meant AFAIK to be used with computer accounts.

If you want that level of granularity you should look at authenticating with Machine Certificates in your RADIUS environment and making some policies around that.

I.e. Machine Authenticated = Access to LDAP, Machine + User Authenticated = ACcess to all resources, User Authenticated = BYOD network access only.

[Markus_M]

Hi Krzysztof,

I'll try adding the flow of FSSO from FortiGate backwards.

1) FortiGate gets user+IP (and maybe group info) ahead of the actual traffic and can use these in policies. Practical case: FortiGate receives a packet for policy evaluation and sees on the policy there is a group it has to match additionally. "Do I have a group that matches the srcip of that packet in my user list?" - the user list is easy in CLI with:

diag firewall auth list

filter the list with "grep"

diag firewall auth list | grep -A7 -i <user or IP>

2) To get this you either need an RSSO (radius accounting) or FSSO connector.

3) The FSSO connector is ideally pointing towards the Collector Agent or a FortiAuthenticator (working as collector). There is a "local agent" on the FortiGate which I would simply avoid as it is less flexible.

4) The Collector will, hence the name, collect events.

It can collect via:

- syslog

- RADIUS accounting

- polling of a domain controller (for user logon events)

- DCAgent (pushes user logon events from a DC to the collector)

- Exchange server events

- Terminal server agents (TSAgent)

- in case of FortiAuthenticator, also FortiClients SSO Mobility agent (needs license)

The FortiGate will not care from where the events come, all will be "FSSO".

The FortiGate also has an accounting connector that simply processes RADIUS accounting messages directly, instead of a collector. Works the same, but should be clear when troubleshooting. If the FortiGate processes RADIUS Accounting directly, FortiGate knows this as "RSSO".

In order for your scenario to work you will need info about an event for your machine event with IP+Username and maybe group for scaling (add one group on policy vs 325 machines).

The processed logon events are only for users. Hence, the recommendation is RADIUS accounting or syslog.

RADIUS Accounting and syslog however are flexible and can supply that information. It depends on your respective server to serve that info.

On FortiGate, Collector Agent and FortiAuthenticator you can map for RADIUS Accounting what Accounting attribute contains the username value, which is the IP and which is the group.

With Collector Agent and FortiAuthenticator you can do the same with syslog.

Best regards,

Markus

[krzysztofp]

I do now the basics of how collectors/fortiauthenticator works.

For security concerns, we decided against using authenticated Workstation checks. Instead we opted to use Radius-Accounting packets from 802.1x, as well as VPN connect/disconnect messages, as they nicely contains information about connected host/username, together with update/logout information.

The thing that i'm struggling with is the LDAP filter that FortiCollector/FortiAuthenticator is using. 

When defining LDAP server we add information about object <class> and <username> attribute. Then Forti software is using it to construct LDAP filter as:
(&(objectclass=<class>)(<username>=user))

From syslog, i get following parameters:

• for Computer
  • Incoming name: computer.domain.tld
  • Maps to ad:dNSHostName
• User
  • Incoming name: username
  • Maps to AD:sAMAccountName

And it works with fortigate syslog, but either for computer or user object.

Current workaround for this issue is to use separate parameter in ad to contain data, fe. extensionattribute10. Then i can create synch script that copies sAMAccountName->extensionattribute10 and dNSHostName->extensionattribute10. Then the system is using this query to find the data:
(&(objectclass=person)(extensionattribute10=userOrComputer))

and i do get proper user and computer in RSSO.

I'm just wondering if this can be done in easier way. Perfect solution will be to be able to use custom query asking two parameters, like fe:

(&(objectclass=person)(|(sAMAccountName=userOrComputer)(dNSHostName=userOrComputer))), or something that will allow me to do regexreplace on username field.

In the latter case, i wish i could use some more advanced syntax on field designation for username:
User-Name={{:username}},
i would like to be able to filter out some values from usernames and concatenate others.
Like for user/computer diffrence, just using sAMAccountName as a name field will be ok, if i could:
- for username just pass the username value

- for computername strip out domain, and add $ at the end. Fe. computer.domain.tld -> computer$
This would allow me to authenticate both computer and users with just samaccountname.

[Markus_M]

Hi Krzysztof,

that is a very nice explanation having a good technical detail. Refreshing!

The mapping for radius accounting is actually done directly on what it receives inside the accounting message, same for syslog.

The LDAP query is done after this mapping step, where it would already be too late. Accounting will not have understood the dNSHostName because another Attribute value is expected to find the username value in.

That cannot be changed, but the Accounting messages are supposed to have the respective values. It is however expected that the PC and user authentication trigger different values. You could maybe create two connectors, or RADIUS accounting sources and read separately for machine and user authentication.

Best regards,

Markus