I have couple of Linux Desktops(Ubuntu 22.04 LTS and Linux Mint LTS versions) that need to use SSO for internet access and other networks. On Fortigate static ip based rules are used for these Linux desktops. These linux desktops are joined to Windows AD thru "sssd" and domain based user login is enabled. However these systems do not show up in FSSO Agent when logged in with AD user name.
FSSO agent mode = DC Agent mode.
On AD, the users are in correct OU and Group.
Are Linux clients supported on FSSO ?.
What are my options to resolve this with other than RSSO or any other Fortinet Products?.
Thanks in Advance,
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Hello @eby ,
I don't have experience with FSSO Linux clients but I have a question maybe this question will solve your problem.
When your Linux client logged on to their computer, are logs created on the AD server? If you say yes, I think you can configure the FSSO Agent can able to read these logs.
Hello @ozkanaltas ,
I don't have a clue where to check logon events on AD server, is there any guide ?. All i know is the linux system hostnames and its static ip.
Thanks,
Hello @eby ,
I found a document for that. You can follow this document for check logs.
https://www.lepide.com/how-to/audit-who-logged-into-a-computer-and-when.html
This is a bit out there, but, as an alternative:
- if the Linux logins generate syslog somewhere, you can send that to Collector Agent
- Collector Agent can be configured to parse the syslog logs to get IP, username, group info
-> I have no idea IF your Linux users generate syslog logs though, so this might not be feasible
Regarding the Windows logs ozkanaltas mentioned - those would be Windows Security Event Logs that FSSO Collector Agent can check to see what users logged in.
Some digging found this reddit thread (https://www.reddit.com/r/fortinet/comments/8qmj3q/comment/e0nqs6e/) covering essentially the same scenario, and it looks like Linux logins may generate a log with event ID 4769, which the Collector Agent can be told to check for:
Basic config:
https://community.fortinet.com/t5/FortiGate/Technical-Tip-FSSO-Agent-in-polling-mode/ta-p/228136
Event Log IDs:
https://community.fortinet.com/t5/FortiAuthenticator/Technical-Tip-Windows-event-IDs-used-by-FSSO-in...
I hope this helps :)
@ozkanaltas- Thanks, created filter to list all events for the test user, but it would not list any thing. Anyway have asked windows admin to look into this.
I have enabled logging in DC Agent registry and collected the following interesting output from dcagentlog.txt
Local user login on Ubuntu.
*****************************************
05/24/2024 16:04:25.990: processing Logon (level=1, logonid=0-0) domain\user_name$ () from (null)
Ignore logon event without workstation information.
05/24/2024 16:04:26.021: finish processing.
Msv1_0SubAuthenticationFilter is called
*****************************************
Using domain user login.
*****************************************
05/24/2024 15:50:28.400: processing Logon (level=1, logonid=0-0) domain\domain_user (Real Name) from (null)
Ignore logon event without workstation information.
05/24/2024 15:50:28.431: finish processing.
Msv1_0SubAuthenticationFilter is called
*****************************************
1, Looks like AD is unable to get system hostname and ip address for Linux logon. Not certain if this is Ubuntu related or Windows AD related.
2, the only difference between local logon and domain logon is the "$" symbol after user_name.
3, Username, hostname and host ip is logged for logins from Windows systems.
4, dcagentlog.txt don't contain any logoff, including for Windows systems, I don't know the registry entry for this.
Note: I can't find any events in the event viewer to determine what exactly is happening.
Thanks,
When logging from Windows system.
*****************************************
05/24/2024 16:03:04.645: processing Logon (level=1, logonid=0-0) domain\domain_user (Real Name) from system-host-name
Domain:"domain-name" DNS suffix added:"domain.com".
05/24/2024 16:03:04.676: finish processing.
workstation IP:"local ip"
Msv1_0SubAuthenticationFilter is called
*****************************************
Hey eby,
ok, this might need a bit of clarification on how DC Agent works vs Security Event Log Polling.
DC Agent:
- this essentially monitors lsass.exe on the domain controller the agent is running on
- lsass.exe is a Windows service that handles domain logins
- DC Agent doesn't actively check anything really (though you can enable DNS lookups), it just parses lsass.exe for logins, and if it finds any, sends them to Collector Agent provided it has either the host's workstation name, or the IP
-> without either, FSSO is not possible, as it works by associating a particular user with a particular IP (which we can get from workstation name via DNS if necessary)
- if Linux logins do not create enough information in lsass.exe when they interact with it, then DC Agent doesn't have anything it can pick up on
- we have no way to influence how/what information lsass.exe picks up and thus makes available to DC agent.
Note: user accounts ending in '$' are usually computer accounts, and are usually ignored by FSSO in any case.
Event Log Polling:
- this works by Collector Agent accessing the Windows Security Event logs and reading the log messages
- domain controllers generate log messages when users authenticate (different logs depending on how they authenticate, so there are a variety of logs the Collector Agent can be told to check)
- the Linux logins might show up in Windows Security Event logs in a usable manner, so event log polling might detect those better
-> You can check event logs on the domain controller that the Linux PC authenticates to (use Win+R to open the 'Run' command, then type "eventvwr" to open up the Event Viewer. Under Windows Logs > Security, you should find any logs IF they are generated
-> As mentioned above, event ID 4769 might be a candidate. How to filter for it:
Have a look on your domain controllers and see if EventViewer > Security logs contains any information for the Linux workstations.
Cheers,
Debbie
Created on 05-30-2024 04:31 AM Edited on 05-30-2024 05:12 AM
Hi Debbie,
When logging into Ubuntu with AD user credentials, Event ID: 4769 is generated.
Whilst FSSO debug logs still "show Ignore logon event without workstation information." and AD event show <local_user>$@<domain> instead of AD username.
I find this very strange, and not certain where issue lies.
-------------------------------
Ubuntu system
-------------------------------
~$ sudo sssctl domain-status <domain>
Online status: Online
Active servers:
AD Global Catalog: dc01.<domain>
AD Domain Controller: dc01.<domain>
Discovered AD Global Catalog servers:
- dc01.<domain>
Discovered AD Domain Controller servers:
- dc01.<domain>
~$
-------------------------------
~$ realm list
<domain>
type: kerberos
realm-name: <domain>
domain-name: <domain>
configured: kerberos-member
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: libnss-sss
required-package: libpam-sss
required-package: adcli
required-package: samba-common-bin
login-formats: %U@<domain>
login-policy: allow-realm-logins
~$
-------------------------------
AD -> Event Viewer -> Security -> Information -> Kerberos Service Ticket Operations.
-------------------------------
A Kerberos service ticket was requested.
TargetUserName <local_user>$@<domain>
TargetDomainName <domain>
ServiceName krbtgt/<domain>
ServiceSid S-1-0-0
TicketOptions 0x60000000
TicketEncryptionType 0xffffffff
IpAddress ::ffff:<local ipv4>
IpPort 41842
Status 0xd
LogonGuid {00000000-0000-0000-0000-000000000000}
TransmittedServices -
-------------------------------
Thanks,
Hey eby,
I'm sorry to say this is rapidly reaching the end of my knowledge :/.
Event ID 4769 CAN be picked up by FSSO Collector Agent if you set it to polling; have you tried that yet, or are you still experimenting with DC Agent?
My best guess is that you will not get it to work with DC agent at all, if it can't get sufficient information from lsass.exe.
Regarding the polling - set the event IDs to '2', that's a predefined set of event IDs which includes 4769, so this may allow Collector Agent to detect your Linux host.
You can leave the DC Agents in place; Collector Agent can still receive and process DC Agent information while also actively polling.
Regarding the username ending in '$', and this being ignored by default, you can try this:
Enter the registry on the Collector Agent host, (Win+R, then 'regedit'), then navigate to HKEY_LOCAL_MACHINE\software\wow6432node\fortinet\fsae\collectoragent, and create a new key (dword).
Call this key 'allow_dollar_sign_in_usernames', and set the value to 1.
This ensures that Collector Agent does NOT ignore events with '$' anymore. However, this also means that machine account activity from Windows hosts may be picked up as well, so keep an eye on the Collector Agent and its logs for any logins with '$' in the name. They might replace legitimate user logins!
If you're already actively relying on FSSO, then please do not do any of the above (enable polling, create the registry key) during business hours, but enable them later or during a maintenance window so you can test with your Linux host and also test with some Windows hosts to see if they encounter any issues!
Cheers,
Deborah
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1732 | |
1106 | |
752 | |
447 | |
240 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.