ÉÍÍÍ» ÉÍÍÍÍÍÍÍ» (WS) º º º º º º ɼ È» º º º º º º º ÌÍÍ ÌÍÍÍÍ͹ ÉÍÍÍÍÍ» ÌÍÍËÍÍÍͼ º º ÉÍÍÍÍÍ» ɼ È» º º º È» º º º º º º º º º È» º º ÌÍÍÍÍͼ º º º º º È» º º º ÌÍÍÍÍͼ ÈÍÍÍÍÍ º º º * Syntax Overview: ApRite [parameters] ApRun Accepted parameters: ApRite /Install Initiate or re-initiate application system ApRite /Destroy Delete/Remove the complete application system ApRite /Masters [+|- ] List/Define accepted application users ApRite /SLaves [+|- ] List/Define users that are accepted as slaves ApRite /Admin [+|- ] List/Define application system administrators ApRite /Allow command Allow [user] access to specified command ApRite /Remove Remove application from application system ApRite /SHow Show status and list current allowed commands ApRite /STatus [Masters|Slaves Pause|Cont] Show or change application system status ApRite /? Display syntax overview * ApRite / ApRun : Application System - Description Purpose: Grant rights to applications: Run applications with NetWare rights that differ from the rights of the person calling the application. The complete system is based on NetWare security. Features: - Allow users to change user ID while 3rd party applications are run. - Multiple security levels based on NetWare security. - Management tool to administer and view the ApRite security. - Built-in self test for virus infection. Author: Wolfgang Schreiber (all rights reserved) Components: ApRite.EXE Administration tool ApRite.DOC Documentation ApRun.EXE Launch applications * Quick Start: Within 5 minutes you can get a quick impression of the capabilities of ApRun: 1) Initiate ApRun: "ApRite /Install" 2) Give a second user (e.g. GUEST) the right to run SYSCON in your name: "ApRite /Allow SYSCON GUEST" 3) Login as GUEST and run SYSCON (with/without ApRun): "ApRun SYSCON" If you want to remove GUEST's privileges you have two choices: 4a) Login as Supervisor and revoke the privileges: "ApRite /Remove " [Insert appr allowance nr] 4b) Remove GUEST from the list of accepted masters: "ApRite /Master - GUEST" * License: The publisher has thoroughly developed and tested the functions of ApRun/ApRite but cannot take any liability for adverse effects or damage that might be caused by software malfunctions, erroneous or incomplete documentation. Orders can be sent directly to the publisher. International distributors wanted. Retail price: US $199 for first file server, US $ 30 for additional server licenses * Demo Version The 3 files APRITE.EXE, APRUN.EXE, and APRITE.DOC may freely be copied to other file servers. But since ApRite is a commercial application, unlicensed users may only have a 60 days testing period. Within this period users can test all features of ApRite on any number of file servers. About 60 days after its installation on a server it will disable itself. When the demo time is over, only the options "ApRite /?" and "ApRite /Destroy" will remain active. Warning: if the demo version detects a file server date change it might disable itself immediately. * Publisher: Dr. Wolfgang Schreiber Schanzenstr. 74 4000 Dusseldorf (Germany) Fax: (xx49) - 211 - 55 64 69 Any comments, suggestions, or error reports are welcome. Users who detect bugs and document those bugs to the publisher will be the first to receive the next release of the application. Written in Borland's TurboPascal v6.0 * Concepts: ApRite is using a concept called 'Application System' and its implementation in based on the NetWare concept of a 'Job Server'. ApRite uses the terms 'Application System', 'MASTER', 'SLAVE', 'ADMINISTRATOR', 'COMMAND', and 'OPTIONS'. Usage of those terms must be explained shortly. Application System: The term 'application system' is used to describe the complete environment supplied by ApRite and ApRun to support rights granted to applications. The application system must be initialized by the Supervisor or an equivalent before users can access it. To explain the other concepts we will refer to some command lines as examples (assumed that U_M and U_S are valid user names): 1) "ApRite /Allow SYSCON U_M" issued by U_S (Slave) 2) "ApRite /Allow FILER" issued by U_S (Slave) 3) "ApRun SYSCON" issued by U_M (Master) SLAVE: A slave is a NetWare user who grants his/her NetWare rights to a master, whenever the master will call a specified program. A slave must have been admitted to the application system by the SUPERVISOR ("ApRite /SLaves ..."). The slave must have specified the commands (and its accepted masters) that can be run in his/her name, before any master can run an application in the name of a slave, ("ApRite /Allow "). In the example given above the user U_S gives the user U_M the right to call SYSCON (command 1) - this means that U_M will get the rights of U_S while running SYSCON. Then U_S allows every legitimate application system master to run FILER with the rights of U_S (command 2). MASTER: A master is a NetWare user who is logged in to a NetWare file server and wants to run an application with different rights than those that he usually has. Masters must have been admitted to the application system by the SUPERVISOR ("ApRite /Masters ..."). A master can issue a program call with the rights of a 'slave' if the slave has allowed (this master) to run an application in his/her name. COMMAND/OPTIONS: A standard DOS command line usually contains the (path and) name of an executable command with or without additional options/parameters). The term 'Command' in this script includes all characters up to the first blank in the command line. It consists of an optional valid DOS path followed by a file name and it may include the extension of the application. The term 'Options' refers to everything that follows the first blank in the normal DOS call. ADMINISTRATOR: An application system administrator can view and change the status of the application system. The administrator can see all allowed applications, can remove specific applications from the system, can halt or restart the system. By default only the person who installs the application system is created as system administrator. New administrators can be defined by the supervisor ("ApRite /Admin ..."). * Installation and Usage: - Read the READ.ME file from the installation disk for information about the first steps; - Copy all files from the installation disk to a NetWork directory; - Setup the system by calling "ApRite /Install" - Define legitimate slaves with "ApRite /Slaves ..." (Users who give their rights to applications) - Define legitimate masters with "ApRite /Masters ..." (Users who receive new rights in applications) - A legitimate slave grants application rights with "ApRite /Allow ..." - Legitimate masters now can call "ApRun" to start the admitted applications. * Security: The application system includes several layers of protection to ensure that only accepted users get access to the system: - only a Supervisor (or eqivalent) can initiate the system; - only specified users can get access to the system; they must have been admitted to the system as 'slaves' or 'masters' by the supervisor; - the user ('slave') who gives his rights to other users ('masters') must actively allow those users access to specified applications; - only the specified applications can be called; use of these applications can be restricted to specified persons; - the master can call the selected applications only if those applications have not been changed since access was granted; - the supervisor or administrator can monitor and change the current status of the application system. - the supervisor or an assigned 'administrator' can remove specified applications from the system; - The automatic self test for virus infection will display a warning if ApRite.EXE is infected by a virus. * Multi-Server Environments The application system is always file server specific: ApRite will define how rights may be changed on the current server. ApRun will change the rights only for the current server. The current file server is defined by your current default drive letter. ApRun will always modify rights on a single server: the server of your default drive. * Syntax: ApRite [/parameter] All options of ApRite can be abbreviated as long as those shortcuts are unique: "ApRite /I" or "ApRite /SH" are valid shortcuts. This overview presents optional parameters within square brackets "[xxx]", user supplied names (e.g. user names or commands) in angle brackets "". Upper vs. lower case letters do not make any difference. * ApRite /? Display syntax overview This command give an overview over the features and available parameters of ApRite.EXE with basic explanations of their effects. Example: ApRite /? * ApRite /Install Initiate or Re-Initiate application system Before using any of the following ApRite parameters the application system has to be established. The installation procedure will only take about a second and will initiate security and all relevant variables. None of the ApRite/ApRun application parts stays resident in a workstation's RAM. The application system uses similar bindery security as NetWare itself; it will store security information in the NetWare bindery. WARNING: If "ApRite /Install" is issued a second time, it will completely reset the application system: all masters, slaves, administrators, or information about accepted applications will be removed. You will be asked for confirmation if the application system is already installed. This option is for supervisors only. Example: ApRite /Inst * ApRite /Destroy Delete/Remove the complete application system This option can be used to completely remove the application system structure from your file server. The only way to recover from the effects of "/Destroy" is to restore the file server from a previous backup. This option is for supervisors only. Example: ApRite /Dest * ApRite /Masters [+|- ] List/Define accepted application users See the discussion of the master-slave concept above. Masters are NetWare users that are allowed to take the identity and rights of a 'slave' while a program is executed. Only the users admitted to the application system as masters are allowed to run applications with the temporary ID of a slave. Before a slave can specify a user as master (that means before he/she can allow a master to run the application in the slave's name) the supervisor must have admitted both slave and master to the application system. This is done with "ApRite /Slaves ..." and "ApRite /Masters ..." Specifying '+' will add new masters, '-' will remove existing masters. Users and groups can be accepted as masters. If a group is specified, ApRite will add or remove each group member individually: the call "ApRite /Masters - everyone" will remove all masters. A slave with supervisor rights can implicitly add masters with the "/Allow" option (see there). This feature applies to supervisors only. Example: ApRite /Master + guest ApRite /Master - everyone ApRite /Ma + guest * ApRite /SLaves [+|- ] List/Define users that are accepted as slaves See the discussion of the master-slave concept above. Slaves are NetWare users whose rights are granted to a master while a program is executed. Only the users admitted to the application system as slaves are allowed to transfer their rights to a application user (master). Before any slave can allow an application to be run in the slave's name, the supervisor must have admitted the user as slave to the application system. This is done with "ApRite /SLaves ..." Specifying '+' will add new slaves, '-' will remove existing slaves. Users and groups can be accepted as slaves. This option is for supervisors only. Example: ApRite /Slave + guest ApRite /Slave - guest ApRite /SL + everyone * ApRite /ADmin [+|- ] List/Define application system administrators An administrator can monitor the status of the application system, view the list of accepted slaves, masters, and applications, and remove specific applications from the system. The administrator is comparable to a queue operator in the printing environment. Specifying '+' will add new administrators, '-' will remove existing administrators. Users and groups can be accepted as slaves. This option is for supervisors only. Example: ApRite /Admin + guest * ApRite /ALlow [command []] Allow [user] access to specified command The option "/Allow" enables a slave to specify, what command is allowed to be executed in his/her name. This option adds the new command to the list of accepted commands. An accepted master is thereby enabled to run this command in the name of the slave. The command must contain at least a valid filename; it may include an optional drive/path specification and/or extension. ApRite searches for the specified command file to add it to its list, so the application must be in the default drive or in one of the search drives, if no path is specified. The specified command can be located on a local drive or second file server, but the rights change will always affect only the current default server (i.e.: the server where the default drive is located). If the application (and optional master) is accepted by the system, it will display the new list of accepted applications. Each registered application automatically receives a unique application ID. This ID can be used to remove specific applications from the system (if desired). All valid file names will be accepted, but only COM, EXE, and BAT files give sense. To use the parameter "/ALLOW" the user must be in the list of accepted slaves, and he/she needs search/file scan rights in the directory of the specified command. If no user is specified after the command, the application can be started by any accepted master. If the specified user is unknown or not accepted as master the command will not execute. If a supervisor equivalent specifies a user who is not a registered master yet, the system will automatically add the user to the master list. If "ApRite /ALlow" is not followed by a command, it will list the current accepted applications entered by the user. Only users - no groups - can be accepted as masters. This option is for supervisors and accepted slaves only. Example: ApRite /Allow syscon ApRite /Allow syscon.exe guest ApRite /Al k:\sub\this.bat guest * ApRite /Remove Remove application from application system Every entry in the list of accepted applications can be identified by its entry ID. The IDs are constants and are assigned by NetWare. Applications can be removed from the system list by a system administrator or by the slave who added the entry to the list. This option is for supervisors and administrators only. Example: ApRite /Remove 473 * ApRite /STatus [Masters|Slaves Pause|Continue] Show or change application system status Comprehensive system status information is displayed. In addition to the status display a supervisor or administrator can change its status. You can determine if slaves may add new jobs to the application system, or if masters may access the application system to acquire the slaves' rights. 'ApRite /Status Masters Pause' will de-activate the application system without destroying any of the stored information: Currently active ApRun applications can be continued, but no master can start new ApRun commands. 'Continue' will re-activate the application system. 'ApRite /Status Slaves Pause' will prevent slaves to add new applications to the application system. Masters still can access the system to acquire the slaves' rights. All exixting information will be kept. Examples: ApRite /Status ApRite /St Masters pause ApRite /St Slaves Cont * ApRite /SHow Show status and list current accepted applications '/SHow' will not only display the short status report, but additionally list the current accepted slaves, masters, administrators, and applications. This option is for supervisors and administrators only. Example: ApRite /Show * ApRun [parameter list] Run applications with another identity If an accepted master wants to start an accepted application in the name of a slave, the command must be launched by ApRun. Without ApRun the application would run with the default rights of the program caller. The command can be followed by the parameters as required by the launched application's syntax. Use the normal command syntax, and simply add 'ApRun' at the beginning of the command line. Masters who want to launch applications need Search/File Scan rights in the application directory. If the command is not to be found in one of the master's search drives, it must include a drive/path specification. ApRun.EXE will use approximately 25 Kb of the workstation RAM while the launched application is running. It therefore limits the RAM available to that application. Since ApRun is not a TSR program it will not stay in the workstation memory except during the execution of the launched program. This option is for accepted masters only. Example: ApRun SYSCON ApRun NCOPY Z:*.* k: /sub ApRun C:\this.bat par1 par2 * Limitations: Due to NetWare limitations and ApRun's implementation there are several aspects administrators should keep in mind. - Number of application configurations: The list of accepted application/rights configurations may include up to 250 entries. - Number of slaves running ApRun simultaneously on one file server: 250 - Memory: since ApRun.EXE has to stay in memory while it changes the rights of a master to the rights of the slaves, and since it has to stay active until the original rights are restored, there is only a restricted area of RAM available to slave applications. Generally ApRun.EXE takes about 25 kB of RAM during the execution of slave applications. The RAM available to applications will be higher if those are COM or EXE files, a little less with BAT files (since ApRun uses COMMAND.COM to run batch jobs). If memory is a problem, you might consider to use 3rd party memory manager (like HIMEM, EMM386, or QEMM386) to load some drivers and TSRs to high memory areas. DOS v4.x will usually leave less memory to applications than DOS v3.x or v5.x. - Multitasking: if ApRun were used in a multitasking environment, ALL tasks would change to the slave's identity as long as one task runs an application with ApRun. Similar considerations apply to task switching environments like DR-DOS v6.x or MS-DOS v5.x. To avoid bypassing of NetWare security, ApRun will not run under Windows or in other multitasking environments. - TSR programs: The complete station of the master will receive the rights and identity of the slave during program execution. Obviously this will affect TSRs that have been loaded previously, too. Therefore TSRs might in some cases represent a breach in security since they receive the same rights as the legitimate application. In most situations this will not be a problem. - Application Updates / Program changes: If a slave allows access to an application ApRun tries to ensure that this program is run without any changes. Future masters can run the accepted application only in its current form (for security reasons). Any changes to the program will prevent masters from being able to start that application. The slave has to re-allow access whenever an application is modified. - NetWare bugs: Due to a NetWare bug few NetWare commands (e.g. SETPASS) will not execute with the ID of the SLAVE but with the ID of the MASTER. This will only affect commands that use a specific NetWare API (GetConnectionInformation). Most commands however will work as expected and run with the ID of the SLAVE. Novell is aware of this bug in NetWare v3.11 - and hopefully fix it in a future NetWare version. Due to the above mentioned limitations the following suggestions are strongly recommended: - Create special users who only have the rights to run one application. The trustee rights of those users might include only a single directory. Accept only those user names as slaves. Take into account that background applications (TSRs) receive the slave's rights, too. - Specify the name of the acceptable master in the 'Allow' command whenever possible. This is especially recommended if the slave has supervisor rights. * Troubleshooting General Problems Problem: An application is not executed though it has been installed with 'ApRite /Allow ...' Possible Causes: - The user does not have a search path to the application or does not have sufficient rights (File Scan/Search rights may be enough). Solution: Check the user's path and rights. Problem: A virus warning is displayed. Possible Causes: - ApRite has a built in virus self-test. A virus might have infected your system. - You have different versions of ApRite on your system. Solution: Run a virus scan utility immediately. * Error messages Message: 'Application list full' Possible Causes: The application system can save up to 250 applications. You exceeded this limit. Solution: Delete some unneeded applications from the list with 'ApRite /Remove'. Message: 'Application System not yet initialized' Possible Causes: ApRite is not yet installed on this server Solution: Install ApRite. Make sure that you have one license per file server. Message: 'ApRite-Demoversion. Valid only .. days' Possible Causes: - You do not have a full version of ApRite but a limited demo version on this server. The time limit has expired. Solution: Purchase a full license. Possible Causes: - On a multi-server system you try to run ApRite on another server than the one that you installed ApRite on. You may use ApRite for the demo period but have to purchase a license for every server that you permanently want to install ApRite on. Solution: Purchase a full license. Message: 'Could not access Application System' Possible Causes: ApRite is not yet installed on this server Solution: Install ApRite. Make sure that you have one license per file server. Message: 'Demonstration time for ApRite on ... expired.' Possible Causes: You do not have a full version of ApRite but a limited demo version on this server. The time limit has expired. Solution: Purchase a full license. Message: ' is no accepted MASTER' Possible Causes: You tried to run ApRun but your are not accepted as application master. Solution: Ask the supervisor to install you as ApRun master ('ApRite /Master ...'). Message: 'Multitasking active' Possible Causes: You tried to run ApRun in an multitasking environment (e.g. Windows, DesqView, Task Switcher). Due to security considerations this is not accepted. Solution: Start ApRun in a single task environment. Message: 'Only a Supervisor can call this function !' Possible Causes: Some functions of ApRite are reserved for Supervisors and equivalents. Solution: Login as supervisor and retry. Message: 'Wildcards not acceptable' Possible Causes: You tried to run 'ApRite /Allow' with wildcards. Solution: Use only one application per command.