How To: Use Protocol Transition and Constrained Delegation in ASP.NET 2.0

  • Article

 

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

patterns & practices Developer Center

patterns & practices Developer Center

Wade Mascia, J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Andy Wigley, Kishore Gopalan

Microsoft Corporation

September 2005

Applies To

  • ASP.NET version 2.0
  • Internet Information Services version 6.0
  • Microsoft® Windows Server™ 2003 operating system

Summary

This How To shows you how to configure and use protocol transition and constrained delegation to allow your ASP.NET application to access network resources while impersonating the original caller. The Microsoft® Windows® 2000 operating system supports delegation; however, access to downstream servers or services cannot be limited by delegation. The Microsoft® Windows Server™ 2003 operating system provides a more secure form of delegation called constrained delegation. With constrained delegation, you can configure the Microsoft Active Directory® directory service to restrict the services and servers that your ASP.NET application can access with the impersonated identity.

Constrained delegation in Windows Server 2003 requires Kerberos authentication. If your application cannot use Kerberos authentication to authenticate its callers, you can use protocol transition to switch from an alternate, non-Windows authentication mode (such as forms or certificate authentication) to Kerberos authentication. You can then use Kerberos with constrained delegation to access downstream network resources.

For demonstration purposes, this How To uses protocol transition with forms authentication. In practice, you would use the LogonUser API because you already obtained the username and password. An example of a production scenario for protocol transition is where you use certificates to authenticate users and want to map them to existing Windows accounts.

Contents

Objectives
Overview
Scenarios
Summary of Steps
Step 1. Use an S4U Logon to Create a Windows Token for the Original Caller
Step 2. Configure Your Service or Machine account for Constrained Delegation
Step 3. Implement and Test Protocol Transition
Using Constrained Delegation Through Multiple Tiers
Domain Functional Levels
Additional Resources

Objectives

  • Use protocol transition to switch from non-Windows authentication to Kerberos authentication.
  • Use constrained delegation to restrict access to specific services.
  • Pass the original caller identity from the Web server to the database server.
  • Pass the original caller identity from the Web server to the application server to the database server.

Overview

When an ASP.NET application impersonates the original caller, it accesses resources by using the security context of the authenticated user. However, the application can only access local resources. To access network resources while impersonating a remote user, your application must use delegation. If your application uses Kerberos authentication to authenticate its users, you can use delegation to pass the caller's identity through the layers of your application, and use it to access network resources. If your application does not use Kerberos authentication, you can use protocol transition to switch from a non-Kerberos authentication mechanism to Kerberos, and then use delegation to pass the identity on.

Protocol Transition

In many situations—for example, if your users access a Web site over the Internet—you cannot use Kerberos authentication because firewalls prevent the client computer from directly communicating with the domain controller. Instead, your application must authenticate the client by using another approach, such as forms authentication, or in an extranet scenario, client certificate authentication.

Windows Server 2003 has a protocol transition feature that permits applications to use a non-Windows authentication mechanism to authenticate users, but still use Kerberos authentication and delegation to access downstream network resources. This allows your application to access downstream servers that require Windows authentication and it allows you to use Windows auditing to track user access to backend resources.

Note that impersonating a Windows identity to access downstream resources brings a number of advantages, but also some disadvantages. The advantages include the ability to use Windows auditing to track user access to back-end resources, and the ability to implement fine-grained access controls to resources (such as databases) on a per-user basis. The disadvantages include the additional administration required to administer fine-grained access controls and reduced scalability. For many applications, the trusted subsystem model is appropriate; for example, where the Web server authenticates the caller, but then uses a service identity to access downstream resources on behalf of the original caller. This results in reduced administration and improved scalability. For more information on selecting the appropriate authentication model for your application, see Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication.

The use of protocol transition to access downstream resources relies on two extensions to the Kerberos protocol. Both extensions are implemented in Windows Server 2003. These extensions are:

  • Service-for-User-to-Self (S4U2Self), which allows you to obtain a Windows token for the client by supplying a user principal name (UPN) without a password.
  • Service-for-User-to-Proxy (S4U2Proxy), which allows an administrator to control exactly which downstream services can be accessed with the S4U2Self token.

For more information about protocol transition and the related service for user (S4U) extensions to the Kerberos protocol, see Exploring S4U Kerberos Extensions in Windows Server 2003.

Constrained Delegation

