Change the local administrator password
Two procedures are included, they both reset the local "administrator" account's password. One to a random value using www.dinopass.com strong password option, and the other one using a static value that needs to be modified in the procedure on line 2 instead of "Passwordtochange7"
Both procedures will write the new password in the Agent Procedure Log, as well as upload a file in the GetFile folder on that endpoint with the new admin password (the file is called adminpwd.txt)
When running the non random procedure, ensure the password meets all complexity requirements as set for that endpoint.
Works as intended. I also added a line to the procedure to set the password to never expire: wmic useraccount WHERE "Name='administrator'" set PasswordExpires=false The above command needed a few extra seconds to run, so I had to add a pause in the agent procedure to let it catch up.
Great to automate the change to reduce the lateral spread. I'll give it 5 stars when it can know not to run on Domain Controllers.
This is a great tool, but I would not write the TXT file back to KWORKING.
Shadow Copy could be used to recover, possible Recycle Bin.
FYI if there is a > or < in the password the result is not stored in the TXT file of Log, because it is interpreted as a pipe command. My very first random password contained a >
Also the passwords are not truely random, they use a log of formulaic character replacement.
I made a Custom filed to store that in.
I'd want a way so the procedure does NOT run on Domain Controllers. Being I don't want AD admin account changed.
How to we know this URL is not recording the passwords generated and the IP from which the request came from
FYI this does not work on Server 2008, but kind of moot since theya re going away this year.
I tried replacing the Invoke-restmethod -uri "http://www.dinopass.com/password/Strong" powershell statement with [System.Web.Security.Membership]::GeneratePassword(15,10) to use Powershell's native ability to generate passwords instead of dinopass. I prefer this because I don't need to allow dinopass thru our AV/FW tools and I can generate a much more secure password with PS.
I can run that exact statement from my own powershell instance, but when running thru the agent procedure on the same machine (mine), the command errors with "Unable to find type [System.Web.Security.Membership]."
Anyone have any ideas here?
I believe that you will need to import the assembly with this command
Add-Type -AssemblyName System.Web
This will make the System.Web functions available for later use.
(I am no Powershell expert, but have had to use this Add-Type" before to use some other powershell features.)
Would you be able to explain how to make that work inside of the procedure window. I was able to run that statement as well inside of powershell ISE, but not sure how to add it in the procedure. Thanks Ben
I've successfully used the above powershell statement in an agent procedure. What's needed is to first run the "Add-type" followed by [System.Web] but they need to be run on a single Powershell line (seperated by a semicolon). This is what works:
Add-Type -AssemblyName System.Web; [System.Web.Security.Membership]::GeneratePassword(16,1)
The last parameters are the number of characters in the generated password (16 in my example) and the minimum number of non-alphanumeric characters in the password (1).
I run the above powershell command to return the result to variable #global:psresult# and then use the variable in the same way as the original dinopass agent procedure. One change is that in addition to writing the new password in the Agent Procedure Log and uploading a file in the GetFile folder on that endpoint with the new admin password, I also use updateSystemInfo statement to write the new password to a custom field "Admin Password".