Skip to main content
GCC_J
New Member
May 2, 2018
Question

FSSO Agent and multiple user logins

  • May 2, 2018
  • 3 replies
  • 33100 views

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.

    3 replies

    ZeroInterrupt
    New Member
    May 3, 2018

    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
    New Member
    May 3, 2018

     

    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
    GCC_JAuthor
    New Member
    May 3, 2018

    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.

    yorvek
    New Member
    January 13, 2025

    Did you receive a solution from support regarding this issue? While disabling the RDP override from the collector agent resolves the problem for RDP, it does not address the issue that occurs when running an application as an administrator on a client PC. In such cases, the user will eventually lose internet access and will need to lock and log back into their computer to restore connectivity.

    jpcastilloux
    New Member
    January 13, 2025

    Yes, the only way to resolve this is to have a standardised Server / Admin accounts nomenclature that you will be able to ignore in the FSSO configuration.

    so let's say, if your admin accounts nomenclature begins by admin-xxxxx , you could ignore in the FSSO the accounts login beginning by admin-* . 

    You can also use the '' ? '' to wildcard a specific character position too instead of the Wildcard ''*'' that implicit the rest of the word.

    Works like a charm but you need to implemant a standardised nomenclature to achieve it.

    jandrewartha
    New Member
    April 15, 2025

    My problem is I want to identify our admin accounts (which are d- for domain, s- for server, w- for workstation admins) on servers, but not on workstations. Ignoring them will ignore them everywhere which is not what I want.

    jpcastilloux
    New Member
    April 15, 2025

    You could create a separate VDOM for your Workstation and in this VDOM you could point to a different FSSO server that has a different ignore list because each VDOM has the possibility to configure different FSSO servers.