Disabling 'Lock Workstation' button in Win XP SP1

[da.Guvna]

Hiya guys,

My colleague us currently trying to produce a secured build for some shared XP machines on our corporate network. Basically, he's stripping out all the bells and whistles, and restricting user access severely to ensure that the machines can only be used for a very specific purpose (i.e. NOT downloading/installing games, looking at pr0n, etc.)

He's got it locked down pretty tight so far, but we can't seem to work out how to disable the 'Lock Workstation' button that you get from the CTRL-ALT-DEL menu.
This is a problem, because the machines log on to the network automatically using a special shared account, which none of the user are supposed to know the password for. If they can lock the machines, they will have to be told the password to unlock it again. We don't want that to happen!

I ran a quick search through google, and found a few pages which all contain the following info: http://www.sanx.org/tipShow.asp?index=137

We've tried this on several machines, and it doesn't seem to be working at all.

Does anyone have an alternative suggestion? I'd really appreciate any help on this one!

Cheers!

[Matt1eD]

This is done through applying security policies through active directory. I felt sure it could be done locally, I'll check, but it's normally as I say in the first sentence.

Addy:

It's also worth noting that you should block this as a shortcut:


rundll32 user32.dll,LockWorkStation

which will bypass the sec. policy for preventing a user locking the workstation

[Jonny M]

See if you can implement it via Start > Run > gpedit.msc

[da.Guvna]

Hey guys, thanks for you replies.

Yep, shortly after I posted we figured out we could do it through gpedit, but if there were some way to do it via a registry key instead, that would be brilliant.

We want to create a config script that runs the first time you boot the PC up, which will ask you which area you are going to put the PC in to, and will apply a different registry config based upon the user's choice.
Being able to tell the script to simply run A.reg, B.reg, or C.reg would be really useful.

Any other ideas?

Cheers!

[DaftpuNk]

If the computers were part of a domain their group policy would of course be defined by the server of that domain. It's a shame you have to implement such a strategy on non-domain based computers.

I haven't tried this but I found this if you want to give it a go...

http://www.winguides.com/registry/display.php/264/

[Cronus]

I'm pretty sure the 'User Key' bit from DaftpuNK's link is what I have used before

[TheAnimus]

oldy enough this polcy dosen't block windows key + L.
I made a rootkit patch which does (amounst many other things) but it can hardly be considered an easy option.

[DaftpuNk]

There is however a policy that blocks windows functions i believe, by that i mean the windows key in a combination with any letter on the keyboard. Perhaps a combination of the two would work?

[TheAnimus]

people can still use a macro or try to open say "rundll32 user32.dll,LockWorkStation"!

[da.Guvna]

I'm pretty sure the 'User Key' bit from DaftpuNK's link is what I have used before

Appreciate the effort guys, but if you look at the link in my first post you'll see I've already tried that. (Actually, it only mentions the LOCAL_MACHINE key, but I also tried the USER_KEY).
For some reason it just doesn't work.

Daftpunk: Our machines are in fact on a domain. It's possible my boss hadn't thought of creating a new group for the shared logon accounts and then amending the policy (I certainly hadn't).....I'll have to ask him!

TheAnimus: We're not too worried about user running macros to lock the workstation....none of them are that educated, which is why we're giving them such limited accounts ;-)

[GDVS]

Use GPOs, it's what they're there for. If you set things up properly moving from scenario a to b should be as simple as moving the machine/user from one OU to another.

[farooqm]

If it's a 1 off use the following, otherwise I agree with GDVS - use GPOs

Make sure you have Admin rights on the machine.
=--------------------------------------=
Browse to the following key:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System

Create a new DWORD entry called: DisableLockWorkstation
Set the value of this key to 1

No need for a reboot
=--------------------------------------=

Have tested this locally and remotely and it seems to work fine (WinXP). Lock button greyed out. Tested in a Windows NT4 Domain and AD Domain.

[da.Guvna]

If it's a 1 off use the following, otherwise I agree with GDVS - use GPOs

Make sure you have Admin rights on the machine.
=--------------------------------------=
Browse to the following key:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System

Create a new DWORD entry called: DisableLockWorkstation
Set the value of this key to 1

No need for a reboot
=--------------------------------------=

Have tested this locally and remotely and it seems to work fine (WinXP). Lock button greyed out. Tested in a Windows NT4 Domain and AD Domain.

Yeah, as I said in my first post, I already tried that and for some odd reason it doesn't work on our build (WinXP SP1).

As for assigning user policies via OU's, the reason we don't want to do that is because it would create a LOT of extra work in terms of applying for Change Requests, amending documentation, etc. It would take about 3 months....no exagerration. We work in a highly regulated industry, and so there's a lot of documentation with it (I'm talking signing 20 pages practically everytime I do a simple unscripted software installation).

Looks like we'll just have to do it manually

[farooqm]

Yeah, as I said in my first post, I already tried that and for some odd reason it doesn't work on our build (WinXP SP1).

As for assigning user policies via OU's, the reason we don't want to do that is because it would create a LOT of extra work in terms of applying for Change Requests, amending documentation, etc. It would take about 3 months....no exagerration. We work in a highly regulated industry, and so there's a lot of documentation with it (I'm talking signing 20 pages practically everytime I do a simple unscripted software installation).

Looks like we'll just have to do it manually

Hehe.... I know how you feel, we have the same, bloody red tape... but have managed to streamline the process so its a 'little' quicker than 3 months ... LOL