Explorer

Question

SSO options for Linux Desktops.

Forum|Forum|2 years ago
May 24, 2024
15 replies
8592 views

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,

ozkanaltas

Valued Contributor III

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.

ebyAuthor

Explorer

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,

ozkanaltas

Valued Contributor III

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

Debbie_FTNT

Staff & Editor

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-WinSec-polling/ta-p/189910

I hope this helps :)

ebyAuthor

Explorer

@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.

@Debbie_FTNT-

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,

ebyAuthor

Explorer

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

*****************************************

Debbie_FTNT

Staff & Editor

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

ebyAuthor

Explorer

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,

AnthonyL

New Member

Hi, I’m interested about this issue because I have the same case to fix. Did you find a solution ?

ebyAuthor

Explorer

Found a solution.

Windows Server FSSO - Polling Mode with Poll logon sessions using Windows NetAPI.
Ubuntu - Windows AD integration using winbind (have done fresh OS install without sssd components)

On DNS server, manual A record need to be created for linux hosts, else will get “No DNS domain configured for <hostname>. Unable to perform DNS Update.
DNS update failed: NT_STATUS_INVALID_PARAMETER” while joining domain on linux host.

winbind require manual configuration of nsswitch.conf, smb.conf, and krb5.conf files.

On smb.conf, idmap config must use "rid" as backend.

Hope this helps anyone looking to resolve this issue.

Thanks,

Arth33

New Member

Hello,

Thanks a lot for help about this issue.
How do you handle, connection change, wired to wifi to vpn ...

What command line do you use to force, fsso login ?
Do you have any delay or is it immediate ?

Thanks very much !

ebyAuthor

Explorer

Use RADIUS for wireless and vpn.

If possible, use .1x with RSSO for wired authentication, thus you can avoid AD/FSSO related complications.

Not forcing any additional command line on linux. Default local user is used only for system maintenance, FSSO reads AD user login on linux and sends to Fortigate. Perhaps you can omit $ on FSSO config to facilitate access for linux local users (i have not tested this), check Debbies FSSO Agent tips.

I have not observed any FSSO delay with Linux clients.

The only caveat is updating DNS entries for linux desktops on AD Server, if you have separate DHCP and DNS server. This can be done thru script on linux clients or on linux DHCP/DNS server.

Brielle564

New Member

@eby wrote:

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,

Linux clients are not directly supported by Fortinet's FSSO (Fortinet Single Sign-On) in DC Agent mode. FSSO primarily works with Windows-based clients.

Sign up

Login with SSO

Login to the community

Login with SSO