Others Having Challenges with Least Privilege (POLP)?

Question

Hi all. Just wanted to reach out to the community to see if others are running into the same challenges deploying the LM least-privilege service accounts as we are.This is what we've identified so far:LM can't retrieve metrics for disks where NTFS permissions don't include read access for the service account.&nbsp;I've scripted a PowerShell permissions check for disks in our environment, but I feel like this isn't a scalable solution.LM can't retrieve metrics for HyperV clusters. The workaround would be similar to the above.There doesn't appear to be a scalable way to confirm monitoring works across all instances/datasources after migration. I've written a script that retrieves all monitoring data for all resources from the LM API, puts it into a SQLite database, for later before/after comparison.The onboarding/migration script only sets SDDL permissions on currently installed services.&nbsp;If a service is newly-installed, or updated, LM can no longer monitor the service. I was considering scheduling the script to run on a regular basis, but read in this forum that it can exceed the max security descriptor length because it writes duplicate permissions.I've reach out to support on all of these issues and been told everything is 'working as expected', and that their devs 'can't anticipate every scenario'. Which is true! But none of what I described is due to an exotic configuration or niche software. Given that switching to a least-privilege model was portrayed as a 'mandate' a few months ago, I feel like remarkably little thought has gone into how this would impact customer environments, but I digress.Has anyone encountered similar issues? What's the consensus on whether the LM least-privilege model actually makes sense in the real world?

andy_c · Answer

oppps, just reread and saw your comments on SDDL, indeed it does need to be run on a schedule. Yeah I walked away from that. Like I'm going to run a set of re-permissioning scripts every couple of hours. The consequences of getting that script wrong and stuffing up all the permissions on all the servers were way too high.&nbsp;

andy_c · Answer

I strongly suspect you cant't see all the services running, you'll see some but not all, and you may also have difficulty seeing certificates.

mww · Answer

I think that's the conclusion I'm arriving at as well. I'm all about reducing the number of domain admins in our environment, but LogicMonitor's mandate/guidance on the topic seems half baked at best.

andy_c · Answer

It's not really an LM issue, any remote connection system is going to have problems either WMI permission , WINRM connections just a whole bunch of stuff. This is from a similar type of product and its just a really exploded view of the whole permissions thing and trying to run powershell remotely.https://docs.sciencelogic.com/latest/Content/Web_Vendor_Specific_Monitoring/Windows_PowerShell/chapter_03_config_PowerShell.htmEasy way around all of this is, for regular Non DC and Workgroup machines, create a regular local account , lock that down, in AD deny RDP and local logon etc.&nbsp; Drop that account into the Admins group on the local servers. Use that account as wmi.user and wmi.pass. For all the DC's and workgroup machines, install a collector. Nano does work fine although its not officially supported in this configuration. Collector runs as 'local system' against itself only and has enough permissions . No Domain admin account required.Some of our customers have 20 collectors each. Half a dozen on DC's a "main collector" for everthing else and all the workgroup standalones get a nano.Its so much easier than dicking around with firewalls , WinRM certs , SDDL's and all that.&nbsp;

mww · Answer

Thanks, this is a really interesting approach! At this point I'm torn between pursuing least privilege further, or just using a credential management system to auto-rotate the password on our collectors. What you just outlined does sound like a feasible approach.