Students pulingl power at startup, then breaking Group Policy processing

[3s-gtech]

Oh joy. This has caused some head scratching and stress.

 

Seems like some of our students with far too much time and far too little sense have worked out a new trick. It involves pulling out the power cable (or resetting the PC, shutting it down however), possibly during logging on. They then restart the PC and log on again - and Group Policy processing (possibly just the user config) hasn't applied. That means no locking down, no redirected folders, etc. Thankfully, with UAC in place and with a robust super-mandatory profile in place (as well as AD users set as User only) they're still only logging on as themselves, but of course they can still get at many things that they shouldn't. Plus, as they're pulling the power it won't be long until I have a wave of corrupted installs. Cue a slew of 'lol i haz admin rightz'.

 

I know this is a classroom control issue. I have tried asking staff to keep an eye on it. I have some names, but it's like anything that's gone into the wild - we've got loads of them doing it now. We can go the brute force approach and warn them all in assembly etc, but I'm wondering if there's anything I can do from a technical view.

 

My policies are pretty robust, when things aren't messed with it all works well. The old 'wait for network at startup' GP setting is on (swear this doesn't work in 7). My only thought now is to bodge across the registry changes from the relevant .POL file in the sysvol into the students' .MAN profile hive, if I can - that way, the policies to lock the session down are at least applied. Makes applying changes a real headache though.

 

This has been a problem for a while though it seems, so I'd like to squash it.

 

Any ideas?

[FN-GM]

Have a look for a program on here called Edulock by @Steve21 . This combined with not allowed cached logins should help.

[3s-gtech]

Cheers. We already run a very similar locking application to Edulock, which locks the PC when the network cable is pulled. This is bypassing the restrictions which it gives, and just seems to break Group Policy processing. All I can think of right now is super-glueing the power cables in!

[adhutton]

Impero locks up the PC when they pull out the network cable.

 

Works really well here

 

Andrew

[3s-gtech]

Yup, but that's not the issue we're having - we already have software that does that

 

Plus, I'm not a fan of Impero - their phone-sales tactics have got my back up!

[3s-gtech]

We had a thought - merge the ntuser.pol from their profiles and registry.pol from the Students GPO into a new ntuser.pol that contains the necessary Group Policy restrictions. That way, even if Group Policy processing fails, the registry changes should still apply. Logons still seem to work okay (and quickly) with this change, so it may work. Don't know if it fixes the issue yet, will have to check on it. Hopefully, if the lockdowns still apply, they'll get bored of this 'hack' and stop doing it...

[sparkeh]

I am intrigued as to why this is happening.

Surely if you have the wait for network setting enabled gpos should be processed no matter how the machine was shutdown?!

[3s-gtech]

You'd have thought! As yet, we haven't been able to emulate exactly how they're doing this, we've just seen the result and they've told us what they did. System Logs show 'Access is Denied' errors on the GPOs as they're applied by the machine on logon, which is truly bizarre. Thing is, I'd expect this problem to occur sporadically anywhere if it was an issue with GP processing system-wide, but the kids have worked out how to invoke it.

[Geoff]

Sometimes poorly grounded power cables are a blessing.

[Duke5A]

Computer Configuration > Policies > Administrative Templates > System > Group Policy : Startup policy processing wait time

 

Set it to something high and the machine will wait for the network to become available (talk to a DC) before allowing a user to login. Be careful though, if you've got a machine with this policy set and it's disconnected from the domain it'll wait the entire timeout period before letting you proceed. I wouldn't use this on wireless either; I learned the hard way.

[3s-gtech]

Don't think I have that set - will have a play with it. Cheers.

[wehr]

in your super-mandatory profile (ntuser.man) what are permissions on

HKEY_USERS\manprofile\Software\Policies

HKEY_USERS\manprofile\Software\Microsoft\Windows\CurrentVersion\Group Policy

HKEY_USERS\manprofile\Software\Microsoft\Windows\CurrentVersion\Policies

?

 

If its not 'full' for authenticated users or everyone GPOs cannot be applied.

 

Besides that... with Windows 7 using standard user accounts i cannot see any security problem when machine specific restrictions are in place. (e.g. remove NTFS create rights for standard users)

 

Since years i follow the strategy to use as few restrictions as possible - GPOs only where necessary. without a problem (ok its a university not a kindergarten).

Restrictions via GPOs in many cases do not provide additional security but to help users not to mess up their own desktop.

 

In my opinion when its perceived as 'i got admin rights' if restrictions fail its more a psycological problem.

[techsup1983]

I can't say I have tried this. But it sounds like it could help.

The policy is called: Startup Policy Processing Wait Time

Configuring Group Policy Processing - Windows 7 Tutorial

Windows 7 machines fail to apply software installation group policy on startup

Hope it helps.

[3s-gtech]

Cheers. The permissions on the profile hive were set, but I've made some changes and they hadn't propogated to those keys, so I've reset them all so Authenticated Users have Full Control. That may help! There isn't a security problem really - NTFS permissions are tight, UAC is on and the machines generally look after themselves. The main issue is probably perception - the kids think they're bypassing security so they're continuing to do it - pulling the power is eventually going to kill some of the installs.

 

I've enabled Startup Policy Processing Wait Time to see if that helps too - left it at the default 120 seconds which should frustrate anyone trying to mess!

 

Thanks for all your help.

[wehr]

lacking permissions on the keys will prevent GPOs from being applied for users.

 

The GP Client will modify permissions on these keys when loading the profile. That means if you load the profile to make updates to the mandatory profile you must adjust the permissions every time.

[3s-gtech]

Makes sense. I just changed the permissions in regedit by loading the hive, so didn't load the profile itself.