File Permissions in ASP

File Permissions

When running an APG script from an ASP page, ensure the APG script has proper create and write file permissions, for both Output files and Log files. When an APG script is run from an ASP page, the APG script runs in the same security context as the ASP page. So, if the ASP security context (normally IUSR_MachineName) does not have file write permissions, by default the output or log file will not be generated.

If you run an APG script from an ASP page using default security settings, an error may occur when content is first written to the output file:

This error occurs when APGen tries to create or write a file using the anonymous user security context. By default, ASP pages are run in the anonymous user (IUSR_MachineName) security context. And by default, IUSR_MachineName does not have permissions to create and write files in web server directories.

There are several solutions to this problem:

Use authenticated access for the ASP file that runs the APG script. To use authenticated access, disable anonymous user access. You can do this in the Internet Services Manager by right-clicking on the ASP file, choosing properties, and then under the "File Security" tab click the "Edit..." button for "Anonymous access and authentication control". Then, uncheck the "Anonymous access" checkbox for the ASP file. After disabling anonymous access, only authenticated users will be able to view/execute the ASP. If the authenticated user has permissions to write files in the web site directory, the APG scripts will run successfully. If the authenticated user does not have permissions to write files in the web site directory, APGen will once again raise an error when it first tries to write to the output file.

This solution is used on the build.asp page in the <install dir>\Examples\awe_apg\ example. Since only administrators should be able to rebuild the web site, this solution is appropriate.
Give IUSR_MachineName Full Control, Modify, or Write access to the web site directories where generated content is placed. This requires an NTFS file system. To give the anonymous user account the necessary priviliges, right click on the web site directory in MS Windows Explorer. Go to the Security tab, click the "Permissions..." button, add the IUSR_MachineName user, and add "Write" access for IUSR_MachineName.

This solution is used in the <install dir>\Examples\DiscussionBoard\ example. Since any anonymous user should be able to add posts to the discussion board, this solution is appropriate. To limit the scope of the permissions, only the \forums\ directory (and all subdirectories) is given additional user permissions.
Use the APGen.Logon, Output.Logon, and/or Log.Logon objects to specify the user account used to create/write the file. Ensure that this account has Write permissions in the output and log directories. This solution is discussed in detail below.
Write a COM component that uses the APGen COM component, and install this wrapper component in a COM+ Server application or MTS Server package. Any user account can be specified to run this process, using the Component Services Add-In or the MTS Explorer Add-In. This solution runs the APGen component in its own process, using the specified user account. The user account should have write permissions in the output and log directories. All access to the wrapper component is via DCOM. For more information on this option, see Running APG Scripts in MTS and COM+.

Any of these solutions can meet the security needs of generating files from ASP. If all users should be able to create and modify web pages using APGen via ASP, use solutions 2, 3 or 4. If only select users can create and modify web pages (and if you want to use Windows authentication), use solution number 1.

File permissions for log files are not as critical as file permissions for output files. If a log file cannot be written to, the log entry is written to the system Event Log. You can also specify that all errors be written to the Event Log (regardless of file permissions) by setting Log.Flags to apgEventLogErrors or apgEventLogFatalErrors.

Using the Logon Object

The Logon object is used to connect to a network share, or to impersonate a user when creating local files. Usage is straightforward. This ASP page runs an APG script, and the output file is generated using the APGen_User account:

<%
Option Explicit

' Create an APGen object
Dim oAPGen
Set oAPGen = Server.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 = "\\wg1\share\" ' network share< BR >
' Execute the APG script
oAPGen.Run Server.MapPath("default.apg")

%>
<h2>APG Script Executed</h2>

There are a few things to be aware of when using the Logon object in an ASP page:

When writing to a local drive, Win32 APIs LogonUser() and ImpersonateLoggedOnUser() are used to impersonate the user before writing the file. LogonUser() requires the process to have the "Act as part of the operating system" privilege, otherwise an Access Denied error is returned. IIS runs in the SYSTEM account, which has this privilege. Out-of-process web applications are run in the IWAM_MachineName account, which does not have this privilege (see Q232513 - PRB: LogonUser Fails in ISAPI Extensions ). Thus impersonation does not work in out-of-process web applications.
When writing to a network share, the Win32 API WNetAddConnection2() is used to connect to the network share before writing the file. WNetAddConnection2() does not require the "Act as part of the operating system" privilege, so it works in out-of-process web applications.

When using APGen and the Logon object in an ASP page, we recommend that you write to network shares instead of to local directories. Even network shares on the local computer can be used.

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

' Set the output directory
oAPGen.OutputDir = "\\wg1\share\" ' network share - GOOD!

Using the Logon object while writing to a local drive can be problematic if the web application is run outside of the IIS process:

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

' Set the output directory
oAPGen.OutputDir = Server.MapPath("output") ' local drive - May be a problem!!
' IMPORTANT: If this ASP page is run in an out-of-process web
' application, logon and impersonation will fail.

For additional information, see the Security topic.