Security

File Security

File permissions are important to consider when running an APG script: Does the process or thread running the script have proper permissions for writing the output files and log files?

Service processes typically run in the local SYSTEM account, though individual threads may use impersonation to run in other accounts. The SYSTEM account has access to all local files, but has no access to network resources. For service processes that write files to network shares, security must be explicitly set.

Interactive user processes (programs run from the shell or from the command line) run as the logged on user. The logged on user's permissions are used by any interactive processes started by the user.

To lock down a system, it is a good idea to run service programs in a user account, and give that user access only to the resources needed by the program.

In addition to the normal options for programming security, APGen provides the Logon object for setting the user account used to write files. The APGen.Logon, Output.Logon, and Log.Logon objects are provided for setting the account used to create all files, or specific output or log files.

The Logon Object

The file stream (the default stream, used for creating output files and log files) uses impersonation or network connections to write files using the Logon account. If the file is written to a local drive, impersonation is performed before writing the file, using the Win32 APIs LogonUser() and ImpersonateLoggedOnUser(). If the file is written to a network share, a network connection to the share is created by passing in the Logon settings to WNetAddConnection2().

LogonUser() performs a security check, and fails (with Access Denied) unless the process is run in an account with the "Act as part of the operating system" privilege. The local SYSTEM account, and other service accounts are typically the only accounts with this privilege. Notably, the IWAM_MachineName account (used for running out-of-process web applications - see Q232513 - PRB: LogonUser Fails in ISAPI Extensions) and most user accounts do not have this privilege. This means that the file stream's impersonation feature for local files will not work in out-of-process web applications, or in APG scripts run from the shell.

If this limitation becomes a problem, solutions include:

Give the user account, that the process is running in, the "Act as part of the operating system" privilege. Consider the security ramifications of doing this before proceeding.
Write to a share instead of directly to a local drive (shares can be on local computers or network computers). The syntax for writing to a share is:
' Create an APGen object
Dim oAPGen
Set oAPGen = CreateObject("APGen")

' Set the logon properties
oAPGen.Logon.User = "APGen_User"
oAPGen.Logon.Password = "pass"
oAPGen.Logon.Domain = "domain"

' Set the output directory
oAPGen.OutputDir = "\\server\share\subdir\" ' write to a share

... ' Run some APG scripts
Connecting to shares (even local shares) does not have the security limitation that impersonation does.
Write a COM component that uses the APGen COM component, and install this wrapper component in a COM+ or MTS Server application. A user account can be specified to run the component's process (all access to the component is via DCOM). When using this approach, the Logon object is unnecessary. For more information on this solution, see Running APG Scripts in MTS and COM+.

Web Server Security

APG scripts contain source code that should be considered sensitive information. Obviously this information should be hidden from web site users. We recommend that you either:

Store APG scripts in a directory that is not visible to the web server (not a subdirectory of the web site). Or
Store APG scripts in a subdirectory of the web site, and use the IIS management console to disable all web access to that subdirectory. Most of the Examples shipped with APGen use this technique to secure the example.

Security on Web Farms

In a web farm scenario, we recommend using domain level security behind a firewall, so each server has the same user accounts. The goal is to keep the web servers homogeneous, and domain security does this.

Also, we recommend writing APG script output to Windows 2000 DFS shares. That way the file system is not dependent on individual computer names.

Debugging

APGen implements Microsoft's Active Script Debugging to provide debugging of APG scripts. APG scripts can be debugged in interactive and non-interactive processes. When an error occurs in an APG script, and debugging is enabled, a pop-up allows the user to debug the script. We recommend that debugging be disabled (see APGen.Debug) for production applications.

There is a security requirement for debugging - debugging requires the "Debug Programs" privilege, which is normally given to the Administrators group and the local SYSTEM account. If a process or thread is running in a user account without this privilege, APG script debugging will be disabled.