Join the Community! Creating your account only takes a few minutes.

I want to get some opinions on this topic, because right now I believe this to be a big security hole that we are about to implement. With out going into too much detail here it is.

++++Explanation++++++

We have implement a power user program within each of our departments to do this we are adding a few users as local administrators to all workstations within each department. The plan that our AD team has come up with is creating a security group with the power users and each computer account as members for said department.

+++Question++++

I asked them why do we need to add the computer accounts to the local admin group? I believe this to be a security hole cause now anyone with physical access to the computer and run programs as the computer account and gain access to any other computer within the department.

Basically what I am asking is why issues/problems can we run into by adding all departments computer accounts to each computer? Is this a security hole or am I just crazy. Thanks for the input!

+++Side Note+++

Our AD team will not use a GPO to apply these admin groups either. They are making me use SCCM to run a script on each computer to add these groups to the local admin group. Does that make any sense?

6 Replies

Computer accounts are already authenticated, why add more complexity to what they are going to screw up anyway. What is it exactly that these power users need to do locally as a local computer account?

The point of this power user program is to allow certain users rights to install needed software, updated software, install local printers, basic troubleshooting, etc.... The decision came down to just giving these users full admin on their department's computers.

I think maybe you (and your AD team) have misunderstood what the computer account is. When a user logs on and runs a program it is running as that user account right? Well when a windows service that is set to run as the Local System account (or Network Service account) runs, that process is running as the computer account whenever it tries to access anything on the network. For a user to be able to run a process as Local System they need local admin permissions anyway, so if you're making all these users local admins then they've got permission to do this but unless you've actually granted the computer accounts permissions somewhere (like in a file/folder permissions ACL) then you're not granting them any permission that they didn't already have.

Adding the computer accounts to the group isn't going to make any difference to anything, because if all the users in this group are local admins on all of the computers then they already have local admin access to the other computers in the group just by using their own logon credentials - they don't need to run a process as Local System (i.e. as the computer account) to get that.

In short I see no reason to add the computer accounts to the group, but it won't cause any issues either. It sounds like it would make more sense to have a separate group containing the computer accounts and then limit your script (or GPO if you did end up doing it that way) to apply to only members of that group that has the computers in. You could do the same with this group you already have that has both users and computers in, but its just a bit neater and less confusing having the two separated if you ask me.

PS I would say doing it via GPO is better than a script pushed out through SCCM personally, because then you have clear visibility at any time of which PCs it is affecting by just looking at which PCs are in this group and in the OU that the GPO applies to. With SCCM once the advertised script has been run, you don't have any easy way to quickly see which PCs it is applied to unless you leave them all in a collection but then you're counting on the fact that no one has removed any of the PCs from the collection. Also a GPO will apply it each time the computer boots up, where as the SCCM script will just be run once presumably and then there's nothing stopping the user's messing with the local admin group and taking people out of it or adding extra people to it (which they will be able to do now that they have local admin permissions themselves). If you use the Restricted Groups feature of a GPO then it will also reverse the changes when you move the computer out of scope (i.e. take it out of that group or move it to an OU that this GPO doesn't apply to) - with the one off SCCM script obviously you'd have to manually do something to change the local admin membership on a PC back to how it was.

Chris128 thanks for your reply to this matter. This whole process just seems to be a lot of unneeded steps. I understand that you have to be a admin to run cmd.exe as a system account, but I remembered a hack to allow a system level command prompt pre login. I decided to test the the whole security of adding computer accounts into the local admin group. Here are my steps and results.

Basiclly this replaces the sethc.exe with cmd.exe. I reboot the computer and come to the logon screen and hit Shift 5 times. This runs sethc.exe which is actullay cmd.exe. At this point the command prompt windows is running under the system context. I then tried to use the "Net use x: \\Comp2\c$" At this point it acts as expected and prompts me for a username and password.

I then went to Comp2 and added Comp1 into the local administrators group, and rebooted comp2.

I then went back to comp1 and ran the net use command again, this time I was not prompted for a username and password the command completed successfully without error. At this point I will able to change, delete, add files and folders on Comp2 from Comp1. I was also able to bring up mmc.exe, regedit.exe and any other management tools under the system context and make changes to Comp2.

I will be putting together a video with the steps that I have taken for all to view.

I know that these are alot of steps to take for someone to gain access to another computer, but if someone was to figure this out it, there would be no stopping them, and we would not be able to track them since they are not using a normal user account.

Ah yeah I remember a similar hack I've used in the past, replacing the accessibility options dialog executable with cmd.exe, as that also gives you the chance to launch it without logging on and will be run in the Local System security context.

However, bear in mind that the user must have logged on as an admin already to replace these executables... so they're only granting themselves permissions they already had anyway. I'm not sayings its not an additional security issue though, and its just another reason why there's no point putting the computers in that group that gets added to local admins. Surely your AD guys gave a reason why they thought they should put them in this group? I'm struggling to think of any, other than like I said before using it to scope the task or GPO that is going to add users to local admins (but then like I said, you'd be better off keeping them in a separate group just used for the scoping and not actually being added to the admins group)

I wish they did give me a reason so I can understand what they are doing but, in talking to them about this they said that it would not a problem and no one would be able to run an application under the system account.

I thank you for your input on this issue. I just wanted to make sure there was not something I was missing our not understanding about this. I will being calling our AD team again to see if I can get some clarification on this. Again thanks for your input.