Jump to content

Recommended Posts

Posted (edited)

Hi, got a bit of a pickle and I'm lost.

 

Kids are able to right-click on cmd.exe and simply "run as administrator". No box for entering credentials, it just opens an elevated command prompt, allowing them run things such as shutdown.exe (which of course does allow them to remotely shutdown other computers).

 

Obviously this is an issue, and I'd assumed I'd accidently given them an admin role or something, but nope - things such as Device Manager gives the message that kids are "standard users" and won't be able to make changes.

 

Have I missed something obvious (it is that sort of day)?

 

Help would be very much appreciated!

Edited by this_is_gav
Posted (edited)

Deepening the plot, I'm trying another laptop (from an identical W7 image) with a cloned user account and while it allows me to run the command prompted elevated (I say that, but there's nothing indicating it is actually elevated - Win8 tells you prompts are elevated, not sure about 7), it gives me "access denied" when running the shutdown GUI.

 

 

 

Is UAC turned off? If you so that might be part of the issue.

 

Yes, UAC is turned off. I wouldn't have thought it would allow some admin aspects to run while others are blocked though?

 

 

 

How do the kids have access to the cmd shortcut? Are they searching in the start menu?

 

Yes, though I've never blocked access to the Windows folder, so they could just launch it from there too. We've never had issues like these before (to be fair, the kid in question wasn't being malicious and showed his teacher and myself while having a bit of a chuckle), so I've never had the need to lock computers down excessively... but then they've never been able to open a program as an administrator either... :\

Edited by this_is_gav
Posted (edited)
Move your scripts to gpp. If students are in the local users group and the uac policy which fails silenlty for requests for elevation for standard users should be enabled. This prevents elevated command prompts. Any logon scripts should run in the user context. If you do need to run elevated scripts use startup scripts which run as the system account which does not require elevation. Edited by free780
Posted

Immediately, if they're heading to C:\Windows\, I can't honestly see why students need to be able to navigate the C:\ drive at all, I'd recommend making it not show up in Computer and stop them navigating through it in an explorer window. (Can be done by policy)

To stop it showing up in the start menu, I'd say provide redirected start menus and disable start menu search bar. (Can also be done by policy)

And definitely, definitely turn UAC back on. (Can probably be done by policy, but not certain on this one)

 

Make sure your pupils aren't set to be local administrators on the machine (at one school I went to, everyone, from teachers, office staff, and even key stage 1 and 2 pupil accounts were local admins! shudder) and deny them the ability to browse to network paths to ensure they can't head to the command line of another PC.

 

Also make sure any restrictions to cmd.exe are also applied to COMMAND.COM, too.

Posted (edited)

Well... it turns out the pupil in question was able to shut down his own laptop (not a shock), but not other laptops (as I said, it was denying me trying to shut down others when logging on as a dummy user).

 

Normally I'd thoroughly test something, but yesterday was rather fraught for several reasons, this landed on me in the last lesson, and by the time I came to test, the pupil had left for the day, so I couldn't log in as him (I could have changed his password of course, though that would have been a touch drastic considering I had theoretically identical dummy users I could use). Obviously with such an issue I wanted it sorted before the start of play today, as if a vulnerability had existed, it may have spread like wildfire through the school and caused chaos.

 

Will probably look into enabling UAC through GPO (if you can) if it gives users more feedback on why something is denied. I'm slightly surprised it doesn't fall back to the XP method if UAC is disabled though. Does 7 still ask for admin privileges if you "run as administrator" with UAC disabled?

 

Anyway, that's a relief. Today is a better day!

 

Thanks again guys. :)

Edited by this_is_gav
Posted (edited)

Still shouldn't have access to it anyway :p But at least the damage is limited!

 

Also to add to my suggestion, stop any programs running from AppData or temp locations (such as if cmd was ran from inside a zip file, or WORD document)

Edited by Garacesh
Posted
Still shouldn't have access to it anyway :p But at least the damage is limited!

 

Also to add to my suggestion, stop any programs running from AppData or temp locations (such as if cmd was ran from inside a zip file, or WORD document)

 

Hi Garacesh, I've edited my post since you replied. Do you know if disabling UAC allow programs to run elevated without entering credentials?

 

When I'm setting up a computer for someone outside of school, I'd always enable UAC, but we had lots of problems with UAC on Vista in school, so I've always disabled it for network computers.

Posted (edited)
When I'm setting up a computer for someone outside of school, I'd always enable UAC, but we had lots of problems with UAC on Vista in school, so I've always disabled it for network computers.

 

Huh. Y'know, good question. I honestly couldn't tell you - going to have to look into that one!