Kerberos delegation on Windows Server 2000 is unconstrained and servers that are configured as trusted for delegation in Active Directory can access any network resources or any machine on the network while using the impersonated user's security context. This represents a potential security threat, particularly if the Web server is compromised.

To address this issue, Windows Server 2003 introduces constrained delegation. This allows administrators to specify exactly which services on a downstream server or a domain account can access when using an impersonated user's security context.

Note   The list of services that can be accessed by delegation is maintained in an Active Directory list referred to as the A2D2 list.

This How To shows how to use protocol transition and constrained delegation in Windows Server 2003 to solve the following common problems:

  • Using a non-Windows authentication mechanism for external clients and then transitioning to Kerberos authentication to access network resources.
  • Impersonating Kerberos-authenticated clients and then using their Windows security context to pass their identities through multiple tiers to access network resources.

Scenarios

Protocol transition is appropriate when a non-Windows authentication mechanism is used by your Web application to authenticate clients. Consider the following scenarios:

  • If your client usesforms authentication, you can use LogonUser. If the user name and password entered through the forms login page map directly to a Windows domain account, your application can call the LogonUser API and avoid protocol transition.

    Note   The example in this How To uses forms authentication for simplicity.

  • If your client uses certificate authentication, you can consider protocol transition. If your client uses certificates to authenticate with your Web server the application can look up the user in Active Directory based on the certificate, and use protocol transition to allow the user to log on.

Summary of Steps

Follow these steps to use protocol transition and constrained delegation in ASP.NET 2.0 on Windows Server 2003:

  • Step 1. Use an S4U Logon to create a Windows token for the original caller.
  • Step 2. Configure your service or machine account for constrained delegation.
  • Step 3. Implement and test protocol transition.

Step 1. Use an S4U Logon to Create a Windows Token for the Original Caller

If your users have Windows domain accounts, but must connect to your Web server from outside the domain or a non-trusted domain (for example, over the Internet), then you cannot use integrated Windows authentication. Instead, you can use a non-Windows authentication mechanism, and then transition to Kerberos as shown in Figure 1.

Ff649317.f01paght00002401(en-us,PandP.10).gif

Figure 1. Using an S4U logon to call a database from an ASP.NET application using the caller's identity

Configure ASP.NET for Forms Authentication

Create an ASP.NET application and configure it to use forms authentication. Note that instead of forms authentication, you could use any non-Windows authentication mechanism to authenticate the users of your application.

To configure a Web site for forms authentication

  1. Create a Web application.

  2. In Internet Information Services Administrator, edit the properties of the Web site. Edit the Anonymous access and authentication control on the Directorysecurity tab, and check the Anonymous access checkbox.

  3. Create a Web application. Add a Web.config file, enable forms authentication, and deny access to unauthenticated users by adding the following configuration.

    <system.web>
    ...
    <authentication mode="Forms"/>
    <authorization>
        <deny users="?" />
     </authorization>
   ...
</system.web>

To create a login form for the Web site

  1. Add a Web form called Login.aspx.

  2. Add a Login control and a CreateUserWizard control, as shown in the following example.

    <%@ Page Language="C#" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head >
    <title>Protocol Transition</title>
</head>
<body>
    <form id="form1" >
    <div>
        <asp:Login ID="Login1" >
        </asp:Login>

    </div>
        <asp:CreateUserWizard ID="CreateUserWizard1" >
            <WizardSteps>
                <asp:CreateUserWizardStep >
                </asp:CreateUserWizardStep>
                <asp:CompleteWizardStep >
                </asp:CompleteWizardStep>
            </WizardSteps>
        </asp:CreateUserWizard>
    </form>
</body>
</html>

Obtain a Windows Token for the Original Caller

Add the following code to your application. This code takes the user name supplied in the login form, constructs a UPN in the format userName@domainName, and passes the UPN to the WindowsIdentity constructor. This constructor uses the Kerberos S4U extension to obtain a Windows token for the user. The code then uses the token to begin impersonation.

using System.Security.Principal;
...
// Obtain the user name (obtained from forms authentication)
string identity = User.Identity.Name;

// Convert the user name from domainName\userName format to 
// userName@domainName format if necessary
int slash = identity.IndexOf("\\");
if (slash > 0)
{
  string domain = identity.Substring(0, slash);
  string user = identity.Substring(slash + 1);
  identity = user + "@" + domain;
}

