2

Before you consider what I want to achieve as insane from a security standpoint, please continue reading:

I'm setting the password for the local admin account on all computers in the domain with a startup script which contains the password in cleartext, of course.

I have limited file permissions to the script and only Domain Computers and Domain Admins accounts can access the file.

To keep it short, do you still consider what I want to do as insane or is this OK from a security standpoint?

sincerely, fjf2002

EDIT

My use case is as follows: I just need the local admin accounts in case of a fallback scenario: A computer drops out of the domain or its network adapter goes broken or something like that and then I'd need the local admin account.

In the domain that I'm administering from now on, different computers have different local admin passwords, and the previous administrator (from whom I took over) can't remember the credentials he once set so I thought I had to reset them all.

Humberto Castellon
  • 849
  • 1
  • 7
  • 17
fjf2002
  • 121
  • 1
  • 5
  • @yagmoth555 I am not sure if I understand correctly. Restricted groups seem to change group memberships, how does that help me? – fjf2002 Oct 21 '18 at 15:04
  • My error, sorry – yagmoth555 Oct 21 '18 at 15:20
  • This is a terrible solution. All someone would need to do is run `psexec -s cmd.exe`, get a command prompt as system/the computer account, and they can access the script. It's also a security worst practice to have the same password for the administrator account on all computers because it gives attackers lateral movement on a silver platter. – Greg Askew Oct 21 '18 at 16:45
  • @Greg Askew: Thank you, this is the first answer that targets my question. First, as far as I know you can only ``psexec -s`` if you have admin rights; but if you have admin rights, you can reset my local admin account password directly. Nothing won. Second, if I choose the local admin account password the same on all machines, this is as far as I understand just as (in-)secure (as you would call it) as a domain admin user - he also has "the same password" on all machines. – fjf2002 Oct 21 '18 at 17:31
  • Wrong, although your flawed assessment does explain how this poor idea originated. There isn't a single security expert in the world that would approve of what you are doing. Actually they would be horrified. If you're going to do something like this, there should at least be a compensating control like using AutoIT to create an obfuscated native executable. – Greg Askew Oct 21 '18 at 17:53
  • @Greg: Thank you for your elaborate answer. Could you point out which of my assumptions you consider as wrong? Thank you. – fjf2002 Oct 21 '18 at 18:57
  • @HarryJohnston setting local admin passwords via GPO was disabled by Microsoft years ago because of how insecure it is to do this. – RobbieCrash Oct 22 '18 at 00:27
  • 1
    @fjf2002 your assumption about how ADDS works relative to using the same password across all machines is wrong. A domain admin password needs to be authenticated against a DC before being allowed to work, which means all you need to do is tell your DC to invalidate that password/account. There is no such protection in your case. The psexec issue isn't about if someone can reset the admin password, it's that they can *discover* the admin password. As soon as I have your startup script, I have control over every machine you've pushed this out to. Don't do this. – RobbieCrash Oct 22 '18 at 00:31
  • @RobbieCrash, reference please. As far as I'm aware that functionality is still in place. – Harry Johnston Oct 22 '18 at 03:19
  • @HarryJohnston https://support.microsoft.com/en-us/help/2962486/ms14-025-vulnerability-in-group-policy-preferences-could-allow-elevati If you have applied the update, I believe that any GPOs which previously had the password set strip it out of them. – RobbieCrash Oct 22 '18 at 03:33
  • Such a script should be using a hashed password not a cleartext one. – kasperd Oct 22 '18 at 04:44
  • I don't think passwords are stripped out of existing policies after applying MS14-025. You just can't edit them or add new ones with GPMC anymore on the machine with the update. The client side GP engine will happily continue processing them if they're set though. (Technically, I only know this to be true for service credentials, but I presume it applies the same to all of them) – Ryan Bolger Oct 22 '18 at 04:47
  • @kasperd : How should a hashed password work - cleartext is needed to set the password on the client, isn't it? – fjf2002 Oct 23 '18 at 17:32
  • @RobbieCrash: Ok I understand better now. But in my setting as a non-admin you can't get access to my startup script in the first place? – fjf2002 Oct 23 '18 at 17:34
  • @fjf2002 The script needs to contain the hashed password in the exact format it will ultimately be stored in the password database. And you need to use the correct call to set a hashed password rather than a cleartext password. The password you have previously had in the script in cleartext should be considered compromised, and the new password need to be chosen such that it has no resemblance to the compromised password. – kasperd Oct 23 '18 at 17:45
  • @RobbieCrash, you're quite right about the policy being deprecated, and thank you for the link. I've done some experimentation and can confirm that the password fields are grayed out when creating or editing the policy, but that any existing GPOs with this setting continue to work and can also be successfully backed up and restored. The patch really was just a change to the GUI, you'd have thought Windows 10 clients at least would ignore the setting. Oh well. – Harry Johnston Oct 23 '18 at 23:23
  • @fjf2002 with default permissions, it is ~trivial to find the GUID for the GPO, and from there browse to \\domain\sysvol\domain\policies\GUID\Machine\Scripts\Startup with an unprivileged user, who can then read your text file, get the local admin password, compromise every system that policy has been applied to. Just don't put a password in a file. Please. Either manually apply a strong password to the local admin account (bad because you'll use the same password) or use LAPS and deal with the additional complexity and difficulty in management (good). – RobbieCrash Oct 24 '18 at 20:50
  • @RobbieCrash: "Just don't put a password in a file. Please." -> I fully agree. - " apply a strong password to the local admin account" -> I fully agree. - "with an unprivileged user, who can then read your text file" -> I assume you are wrong. Read my question, please. Only Domain Computers and Admins have access to the text file. – fjf2002 Oct 25 '18 at 14:00

1 Answers1

3

Your situation is the perfect use-case for LAPS (Local Administrator Password Solution).

It's a free tool from Microsoft to automatically manage the local admin passwords on domain joined Windows machines and keep them stored in AD that you can look up whenever you need them. There are a number of guides out there for setting it up. But if I recall correctly, it mostly consists of getting the agent deployed (doable via GPO software deployment) and configuring a couple group policy settings that tell the agent how often to rotate the password.

Ryan Bolger
  • 16,472
  • 3
  • 40
  • 59
  • I know, I have read about LAPS. But I wanted a simple solution and just one password. – fjf2002 Oct 21 '18 at 15:30
  • One common admin password across all machines is largely considered a security bad practice these days. As Greg pointed out in the comments, it basically gives an attacker free reign to move from machine to machine through your network once they can compromise a single machine. – Ryan Bolger Oct 21 '18 at 21:40