How can I automate this?
Mike Slaunwhite
PROBLEM:
- I have ~20 off-site machines which are not on a Windows domain, but I need to remotely administer them via PDQ.
- The local Administrator account on these machines is disabled. We have a differently named local admin account on these machines. The users of these machines only have basic user access and cannot be trusted with local admin.
- Because of the non-standard local admin account name, PDQ fails to connect and I cannot access the ADMIN$ share unless I add a registry key on each of those machines (see: http://support.adminarsenal.com/entries/20828513-Can-t-access-ADMIN-share-using-a-local-user-account)
- I need to be able to get the ADMIN$ share accessible without having to remote desktop into each of these machines and disrupt business.
HALF-ARSED SOLUTIONS:
These are ideas I've had, but don't work for various reasons (mainly because I'd have to do manual work on each machine)
- Re-enable the local 'Administrator' accounts on the machines. Sucks because we purposely have it disabled for security reasons and I'd have to touch each machine.
- Add the registry key on each machine manually. Sucks, because again I'd have to remote desktop into each one.
- Run the PDQ remote repair utility. I'd love to, but it requires elevated permissions and we don't give the users admin access.
- Self-elevating Powershell/Batch scripts. I looked into these, but none seem to really work without having to enter a admin password on the user end of things.
- Remotely connect using Powershell. The service which powershell needs to connect has a required system service turned off. Users don't have access to run Services.msc to start it.
- Email them a registry file (.reg) to double click and add the needed registy key. Nope, needs admin access via UAC to do it.
Any other ideas? I'm down to researching virus-like things to try and bypass UAC so I can get a simple registry key added.
0
Comments
Hi Mike,
This is a bit of a pickle but still possible. One option would be to use something like psexec which is part of the Sysinternals suite. (https://technet.microsoft.com/en-us/sysinternals/psexec.aspx)
Another option would be to load the remote registry locally, make the changes, and then save it. (https://technet.microsoft.com/en-us/library/cc732388.aspx)
You can also look at using Powershell. Here is a site that can help you avoid some of the pitfalls of running it: (https://blog.netspi.com/15-ways-to-bypass-the-powershell-execution-policy/)
Hi Jason,
Thanks for your ideas, but unfortunately they don't seem possible in my odd pickle of a a situation. Nearly all of them need something enabled on the client before I can connect to the client.
PSEXEC: This is a nice tool, but in my testing I found that the 'LocalAccountTokenFilterPolicy' registry key needs to be enabled on the client to connect. Unfortunately, that is the exact same key which I'm trying to remotely add, so I can't add it, because it's not there. Wow, this is getting pretty meta.
REMOTE REGISTRY: The remote registry service isn't running on the client machines, so I would have to get into each one of them to turn on the service. Unless you know of a way where I can remotely trigger a service to start?
POWERSHELL: I've hit roadblocks because whether the services to execute powershell remotely aren't running on the client machines, or if it did have the users trigger a powershell script for me, they wouldn't have the elevated permissions to make a registry changes with powershell.
So I guess where I am still at, is it possible to enable a system services or add a registry key remotely when LocalAccountTokenFilterPolicy=0?
Only 20? thats not too bad then. Is remote desktop enabled on these computers? You should be able to just remote into them and do what you need.
If not remote desktop, Do you have Dameware? as long as you know a working admin account on the machine you should be able to use dameware to remote into them.
I am able to remote desktop into them, but I'm trying to avoid having to manually touch each machine and disrupt what they're working on by taking over the computer. Unfortunately, if they're not on a domain, this gets trickier.
don't think you have much of a choice on this one.