Desktop Authority Tech.-Tips

Restrict usage of Certain Applications on your network
You want to restrict what applications users of the network are able to run on their workstations.

How ?
There are two methods to approach this problem. You may want to designate which applications are not allowed to run, and allow all others to be executed normally. This option is configurable on Windows 2000/ME/XP only.

Alternatively, you may choose a more restrictive approach that allows only specific applications to be executed, while all others are not allowed at all. This option is configurable on all versions of Windows.

The problem with taking such a restrictive approach is that it requires alot more work to configure an appropriate level of control while leaving a reasonable amount of functionality. Both methods are explained below.

Setup with DesktopAuthority

Method 1:To restrict users from running specific applications, multiple registry keys must be created. The first key enables the policy in Windows. Remember this policy is effective in Windows 2000/ME/XP only, so be sure to configure your Validation Logic accordingly. Use the Registry tab within DesktopAuthority to add an element with the following settings (See Figure 1):

• Action: WriteValue Hive: HKEY_CURRENT_USER


• Key: Software\Microsoft\Windows\CurrentVersion\Policies\Explorer


• Type: REG_DWORD


• Value: DisallowRun


• Data: 1

• Action: WriteValue Hive: HKEY_CURRENT_USER


• Key:Software\Microsoft\Windows\CurrentVersion\ Policies\Explorer\DisallowRun


• Type: REG_SZ


• Value: AOL Instant Messenger


• Data: AIM.EXE

Method 2: To restrict users from running any application other than those you have approved, multiple registry keys must be created. The first key enables the policy in Windows.

Note: This approach requires alot of forthought and research. Remember, this policy restricts the execution of all applications, including things as simple as CACL.EXE or IEXPLORE.EXE. Your logon script executes just as any other application, and when DesktopAuthority calls on an executable such as MAKESCUT.EXE or SLEXEC.EXE, these must have been provided for while configuring this policy or else they too will fail.

It is much more desireable to use the 1st method listed above when attempting to restrict the application a user is allowed to run. This 2nd method has been provided for environments other than 2000/ME/XP where a high level of lockdown is desired.

Use the Registry tab within DesktopAuthority to add an element with the following settings (See Figure 3):

• Action: WriteValue Hive: HKEY_CURRENT_USER


• Key: Software\Microsoft\Windows\CurrentVersion\ Policies\Explorer


• Type: REG_DWORD


• Value:RestrictRun


• Data: 1

• Action: WriteValue Hive: HKEY_CURRENT_USER


• Key: Software\Microsoft\Windows\CurrentVersion\ Policies\Explorer\RestrictRun


• Type: REG_SZ


• Value:Microsoft Word


• Data: WINWORD.EXE

Description The DesktopAuthority Manager only needs to be installed to a single machine on your domain. In order to remotely use the manager, you do not need to perform a separate installation or run terminal services.

You can simply create a shortcut to the manager executable and launch it from any computer running Windows NT 4, Windows 2000 or Windows XP. Better yet, configure an entry within DesktopAuthority Manager to automatically create this shortcut for you!

Solution

Create an entry on the Shortcuts tab to create a shortcut on your desktop to the DesktopAuthority Manager anytime you log onto a computer running Windows NT/2000/XP.

• Open DesktopAuthority Manager and select Client Configuration > Shortcuts.


• Press Add to add a new entry.


• Configure your entry with the settings shown in Figure 1:


• Configure the appropriate Validation Logic. You may want to configure this shortcut to only be created for members of your IT staff. Also, be sure to set the OS validation to NT/2000/XP only, since the DesktopAuthority Manager cannot be executed from a 9x machine.


• Note: The \\Servername would be the server where you have the DesktopAuthority Manager installed.

USB "thumb drives" drive some security folks crazy because they're so small physically and so big storage-wise; what's to keep people from popping a USB drive into a USB slot, copying corporate data and walking out the door?

For the USB-paranoid, SP2 includes an ability to let users read data from a USB drive, but not write data to that drive. It's a simple Registry change. 

First, create a whole new key: HKLM\System\CurrentControlSet\Control \ StorageDevicePolicies.

Then create a REG_DWORD entry in it called WriteProtect. Set it to 1 and you'll be able to read from USB drives but not write to them.