URGENT: Stopping bat files, exe etc and userpasswords command

Hi

We had a student come in and run a batch file on our RDP server (which was setup for students to work outside college) which allowed him access to active directory.

The batch file that ran had the following details:

control userpasswords

This allowed him to run an MMC with which he could view Active Directory.

I have tried to look for the exe file that is being run, but cant find it. Googled the problem and did not come up with anything.

I understand, and some may mention that because he has limited access rights he cannot do much, however I do not want anyone to run this command, bat or exe files.

I have searched the forum but was unsuccessful in finding anything.

Could someone shed some light on what can be done to stop this.

Did he run it from a thumb drive? It sounds to me like there is a hole in your policies he is exploiting. Is he being disiplined as this is quite a serious offence under civil law y'know?

You should be looking for topics on software restriction policies and the file screen features of server 2003 R2.

Check your group policies. There is a setting in user policies under I think admin templates > Windows Components probably called Microsoft manage console or something similar that allows you to set what MMC snapins are available to anyone with that policy applied. Mine are set so that Teachers can access only the Active directory User and computers so they can reset passwords. Pupils are restricted from starting ANY MMC snapin. They have no need to.

That should cure your current problem but I would also advice carefully checking your permissions on AD OUs themselves. Even if a pupil could start an AD users and ciomputers MMC on my network they stil could not access any settings etc because they don't have permission to browse them. The teacher group has slightly higher permission to allow them to change passwords but in general only Techs and NMs should have AD access. In a default 2k3 installed domain I think only domain and enterprise admin groups have access to AD so you may have inheritted some unwise changes to AD security.

Teth with access to the correct tools users have read access to most of AD by default.

frankybaloney as mentioned above you need to look at software restriction and if you have R2 the FSRM features.

Quote:

---

Originally Posted by cookie_monster

Teth with access to the correct tools users have read access to most of AD by default.

frankybaloney as mentioned above you need to look at software restriction and if you have R2 the FSRM features.

---

As he said, we have had some success with the blight of swf and exe games on our network.
Even to the point we had to curb it back a bit because it was deleting .js files from students OCR work.
Not sure how well it works with virus*ahem*pen drives tho. I haven't really had a play with it yet

In combination with locking out all MMCs with group policy you should be covered tho.

A software restriction policy to restrict executables to only running from locations you aprove is a must I think too. Only our 6th form computing students are an exception to the policy that prevents running anythign executable including Java, swf, bat, com, vbs, etc.. from removable drives and home drives.

They have a slightly different policy that allows them to run executables from a folder in their home space that only 6th form pupils can create and use. Its neccesary for pascal with delphi and VB2005 Projects. They don't tend to abuse it because there are only 23 of them in the school so tracking down an offender wouldn't take long.

They are still banned from running installers of course.

We put so much effort into restricting what they can do lol.

On my list for tomorrow is preventing the intel graphics options from being accessable by a student and resetting a room full of screen back to 1280x1024 instead of 800x600 which they worked out how to do on our new suite today.

Out of interest, does restricting access to control panel via GPO block this as "control" just launches control panel.

Either way I'd hope that s/w restriction would sort it out for you.

You control panel is different entirely to MMC. Some of the items in control panel will start an MMC put its not an MMC in itself so there are 2 seperate sections of GP to configure to properly lock it up.

An account with access to control panel fully restricted could still access disk management, services, computer management etc directly if they knew how to start an MMC and add the apropriate snapin unles you lock the snapins individually or the MMC as a whole.

Quote:

---

Originally Posted by Teth

You control panel is different entirely to MMC. Some of the items in control panel will start an MMC put its not an MMC in itself so there are 2 seperate sections of GP to configure to properly lock it up.

An account with access to control panel fully restricted could still access disk management, services, computer management etc directly if they knew how to start an MMC and add the apropriate snapin unles you lock the snapins individually or the MMC as a whole.

---

Yeah, so blocking control panel should block this particular route (not verified that though) but obviously if they can run "mmc" and then add snapins they'll get to the same place. This is the recurring problem with group policies: they mostly stop people using a particular route to get to a setting rather than removing the right to change the setting itself.