K… this is goin out to all those (both of you) who asked, "Hey, how the heck can I lock my workstation at work from my smartphone like you do??"
In the words of Mr. Wizard, "Well Timmy – you can’t!".
Well not exactly. Most people assume I’m running one of my goofy sys-admin scripts to lock all workstations at the same time from my cell phone when I forget and walk off without doing that. (Me forget? NEVER!!!) I do – and I could use a couple techniques for this but I actually use a script, and it has to be run on the machine itself. "But golly jee-whiz Mr. Wizard… isn;t there a remote script to trigger all of them out on Technet??" said Timmy…
"Why yes Timmy… there is. But I don’t use it." I use ONE script – and don’t use WMI to connect remotely to other machines because although you can do it safely, anyone who is running a script for it – might be tempted when the script doesn’t work for security reasons – to loosen up security. So I’ll show you how I trigger the script on all the machines I need to at the end of this…" 🙂
The key – is to call the User32.dll of Windows – using a shell command and RunDLL32.exe. Here’s the code that makes it work…
Figure 1: Lock_WorkStation.vbs
On Error Resume NextSet objShell = CreateObject("Wscript.Shell")objShell.Run "%windir%System32rundll32.exe user32.dll,LockWorkStation"Set objShell = Nothing
Basically, all I’m doing is running the script above. Now – how I do it from a cellphone is pretty simple. Since I’m always running Outlook – I’ve merely created a rule that runs when a special message is sent FROM ME – with a special code in it.
When the workstations recieve that – it runs the script shown above. I mentioned the article with from technet that has the example below as a method of executing that script remotely. Now mind you it’s good – I personally would slap an impersonationLevel=impersonate in there – but I’m a picky bugger. It’s also where many of your headaches with running this script will come from. Here’s a few examples of headaches you’ll get with this script… it won’t run because of permissions issues. It may not run if the sys-admin has reduced your privleges via a GPO, it may not run if there’s a network glitch or across domains… basically there’s several things that will cause this to cough up blood. It’s one of the many reasons I dislike the use of vbscript to automate things on a remote system. But the key reason is it’s something that should not be done by someone without a solid understand of security in an enterprise environment. It’s too easy to cause the permissions to become lax by a sysadmin because they want a cool script to run.
Then, when they get attacked via a script they blame it on the scripting security features of the script language being so lax. When in fact, it’s the scripting security features they ignored – to get something else to run. Yes – we CAN make this script below run. But if we don’t have to – why should we??
Figure 2: Scripting Guys Article Script...Const OverwriteExisting = TRUESet objFSO = CreateObject("Scripting.FileSystemObject")objFSO.CopyFile "C:Scriptslock_workstation.vbs", "\myWorkStationC$Scripts", OverWriteExistingstrComputer = "myWorkStation"Set objWMIService = GetObject ("winmgmts:\" & strComputer & "rootcimv2:Win32_Process")Error = objWMIService.Create("cscript c:scriptslock_workstation.vbs", null, null, intProcessID)
From a practical view point using VBScript to execute on a remote machine is first of all – stupid. That’s just me – but it’s dumb. To do it properly should only be done by people who really understand the ins-and-outs of security on Windows systems. Anyone who’s going to be using a script to do this is asking for a security hole to come up and bite them on the behind. Here’s the bottom line from my tighter than a ducks butt security perspective … the script listed above? It’s harmless. You have good control over it and you’re in 95% of the time going to be fine with it.
Heck – add in a check using impersontationLevel=impersonate! and yer probably golden. BUT … it’s a potential hole because if that script can be executed remotely – others can as well. It’s a personal thing of mine – but I want control of what scripts are run remotely even if they require my Admin level to execute them. Just because you’re a Policeman – does not mean it’s safe to leave your handguns around the house where kids can play with them y’know?
So… here’s how I control it – I have the Lock_WorkStation.vbs script shown in Figure 1 above, and that’s all I need. I activate it using a rule from Microsoft Outlook. Here’s my rules: 1) Message MUST come from Me. 2) Message MUST Contain an Alpha-Numeric code.
I send myself an email – it reads it and runs the script. Now that’s a pretty simple way of handling it. The caveat to this is of course… I need to have Outlook running. Now – how do I get around that without compromising security? For that … I’ll need some code and a real application.
I’ll show you how to do that next 😉