FSSO creating Issues when taking RDP of other systems using different domain user account

[sheerazali]

Hi Fortinet Community,

I would like to explain our scenario and seek your advice on an issue we're encountering.

In our environment, we have configured two Domain Controllers (DCs). Each DC has a separate FSSO-DC Agent and a separate FSSO-Collector Agent. In total, we have two collector agents and two DC-agents across our two DCs. We are using the DC Agent Mode, where the DC agent sends logon information (Windows security logon events) to the collector agents.

The issue we're facing occurs when a user (e.g., 'abdul.rehman@example.com') logs into a Windows machine. The user is successfully authenticated by FSSO and gains access to resources according to the Firewall Policies. At this point, we can see in the FortiGate FSSO Users Dashboard that the user 'abdul.rehman@example.com' is listed with the assigned IP address (e.g., '192.168.100.100').

The problem arises when the user attempts to access one of our internal systems (a server or another PC) using the RDP protocol from the same machine where they are already logged in and authenticated. When the user logs in via RDP using a different account (e.g., 'rdp-user@example.com'—an account created specifically for RDP access within the AD network), FortiGate shows that after 2 to 3 seconds of successful RDP logon, the session with 'abdul.rehman@example.com' disappears. Instead, 'rdp-user@example.com' appears with the same IP address '192.168.100.100', even though 'abdul.rehman@example.com' is still logged in. Consequently, 'abdul.rehman@example.com' can no longer access resources until they log off and log back in.

Could you suggest what might be causing this issue and where to start troubleshooting?

• How can we troubleshoot which authentication protocol is being used during these processes?
• Is it possible that this issue is related to NTLM-based authentication?
• Should we consider moving to Kerberos for testing?
• or is there any other issue other than the mentioned ones?

Any insights or guidance on resolving this issue would be greatly appreciated.

Thank you!

#FortiGate #FortiOS #FSSO

[tpatel]

Hello sheerazali, 

Can you please check event log in server because if you rdp in different pc then that pc is getting different ip address.

Check on windows server you are able to see another user name and ip in event logs.

[FortiArt · Accepted solution]

Would you please check this article and confirm that the checkbox for Disable RDP Override setting is enabled:

https://community.fortinet.com/t5/FortiGate/Technical-Tip-FSSO-RDP-logon-override/ta-p/197159

Hope this help

[sheerazali]

Hi @FortiArt 

As i already mentioned that we are not running our Collector Agent as Polling Mode. We are running Collector Agent with DC-Agent in DC-Agent Mode. The Guide you provided is related to Polling Mode. 

[sheerazali]

Hi @FortiArt 

Please ignore the previous comment & confirm that if use use "Disable RDP Override" option does it impact our services as all these are in production currently. 

[pminarik]

This is a known limitation, caused by the fact that in this situation the Domain controller records logon events for rdp-user@example.com for BOTH the source PC and the RDP destination PC.

The only proper solution is the RDP override settings, supported only by the two event log polling methods - https://community.fortinet.com/t5/FortiGate/Technical-Tip-FSSO-RDP-logon-override/ta-p/197159 - as @FortiArt has already suggested.

If you must use DC Agent specifically (why?), the only solution is this one:

https://community.fortinet.com/t5/FortiGate/Technical-Tip-FSSO-avoiding-overwriting-logons-when-usin...

With the BIG caveat that this will only ever work if you use NTLM to authenticate the RDP connections, which is realisitcally doable only if you connect to the RDP destinations exclusively using their IPs (= never connect to "rdp.server.mydomain.com", always connect to "192.168.123.45").

(This solution works by ignoring NTLM-based logons. Connecting to an RDP destination by its FQDN will trigger Kerberos-based authentication)