Your comments

My issue I created a post for in regards to scripts running out of C:\Windows\Temp is a bit different than this issue.... This is related to the directory where tools are being ran in, I'm discussing scripts that SC attempts to run whether it be server side to generate video recordings from sessions or on a workstation to query data to put into the webui.... I suppose it could tie into this slightly....

Having something in place which would allow us to more easily specify prompt for consent would be nice.

Right now we can do some stuff through our LT integration on a per client basis that forces us to get consent from the customer before we can remote in however if we do it directly through the SC web portal we can pop right in,

Having something in place that more easily allows us to have control over prompt for consent such as settings that allow us to apply the flag based on the organization field on whether for "Workstation" type operating systems prompt for consent but for "Server" Type operating systems we may be able to allow unattended access. Or have it to where regardless of what type of access we want it all requires consent.

Right now regardless of how you do it there isn't really an easy way of having it so it prompts users for consent whether we do it through SC or LT, and to do it in SC from what I gather it would mess up all my session groups to do it....

I'm open to additional feedback but right now we've had clients that absolutely require this for compliance purposes and it is NOT easy at all to set this up without putting something in place that I would consider to be a "Workaround" or "Bandaid"




Additionally, to add on to what I listed above.

Will there be any options or plans in the future to also have an automatic block feature where if someone failed 5 logon attempts consecutively in a 30 minute time period it would deny connections from their IP address? From there you could determine if it will automatically lift the block after X amount of time or be a permanent block.

Side note we'd have to be careful with this because if lets say some internal person fat fingered their pass 5 times and they were at a client location trying to log on, would it deny connections from all clients at that location coming from that IP address?...

Just food for thought.





I like this idea,

Would be nice to have something like this to know if someone is attempting to abuse the service we would be able to take action.

Email notification if there are X amount of failed login attempts over X period of time.