// The WindowsIdentity(string) constructor uses the new
// Kerberos S4U extension to get a logon for the user
// without a password.
WindowsIdentity wi = new WindowsIdentity(identity);
WindowsImpersonationContext wic = null;
try
{
  wic = wi.Impersonate();
  // Code to access network resources goes here.
}
catch()
{
  // Ensure that an exception is not propagated higher in the call stack.
}
finally
{
  // Make sure to remove the impersonation token
  if( wic != null)
    wic.Undo();
}

Note   In many cases, the UPN is the user's e-mail address, but it does not have to be. For some accounts, it may not be configured at all. The default format for a UPN is userName@DomainName. If you are logged on to a domain, you can display your user name in UPN format by running the command whoami /upn from a command prompt. Whoami is a command-line tool available on Windows Server 2003 and in the in the Support/Tools directory on the Windows XP Professional operating system CD.

Token Types

The type of token generated with the S4U2Self extension determines what you can do with the token while impersonating. You can obtain the following token types:

  • Identify-level token. This is returned by default. With this token type, you can check to see what groups are contained in the token, but you cannot use it to access local or remote resources while impersonating.

  • Impersonation-level token. This type of token allows you to access local resources while impersonating. To obtain this type of token from the WindowsIdentity constructor, you must grant your process account the "Act as part of the operating system" user right.

    Note   This places your process within the trusted computing base (TCB) of the Web server, which makes your Web server process very highly privileged. Where possible, you should avoid this approach because an attacker who manages to inject code and compromise your Web application will have unrestricted capabilities on the local computer.

    Note   If your process account is part of the TCB, you get an impersonate-level token. To access network resources, you must enable protocol transition in Active Directory. In this case, you can obtain S4U2Proxy tickets on behalf of your client by accessing remote services defined in the A2D2 list.

Step 2. Configure Your Service or Machine Account for Constrained Delegation

In this step, you configure Active Directory to allow your Web application to use constrained delegation to access a remote database server.

If your ASP.NET application runs using the Network Service machine account, then you must enable protocol transition and constrained delegation for your Web server computer. However, if your ASP.NET application runs under a custom domain account, you must enable protocol transition and constrained delegation for the custom domain account.

Note   If you use a custom domain account to run SQL Server, you must create a service principal name (SPN) for this account. You can do this by using the following command:

setspn -A MSSQLSvc/ databaseservername.fullyqualifieddomainname

domain\customAccountName

If you run SQL Server by using the System account (which is not recommended because of the associated high privileges that an attacker could exploit), an SPN is created automatically for you.

For more information about running your ASP.NET application under a custom account, see How To: Create a Service Account for an ASP.NET 2.0 Application.

To configure protocol transition for the machine account

This procedure assumes that you are running your Web application under the Network Service machine account.

  1. Start the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in.

  2. In the left pane of the MMC snap-in, click the Computers node.

  3. In the right pane, double-click your Web server computer to display the Properties dialog box.

    Note   If the Properties dialog box does not have a Delegation tab and there is a single checkbox called Trust Computer for Delegation on the General tab, your domain is operating as a Windows 2000 mixed domain. You must raise the domain functional level to Windows Server 2003 as described in the section "Domain Functional Levels," in this document.

  4. On the Delegation tab of the Properties window for the Web server computer, Do not trust the computer for delegation is selected by default. To use constrained delegation, select Trust this computer for delegation to specified services only. You specify precisely which service or services can be accessed in the bottom pane.

  5. Beneath Trust this computer for delegation to specified services only, select Use any authentication protocol.

    If you select Use Kerberos only, constrained delegation works only with Kerberos authentication. If you are using protocol transition to switch from forms authentication (or an alternate non-Kerberos authentication mechanism) to Kerberos, then you must select Use any authentication protocol.

  6. Click the Add button. This displays the Add Services dialog box.

  7. Click the Users or computers button.

  8. In the Select Users or Computers dialog, type the name of your database server computer if you are running SQL Server as System or Network Service. Alternatively, if you are running SQL Server by using a custom domain account, enter that account name instead. Then click OK.

  9. You will see all the service principal names configured for the selected user or computer account. To restrict access to SQL Server, select the MSSQLSvc service, and then click OK.

    Note   If you want to delegate to a file on a file share, you need to select the Common Internet File System (CIFS) service.

To configure protocol transition for a custom domain account

