Securing a Web-based MS Transaction Server Application

By Michael Morel

Microsoft Consulting Services

On This Page

Introduction
Application Security Flow
Recommendations
Moving to the Internet
Further Reading

Introduction

Purpose

The Microsoft BackOffice™ family of products offers the framework for robust and secure three-tier and web-based applications. However, setting up security in such an environment can be a complex topic. It is not uncommon that a team develops and thoroughly tests an application on a server to which the team has full access. To the team's surprise and embarrassment, the application encounters a great number of security-related problems once moved to a production server, often making the application appear as if it was not tested at all!

This document attempts to explain how security works in a typical web application. While the security models in each of the BackOffice products are documented individually, this paper will show how all of the models fit together very nicely as one integrated security package. Rather than covering each product in detail, I will concentrate on how the products work together, and provide references to detailed product information. Finally, I will make some recommendations on how to set up your server to avoid problems.

The Reference Application

This document describes security considerations in a "typical" BackOffice web-based application. The reference application in the sections that follow is an "intranet" application, where users are connecting to the server over the corporate network. All of the security concepts presented in this paper apply equally to Internet applications. The difference is that in an Internet application, users typically do not have Windows NT accounts on the server's domain, so they all appear as the "anonymous" user, and must gain access to all resources as this user.

This typical application has the following attributes:

• Clients access the application using a browser. For Internet applications, the browser might be one of any number of browsers. For intranet applications on the corporate network where Windows NT validation is required, the browser must be capable of Windows NT Challenge / Response authentication, i.e., Internet Explorer 3.02 or greater.

• Server-side logic is implemented in Active Server Pages (ASP), driven by Internet Information Server (IIS) 4.0.

• Much of the business logic is implemented as server components, some of which run under Microsoft Transaction Server (MTS) 2.0. Some of these components consume the services of other components.

• Microsoft SQL Server 6.5 is used for data storage. All business data access is done through the components.

Although the typical application describes a web-based application, many of the points apply equally to a three-tier application with a Windows client accessing server components using DCOM.

Application Security Flow

The table on the next page summarizes the flow of the reference application, in terms of security. The first column shows the security context under which pieces of the application run. Subsequent columns show how each piece of the application takes part in the security flow. The sections following this table will further explain how each product contributes to the overall security picture.

In the table example, three components are created. They are described as follows:

IIS and NTFS (Steps 1 through 7)

The first security barrier that an application user must scale is access to the application scripts and HTML files. Scripts cannot be executed, even HTML cannot be sent to the requesting browser, until the user gains access to the files. Steps 1 through 7 in the table describe the interaction between the browser, IIS, and NTFS.

If your IIS installation allows anonymous access, when a user first enters a web application, that user is "anonymous". That is, IIS does not know who the user is. Every anonymous user is assigned the same Windows NT user id. By default, that user name will be "IUSR_Machine Name", where Machine Name is the name of the computer on which IIS is running. For our discussion, we'll call this user IUSR_WWW.

When the browser requests an application file, for example, DEFAULT.ASP, IIS tries to read the file on the user's behalf. This request is sent to the file system, NTFS. NTFS checks to see if the user, IUSR_WWW, may read the file.

In this example, the application is an intranet application, its access restricted to only certain users on the domain. So you need to get the user name of the actual user, not the anonymous user. To do this, make sure that IUSR_WWW cannot read the application file (DEFAULT.ASP). If NTFS rejects the read request, IIS sends a challenge back to the browser, and the browser responds with the user name of the "real" user.

Assuming the user is a valid user of the application, this time when IIS tries to read the application file, NTFS grants access. From this point on, IIS operates as the validated domain user.

With IIS 4.0, you can eliminate the use of the anonymous user altogether for your application. Just disable anonymous authentication in the IIS "Directory Security" properties for the virtual directory. IIS will issue a challenge to the browser immediately, before attempting to access any files. With previous versions of IIS, you could disable anonymous access, but it had to be done on a per-server basis, not per virtual directory.

Of course, there may be applications that allow anonymous access. To allow for anonymous access to an application, simply make sure that IUSR_WWW has been granted access to read the application files. However, remember that you cannot have it both ways. If IUSR_WWW has access to the files, IIS will never challenge the browser, so even validated domain users will always come in as IUSR_WWW.

