36 replies to this topic

[bowl443]

Windows 2008 domain with domain controllers running '08 R2.

We had user today add themselves as a local admin, giving himself full rights to that machine on a Windows 7 machine.

How can I prevent this with a GPO?

[n_K]

To be able to do that he was either domain admin or admin on the machine, surely your question should be how did he get access to making himself an admin, no?

[cybertimber2008]

I think power users can add other users as administrators too... but yea the user was not just in the "users" group. Or they used a boot cd...

[+sc302]

You make them a normal user on the computer. That is how you do it. If they use a boot disk to get around it, set a bios password and put security screws on the case so they can't open it. If they continue to break policy it is grounds for termination or removal of computer rights (at least that should be in your policy).

Power users does not allow you to add admins to the computer. You would need to be an admin or a group that has local admin rights. Or a boot disk like the free hirens disk that you can download and boot off of.

[+BudMan]

"We had user today add themselves as a local admin,"

As sc302 mentions "boot disk to get around it, set a bios password"

If I have physical access to the box - I can just boot one of many different tools to change the local admin account password. Log in with that for what I need, or log in with that and then give whatever other account I want local admin as well.

You can not prevent that from happening with a gpo.. The box would have to be setup with a bios password to prevent booting from removable media, be it cd or usb, etc. And you also need to prevent pxe - or I could just boot the tool I need to change the local admin password via pxe if so desired, etc.

[Kaedrin]

bowl443, on 24 January 2013 - 22:06, said:

Windows 2008 domain with domain controllers running '08 R2.

We had user today add themselves as a local admin, giving himself full rights to that machine on a Windows 7 machine.

How can I prevent this with a GPO?

Group Policy Preferences. This will properly layer over multiple GPO's targeting the same group.

Computer Configuration\Preferences\Control Panel Settings\Local Users and Groups.
Create a "New Local Group" and from the drop down caret under Group name: select "Administrators (built-in)
Checkmark "Delete all member users"
Checkmark "Delete all member groups"

Now select the "Add" and then "..." buttons to query for domain groups or user objects. Do not type in the Name: field manually unless you are defining a local computer user or group object that will still be a member, otherwise you may not properly attach the domain object SID to the GPP. You may wish to add the local computer "Administrator (built-in)" user to this group.

Under the Common tab you should select "Remove this item when it’s no longer applied." and select "No" so that all members added to the group are removed when the GPO no longer is used against the computer. Beware that if you do not have a higher level GPO that automatically adds a local Administrator to this group that it is possible to remove all Administrators from a computer.

Beware on using "Delete all local users" against servers. You will discover scenarios where your GPO will cease to function on servers containing certain roles (I believe it involves the Configuration Manager agent being present), and then you may have almost everyone trapped out of the server until you create a lower level GPO that fixes the issue and wait for your GPO refresh timer to execute. In this particular case if you need to control local users, have a parent GPO control removal, and a layered GPO control the actual members. It'll scream at you in the event logs when Delete all local users fails to function.

If you do this, even if someone adds an account to the Administrators group, your next GPO refresh will undo the change. If someone adds a user to the group while the machine is offline, the GPO refresh at startup will likely remove the user from the group before or during logon. People who know how to launch PowerShell under the System context of the Logon screen however will be able to defeat this GPO. If you really want to prevent offline attacks, use BitLocker, but BitLocker will not defend against an online attack that enables a CLI to work at the logon screen.

As I recall, this GPP has no effect against built-in groups on Domain Controllers.

[majortom1981]

He had to have been an admin or used a boot disk. At work I have all machines password protected for all boot except hdd. Maybe you should do that yourself. This would be set in the bios.

[+sc302]

Kaedrin, on 24 January 2013 - 22:51, said:

Group Policy Preferences. This will properly layer over multiple GPO's targeting the same group.

Computer Configuration\Preferences\Control Panel Settings\Local Users and Groups.
Create a "New Local Group" and from the drop down caret under Group name: select "Administrators (built-in)
Checkmark "Delete all member users"
Checkmark "Delete all member groups"

Now select the "Add" and then "..." buttons to query for domain groups or user objects. Do not type in the Name: field manually unless you are defining a local computer user or group object that will still be a member, otherwise you may not properly attach the domain object SID to the GPP. You may wish to add the local computer "Administrator (built-in)" user to this group.

Under the Common tab you should select "Remove this item when it’s no longer applied." and select "No" so that all members added to the group are removed when the GPO no longer is used against the computer. Beware that if you do not have a higher level GPO that automatically adds a local Administrator to this group that it is possible to remove all Administrators from a computer.

Beware on using "Delete all local users" against servers. You will discover scenarios where your GPO will cease to function on servers containing certain roles (I believe it involves the Configuration Manager agent being present), and then you may have almost everyone trapped out of the server until you create a lower level GPO that fixes the issue and wait for your GPO refresh timer to execute. In this particular case if you need to control local users, have a parent GPO control removal, and a layered GPO control the actual members. It'll scream at you in the event logs when Delete all local users fails to function.

