Working Around Workstation and Apps Restrictions
Novell Cool Solutions: Trench
Digg This -
Updated: 12 Oct 2005
Question: Noah G. wrote: I am working with a NetWare 6/ Windows NT 4 network. The workstations consist of several 95/98 desktops and a few 98 laptops (we are in the process of upgrading). Applications are sent down by ZENworks. We have set up some fairly strict policies that get in the way of administration sometimes. One such policy prevents them from installing anything including running install.exe or setup.exe.
We have had times when the NIC or something else will go bad, and the administrator can't log onto the workstation due to restrictions in place on the workstation. If the administrator could log in, then the restrictions would be removed. Is there a way to remove the restrictions from a workstation or laptop that can't login anymore without totally reinstalling it?
Answer: It's not easy to do this with Windows 9x as it's not truly multi-user aware.
The solution with Windows NT/2000/XP is to have a different policy set for administrators.
Anyone out there have a sneaky method of doing this? Let us know.
- Dwayne Watkins
- Michael Raugh
- Keith Sanders
- Bradley Butcher
- Tom Hafemann
- Geoffrey Carman
- James Smith
- Terry Hall
- Bryan Keadle
- Sara Whipple
- Keith Runge
- Eric Ho
- David WhiteNEW
Why not have two copies of registry settings: one with the settings locked down, and the other with King-like settings.
This way, if you need to, you can simply push, pull, drop in, or double click a ".reg" file or create a batch file to send out the policy changes.
Just saw the piece on restricted workstations. I usually handle this by creating an app object that makes the needed registry changes to lift the restriction (usually just involves setting a DWORD value to zero that had been set to nonzero to enforce the restriction) and associate that object to the Admin user or my help desk group. Tech logs into workstation, runs that app, and can do whatever is needed; user logs in afterward and restrictions get enforced again.
Another answer for the case where an admin can't log in is for the tech staff to carry a floppy with the same restriction-lifting registry code in an REG file. The staffer puts the floppy in the machine, opens UNRESTRICT.REG (that's the name I used), and it gets imported into the registry. For remote users you can put the REG file in a home directory and then remove it afterwards so the user can't unrestrict themselves at will.
We handled this in the past by booting to a dos prompt via either F5 (if not disabled), or via boot disk.
You can change to the \Windows directory and use the dos version of regedit to import a .reg file that disables the policy keys in the registry that set the restrictions.
- Open Microsoft Management Console (MMC) on a computer.
- Load group policy snapin with a connection to the remote computer with the problem.
- Right mouse on local computer policy.
- Disable computer configuration settings.
- Disable user configuration settings.
- Reboot the computer.
All policies are open.
I don't know if this applies to the settings they use, but when this happens at my school I do the following. I have a renamed copy of Poledit on a floppy (named something that will run despite the policies on the workstation, like explorer.exe or one of the NAL programs) and then reset the policies. This allowed me to get into the system settings and fix the nic. I have also done this with the Novell client installer when it wouldn't run for the same reason. Once I got the client reinstalled the problems went away.
If nobody has thought of this yet, I sure hope you give me the credit.
We lock down all our workstations for "users". From time to time, we want to run certain programs that users do not have access to with their priv's. We have a really neat way of keeping security without any compromise or logoff.
Starting with Windows XP, the "runas" command enables you to run any application "AS" another user, including the Administrator. However, we have taken the "Runas" command away from our users. FYI, you can copy the "runas.exe" from a Windows XP workstation to a Windows 2000 workstation and it WORKS!
Anyway, we created NAL objects that run applications such as Computer Manager. This one will prompt you for the LOCAL admin password. If you are in an AD domain, adjust the "/user" part to be firstname.lastname@example.org
Run command %windir%\SYSTEM32\runas.exe Additional Parameters /user:%COMPUTERNAME%\Administrator "mmc %windir%\system32\compmgmt.msc"
As you see, we are running only one snap-in. You can change to ANY snapin at all.
A popular one here is Task Manager. We do not allow the creation of new tasks. However, logged in as Administrator, you can
Run Command %windir%\SYSTEM32\runas.exe Additional Parameters /user:%COMPUTERNAME%\Administrator %windir%\system32\TASKMGR.EXE
(PS. Make sure you put a SPACE before /user..... Otherwise the run command and additional parameters will run together like this %windir%\SYSTEM32\runas.exe/user:%COMPUTERNAME%\Administrator %windir%\system32\TASKMGR.EXE and not work. You really want this: %windir%\SYSTEM32\runas.exe /user:%COMPUTERNAME%\Administrator %windir%\system32\TASKMGR.EXE)
This has saved us LOTS of hours logging off/logging on. A lot of times, the problems are profile related and can ONLY be debugged as that user. This helps skirt all security as the administrator. Be careful! If someone gets your administrator account password, they then become GOD on your network.
Create a lock-down policy in ZENworks and associate it with the typical users. Then create an 'admin' policy, that reverses all the things done in the lock-down policy, and associate it with a technician account.
If the technician needs local privileges, log in with the technician account. If they need to test with policies enforced, use the less privileged account.
We use an in-house application for many administration tasks and presenting useful information to the user.
One of the functions we have created is the ability to run the app and authenticate to NDS using your full context and password. If you're a member of the Desktop Administrators group then it unlocks administration features within the app.
One of these features is an 'Unlock PC' option. This runs
a Windows script that changes the necessary registry entries, then
refreshes the registry using
secedit.exe /refreshpolicy user_policy /enforce
and secedit.exe /refreshpolicy machine_policy /enforce.
We have also created a 'Lock PC' for administrators to restrict the desktop before leaving. If this isn't used, ZENworks applies Group Policy restrictions at next logon.
One thing I have done is deny the Administrators Group access to the directory where the Group Policies are stored. When I log in, I'm basically denied rights to those files and Group Policy is not applied to me.
I have the "ultimate" method. :-) Policies.exe (available below)
Because we remote control our users for support purposes, we wouldn't want to give away the workaround for "unrestricting" workstations. Also, often we want to be logged in as the user we're supporting, so as to be working against their profile, so logging out as a different user or using RunAs.exe isn't appropriate.
You could create your own batch file with these commands:
@echo off REM This exports the settings regedit /e %temp%\~pol.1 "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies" regedit /e %temp%\~pol.2 "HKEY_CURRENT_USER\Software\Policies" regedit /e %temp%\~pol.3 "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies" regedit /e %temp%\~pol.4 "HKEY_LOCAL_MACHINE\SOFTWARE\Policies" echo REGEDIT4>"%Temp%\~PolApply.reg" echo.>>"%Temp%\~PolApply.reg" type "%Temp%\~Pol.1"|find /v "Windows Registry Editor Version 5.00">>"%Temp%\~PolApply.reg" type "%Temp%\~Pol.2"|find /v "Windows Registry Editor Version 5.00">>"%Temp%\~PolApply.reg" type "%Temp%\~Pol.3"|find /v "Windows Registry Editor Version 5.00">>"%Temp%\~PolApply.reg" type "%Temp%\~Pol.4"|find /v "Windows Registry Editor Version 5.00">>"%Temp%\~PolApply.reg" del "%Temp%\~Pol.*" REM "%Temp%\~PolApply.reg" are the policy settings exported REM Now, delete the registry keys: echo REGEDIT4>"%Temp%\~PolRemove.reg" echo [-HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies]>>"%Temp%\~PolRemove.reg" echo [-HKEY_CURRENT_USER\Software\Policies]>>"%Temp%\~PolRemove.reg" echo [-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies]>>"%Temp%\~PolRemove.reg" echo [-HKEY_LOCAL_MACHINE\SOFTWARE\Policies]>>"%Temp%\~PolRemove.reg" regedit /s "%Temp%\~PolRemove.reg" REM Workstation is now unlocked **See NOTE: below echo. echo Press any key to re-apply settings... pause>nul REM Import exported policy settings regedit /s "%Temp%\~PolApply.reg" del "%Temp%\~Pol*.reg" echo. echo Done. echo.
NOTE: though registry policy settings have been deleted, Explorer needs to be "refreshed" for some of the settings to take effect. One way to do this is to kill the Explorer.exe task and re-run it, but it's crude. My Policies application is able to do this cleanly however (refresh Explorer)
I have created my own little utility, Policies, that first prompts for a Password. Because the password dialog only shows * entries, an observing user wouldn't know what to type. After entering the correct password, it exports the registry keys to some temporary files, then deletes the registry keys, thereby removing all restrictions (just like the .BAT file above). Now you can do whatever you want to the machine, *before* pressing OK on the message box. Once you press OK on the message box, the exported registry keys are re-imported and the temporary files deleted, leaving the workstation back to being locked down. Pretty slick...quick and easy.
This works as long as the user has the necessary rights to these registry keys to be able to modify and delete them. This above .BAT file is effectively what Policies.exe is doing, except Policies.exe gives you a password dialog and refreshes Explorer so that all policy changes are refreshed.
School Admins can contact Bryan for his tool: policies.exe.
Usually what I do is to use gpupdate / secedit. Basically these are the steps:
- Create admin's policy
- Copy the admin's policy folder and gpupdate/secedit to a CD or thumbdrive
- Use a batch file to copy over the admin's policy to the locked workstation C:\WIN[NT/DOWS]\SYSTEM32\GroupPolicy and run gpupdate/secedit to force it to update, then the workstation will be unlocked, read: God-mode
With 2000 & XP, you can launch the mmc from a command prompt and edit %systemroot%\gpedit.mmc to allow you to run installer (Disable Computer Configuration\Administrative Templates\Windows Components\Windows Installer\Disable Windows Installer) until the group policy refreshes from the server.
One way around a restricted XP workstation is to use RUNAS in conjunction with Internet Explorer.
- Using Windows Explorer, navigate to C:\Program Files\Internet Explorer\IEXPLORE.EXE, right-click and select Runas.
- After logging in as the local Administrator, use the IE address bar to go whereever you want with Administrator privileges.
- Want to change file system rights? Enter "C:\" in the IE address bar and navigate to the folder just like using Windows Explorer.
- Want to change NIC settings? Enter "Control Panel" in the IE address bar and navigate to Network Connections.
As long as IEXPLORE is running or any program started while in IEXPLORE, you have administrator rights through it. This is a great way for solving problems through remote control without logging out the user and logging in as the administrator.
Since you have ZENworks to push down applications, I am assuming you have imported all workstations in your network environment.
We have a similar environment in our organization. We have a few locked-down terminals for the public in our network. Here is how you should do it.
- Upgrade all Win98/95 to WinNT. If possible, upgrade them to WinXP. Maintaining one OS platform is easier then multiple platforms.
- Create two workstation policies using ZENworks 'Computer System Policy'. One is for the most restricted environment (Public Terminal). The other one is for the least restricted environment for Administration purposes.
- Associate those two workstation policies with users depending on what they need. For maintainance purposes, sign on to the workstation with the least restricted user. Otherwise, sign on as a terminal user.
- Prepare a workstation with a few applications you want and apply all Windows patches. Load the image of the workstation to the network. In case the system crashes, just dump the image back to the workstation.
- For off-hour maintainance purposes, turn on the WOL feature in system BOIS setting.
Basically, if ZENworks can push applications for you, ZENworks will do the patches for you too. You can roll out patches the same way as you roll out your applications. You do not have to do any extra work. ZENworks will take care of your workstations for you.
In our environment (Windows 2000 / NW 5.1 / ZENworks 3.2) we decided to remove local workstation users from the Administrators group as well as applying some of the ZENworks policies. This gives us a higher level of workstation security but obviously major headaches when trying to administer / troubleshoot the workstation.
The following workaround was suggested to me by one of the ZENworks forum sysops:
Create a NAL object that runs cmd.exe and set it to run as "Unsecured system user" on the Run options > environment tab in ConsoleOne. This means that the app runs with the workstation security instead of the local users and is able to amend the registry / Winnt directory etc. The only pre-requisite is that the workstation is imported correctly.
One thing to be aware of is that by default the workstation will only have file rights that it has inherited from above, eg sys:public. If you want access to files located elsewhere you must explicitly assign them.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com