Creating Non-MTS Components in ASP (Steps 8 through 10)

Once the Active Server Script file is read by IIS, the ASP engine executes it. One very common operation in ASP scripts is to create and use some component. Some components may run under the control of Microsoft Transaction Server, and some may not. First, let's look at those components not installed in ASP.

Typically, general system components will not be installed in MTS. For example, ADO or ActiveX Messaging Objects might be used to access data or send mail messages. These are not installed in MTS.

This is a very common place for permission problems. Most people remember to grant the proper file access to their application directory, but it is easy to miss the components. The domain user must have access to all of the files that get loaded on the server when an object is created. This will almost certainly include the \WINNT\SYSTEM32 directory, where supporting DLLs are located. For ADO, the user must have access to the ADO and OLEDB component directories ( \Program Files\Common Files\System\Ado and \Program Files\Common Files\System\Ole DB by default).

Note that you may not invoke remote components directly from an ASP script. This is because while IIS executes the script under the authenticated user's identity, it restricts access to the network1. This does not mean that you cannot access network resources at all, however. You can create a "helper" component that will access the remote component, and install this component in a local MTS package. When setting the identity under which this package will run, make sure the package account has the required access to the remote component(s).

Note: If you are using Microsoft Access in a web-based application, the server must define a directory for temporary files, and the user will need write access to this directory. Please see Microsoft Knowledge Base article 164535 for details.

Using MTS Components

Creating MTS Components (Steps 11 through 15)

The business components used in the application are typically installed into Microsoft Transaction Server. MTS provides a complete security model to prevent the unauthorized use of components and, by association, enterprise data.

When the ASP script attempts to invoke methods on an object under MTS, the method call will not proceed until MTS checks to see if the user is allowed. Remember, when the script is running, the security context is that of the validated domain end-user.

If package security is enabled under MTS, MTS checks that the user belongs to one of the roles on the package. The Windows NT user may be directly added to a role, or may belong to a Windows NT group that has been added to the role.

Role-based security may be set for individual components within a package, or even for interfaces implemented by a component. See the Assigning Roles to Components and Component Interfaces in the on-line Microsoft Transaction Server Reference for more information.

Once MTS determines that a user may call a component, MTS runs the package that contains the component. This package should be run under the identity of a special Windows NT user created specifically for the package. In the example, the Windows NT account used by PkgB is called MTSPkgB. From this point on, any access by the component is done through this new Windows NT user id.

SQL Server Access by MTS Components (Steps 16 through 18)

When an MTS component requests database access, it does so under the user id of the package (user MTSPkgB in this case). No matter who the end-user is, the database only sees the package identity. This approach to database security has a number of advantages:

• Since the user does not login directly to the database, all database access can be totally encapsulated by the business component. This ensures data integrity.

• Since multiple concurrent users all connect to the database in the same way, MTS can use connection pooling to reduce the load on the database, thus improving scalability dramatically.

• Because each user does not need a login to the server, it reduces administration when setting up application access.

• Instead of thinking about end-user security in terms of databases and tables, MTS allows you to think about security in terms of the roles that an individual plays in the organization. This is a much more natural way of administering security.

SQL Server should be setup to allow Integrated (or Mixed) security. Then each package identity should be mapped to a SQL login. This login should then be given the proper access to databases and database objects.

Cross-Component Access (Steps 19 through 24)

In our example, component B creates an instance of component C and relies on the services of component C to get some of its work done. These two components have been installed into MTS under two different packages.

The first thing you might try to do is add the end-user to a role on package C. However, it is not the end-user that requests the services of component C. This component is created from within component B, and when PkgB runs, it does so under the user id MTSPkgB. This is the user that must be added to a role on PkgC.

Likewise, if component C must access the database, then the PkgC user id (MTSPkgC) must be mapped to a SQL login. Component B does not need to have direct access to component C's data. Component B is very much a client of component C, just as the end-user is a client of component B.

Application Role-Checking (Steps 25 through 27)

For a very fine degree of control, an application can also specifically check role membership before performing some operation. In the example, the script (running as the end-user) executes a method intended for administrators only. The component calls the context method IsCallerInRole to determine whether the caller is an administrator, and proceeds based on the answer.

