Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
dirome
New Contributor II

FSSO Monitor - IUSR_TASK

Hi, I am seeing monitor on users and devices, and I choose the "show all fsso logons" and the list shows in name user "IUSR_TASK", what is the meaning this name?

7 REPLIES 7
Fishbone_FTNT

Hi Dirome,

I am not aware of any "IUSR_TASK" meaning there. Could you post a screenshot so me and maybe others looking here know what you do exactly mean?

Also, you can cross-check what you see in GUI "Show all fsso logons" in CLI by executing command

diagnose debug auth fsso list

If you see this user in the list too, information came already from FSSO Collector Agent, and you have to check there too.

 

Fishbone )(

smithproxy hacker - www.smithproxy.org

dirome
New Contributor II

Hi Fishbone_FTNT,

 

attached image, I'm just waiting for your help

 

boneyard
Valued Contributor

that points it to be a user in your environment, might be some service account or such. have you checked your AD user list to see if it is there?

Fishbone_FTNT

Hi Dirome,

Boneyard is correct, this is your AD user. You don't see any groups for it, since some of his AD groups is present in group-filter, but is at the same time not associated to any Fortigate group.

 

 Fishbone )(

 

smithproxy hacker - www.smithproxy.org

dirome
New Contributor II

Hi boneyard / Fishbone,

 

I checked with admin of AD and this is a user of service.

 

Thanks to all

Fishbone_FTNT

Hi Dirome,

great you figured out! I am pretty sure you know what we usually do with such users, so just for completeness for other readers: typically you will want to add this user to "ignore list" in FSSO Collector Agent.

 

Why? Because service which runs as different user can trigger logon event. This event could be detected by FSSO  Collector Agent polling thread, which will replace current user logon entry in its FSSO logon list. This is very common mistake in many FSSO setups.

 

In recent FSSO CA versions you can also use in "ignore list" wildcard matching with '*' and '?', which makes list very maintainable. For example, you can keep some naming convention for service users, say,  "*_TASK" and use this pattern in "ignore list" too.

 

To illustrate problem in more detail, here goes some (rather longer) example:

[ol]
  • User DOM\john1 is logged in WKS1, FSSO CA is aware of it and has corresponding logon entry. He is member INTERNET_OK group.
  • Administrator installs maintenance script to all workstations, effectively running as DOM\BACKUP_TASK, member of domain admins to backup some data from workstation harddrives somewhere. This user is member also of INTERNET_DENIED group.
  • John1 is normally working on WKS1 and surfing happily internet.
  • At some time, backup script is executed on WKS1, triggering logon event of DOM\BACKUP_TASK
  • FSSO detects logon event from 4/ => replaces logon entry for WKS1, now FSSO CA thinks there is user DOM\BACKUP_TASK on WKS1 => all Fortigates are notified
  • Since DOM\BACKUP_TASK is in INTERNET_DENIED group, John's internet access is denied now on.
  • Backup task is finished. However there is no real logoff event in AD, so FSSO CA still thinks there is BACKUP_TASK user logged in WKS1
  • FSSO CA is performing each few minutes so called workstation checks, to detect if the user is still present on workstation. Now FSSO CA tries to connect to WKS1 in order to do such an check. a) FSSO CA is connected successfully, and is now realizing there is no longer BACKUP_TASK user logged in => FSSO logon entry for WKS1 is removed from FSSO list! Now there is no logon entry for WKS1, neither with incorrect user BACKUP_TASK, nor correct entry for JOHN1. b) If FSSO CA fails to connect to WKS1, logon entry will transit to 'Not Verified' state, but this entry is also incorrect, since FSSO CA still believes that there is BACKUP_TASK user, so John cannot access internet. Logon entries with this status will be automatically removed after "Dead entry timeout" elapses.
  • Situation is indeed "resolved" by logon event triggered by John, for example if he logs out and back in, if he access some network shares, etc.
  • Result is very frustrating for normal users, while root cause is pretty simple: one overlooked service account. It will make FSSO setup to appear randomly not working. But is just misconfigured. [/ol]

     

    So please don't underestimate service accounts, pay very close attention to them, especially how they are used on workstations.

     

    My 2c,

    Fishbone )(

     

     

     

  • smithproxy hacker - www.smithproxy.org

    dirome
    New Contributor II

    Hi Fishbone, I'm sorry I was very busy with other topics, but your last answer complement better the last information. Very thanks. dirome

     

     

    Labels
    Top Kudoed Authors