By Bryan Keadle
Having restrictive group policies applied for a user/workstation is nice in order to keep users from doing what they shouldn’t or tweaking their way to a Help Desk call. However, it also becomes a hassle when you do need to provide support for the end user. Often, logging out and logging in as an Administrator to remove the restrictions isn’t only slow and cumbersome, it also isn’t helpful if the issue you may be trying to resolve is specific to the user’s profile.
In my environment, I use my own custom utility, Policies.exe, which allows me to temporarily remove policy restrictions, do what needs to be done, then put the policy restrictions back…all without a reboot!
Here’s how it works:
With policies accessible on a network drive (or delivered as a NAL object), as the user I run POLICIES.EXE. I’m prompted to enter the administrative password:
Password is: Authorized (case sensitive)
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. 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, restoring the workstation to it’s “locked down” state. 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 version of POLICIES.EXE is also INI-configurable. An INI of the same name in the same directory (IE: policies.ini) provides these options:
[SETTINGS] PSWD=Hex Password (set with PSWD command line) LOG=Log File LogEntry=%UserName% on %ComputerName% incorrect password for POLICIES.EXE LogUse=Y ;to log use of policies
PSWD= alternate, encrypted password
LOG= Log filename (and path) for logging usage of Policies
LOGEntry= text of log entry
LogUse= Enable/disable use of policies.exe logging
To set your own password for Policies.exe, run:
Enter existing password (default=Authorized)
Enter your new password. This will then be stored in the .INI in an encrypted format.
To address the concerns that your end-users could find this tool, download it, and run it from anywhere to circumvent your group policies, POLICIES.EXE will also check the search path AND Z:\PUBLIC for any other POLICIES.INI file and if found, *AND* the user is unable to change it’s file attributes (hence, placed there on a restricted network drive by a NetAdmin), IT’S INI settings will be used instead, thereby overriding any default settings or settings that may be defined by an .INI located with the .EXE.
Note: Alert reader Vicki W. noted that having this tool freely available for download by her students was a significant security concern for allowing them to also circumvent their policy security measures.
To address this legitimate concern, POLICIES.EXE will also check the search path and Z:\PUBLIC for any other POLICIES.INI file and if found, *AND* the user is unable to change the attributes of the file (hence, placed there in a restricted directory by a NetAdmin), it’s INI settings will be used instead, thereby overriding any default settings or settings that may be defined an .INI located with the .EXE.
Note for v42
By popular demand…or should I say…UNpopular demand (!)… this tool *requires* the NetAdmin conditions to be in place for it to work. If attempted to run this program without the read-only conditions in place, the user will simply get this “You are not authorized to use this program without the Network Administrator’s approval!” message:
This addresses the concerns from people that the availability of this tool to run without NetAdmin approval and conditions set makes your job harder…not easier…which certainly isn’t my intent! Thanks for participating in this community….this is how it’s supposed to work!
(Works for Win2K and WinXP)