This procedure assumes that you are running your Web application under a custom domain account.

  1. Create an SPN for your custom domain account. Kerberos requires an SPN to support mutual authentication. To create an SPN for the domain account:

    1. Install the Windows Server 2003 Tools from the Windows Server 2003 CD.

    2. From a command prompt, run the Setspn tool twice from the C:\Program Files\Support Tools directory as shown here.

      setspn -A HTTP/webservernamedomain\customAccountName

      setspn -A HTTP/webservername.fullyqualifieddomainname

domain\customAccountName

    > **Note**   You can only have a single SPN associated with any HTTP service (DNS) name, which means you cannot create SPNs for different service accounts mapped to the same HTTP server unless they are on different ports. The SPN can include a port number.

  1. Start the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in.

  2. In the left pane of the MMC snap in, click the Users node.

  3. In the right pane, double-click the user account you are using to run the ASP.NET application. This displays the user account properties.

    Note   If the Properties dialog box for your account does not have a Delegation tab, this indicates that a service principal name (SPN) does not exist for the user. Create an SPN as explained in step 1, above.

  4. On the Delegation tab of the Properties window for your Web server computer, Do not trust the computer for delegation is selected by default. To use constrained delegation, select Trust this user for delegation to specified services only. You specify precisely which service or services can be accessed in the bottom pane.

  5. Beneath Trust this user for delegation to specified services only, select Use any authentication protocol.

    If you select Use Kerberos only, constrained delegation works only with Kerberos authentication. If you are using protocol transition to switch from forms authentication (or an alternate non-Kerberos authentication mechanism) to Kerberos, then you must select Use any authentication protocol.

  6. Click the Add button. This displays the Add Services dialogue.

  7. Click the Users or computers button.

  8. In the Select Users or Computers dialog, type the name of your database server, and then click OK.

  9. You will now see all the available services on your database server. To restrict access to SQL Server, select the MSSQLSvc service, and then click OK.

Step 3. Implement and Test Protocol Transition

In this step, you implement the code necessary to call the database using the identity of the caller. This example assumes the target database is a SQL Server called DBServer, the database server requires Windows authentication and the required database is the Northwind database.

Note   To allow access to SQL Server, you must create a SQL Server login for each of your application's end users or for a set of groups that the users belong to, and grant them read access to the Northwind database.

To implement code that uses the caller's identity

  1. Define a connection string to the database server in your Web.config file, specifying Windows authentication to the database, as shown in the following example.

    <configuration xmlns="https://schemas.microsoft.com/.NetConfiguration/v2.0">
  <connectionStrings>
    <add name="nwindConnectionString" connectionString=
"Data Source=DBServer;Initial Catalog=northwind;Integrated Security=True" 
         providerName="System.Data.SqlClient" />
  </connectionStrings>
  ...
</configuration>

  2. Use code similar to the following to impersonate the caller and access the database.

    Using System.Data.SqlClient;
Using System.Security.Principal;
...
private DataTable CallDatabase()
{
  DataTable dt = new DataTable();
  WindowsImpersonationContext wic = null;
  try
  {
    // First, impersonate the original caller
    wic = ImpersonateEndUser();
    // Fetch data from the database using the original caller's 
    // security context
    using (SqlConnection conn = new SqlConnection())
    {
      conn.ConnectionString = ConfigurationManager.ConnectionStrings
                               ["nwindConnectionString"].ConnectionString;
      conn.Open();
      SqlCommand cmd = new SqlCommand("Select ProductName from Products",
                                       conn); 
      SqlDataAdapter da = new SqlDataAdapter(cmd);
      da.Fill(dt);
    }
  }
  catch
  {
    // Do not let the exception propagate higher up the call stack
  }
  finally
  {
    // Ensure that impersonation is stopped
    if( wic != null)
      wic.Undo();
  }
  return dt;
}

