It is possible to do what you’re describing, as long as you are okay with the security implications of distributing a csv with a bunch of passwords to 200 servers.
Say you had a simple “password.csv” containing the following:
server1,p@ssw0rd
server2,P@SSW0RD
Using that, you could match the computer to the line in the CSV and create a parameter in your action script containing just the password, like so:
parameter "password" = {following text of first "," of line whose (it starts with (computer name as lowercase)) of file "password.csv")
From there, you could just deploy the task to every server you care about, using our “password” parameter as the argument to net user
Oh yeah, for sure. Didn’t say it was a good idea, just that it was possible. There are definitely ways to harden this approach, so if it is important enough to OP to do this, hopefully my answer is a push in the right direction.
At my last job, we weren’t really able to deploy LAPS, so I wrote what we called FLAPS (Faux LAPS). It was a per-department policy action that set the admin password on a given computer to a string chosen by the person in that department, the computer’s serial number as lowercase, and a second chosen string. There was an accompanying analysis that would check how recently the password on that account was changed by FLAPS.
Desktop techs didn’t like it because it’s sometimes inconvenient to get a computer’s serial number (like if you’re sitting in front of it), but it otherwise was a good solution for us to make sure we had unique but still usable in a pinch passwords on every machine.
Secure parameters and OpenSSL encrypted passwords two of the common approaches.
We take it a step further in our organization and use relevance substitution to do static + dynamic password combinations based on a formula for additional strength. These combination passwords are now standard practice for our domain and local administrative and service accounts.
