Forum Discussion

MWW's avatar
MWW
Icon for Neophyte rankNeophyte
2 months ago

Others Having Challenges with Least Privilege (POLP)?

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:

  1. LM can't retrieve metrics for disks where NTFS permissions don't include read access for the service account. I've scripted a PowerShell permissions check for disks in our environment, but I feel like this isn't a scalable solution.
  2. LM can't retrieve metrics for HyperV clusters. The workaround would be similar to the above.
  3. 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.
  4. The onboarding/migration script only sets SDDL permissions on currently installed services. 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?

6 Replies

Sort By
  • Andy_C's avatar
    Andy_C
    Icon for Neophyte rankNeophyte
    2 months ago

    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.

  • Andy_C's avatar
    Andy_C
    Icon for Neophyte rankNeophyte
    2 months ago

    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. 

    • MWW's avatar
      MWW
      Icon for Neophyte rankNeophyte
      30 days ago

      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's avatar
        Andy_C
        Icon for Neophyte rankNeophyte
        30 days ago

        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.htm

        Easy 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.  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.

         

  • Cole_McDonald's avatar
    Cole_McDonald
    Icon for Professor rankProfessor
    7 days ago

    We 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.