Disabling scripting on login

Question

We recently discovered that an employee of our client was able to execute a "script" that prevented other users from logging into the server.

This is a Windows Server 2003 box and employees connect via thin clients.

When a user logs in there are a few scripts that run to setup printers, etc so disabling scripting all together is not an option.

I know how to disable Windows Script Host but am not sure how to prevent a user from executing DOS commands in a batch file. The users cannot start a command prompt but can create and run batch files.

Is there a way to disable DOS scripts (batch files) after the start up scripts have run? Scripting would also have to be enabled (on logout?) the next time the user logs in so the start up scripts can run.

What would you recommend? The goal is to prevent users from executing DOS and WSH scripts.

Disclaimer: I am not a sys admin. I am a programmer who has been asked to see if there is a programming/scripting solution to this problem.

My initial thoughts are to disable scripting after the start up scripts run and then enable scripting again on log out. This is based on my assumption that there are registry keys to control this stuff but I may be wrong so I am looking for advice.

Thanks for your help.

UPDATE After having a chat with my boss it appears that some of the security that was implemented around some areas was nothing more than hiding and disabling dialogs. So it is possible the employee attacking the server did not have have the proper permissions applied to their account. Classic case of obfuscation is not security. This is not known for sure but is a possibility. We are still simulating the client's environment and running some tests.

If anyone else has any suggestions I would still love to hear your comments.

Answer 1

Short answer is "no, not really", and a deeper answer would involve an investigation into what actually happened. Do you have the real details?

Edit based on your response - then my answer is that looking to "disable scripting" is the wrong answer, and the right answer is to make sure that none of the users have more than the permissions that they need. No one other than the sysadmin(s) should be a "Domain Admin" or "Server Admin." If the dismissed employee managed to do this without elevated or incorrect permissions, and simply did something stupid that essentially caused a DOS attack on the server, there's not much you can do to prevent that at all.

Answer 2

In theory a single user should not be able to do this unless they had (or could obtain) some form of elevated rights on the server. I'd also advise finding out exactly what happened and how it happened before proceeding with any kind of script disabling.