Novell is now a part of Micro Focus

Using ZENworks to Protect PCs against Disgruntled Former Employees

Novell Cool Solutions: Feature
By David Lange

Digg This - Slashdot This

Posted: 24 Aug 2005

"This method does indeed delete unwanted accounts, but I would suggest that you should first consider using volatile users, along with a workstation policy that invokes Volatile User Caching (same feature exists in earlier versions of ZENworks also). This will automatically delete dormant accounts, if the user has not logged in for a set number of days. Depending on your requirements, this may be more efficient."
--Shaun Pond, ZENworks Product Specialist

PROBLEM: Dynamic Local User (DLU) leaves an account on the local PC. Deleting or disabling the account in NDS does not, of course, delete or disable the account created by DLU on the local PC. This is a potential security problem if a former employee gains physical access to a PC he previously used with DLU, or maliciously provides his credentials to someone else who could gain access.

We have over 2000 users located at 40 different sites. Some of them travel to different sites on a regular basis and log in to a different PC every time. Our employee turnover averages 300 per year so there can be dozens of accounts that need to be deleted from dozens of computers every month.

While manually deleting a local user account from a PC is not a difficult task, it is impractical to do so because of geography and the number of PCs that might have been used by each user.

We could have solved this problem by making DLU create "volatile" accounts which are deleted after each login. However, we want our users to have some control and customization of their desktops.


  1. Create a ZENworks application object that uses Microsoft's "Addusers.exe" utility in conjunction with a list of accounts that should be deleted from all local PCs.
  2. As part of our user account decommissioning procedure, we added one step: add the username to a central list of "banned user" accounts that should be deleted from all local PCs.
  3. Every month (in conjunction with another monthly procedure which uses ZENworks to change all our PCs' "Administrator" account passwords), we edit the ZEN application object availability so it is only available if the local PC does not have a current copy of the "banned user" list.
  4. The ZENworks object is associated to everyone and if it meets the availability requirements (the "banned user" list is not current on the local PC), it copies the list to the local PC and then runs "addusers.exe" against the list to delete those accounts. This ensures that no matter who logs in to the local PC, the banned users will be deleted from the PC.

The decision to run the process monthly is a compromise between our security comfort level and the potential of slowing down the PC during the login process. Your security posture should dictate how often you want to run the process. Weekly or daily processing would obviously provide better security by reducing the window of opportunity for a disgruntled employee to get back into a PC.


Assumption 1: You have a user package with a dynamic local user policy and "Use e-directory credentials" selected. (See TID 10058297, which is written for ZENworks 3, but still applies). Any time a user successfully authenticates to NDS, ZENworks automatically creates or manages an account with the same name on the local PC.

Assumption 2: You have obtained the AddUsers.exe utility from Microsoft. I was able to find a version of the addusers.exe program on Microsoft's download site. It is the NT4 version, but I have tested it on 2k and XP and find it performs the functions needed for this article.

This utility is also included in the Windows 2000 Server Resource Kit, which Microsoft sells (or sold) as a separate product. The Win2kSRK is a set of seven volumes with a companion CD that includes the 38 kb file we're interested in. The Windows NT Resource Kit contained an earlier version of the file. I've tested both versions on Win2k and WinXP and found they both perform the functions I needed. The tool is documented here.

NOTE: I do not condone the violation of Microsoft's copyright by downloading a copy of the file that has been posted on someone else's web site. The proper and legal way to proceed would be to buy the 7-volume resource kit from someone like Even though one could easily Google the phrase "addusers.exe" and find a copy that is downloadable, one should not do so -- that would be wrong. Here is one source of the resource kit: (that would be a legal way of obtaining the file).

Once you have the addusers.exe utility you should proceed as follows:

  1. Create the list of banned users:

    • The "[users]" header is required. Everything below it is processed as a user name.
    • The ";date" entries will process as user names, but are unlikely to be found. This is a mechanism that allows us to routinely remove older user names from the list so that common names like JSmith and JJones can be used again in a couple of months.
  2. Use ConsoleOne to create the ZENworks application object:
    1. Create an application object for: Simple application (no .AOT/.AXT/.MSI file)
    2. ObjectName: BannedUsers
    3. Path to file: C:\SomeDirectory\AddUsers.exe
    4. Availability: Delete the 95/98 OS, leaving only NT/2k/XP
    5. Associations: leave blank for now.
    6. Select "display details" and "Finish"
  3. Modify the new application object:
    1. Identification/Icon tab: de-select the "show progress" option
    2. Distribution Options/Application Files tab: create entries to copy two files from your source server " addusers.exe and bannedusers.text. Copy them both to the same directory you specified in 2c above. Set both to "copy if different" and "distribute always".
    3. Run Options/Application tab: Path to file should be set already (refer to 2c above). Parameters: /e C:\SomeDirectory\bannedusers.txt (Same directory as 2c above)
    4. Run Options/Environment tab: Run: Hidden. Executable Security Level: Run as secure user.
    5. Availability/System Requirements tab: Add a "File Date Requirement" with the following parameters: Show = False; File = C:\SomeDirectory\bannedusers.txt; is = "before"; Date = [the date on the SERVER version of bannedUsers.txt]
    6. Associations tab: You probably have an "all users" group, "all workstations" group in your tree. Make sure the association is "forced run" only. Your goal is to ensure the app is run no matter who logs in next.
  4. Day-to-day procedure:
    1. As you disable or delete users from your tree, add them to the SERVER version of you bannedusers.txt file.
    2. However often you decide to do so (perhaps weekly or monthly): Change the date on the Banned Users application object/Availability/System Requirements/File Date parameter to match the current date of the SERVER version of the bannedusers.txt file.
    3. When ZENworks next checks for applications it should run, it will notice that the PC"s version of the bannedUsers.txt file is older than specified and will make sure it has good copies of the two required files before proceeding to delete the users
    4. You should occasionally purge the oldest users from the list so that common user names can be recycled by newly hired employees. If you try to create a new user whose username is still on the bannedUsers list, their account will continuously be deleted from their PC.

There are several other ways to configure the application availability. For example,

  • Associate the app to workstation objects and select the run-once option. Change the version number whenever you want it to re-run. Delete the file date requirement.
  • Delete the file date requirement and the application will run every time ZENworks refreshes, ensuring banned users are immediately removed from your PCs.

If you have any questions you may contact David at

Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions.

© Copyright Micro Focus or one of its affiliates