private WindowsImpersonationContext ImpersonateEndUser()
{
  // Obtain the user name (from forms authentication)
  string identity = User.Identity.Name;

  // Convert from domainName\userName format to userName@domainName format
  // if necessary
  int slash = identity.IndexOf("\\");
  if (slash > 0)
  {
      string domain = identity.Substring(0, slash);
      string user = identity.Substring(slash + 1);
      identity = user + "@" + domain;
  }

  // The WindowsIdentity(string) constructor uses the new
  // Kerberos S4U extension to get a logon for the user
  // without a password.
  WindowsIdentity wi = new WindowsIdentity(identity);
  return wi.Impersonate();
}

    Note the following points about the preceding code:

    • The ImpersonateEndUser method uses the user name of the user that has been authenticated using forms authentication. It converts the user name to UPN format (userName@domainName), and passes the UPN to the WindowsIdentity constructor. This constructor returns a Windows token for a domain account without requiring the account's password.

      By default, an identify-level token is returned. You can only use this to check the user's group membership. You cannot access local or remote resources. However, if you configure protocol transition in Active Directory, you can use the token to access specified services on selected servers as defined by the A2D2 list.

    • Your application must authenticate the request by using the user name and password submitted on your forms login page. When your application determines that the user is authentic, you must select an existing Windows account to represent the user on the back end. This example assumes that the user submitted a Windows user name and domain name on the forms login page and supplied a password that the ASP.NET membership provider could verify. This is not the password for the Windows account. The purpose of protocol transition is to avoid exposing Windows passwords in this way.

      In this example, after the membership system in ASP.NET verifies the user's password, the Web application converts the user's name into the UPN form and constructs a WindowsIdentity object.

      If you try to create a WindowsIdentity object for a user that does not exist, the WindowsIdentity constructor generates a System.Security.SecurityException with the message Logon failure: unknown user name or bad password.

To test protocol transition and constrained delegation

  1. Start your application.

  2. Use the CreateUserWizard control on the login page to create two user accounts: one that has a user name that matches a domain account and also has a SQL Server login that authorizes read access to the Northwind database, and one that has a user name that does not match a domain account.

    Note   By default, the ASP.NET login controls automatically create and configure a SQL Express membership database in the \app_data folder to act as your membership database. For more information about how to use alternate databases, see How To: Use Membership in ASP.NET 2.0.

  3. Use the Login control to log in with the user account that does not match a domain account. The login will succeed, but the attempt to impersonate the user will fail and will generate a SecurityException because the user name does not match a domain name.

  4. Start the application again. Log in using the user name that does match a domain account name. On the Web server, the ASP.NET application impersonates the original caller and runs using the identity of the caller. The constrained delegation configuration ensures that the same identity is used to access the database.

Using Constrained Delegation Through Multiple Tiers

You can use constrained delegation to pass the original caller's identity through multiple application tiers, for example from a Web server to an application server to a database server.

Web to Application Server to Database

In the following intranet scenario, the client's computer is on the same domain as the servers and can communicate directly with the domain controller. As a result, the ASP.NET application is configured for Windows authentication and the Web site is configured in IIS for integrated Windows authentication.

The Web server accesses middle-tier business logic exposed by a Web service on an application server. This scenario is shown in Figure 2.

Ff649317.f01paght00002402(en-us,PandP.10).gif

Figure 2. Use constrained delegation with or without protocol transition through multiple tiers where the original caller is authenticated with Windows authentication.

The key features of this scenario are:

  • The application uses Kerberos authentication to authenticate users. As a result protocol transition is not required.
  • Constrained delegation is required to allow the Web application, while impersonating, to access the HTTP service on the application server.
  • Constrained delegation is required to allow the application server, while impersonating, to access the SQL Server (MSSQLSvc) service on the database server.
  • The Web service on the application server uses Kerberos authentication to authenticate its caller (the Web application), and then impersonates the authenticated caller while accessing the database.

Web Server Configuration

To configure the Web server, you need to enable Windows authentication within IIS, configure your ASP.NET application for impersonation, and set the Credentials property of the Web service proxy.

To configure your Web server and ASP.NET presentation-tier application

  1. Use IIS to configure your Web site for Integrated Windows authentication. Make sure anonymous access is disabled.

  2. Use the following settings to configure your ASP.NET application to use Windows authentication and impersonation.

    <system.web>
    ...
    <authentication mode="Windows"/>
    <identity impersonate="true"/>
    ...
</system.web>

  3. Set the Credentials property on the Web service proxy to pass the authenticated user's security context to the Web service, as shown in the following code.

    // Call the web service passing the original user's credentials
DataAccessWS.WebService ws = new DataAccessWS.WebService();
ws.Credentials = CredentialCache.DefaultCredentials;

ws.GetData();

Application Server Configuration

To configure the application server, you need to enable Windows authentication within IIS, configure your ASP.NET application for impersonation, and use Windows authentication to access the database.

To configure your application server and Web service

  1. Use IIS to configure your Web site for Integrated Windows authentication. Make sure anonymous access is disabled.

  2. Use the following settings to configure your Web service to use Windows authentication and impersonation.

    <system.web>
    ...
    <authentication mode="Windows"/>
    <identity impersonate="true"/>
    ...