IsCallerInRole always checks the direct caller, just like the normal MTS access checks. So, if component C calls this function, it will be checking the role membership of the MTSPkgB (the direct caller), not the end user. In fact, the end user is not even in a role on PkgC. This is consistent with the discussion of cross-package access, above.

Recommendations

Keeping in mind the flow of security contexts in a three-tier application, this section presents some recommendations for deploying a secure application that is also easy to administer. The names used here for users and groups are really not important, as long as you consistently follow whatever naming standards you set.

General

• If it is at all possible, a Quality Assurance server should be used for staging applications, before moving them to production. This server should have the same security settings as the production server on which the application will ultimately run. These security settings include NTFS permissions, MTS Roles, and SQL Server users. Without such a server, there is a very good chance that an application that runs fine on a developer's machine will encounter permission problems when put into production. When testing an application on the QA server, be sure to login as a user that is not a member of the Administrators group.

• MTS provides a flexible and robust model for role-based application security. However, it is important that security is considered while designing an application. It is the developer who determines what the roles are in an application, and allows operations on the data based on role membership. The only security consideration that occurs at deployment time is which Windows NT users belong to which roles.

• If your application has any requirements for auditing, you must design for this in your business components. Database auditing will not be useful under this security model, because all users access the database through the same user id (the package's account).

• To implement logging in your component, use the GetOriginalCallerName method. This returns the Windows NT name of the end user, even if the component was called directly by another component. For example, in the reference application, if component C keeps a log of all modifications to business data, it can use GetOriginalCallerName . The return value will be the name of the end user, not the name MTSPkgB, which is the direct caller. The call might look like this:

  Dim sModifiedBy as String
   sModifiedBy = GetObjectContext().Security.GetOriginalCallerName()
  

Users, Groups and Roles

• In this discussion the user anonymous user (IUSR_WWW) should be treated as any other application user. The only difference is that more than one end user will map to IUSR_WWW.

• The end users of an application should gain access to all resources through membership of a Windows NT group. End users should not be directly granted access to any resource (databases, files, or Microsoft Transaction Server components).

• At least one Windows NT group should exist for every application. If there are differing roles in an application, which require different levels of access to resources, then there should be a Windows NT group for each of these roles. For example Bank Tellers and Bank Managers .

• In MTS, every package should have at least one role. If there are differing levels of access, then there must be a role for each type of access. For example, Tellers and Managers on the Bank package.

• Use MTS Explorer to associate the Windows NT groups with MTS Roles. Once this is done, to add a new user to the application, the Windows NT user must simply be added to the Windows NT group. This is an operation that security personnel are already familiar with.

• Create a Windows NT group called MTS Packages . For each package account that you create, add it to this group. This is just for convenience when mapping a Windows NT user id to a SQL Server login using the SQL Security Manager.

  Create a Windows NT account for each package to run under. You may want the account name to start with "MTS", and contain the package name in it. For example, MTSBank . This account should be setup as follows:

  • User Cannot Change Password

  • Password Never Expires

  • Belongs to Users (and any other groups your application may require)

  • Log on as a Batch Job user right

  • Set and remember the password for this user.

  • Add this account to the group MTS Packages .

• In MTS Explorer, set the package identity to the account you just created.

• Using SQL Security Manager, map the package account to a new SQL Server login with the same name. Tell Security Manager to create a database user at this time also. In this example, a SQL login MTSBank will be added, and a user named MTSBank will also be added to the proper database.

Setup Considerations

NTFS

• Assign the proper NTFS privileges to the Windows NT groups to which the end users belong. Files access may include Read / Execute access to the following:

  • The directories in which the application's web files (ASP, HTM) are located. By default this falls somewhere under \InetPub\WWWRoot .

  • The directory in which any application components are located.

  • The ADO and OLE DB directories, if these components are being used from ASP scripts. By default these components are installed into \Program Files\Common Files\System\Ado and \Program Files\Common Files\System\Ole DB .

  • The 32-bit system directory ( \WinNT\System32 by default), where supporting libraries are located.

• If you do not want to allow anonymous access, be sure that the anonymous user cannot read the files in your web directory, to force a challenge early in the process.

Internet Information Server

• Depending on the needs of your applications, set IIS to Allow Anonymous and NT Challenge / Response. Remember that if anonymous access is allowed, to get the end user's real id, you must force a Windows NT challenge by restricting access to the web files in NTFS.

• For IIS 4.0, if your application will not allow access by the anonymous user, disable anonymous authentication in the IIS "Directory Security" properties for the virtual directory, using the Internet Service Manager.

ODBC

• For transparent access to SQL Server, make sure the SQL Server data sources are set to Use Trusted Connection in the ODBC setup dialog.

• If any applications use MS Access databases on the server, make sure the TEMP System environment variable is set, and the end users have write access to the temporary directory.

MTS

• Make sure security is enabled on the packages used by the application.

• If you are not using component-level security, make sure security checking is not enabled on the components.

• If the application checks role membership to determine if the caller may proceed with a privileged operation, make the check fail-safe. That is, if the component is run outside of the MTS context, or is not properly installed into MTS, the check should fail. The following Visual Basic code shows an example:

Private Function IsInRole(ByVal strRole As String) As Boolean On Error GoTo HandleError Dim Ctxt As ObjectContext Set Ctxt = GetObjectContext() If Ctxt Is Nothing Then ' Not running under MTS IsInRole = False Exit Function End If If Not Ctxt.IsSecurityEnabled() Then ' Forgot to enable security IsInRole = False Exit Function End If IsInRole = Ctxt.IsCallerInRole(strRole) Exit Function HandleError: IsInRole = False Exit Function End Function

SQL Server

• For transparent access to SQL Server, make sure SQL Server is setup for Integrated or Mixed security.

Moving to the Internet

For the intranet reference application described earlier, NT Challenge / Response was the recommended authentication style. For internet applications where clients will generally not have user accounts in your server's Windows NT domain, and many different browsers must be supported, digital certificates may be a better solution. To use digital certificates, users first obtain a client certificate from a trusted third-party organization or from your own Certificate Server. When users contact your secure web site, the Secure Sockets Layer (SSL) 3.0 security features of IIS authenticate them by checking the contents of the encrypted digital identification submitted by the user's Web browser during the logon process. The client certificate generally contains other identifying information about the user and the organization that issued the certificate.

You can configure IIS to map client certificates to a local Windows NT account. The mapping features of IIS allow you create one-to-one mappings between certificates and accounts or map multiple certificates to a single account. In most cases it isn't practical to create Windows NT accounts for individual internet users. You may want to map certificates to different local accounts based on the organization that issued the certificate or on the organization to which the user belongs. If you allow different organizations to access your secure site, the latter approach allows you to configure the access that each organization is granted via the Windows NT account to which they are mapped.

When you configure the security for your virtual directories in IIS, you can enable SSL encryption and optionally require a certificate for authentication. You can use certificates alone, or in combination with NT Challenge / Response to support both intranet and internet users.

Once the appropriate certificate mappings have been established, configure your application security the same as in the intranet scenario. The difference here is that the account(s) you configure will be used by multiple individual users. In effect, you trade the ability to control individual access for the ability to support many users with little administrative overhead.

One way to regain individual accountability (if not control) is to incorporate information from the client certificate into the auditing code of your MTS components. IIS makes this information available through its intrinsic objects which are propagated automatically to downstream components by MTS.

The code fragment below shows how to retrieve the subject fields from the certificate the client used for authentication. This code assumes that both intranet and internet clients access the component, so a certificate need not be present.

Dim strCertSubject As String
Dim objContext as ObjectContext
On Error Resume Next
Set objContext = GetObjectContext()
strCertSubject = objContext("Request").ClientCertificate("Subject")
If (Err.Number <> 0) Then
    strCertSubject = "(No Certificate)"
End If

For more information about using digital certificates with IIS and issuing client certificates, refer to the online documentation for MicrosoftInternet Information Server 4.0 and Microsoft Certificate Server.

Further Reading

• Security Topics for Visual InterDev, MSDN, Technologies and Languages Articles

• Internet Information Server Authentication, Windows NT 4.0 Server Resource Kit

• Microsoft Knowledgebase article 164535, Random Errors w/ IDC or ASP Queries to Access Database

• Configuring Security, Microsoft Transaction Server Administrator's Guide

• Security Concepts, Administrator's Companion, SQL Server Books Online

• Managing Security, Administrator's Companion, SQL Server Books Online

1 This restriction only applies for clients that are authenticated using Windows NT Challenge / Response. This is the style of authentication used for most intranet applications.