Neophyte
ProfessorWe have solved it for the most part / are in the process of packaging the solution we came up with. I'm verifying with my management that I can share to the community more fully, but we start with a basic user with a long/strong password (40+ random gen characters)... this is either a domain user or a local user depending on whether or not it's a WORKGROUP machine.
The deployment script runs on our RMM/Automation platform with a few assumptions about the service account being utilized... specifically, the local vs. domain context (currently working on the environments where we use a trusted domain rather than either a direct local or domain joined).
Once done, CSV import of devices and properties set for wmi.user and wmi.pass (plus a handful of metatagging done using properties and inherited properties to populate them into the rest of our toolset (Ticketing / Automation / Messaging Platforms / etc.).
Here are the general steps our automated permissions deployment takes:
There are still a few hiccups and the script's sections are broken out into individual pieces as well as the main intial push to sweep up future issues (i.e. service for an application gets uninstalled / reinstalled, so needs SDDL pushed against it again). We've run into surprisingly few stumbling blocks since the big initial push for the development of the deployment script/s.
*** In terms of managing the scale, we're an MSP with an initial monitoring lift of 50+ company's servers. None can use the same domain, collector, or service accounts. Our automation tool is the key here. Once a device has been deployed, we can create preening scripts as well that will let us keep everything working nicely and double-check the permissions haven't expanded past what we need/allow for monitoring.
Big thanks to Barb​ for early on help with this.