If you do this, even if someone adds an account to the Administrators group, your next GPO refresh will undo the change.

As I recall, this GPP has no effect against built-in groups on Domain Controllers.

The damage is already done at that point. There is no gpo that prevents this.

[Kaedrin]

sc302, on 24 January 2013 - 23:05, said:

The damage is already done at that point. There is no gpo that prevents this.

Depends what the actual story is, which the OP barely gave details on. What I described helps mitigate. (BTW, you responded to my original message prior to a bit of editing)

To prevent offline attacks, the only real "solution" is to manage the machines with BitLocker, a TPM, and Network Unlock.

A BIOS System password is only effect against "some" computers with properly designed firmware. A large majority that I've encountered do not block the F12 (or equivalent) firmware/BIOS boot menus even if a System password is present, including some of Dell's business line machines. Only some actually require authentication if a system password is present. I have some Precision workstations that do intrusion detection great, but only a BIOS user password will prevent a user from calling on the boot menu (and of course block them from using the computer at all without support). I don't believe any vendor is 100% consistent across their motherboard models when it comes to securing its BIOS/Firmware boot menu.

Also, when properly managed, "BitLocker+TPM+Network Unlock" is the better solution than any firmware block or physical lockdown because it requires the end user actually have technical skills. They need to have successful online attacks before an offline attack becomes possible. At this point most failures will be the result of desktop mismanagement.

Obviously it’s a bit trickier on mobile systems, as Network Unlock likely becomes impossible and you have to replace it with +PIN/+USB.

[bowl443]

Sorry for the brevity in the OP. I hammered out the question before leaving the office for the day. I probably should have waited until I had all the details before posting. An area tech called me with the problem and the details were vague.

It is my understanding that the user launched the user account applet and made the changes. I was hoping that there was a GPO that disabled access to that particular applet.?.

Thanks for the responses.

When I get to work tomorrow morning I'll set up a test user with the same privilages and try it out and see if I can figure out how he did what he did.

[n_K]

bowl443, on 25 January 2013 - 02:39, said:

It is my understanding that the user launched the user account applet and made the changes. I was hoping that there was a GPO that disabled access to that particular applet.?.

Then the problem lies with your lack of basic security then, nothing GP will fix - you've set his account up as an admin.

[Simon-]

Agree with grounds for termination and so on, but also worth pointing out, try and find out what possessed the user to get Admin rights. Did he do it because he is an ass who wants to install some dodgy Facebook games, or is there something wrong with his computer that hasn't been addressed and he was trying to take matters into his own hands to fix it out of frustration?

[+BudMan]

Kaedrin -- are you talking about restricted groups? Seems like a really long explanation of restricted groups to me. Which sure you can restrict who is in your admins group. And yes that is a great idea and normally an audit requirement anyway..

But if I have local admin - its real easy to block gpo being pushed from the domain..

Now sure if you want to go the encrypted route - this can also prevent the boot tools to change the admin account. But normally your not trying to keep out the elite hackers here.. Your keeping billy joe bob from running some boot tool he found on the net, etc.

But yeah if all he did was launch user manager -- then he had rights in the first place. Does someone have domain users in the Domain Admins group

[Kaedrin]

BudMan, on 25 January 2013 - 11:00, said:

Kaedrin -- are you talking about restricted groups?

Restricted Groups is legacy. They have extremely limited functionality compared to GPP Groups, and as I recall cannot be layered across multiple GPO's. Unless the target is a pre-Vista system, GPP Groups should be used instead. I abandoned Restricted Groups entirely once Vista SP1 & 2008 SP1 were released.

[eXtermia]

Even if you set a boot bios password to prevent booting from CD the passwords can usually be reset. However if you enforece bitlocker with the key being backed (with hardware TPM) up to AD and only recoverable from AD admins there is no way they can use any off the street tool to add thierselves as Admin. First they would have to have access to the AD and have rights to view the key. Note Admins can still boot and use the recovery MS DART toolsets and reset passwords or whatever with the recovery key. There is no way the user will be able to boot from cd and give himself admin rights.

There is a small chance of privilege level escalations using say a faulty cisco vpn client allowing the users to get system access and then give themselves root from a running machine. Also there is a small chance they could freeze the memory (actualy temp wise) and read the bitlocker key from an additional machine. However the general user with all his "hacker" tools arent' going to bypass a full system encryption (assuming you have a TPM module in place)

You don't say if you do have a TPM enabled machines or not.

However s/he already OWNS this machine. The only way to ensure they don't give themselves rights again is to re-image. As as long as he or she had admin rights to begin with, they may of installed a system level back door that simply gives the right back even after you removed them from the Admin group.
Do you make them sign an user agreement, or if they do have elevated rights a privledged level access agreement?