According to this page, having UAC disabled automatically grants elevated permissions to any program that requests them - however it doesn't mention if the account doesn't have admin privileges anyway. Going to jump on a test account and test this out.

So I'd definitely recommend UAC enabled - Besides having a UAC prompt pop up tells you it's a permissions error. Having nothing at all is just confusing Having it allow elevated privileges without authentication is just daft.

UAC was terrible in Vista but I've never had issue with it on Win7.

Edited by Garacesh
  • Thanks 1
Posted

This is easy to resolve -

 

User Config > Policies > Admin Templates > System - Prevent access to the command prompt - Enabled, then specify No for script processing.

 

Whilst you're at it do the same for Prevent access to registry editing tools as well.

Posted

Tested it with a machine that's off the domain:

With UAC enabled a 'Standard User' (as per Windows 7 default) is given a UAC prompt when trying to run C:\Windows\System32\cmd.exe as an administrator (right click menu) but can launch it normally, too.

With UAC disabled, no UAC prompt is shown when selecting run as administrator, but the command line still launches. 'net stop spooler' returns Error 5: Access is denied. Command line can still be ran 'normally' by double-clicking it too.

 

With that, I am assuming if UAC is disabled, the program is still launched with their current privileges. Still, I'd say turn it on anyway.

  • Thanks 1
Posted

These are the results from my tests -

 

Pupil user with a shortcut to cmd.exe in their home area running Windows 7 x86 with UAC disabled.

 

Simply double clicking it displays the command window with the message "The command prompt has been disabled by your administrator" Press any key to continue and it disappears.

 

I then right clicked the shortcut and selected Run as administrator. Again the same message as above appears. UAC makes absolutely no difference, it's all to do with the correct policies applied in this context.

Posted
I don't mind kids having access to the command prompt - indeed, in one sense I prefer it, as I can go into a class and just run gpupdate quickly if needs be (we had the "wait for network on boot" (or setting to that effect) disabled, so sometimes it took 2 reboots for computer settings to take effect). So long as they have no control they shouldn't have, I don't mind leaving the command prompt available, but I'll disable it for now, see if there's any ill-effects and see if I can enable UAC through Group Policy.
Posted

I agree with others on here. No access to command prompt for standard users, however I have a loophole here that I can exploit if necessary to troubleshoot.

 

There are some advanced security option you can set for this as well. It means that you can have UAC enables for student account but in effect disabled for your use if you find it a little annoying. In group policy under Security Setting/Security Options at the bottom are some UAC options.

 

The interesting ones here are about Admin Approval Mode so you can prevent the consent box from appearing and just elevate anyway. You can also deny standard user from receiving any prompts and automatically deny requests however I have found this can be a little restrictive if you need an elevated cmd to troubleshoot a problem.

Posted
Immediately, if they're heading to C:\Windows\, I can't honestly see why students need to be able to navigate the C:\ drive at all, I'd recommend making it not show up in Computer and stop them navigating through it in an explorer window. (Can be done by policy)

If you think you have the hard drive blocked fully, try this....

 

Make a shortcut to c:\windows\system32\cmd.exe. if while making the shortcut you get an error, try again. ( hit okay in the error and then hit next again)

 

Or, make a shortcut to \\localhost\c$

Suddenly the high HDD got a lot harder to block

Posted
Or, make a shortcut to \\localhost\c$

Suddenly the high HDD got a lot harder to block

 

and deny them the ability to browse to network paths

We do it here, they can't browse anywhere that starts with '\\' or by IP Address (even if they can connect to it anyway, for example, they can't browse to \\printserver\ even though they can print to printers on \\printserver\)

Posted
Well... it turns out the pupil in question was able to shut down his own laptop (not a shock), but not other laptops (as I said, it was denying me trying to shut down others when logging on as a dummy user).

 

Normally I'd thoroughly test something, but yesterday was rather fraught for several reasons, this landed on me in the last lesson, and by the time I came to test, the pupil had left for the day, so I couldn't log in as him (I could have changed his password of course, though that would have been a touch drastic considering I had theoretically identical dummy users I could use). Obviously with such an issue I wanted it sorted before the start of play today, as if a vulnerability had existed, it may have spread like wildfire through the school and caused chaos.

 

Will probably look into enabling UAC through GPO (if you can) if it gives users more feedback on why something is denied. I'm slightly surprised it doesn't fall back to the XP method if UAC is disabled though. Does 7 still ask for admin privileges if you "run as administrator" with UAC disabled?

 

Anyway, that's a relief. Today is a better day!

 

Thanks again guys. :)

 

Sounds to me as though he's in the local 'Administrators' group on the laptop and you have UAC disabled.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...