Forum Discussion

Cole_McDonald's avatar
Cole_McDonald
Icon for Professor rankProfessor
5 days ago

Issues automating Least Privelege at scale

I'm working through how to implement the least privelege "Windows_NonAdmin_Config" script in 100+ environments.  In at least two, the LM service account we have is the only one with enough admin credentials to change the account to non-admin.  I'm testing in our own internal systems to make sure I can get it to work.

In my first go of it as both the LM Service account and using my own Admin creds in our environment, I'm getting errors:

Has anyone else seen this?  I'm going to keep chipping away at it as I'd like to come up with a purely LM solution to the shift due to the scale of the effort in our MSP environment.  We do have ConnectWise Automate to utilize if I can't get this working, but right now, I can't even get it going using the instructions provided directly on the VM (in a console window using 'enter-pssession 127.0.0.1 -credential (get-credential)' to get a session with admin priveleges.

least privelege
powershell
service account
  • Cole_McDonald's avatar
    Cole_McDonald
    Icon for Professor rankProfessor
    2 days ago

    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.

    • thedietz's avatar
      thedietz
      Icon for Neophyte rankNeophyte
      2 days ago

      Just a note because you mentioned using tokens for user and pass.   What I found is I do not think the Password of the account is needed unless you are running the script against the collector.  Password would be required to configure the service to log on as.

      I updated the script so when I run it against Windows Servers that I am monitoring.  For that I see no reason a password is needed for the account.   I added a parameter called "isCollector" with a validate set "Yes", "No" to the script.  Then a simple if statement (after adding parmeter it's now line 886) to the section commented ## FUNCTION FOR PART 4 ## PARENT FUNCTION.

      So that would be line 887-956...and it only runs that code (the part that requires a password) if it is a collector.  So If ($isCollector -eq "Yes").

      let me know if you have questions or this doesn't make sense

  • Allied's avatar
    Allied
    Icon for Neophyte rankNeophyte
    3 days ago

    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.

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

      I absolutely agree with this sentiment... just a pull down "convert to non-admin service account" in the collector management window would be ideal.

  • Kelemvor's avatar
    Kelemvor
    Icon for Expert rankExpert
    4 days ago

    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.  ;)

  • Mike_Moniz's avatar
    Mike_Moniz
    Icon for Professor rankProfessor
    5 days ago

    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.