Tools aim to make NT admin a snap

So you're migrating your agency's network to Microsoft Corp.'s muchballyhooed Windows NT platform. You've set up the necessary user accounts, local and global groups and appropriate domain trust relationships. You give yourself a welldeserved pat on the back and prepare to push the daytoday adm

So you're migrating your agency's network to Microsoft Corp.'s much-ballyhooed Windows NT platform. You've set up the necessary user accounts, local and global groups and appropriate domain trust relationships. You give yourself a well-deserved pat on the back and prepare to push the day-to-day administration tasks out to the help-desk staff. Not so fast.

Windows NT's security access database, which stores users' and groups' rights, is relatively flat. You cannot give your help-desk staff limited authority over users, groups and resources. With Windows NT, it is an all-or-nothing proposition; your help-desk staff must have the security equivalent of either domain administrator or account operator. That's where two new software tools enter the picture. I reviewed both packages, which allow network administrators to assign granular administrative duties without compromising security. These tools are Enterprise Administrator (EA) from Mission Critical Software Inc. and Trusted Enterprise Manager (TEM) 2.0 from Master Design & Development Inc. (MDD).

How They Work

Both EA and TEM are client/server-based applications. The server portion of each product runs as a secure Windows NT service logged on with administrator rights. The service software makes no alterations to the integral components of the Windows NT operating system, such as the kernel or the security access database. This service acts as a proxy to the respective client software front end for each product and fields the administrative requests received from the client software.

Depending on the granular rights assigned to the individual posting the request, the service reacts and makes the appropriate changes or rejects the request. The EA service can be run only on a Windows NT 4.0 primary domain controller (PDC) or backup domain controller (BDC), and only one instance of the service can exist in each domain. EA creates and maintains its own hive within the Windows NT registry, where it stores its security and policy information.

For redundancy, EA suggests installing the server service on a BDC, setting up the service as a manual start-up and then enabling the EA Registry Replication feature. This feature will replicate the critical EA registry information to one or more backup EA servers within the domain.

The TEM program does not modify the Windows NT registry or create extensions within the Windows NT security database. Instead, TEM stores Windows NT account information with rights to each global group to be managed in the TEMCFG directory in the form of .INI control files.

The TEMCFG is set up as a Windows NT share, and the control files contained within are queried by the TEM service when a TEM client is launched.

Installation

To prepare for testing, I configured the TEM Service/Sync and EA Service on two separate Windows NT 4.0 servers. For TEM, this computer is called the TEM Host, and it can be a Windows NT server PDC, BDC, member server or Windows NT workstation. MDD recommends the TEM Host be a PDC in the master user domain to eliminate overhead traffic on the network when updates to the Windows NT security database are made.

The EA Service can only reside on a PDC or BDC, and only one instance of the EA service can be running on any one server within the domain.

Both TEM and EA require an account to be configured on the host server with administrative rights. The TEM documentation provided step-by-step details on how to configure the service account on the Windows NT server. Once I configured the Service account, I launched the TEM setup program. The setup process is quite extensive, but it is well-documented in the setup guide and is fairly straightforward. The EA product is also well-documented, but I did not need the user manual very often when installing the product.

Granting Rights

EA takes a special approach to administrative naming conventions, with administrators divided into resources, territories, marshals and deputies. As an administrator, you configure the EA marshals within the domain. A marshal then has the power to create a territory (or virtual domain) within the domain. The marshal can define what resources exist in the territory, such as users, servers, workstations and print queues. The marshal can then "deputize" various users and define what administrative tasks the deputies can perform on resources within that territory.

For example, a marshal can define the accounting department as a virtual domain within a global domain. He can then define the users, workstations, servers and printers within the accounting department in the virtual domain.

Finally, he can deputize and equally divide administrative duties among the help-desk staff and even deputize key people in the accounting staff to have some administrative ability, such as resetting passwords or administering print queues.

TEM takes a similar approach but without the Wild West descriptions. In TEM, the highest administrative authority is the TEM enterprise manager, which is equivalent to a marshal in EA. The TEM enterprise manager can create junior administrators called trusted managers, which are similar to EA deputies. The TEM enterprise manager can grant granular administrative rights to these trusted managers.

One big difference between the two software packages is the use of virtual domains vs. global groups. In TEM, management is done at the global group level, while EA enables the use of a subdomain within a domain. TEM boasts that this feature will make it easier to migrate to the Active Directory service available in Release 5.0 of Windows NT because global groups will become organizational units.

Client Software

I found both client packages easy to install and configure on my local Windows-based PC. Both products provide easier and improved management interfaces over the standard tools found with Windows NT.

The TEM client's main display divides the window into three slices. Listed on the left half of the display are the managed NT global groups. The right half of the screen lists account information, such as full name, last log-on, log-on count and log-on server. Depending on the access level of the trusted manager, different options will be allowed from within the client.

Some of the routine day-to-day administrative tasks are quickly available through toolbar icons within the TEM client. For example, I could easily reset a password, delete a user or modify a global group with a click of the mouse. I also could access user property information from the toolbar. The information in this box is similar to that found in the Windows NT Domain Manager application, such as log-on hours and account information; however, I preferred the layout in TEM because it was in a tabular window format.

Other noteworthy features in TEM include a copy user routine, which lets you set up rights for a new user by cloning the rights of a current user. TEM also has introduced Active Collections, which enables administrators to enforce consistent levels of authority over trusted managers. Default templates ship with TEM; these can be modified, or you can create your own. The EA client has a slick interface that I preferred over the TEM client. The main screen was structured in a tabular window format. Depending on your access level (marshal or deputy), you are restricted to the tabs displayed in the client.

Reporting Features

In addition to adding granularity to the Windows NT environment, both products provide reporting features that make them a value-add to your administrative toolbox. The EA product ships with a runtime version of Microsoft Access and has 30 pre-programmed reports available out of the box. EA also has a separate reporting program that can be launched with the EA client. This reporting program allows the administrator to view the available reports by report type.

EA also allows you to set criteria for the individual reports you select. You also can easily program your own reports using a full version of Microsoft Access and have them listed and available within EA.

The TEM product has useful but limited reporting features within the client software. However, data can be exported from the client and imported into a runtime version of Microsoft Access included with the product. As with EA, TEM includes pre-defined queries, and the user can create custom queries within Microsoft Access.

Conclusion

Both TEM and EA address a key concern for government agencies deploying large Windows NT networks: granular administration. Will products such as these be needed when Windows NT 5.0 ships? That's hard to say. But both vendors are preparing versions for NT 5.0 that they say will provide more granularity than is offered by Microsoft. Reporting features also will be an important element for both products.

Give each product a try and see which is right for your environment. Both are available for limited-time trials. Trusted Enterprise Manager can be found at www.mddinc.com, and Enterprise Administrator can be found at www.missioncritical.com.

-- Marshall is the information systems manager for FCW Media Group. He can be reached at john_marshall@fcw.com.