Agent based FSSO and multiple/concurrent logons into one workstation

[psy]

Can someone please explain or point me to documentation on what happens when a second/concurrent user logs into a workstation?  I'm not very clear on what happens and I haven't been able to find any notes regarding that kind of situation.

Example: AD Domain user01 logs on to a workstation; while working, discovers s/he needs software/plugin installed.  AD admin user logs into the same workstation, while user01 is also logged in, to install that software/plugin. Let's also say that the AD admin user account is not in the Ignore User List...   What security policy would be active at the point the AD admin user concurrently logs in?  Does one supersede the other?  And what happens to user01 security policy when the AD admin user logs off?   thanks in advance

[mhope]

Hi,

I have same problem, AD Domain user1 logs on to a workstation, then he needs to make an RDP connection with another AD user2 that has internet connection denied. 

The workstation lost internet connection since now the agent has user2 authenticated.

Please someone can give us a clue.

[hklb]

Hello,

You can maybe install TSagent (if the computer is used as a a terminal server), or configure NTLM authentification (requiere to configure explicit proxy).

Lucas

[Fishbone_FTNT]

Hi,

logon event is generated too when another user logs in the workstation. This is why current user is overridden.

You have to implement ignore user list in FSSO Collector Agent to ignore logons for such an user.

Ignore list supports wildcards (not regex), so you can fill ignore list with entries like rdp_admin*.

Note that also maintenance scripts running on workstation can do the same; they can generate logon event and override

current user too.

TSAgent is solution for Terminal Server and is not suitable for one-person workstations. When there is user

logged in via RDP, tsagent will allocate special source port-range for him.

Users without port-range from this IP address will be blocked on Fortigate ... which is probably not really desired in this case.

Fishbone

[Nihas]

Basically FSSO is using for identity based network traffic access.

Simply , FSSO agent doesn't do anything on server access level/ or AD user level, which means infront of FSSO agent there is no "enterprise admin"/"administrator"/"schema admin" or "normal domain users" etc. It fetches only the user login details from the AD and send to the Fortigate.

You and Fortigate has to decide how to control the traffic with those logins.

For example -

1.Create a security group in AD  - " Management Users" and add all management users into that security group.

2. Create a security group in AD - " Normal users " and add other normal users into the group.

3. Filter only those groups ( or as ur wish) - in FSSO agent.

4. Create 2 user groups in Fortigate with "MGMT Users" and "Normal Users" and map them with respective ( above mentioned) FSSO groups.

5. Create a policy for Managment users with source identity as " MGMT Users " and destination x.x.x.x - Here you can apply a 'less restricted' Web Filter profile /application control profile etc.

6. Create a policy for Normal users with source identity as " MGMT Users " and destination x.x.x.x - Here you can apply a 'highly restricted' Web Filter profile /application control profile etc.

Best,

Nihas