</system.web>

  3. Use Windows authentication to access the database. The impersonation configuration ensures that the authenticated user's credentials are used to access the database. You must ensure that the relevant end user account has a SQL Server login and relevant database permissions.

Active Directory Configuration

You must configure Active Directory to allow the Web server application to use constrained delegation to access the Web service on the application server. You must also configure Active Directory to allow the Web service on the application server to access the SQL Server database.

To configure constrained delegation for the Web server

  1. Use the Active Directory Users and Computers MMC snap in to display the Properties dialog box for either the Web server computer (if you are using the Network Service account to run your ASP.NET Web application), or your custom user account (if you are using a custom account to run your application).
  2. On the Delegation tab of the Properties window, select Trust this computer/user for delegation to specified services only. This enables constrained delegation for the services you will select in the bottom pane.
  3. After Trust this computer/user for delegation to specified services only, select Use Kerberos only. This restricts the use of constrained delegation to scenarios where the callers are authenticated using Kerberos authentication only. Note that if you are authenticating callers to the Web server using any technique other than Kerberos you must select Use any protocol, and obtain a Windows token for the caller programmatically as explained in the section, "Step 1. Use Protocol Transition to Create a Windows Token for the Original Caller," in this document.
  4. Click the Add button. This displays the Add Services dialog box.
  5. Click the Users or computers button
  6. In the Select Users or Computers dialog box, type the name of your application server, and then click OK.
  7. You will see all the available services on your application server. Select the HTTP service, and then click OK.

To configure constrained delegation for the application server

Follow the configuration steps described above for the Web server, except restrict access to the MSSQLSvc service on the database server.

  • In the Active Directory Users and Computers MMC snap-in, select the application server computer account (if you are using the default Network Service account to run Web service applications).. If your Web service applications run under a custom domain account, select that user account instead.
  • When you configure the services for which constrained delegation is permitted, select the database server computer and the MSSQLSvc service on that computer.

Note   If you are using a custom domain account to run your Web application, Web service or SQL Server, be sure that you have created an SPN for the account. For details about creating an SPN, see "Step 2. Configure Your Service or Machine Account."

Domain Functional Levels

By default, a Windows Server 2003 domain runs in Windows 2000 mixed mode. You must raise the domain functional level to Windows Server 2003 to use constrained delegation and protocol transition.

Note   This change is not reversible.

To verify the domain functional level

  1. In the left pane of the Active Directory Users and Computers MMC snap-in, right-click the root node for the domain, and then click Properties.
  2. The Properties dialog box displays information including the domain functional level. If the domain is operating as a Windows 2000 mixed domain, you must raise the domain functional level to Windows Server 2003 before you can use constrained delegation.

To raise the domain functional level to Windows Server 2003

  1. In the Active Directory Users and Computers MMC snap-in, click the root node titled Active Directory User and Computers [machinename. domain].
  2. On the Action menu, click All Tasks, and then click Raise Domain Functional Level.
  3. Select Windows Server 2003 from the Select an available domain functional level dropdown box. Click OK.

Additional Resources

Feedback

Provide feedback by using either a Wiki or e-mail:

We are particularly interested in feedback regarding the following:

  • Technical issues specific to recommendations
  • Usefulness and usability issues

Technical Support

Technical support for the Microsoft products and technologies referenced in this guidance is provided by Microsoft Support Services. For product support information, please visit the Microsoft Support Web site at https://support.microsoft.com.

Community and Newsgroups

Community support is provided in the forums and newsgroups:

To get the most benefit, find the newsgroup that corresponds to your technology or problem. For example, if you have a problem with ASP.NET security features, you would use the ASP.NET Security forum.

Contributors and Reviewers

  • External Contributors and Reviewers: Jason Taylor, Security Innovation; Rudolph Araujo, Foundstone Professional Services
  • Microsoft Consulting Services and PSS Contributors and Reviewers: Adam Semel, Tom Christian, Wade Mascia
  • Test team: Larry Brader, Microsoft Corporation; Nadupalli Venkata Surya Sateesh, Sivanthapatham Shanmugasundaram, Infosys Technologies Ltd.
  • Edit team: Nelly Delgado, Microsoft Corporation; Tina Burden McGrayne, TinaTech, Inc.
  • Release Management: Sanjeev Garg, Microsoft Corporation

patterns & practices Developer Center

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.