Must defeat security to use in workgroup?
After much research looking for the best automation tools, it became clear and I was delighted to run across your products. We are relatively small in size so I have our group of companies setup with a few workgroups. My enthusiasm waned greatly as I began evaluating and discovered what was required in order to use these products in a workgroup scenario.
In fairness, I have seen that disabling Remote UAC is not something unique to your product, even other large competitors (SolarWinds) require this also. How is everyone okay with this? Microsoft is quite clear this "is not a good idea" security wise.
I have used Symantec Endpoint Protection for a decade in this same workgroup enviroment and am able to push out installs from the management console without having to disable Remote UAC, so I know that it is certainly possible to achieve this functionality WITHOUT putting stations at risk of loopback attacks.
What am I missing here? Why should I not be concerned about the security implications of this? I really would like to purchase your products but I would need some mighty reassurance about why this is okay.
Comments
The differecne is that with Symantec you have a running service with higher privileges where as the PDQ deployment service has to be started remotely first.PDQ does not work the way Symanec does (yet). Thus it requires an administrative account torun. This is not a problem in a domain, just in the workgroup. It would be a piece of work to get say 50 installations of a PDQ installation service ready to work.
BTW, in my experience in most cases are the users members of the administrators group and thus causing the malware havoc. I do prefer to educate the people, so they dont mess up.
Thanks for the timely reply. I luckily won the limited user battle at the beginning of my tenure here. I got the owner and upper management on board and immediately limited everyone's accounts (including theirs). Things have been pretty much smooth sailing since as far as malware issues go.
That is why I'm reluctant to dumb down security in order to implement your products without fully understanding the additional risks I'm taking on by doing so. I can't seem to find much information on "loopback attacks" or advice on mitigating them in this scenario. All my googling seems to provide is people echoing Microsoft's stance to not do it.
I guess I'm looking for something that doesn't exist... convenience AND security. I don't really like to talk about what security systems I have in place, but I do have multiple layers throughout our footprint, so that is why I'm wondering if perhaps I'm being too paranoid about relaxing this setting.
A way around this is to set up the a new shared directory on all the targets and then modify the Target Service setting under Preferences. The limitation is that the path and sharename must be identical across all of your devices. Example: You create a directory on each computer (C:\Deploy) and share that directory to Administrators.
Doing it this way does require quite a commitment since custom directories and shares would have to be created.
Remote UAC is, as I understand it, an issue when trying to access the C$ and Admin$ shares using local accounts.
Wow, that's awesome information Shane, thanks for that! So this would give me full functionality of the program?
Hi Allan,
It should work, yes. I haven't tested it with Remote UAC enabled but we added this feature (Target Service) for customers who had security policies that restricted the use of ADMIN$.
Shane, thanks again. I see the help files now for Target Service. I will give that a go. Consider this solved.