this_is_gav (27th February 2014)
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 confusingHaving it allow elevated privileges without authentication is just daft.
UAC was terrible in Vista but I've never had issue with it on Win7.
Last edited by Garacesh; 27th February 2014 at 09:27 AM.
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.
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.
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.
That's why I did it on a non-domain test machine - we can assume that @this_is_gav doesn't have the right policies in place (no offence intended) as they can already get to a command prompt, administrative or not.
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.
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.
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
Yea sounds like you have some weird setup as we have uac turned off and a bunch of policies set in place and they have mandatory profiles too we also have it set that every time a computer boots up and logs off delprof2 is ran and all profiles get deleted
I dont see the point in giving them access to cmd ok maybe useful to you but if they know what they are doing and the students are clear enough they could do damage e.g first point of attack is to gather data about the network and that can be done with cmd by using a net view command will give you a list of computers on the work and I know these are just kids but should still be savvy and not leave holes open.
also aslong as ur students are just domain users then not alot they can do. I would creating a test ou and practice on how to use gp and secure the systems
And as for uac well nice feature but can over kill esp if you need a driver installing
Uac is fine. If you want to update a driver use sccm or a script as system.
Or so I thought... Testing it just to be sure show me that isn't the case.
Thank you for bringing that to my attention. I'll explore further into this and see what 'damage' I can do on my test account.
Edit: If you navigate to the command prompt it declares it has been disabled by the administrator. So that's good.
Last edited by Garacesh; 28th February 2014 at 11:53 AM.
There are currently 1 users browsing this thread. (0 members and 1 guests)