FSSO Agent and multiple user logins

[GCC_J]

We have an issue with FSSO-based web filtering that I so far have been unable to solve:

We have the FSSO DC agents installed on all DCs.  We have 4 AD groups set up, and we're using a guest profile set to Deny everything.  Everything is working great, pulling in user logins, blocking sites, etc...  Except for one thing.  We have some users in our organization that either (1) Login from a PC with more than one username at a time, or (2) Admins will connect to other machines, either through CIFS/SMB shares or RDP using their 'Admin' accounts (our admins use a standard user account for day-to-day work activities).  The issue is that when someone does this, the FSSO agent drops their normal user account from the list and adds the second account.  Then when the second account logs off, it doesn't add the original account back, which means the first user account is now using the 'Guest' web filtering profile and they get blocked from all web sites.  To get back on the "Logged on users" list, they have to basically lock their computer, then unlock it, which re-authenticates to Active Directory and the FSSO agent logs it and adds the account back to the list.

This is a major annoyance.  This even impacts certain users who keep remote drives mapped using different credentials.  Is there any way around this?  It is making us re-think our entire setup.

[ZeroInterrupt]

are these windows 10 machines?  Are the users that are logging in with multiple usernames completely logging out and then logging in or are they using 'switch account'?  As far as the admins logging in via RDP, I Have the same issue with servers from time to time, and the fix I have found is when the admin is done with the session completely log out so the user has to relog.

[emnoc]

I had the same issues and never go this resolved hows your diagnose  output for FSSO

          diag debug authd fsso server-status         diag debug auth fsso list

        diag debug enable         

Do that and monitor the output.

Ken

[GCC_J]

We have (2) admins, one is on a Win 7 workstation, and the other is on a Win 10 workstation.  Same problems for each.  Our IS Policy requires admins to use a standard user account for day-to-day activities, only using their privileged account when needed.  That means working on their station using an unprivileged account and RDP'ing to PCs and servers for administrative purposes over the course of the day using their privileged account.  When they do this, the DC Agent reads the RDP login as coming from their workstation (even though they are logging into a server via RDP), and drops their standard account from the Logged On Users list.  This also happens when mapping remote drives using admin credentials when logged in to the station with their standard account.

The FSSO DC agent is working "correctly", meaning that the AD logons are successfully being read.  I've monitored the debug log for the DC agent, and that's how I figured out why the Admins are constantly complaining that Web Filtering "wasn't allowing us to browse websites that should be allowed after we're logged in for a little while" (The DC agent is reading from AD that another user is logging on from the same IP address, even though it is a remote connection it doesn't seem to matter).  When they use any other credentials to connect to any network resource, the DC agent sees them 'logging on' to that device from their own workstation's IP address with another user account.  The DC agent then drops their actual user session off the logged on users list, which pushes them to the Guest profile, which is set to deny everything.  The only way to get the user name back on the "Logged on users" list in the DC agent is to either log completely off and back on to their workstation (which is not feasible 100 times per day), or the method that we've started using which is to just Lock the workstation and then unlock it (which causes a re-authentication to AD).

"Switch user" is not affected by this issue because every time you switch users you re-authenticate to AD and the login is "noticed again" by the FSSO DC agent.

I really can't believe this is not more of an issue for people.  It's driving us crazy and seriously making us rethink the entire setup.

[ZeroInterrupt]

gccjanderson wrote:

We have (2) admins, one is on a Win 7 workstation, and the other is on a Win 10 workstation.  Same problems for each.

The FSSO DC agent is working "correctly", meaning that the AD logons are successfully being read.  I've monitored the debug log for the DC agent, and that's how I figured out why the Admins were constantly complaining that Web Filtering "wasn't allowing them to browse websites that should be allowed" (The DC agent is reading from AD that another user is logging on from the same IP address, even though it is a remote connection it doesn't seem to matter).  When they use any other credentials to connect to any network resource, the DC agent sees them 'logging on' to that device from their own workstation's IP address with another user account.  The DC agent then drops their actual user session off the logged on users list, which pushes them to the Guest profile, which is set to deny everything.  The only way to get the user name back on the "Logged on users" list in the DC agent is to either log completely off and back on to their workstation (which is not feasible 100 times per day), or the method that we've started using which is to just Lock the workstation and then unlock it (which causes a re-authentication to AD).

"Switch user" is not affected by this issue because every time you switch users you re-authenticate to AD and the login is "noticed again" by the FSSO DC agent.

I really can't believe this is not more of an issue for people.  It's driving us crazy and seriously making us rethink the entire setup.  Please someone tell me I'm an idiot and that I'm just overlooking something simple!

Here is a test, i am seeing this at another site and it is the multiple users being logged into a machine via the switch user.  Have a user log into the machine, run the commands above mentioned by 'Emnoc', make note of IP, username and groups.  Lock the machine and login with the admin account mentioned above. Run 'diag debug auth fsso list' and find the ip and username.  At this point it should be the last account logged in, log out of the machine and select the account that originally locked the computer.  Again, Run 'diag debug auth fsso list' and find the ip and username.  Did it stay with the admin account, did it disappear from the list (a 'guest' user)?  Please post what you find.  Locking and unlocking does not necessarily trigger AD authentication the machine could be using cached credentials. 

I've never seen this type of behavior when connecting to a drive on a remote machine internally (ex. via the hidden share) and being forced to elevate privileges (logging in as my domain admin). 

There used to be a major issue when using Citrix/RDS and publishing a web browser that produced similar issues to what you are explaining, but they have since fixed with a different server agent (tsagent).  

[GCC_J]

Unfortunately for this setup I do not have access to the actual fortigate web interface or the CLI.  It's a hosted network-based solution in our ISP's datacenter.  All I have access to monitor is the DC Agent logs, which honestly is enough to tell me what's going on as far as user logons and IP addresses.

We used to manage web filtering ourselves with our 100D, but we never used the Guest profile as a catch-all to block internet access for "unauthenticated users" until now.

"I've never seen this type of behavior when connecting to a drive on a remote machine internally (ex. via the hidden share) and being forced to elevate privileges (logging in as my domain admin)."  We are experiencing this with mapped drives, and removing all mapped drives using admin credentials "resolved" the issue.  But we do not want this to be the permanent solution.

[emnoc]

open a  case with support and see what they say.

Ken

[AtiT]

Hello,

for RDP logins you can disable the RDP override function in FSSO Collector Agent settings:

Show Monitored DCs - > Select DC to monitor - > Check "Disable RDP override"

For special accounts and service accounts you can ignore their logon sessions in FSSO Collector Agent settings: Set Ignore User List - > Add Users - > (select users) - > Add

[GCC_J]

Thanks for the advice.  I will give the Disable RDP Override function a try tonight.

As for using the ignore list, am I correct in saying that any accounts on the ignore list would by default be assigned to the guest profile, and therefore be denied internet access?

[jpcastilloux]

Have you found a resolution to this problem, im in the exactly same situation than you