According to Novell, they are still working on the ability to assign dynamic rights to applications so that a user cannot access those rights outside of that application. In other words, when they launch the object they have the rights to perform the actions related to the object and when they exit the app, they no longer have those rights. Through the use of ZENworks and a few nifty tools from the NT Resource kit, I have put that ability to work today.

Under Windows 3.x and 9.x only a single session can be running at a given time. Under Windows NT, however, many user sessions can be running simultaneously. This allows a user sitting at an NT box to be running multiple applications each using a different "user’s" authority. This means that I can be running applications A, B, and C all from SERVER1 while attached to SERVER1 as USERA, USERB, and USERC. NT Resource Kit supplement #4 contains a utility called PULIST.EXE which lets you view all running applications and the security context they are running in such as "system", "usera", or "userb".

The use of different security contexts is most commonly seen with services. A service will generally logon using the "system" account. This is the internal account used by the operating system and has full control to the local PC. The service can be changed to logon using either a local account or a domain account. The service will now run have the same local and network privileges as the account specified The NT Resource Kit supplement #4 has a utility called SRVANY which allows any program to be run as a service and take advantage of this ability.

One such service that can be very useful is the "workstation manager" service. This service can be assigned rights through the workstation object in the NDS. The workstation object can be assigned either file rights or NDS rights. To assign file rights, just select the volume and drill down to the desired directory. Select "trustees of this directory" and add the workstation object or workstation group. To assign NDS rights simply right click on the desired object and select "trustees of this object." Add the workstation object as a trustee and assign it any desired rights.

NT Rescue Kit supplement #4 also has an "SU" utility which allows for the starting of applications using a different user’s security context. The user specified must be either a local NT user or a member of the NT domain. If access is desired to a Novell server, there must be an NDS user (or alias) in the same context with the same name and password as the NT user specified. This can be handy to allow non-admin to run automated command-line utilities which normally require NDS administrative rights or to install software from a Novell server which requires local admin rights and access to the Novell server.

The syntax for the SU utility is - SU.EXE userid "command" ms_domain

The use of this utility does not require an MS Domain. If the workstation is not part of a domain, it will default to looking at the local account database. Each workstation, however, would have to have a common account with the same password.

net localgroup administrators localadmin /add

The two commands issued above will create a user name localadmin on the local workstation with the password secret and place that user in the administrators group. These commands can be scheduled by workstation manager with system authority to create this common account for use on all PCs.

The password for the account used by the SU utility must also be passed automatically.

There are two methods for passing the password to the utility.

The first method echo's a variable to the SU utility. The variable is best defined via the "environment" tab of the application object. The variable can be defined and assigned a value that will only be available during the execution of the NAL application. This will prevent users from seeing the value of the variable.

/cecho pwd|su.exe userid "command" ms_domain

The main drawback to this method is that someone could access the application object and read the password from the application object.

The second method of passing the password is redirecting a text file into the su utility.

su.exe userid "command" ms_domain <f:\passwds\userid.txt

The network directory containing the password text files should be secured so that no users have access to this directory. Then assign workstation objects the rights to read this directory. The application would need to be run as a ZEN 2.0 application using "unsecure system user" to be able to read the text file with the assigned restrictions. This is a major drawback since on advantage of the SU utility is that it can give you ZEN2.0 capabilities without ZEN 2.0. The advantages to this method is that you would be able to call an "unsecure system" application that had access to NT resources or to run an application that does not function properly while running the via the system account, such as control.exe.

By using the full version of ZEN 2.0, not the starter kit, you are able to assign applications to run as either "secure system user" or "unsecure system user". These applications are executed with the authority of the workstation's system account. A "secure system user" application will not be able to interact with the user. It must run without any prompts from the user and it will not be visible to the user while it is running. The "unsecure system user" allows for the user to interact with the running application.

An application running as either a "secure system user" or an "unsecure system user" will not be able to access the logged in user's rights. This means by default that any application defined as a "system user" will not be able access any application sitting on a network drive. To access applications on the network drive, the workstation object must be assigned the necessary file rights.

One such utility is the REMADDR.EXE utility for clearing stuck network addresses. This utility requires administrative rights to the user object if the action occurs against a replica on a Netware 5 server. Since granting full administrative rights to the helpdesk for our user objects is not desirable, I have begun using the SU utility to grant the helpdesk staff NDS administrative privileges in a fashion that they cannot use outside of the NDS application.

The process actually uses 2 NAL application objects. The first NAL object creates a batch file, which runs remaddr.exe with the user ID to clear. This is done by using a prompt macro to request the user ID and then using the text file function to build the batch file with the name entered. The second NAL object calls the first application object using either the SU utility with a user account that has necessary rights or the user objects or using the "Unsecure System User" with ZEN2.0 and assigning the workstation object sufficient rights to the user objects to perform the actions.