Issues automating Least Privelege at scale

I tried the script and had similar problems. When I opened a support ticket it was mentioned they have observed that the script "Windows_NonAdmin_Config.ps1" released in earlier collector versions will not give the necessary permissions. Said this is fixed and will be released in collector version GD 36.001 and later collectors. I'm not keen on using a GPO to target the servers. I would like to see a LM solution using a button in the portal that will manage the process and update the permissions for us.

It looks like they are changing positions on this requirement.  Still probably a good thing to do but at least it's not going to be forced.

Important Security Announcement | LogicMonitor - 15844

I have not used that script (I'm not currently involved with the non-admin project) but what else is better to do then look over a PowerShell script on a Friday night...

Oddly the line that is failing for you, 728, is line 711 for me, but it looks to be part of the ChangeSecurityDescriptor function. It looks like that line is attempting to look up the user on the system and get it's SID using the NTAccount.Translate(Type) function. I was able to replicate your issue when passing in a local user on a domain-joined system. Try changing this code two lines above the failure, from:

$objuser = New-Object System.Security.Principal.NTAccount($ComputerName, $UserName)

to: 

$objuser = New-Object System.Security.Principal.NTAccount($UserName)

NOTE! I only did a quick test of just the failing section of that script by having it skip straight to this function. The script is pretty complex and half of it is C# embedded code with DLL imports so no idea if it's doing something weird and that change causes you to be deleted from the universe. Also since your failing line number is different than mine, it might be a different version of the script. I looked at the script from a freshly installed v36.200 collector.

I tried the script a while ago when it first came out.  I ran into problems as well.  I opened a support ticket and they seemed very confused about what I was trying to do.  I tried to explain that I was following their instructions using their provided script, but I didn't get anywhere.

I decided to just worry about it later.  ;)

Got it to run without alteration.  Have to figure out how to do so without human intervention to make this a usable script in our environment (100+ domains = 100+ accounts).

Based on Mike_Moniz 's findings, I made sure to use the account explicitly as entered in the "Logon as" section of the service.  I'd been assuming that the script would use the collector's host's domain for the account, so had just entered the username (as the flag implies)... but it wanted the domain stated explicitly.  domain\username format.  I was running in powershell under the account being changed to make sure the collector would be able to make the necessary changes from "within the house."  I'll most likely be stealing the script out of the agent/bin folder and altering it to run using tokens for user and pass from a propertySource script.  Have it run once a day, add a test for domain admin membership and run the LM LP change code against it if it is still a domain admin.  Skip it all if it is not... then add a property at the end indicating whether or not the account has DA in each client domain.