January 2011


hi

today i am going to setup Form based authentication, i have already completed that but now i will do this in IIS 7.5, so i will be skipping some steps. if you want to have a look at that, please https://shafaqat309.wordpress.com/2011/01/15/forms-authenticationwssmoss/

first of all create new database using aspnet_regiis tool

i am naming it “FBA”

open IIS and open the settings if Central Administration Web Application.

first of all set the connection string

now move to “Providers”  select “.Net Users” from the feature drop-down, name it “FBAUserProvider” and select your preferred settings.

once done then select  “.Net Roles” from the feature drop-down and configure the role provider,  i am naming it “FBARoleProvider”

that’ s it for the central admin application now move to new web application that u have created for Forms Based Authentication if u have not created yet then create it now.

create new connection string, user provider and role provider and this time set them as default and enable them.

now move to central admin site and select the application and move to Authentication Providers.

select form based authentication and provide the name of membership  and role provider and save settings.

now create a new user using IIS and add this user to site collection administrator.

now enable form authentication for new web application using IIS

now open new web application

click at the top right corner then u will be navigated to the login page

i will come with another page on how to customize the login page and add own custom application pages. Leave ur comments.

Advertisements

Hi all

Today I will demonstrate how can we enable anonymous access for a sharepoint web applicaqtion, I already have enabled forms authentication and whenever I try to open the web application, following screen comes up that shows I must login to the site to create document libraries and lists.

Follow the steps to enable anonymous access for the web application.

  • Move to central administration
  • Choose correct web application where u want to enable anonymous access, by default central administration web application will be selected, you can change the selected application and then select the membership provider.

click on the provider and edit the settings, you will see the following screen and check “Anonymous Access” check box.

open your web application and login using your site collection administrator account and move to Advance permissions in people and group section, go to settings menu and click “Anonymous access” as per following screen

after clicking you will see following screen and select “Entire Site” and press ok

once it is done you have enabled anonymous access, now open your web application, you will see following screen

Highlighted red section on top right corner shows that you are not logged in to the site and you can access the main site page.

Let me know if you have any question in implementation.

Hi all

Today i was trying to setup form authentication for may share point web application and finally i successfully completed it, let me describe you what steps i followed to setup this.

A step-by-step guide to configuring Forms authentication in SharePoint 2007

Following is a checklist for setting up Forms Authentication in SharePoint 2007

  1. Setup the membership data store
  2. Add a new user to the membership data store
  3. Configure SharePoint Central Administration web.config
  4. Configure the SharePoint site’s web.config
  5. Enable Forms authentication on the SharePoint site
  6. Authorize the Forms-based user to access the site
  7. Login

In this article, we will be using the SQL Server membership provider to authenticate users, but you can use any membership provider that you so choose. The steps involved will be about same, but the specifics of those steps may change depending on your provider. I’m also assuming that you’ve already installed SharePoint and created the SharePoint site on which you’re trying to enable forms authentication.

Step 1: Setup the membership data store

Before you can use the SQL Server membership provider, you have to set up the database that the provider uses to store member and role information. Microsoft ships a handy tool named the ASP.NET SQL Server Setup Wizard along with the .NET Framework, which will guide you through the process of creating the table structure and stored procedures required for the provider. You can launch the wizard by running aspnet_regsql.exe from the .NET Framework folder, which is normally found in the following location:

<WindowsDirectory>\Microsoft.NET\Framework\<version>\aspnet_regsql.exe

C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regsql.exe

When you launch the wizard, the “Welcome” screen appears and tells you all sorts of useful things about what the wizard does and the command line parameters you can use to get more options. It makes for great reading. When you’ve satisfied your literary pallet, click the Next button to display the “Select a Setup Option” screen (Figure 1).

Figure 1 – ASP.NET SQL Server Setup Wizard – Select a Setup Option screen

From the “Select a Setup Option” screen, choose the “Configure SQL Server for application services” option button. This lets the wizard know you want to add new tables and stored procedures to a membership database. You can also use the wizard to remove the table structure and delete all data in the database, but we don’t need to deal with that right now. If you accidentally add the structure to the wrong dataset, you may have to deal with it later. Click “Next” to move to the “Select the Server and Database” screen (Figure 2).

Figure 2 – ASP.NET SQL Server Setup Wizard – Select the Server and Database screen

Enter the name of your database server in the Server textbox to let the wizard know which SQL Server it needs to access. Then enter or select a database name in the Database combo box. The combo box displays a drop down containing a list of existing databases. If you want to add the tables and stored procedures for the provider to an existing database, select the database from the list. If you want to create a new database, then just type the name of the new database directly in the combo box and the wizard will create the database automatically. You may also need to enter SQL Server authentication credentials if you connect to the database using SQL Server authentication instead of Windows authentication. These credentials are not used outside of the wizard, so it won’t affect your SharePoint configuration one way or the other. Click the Next button to continue to the “Confirm Your Settings” screen.

The “Confirm Your Settings” screen displays a summary of the epoch-defining choices you’ve made thus far in the wizard. In other words, the server and database name. If you’re feeling hesitant about either, then this is your chance to back out. When you’ve got your courage built up, click the Next button.

In about a second, or about one and half seconds if you’re using a Virtual PC image (like me), the wizard creates all of the tables and stored procedures required by the membership provider. If it takes longer than that, you’ve entered a setting incorrectly and the wizard is waiting to time out (or you have a really slow machine). The wizard then displays a final status screen indicating success or failure. If the wizard fails, it details the reasons why so you can fix the problem. There are only six settings in the entire wizard (if you count option buttons as “settings”) so you should have a sporting chance at troubleshooting the problem. The success screen just tells you that everything worked and to click the Finish button.

At this point, the database you selected is populated with the proper table structure and stored procedures required by the provider, so now you can add a user to the membership database.

Step 2: Add a user to the membership data store

In IIS 7.0, there is a convenient “Add User” feature that uses the membership provider configured for the website to create a user. Unfortunately, IIS 7.0 isn’t available for Windows Server 2003 so, in a production environment, you’re probably stuck with IIS 6.0, which doesn’t have a comparable add user feature. This makes adding users a bit tedious, but here’s how you do it.

  1. Create a new ASP.NET web application
  2. Configure the new application for Forms authentication and point it at your newly-created membership database
  3. Copy the machine key element from your SharePoint site’s Web.config into to your new web application
  4. Add users and roles using the ASP.NET Web Site Administration Tool (if you have Visual Studio 2005 handy) or create users via the CreateUserWizard ASP.NET control.

I’m assuming you know how to create a new web site, so I’m not delving into any of the specifics of step 1. Once you have the website created, add a new Web.config to the application root and add the following configuration setting to the file:

Listing 01 – Web.config for the User Creation Website

<?xml version=”1.0″?>
<configuration xmlns=”http://schemas.microsoft.com/.NetConfiguration/v2.0“>
<connectionStrings>
<add name=”MembershipDatabaseCNX” connectionString=”SERVER=SHAFAQAT-PC\SQLEXPRESS;DATABASE=WssFBA; TRUSTED_CONNECTION=true;”/>
</connectionStrings>
<system.web>
<machineKey
validationKey=”8E074B186056F889587355255B167DA297AD837E43FD9850″
decryptionKey=”991D4DEB57A2263855C31AA1D3FF4F1AD508A53D2A94658F”
validation=”SHA1″
/>

<authentication mode=”Forms”/>
<membership defaultProvider=”DemoMembershipProvider“>
<providers>
<add
name=”DemoMembershipProvider
type=”System.Web.Security.SqlMembershipProvider,
System.Web, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a”
connectionStringName=”MembershipDatabaseCNX
enablePasswordRetrieval=”false”
enablePasswordReset=”true”
requiresQuestionAndAnswer=”true”
applicationName=”/”
requiresUniqueEmail=”false”
passwordFormat=”Hashed”
maxInvalidPasswordAttempts=”5″
minRequiredPasswordLength=”7″
minRequiredNonalphanumericCharacters=”1″
passwordAttemptWindow=”10″
passwordStrengthRegularExpression=””
/>
</providers>
</membership>
<roleManager enabled=”true” defaultProvider=”DemoRoleProvider“>
<providers>
<add
name=”DemoRoleProvider
connectionStringName=”MembershipDatabaseCNX”
applicationName=”/”
type=”System.Web.Security.SqlRoleProvider, System.Web,
Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a”
/>
</providers>
</roleManager>
</system.web>
</configuration>

I’ve bolded a few areas of Listing 01 because you will need to modify them to work on your system:

  1. Replace the machineKey element from the listing with the machine key element in the Web.config from your SharePoint site. The machine key from the listing is the machineKey from my SharePoint site (on a VPC local to my box, so calm down you crazy Hax0rs) so it won’t do you much good. The machineKey element changes from site to site, so make sure you get it from the site you want to configure for Forms authentication and not another site, or the SharePoint Central Administration site. You need matching machineKeys in the web application and the SharePoint site because user passwords are hashed (one way encrypted) and the hash routine uses the machine key value as part of the hashing algorithm.
  2. Make sure your connection string points at the appropriate server that houses the membership database you just created. Also make sure the appropriate credentials are supplied to the connection string.
  3. You can name your connection string anything you want, just make sure you use the same name later on in the connectionStrngName parameter for the membership and roleManager provider configurations.
  4. Make sure your applicationName parameters match in both the membership and roleManager provider configurations. The SqlMembershipProvider allows multiple applications to use the same membership database, so a mismatched name makes the provider think there are two applications instead of one and your members and roles won’t associate correctly.
  5. Feel free to configure the password settings of the membership provider as you see fit.

Once you have the configuration settings in place for your web application, you need a way to add users. If you are using Visual Studio 2005, you can use the built-in Web Site Administration Tool:

  1. Click the Website menu and choose the ASP.NET Configuration menu item. This launches a new web browser window that displays the Web Site Administration Tool.
  2. Click on the Security tab or link.
  3. Click on the Create User link and create a new user. Remember the login information because you’ll be needing it later.

If you do not have Visual Studio 2005, then you can use the CreateUserWizard control to add a new user to the membership database. It’s not as nice as the Web Site Administration Tool interface, but it does get the job done. Create a new page named CreateUser.aspx and add the following markup to the file:

Listing 02 – CreateUser.aspx

<%@ Page Language=”C#” %>
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN”
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”&gt;
<html xmlns=”http://www.w3.org/1999/xhtml&#8221; >
<head runat=”server”>
<title>Create User Wizard</title>
</head>
<body>
<form id=”form1″ runat=”server”>
<asp:CreateUserWizard ID=”CreateUserWizard1″
runat=”server”></asp:CreateUserWizard>
</form>
</body>
</html>

Once you save the file, navigate to the CreateUser.aspx page using your browser and create a new user. One way or another, you should have a user in the membership database at this point.

Step 3: Configure SharePoint Central Administration Web.config

Now that you have a user in the membership database, you’ve got to let SharePoint know that the user exists and grant the user access to your SharePoint site, which means configuring your site to use Forms authentication. You configure authentication through the SharePoint Central Administration web interface, but Central Administration needs to know about your membership and roleManager providers before that configuration can take place. That means you have to add the appropriate <connectionString>, <membership>, and <roleManager> configuration elements to the Central Administration Web.config. The configuration for Central Administration is almost identical to Listing 01, but this time around you do NOT set the defaultProvider attribute on the <membership> and <roleManager> elements, and do not set the enabled attribute on the <roleManager> element. Also, the Web.config for Central Administration already contains a great deal of configuration data, so make sure you do not accidentally remove or modify any existing settings.

Open the Central Administration’s Web.config. If you do not know where this is located, use the IIS Manager to determine the home directory for Central Administration and open the Web.config from that directory.

Add the following configuration elements to the Central Administration’s Web.config. Please note that some element, like <membership>, <connectionStrings>, and <roleManager>, may already exist in the Web.config. If they do, add the child elements to the existing item.

Listing 03 – Additions to the Central Administration Web.config

<?xml version=”1.0″?>
<configuration xmlns=
http://schemas.microsoft.com/.NetConfiguration/v2.0”&gt;

<connectionStrings> <!– element may already exist –>
<add name=”MembershipDatabaseCNX”
connectionString=”SERVER=SHAFAQAT-PC\SQLEXPRESS;
DATABASE=WssFBA;
TRUSTED_CONNECTION=true;”/>
</connectionStrings>

<system.web>

<membership> <!– element may already exist –>
<providers> <!– element may already exist –>
<add
name=”DemoMembershipProvider”
type=”System.Web.Security.SqlMembershipProvider,
System.Web, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a”
connectionStringName=”MembershipDatabaseCNX”
enablePasswordRetrieval=”false”
enablePasswordReset=”true”
requiresQuestionAndAnswer=”true”
applicationName=”/”
requiresUniqueEmail=”false”
passwordFormat=”Hashed”
maxInvalidPasswordAttempts=”5″
minRequiredPasswordLength=”7″
minRequiredNonalphanumericCharacters=”1″
passwordAttemptWindow=”10″
passwordStrengthRegularExpression=””
/>
</providers>
</membership>
<roleManager> <!– element may already exist –>
<providers> <!– element may already exist –>
<add
name=”DemoRoleProvider”
connectionStringName=”MembershipDatabaseCNX”
applicationName=”/”
type=”System.Web.Security.SqlRoleProvider,
System.Web, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a”
/>
</providers>
</roleManager>

</system.web>

</configuration>

Now the Central Administration knows about your provider configurations. You would think that having the information in the “SharePoint Central Administration” would be enough, but no. You’ve got to add it to the Web.config in your SharePoint site as well.

NOTE: Notice that Listing 03 never refers to the machineKey. Not even once. This is because you should not mess with the machineKey in SharePoint Central Administration. Leave it alone. Do not change it. Do not delete it. Your provider does not do any encrypting or hashing from the Central Administration, so you don’t have to synchronize the machineKey between the two sites. If you change the machineKey in Central Administration, bad things could happen.

Step 4: Configure SharePoint Site Web.config

At this point, you should be tired of messing with configuration settings, but the end is near. Go ahead and open the Web.config in the root directory of your SharePoint site, and make the same changes that you made to the SharePoint Central Administration’s Web.config. Use Listing 03 as your guide. When you are finished, you need to set the defaultProvider attributes in the <membership> and <roleManager> elements, and the enabled attribute in the <roleManager> element, as shown in Listing 04.

Listing 04 – Attributes that appear in the SharePoint site Web.config (but not in the Central Administration Web.config)

<?xml version=”1.0″?>
<configuration xmlns=
http://schemas.microsoft.com/.NetConfiguration/v2.0”&gt;

<system.web>

<membership defaultProvider=”DemoMembershipProvider”>

</membership>
<roleManager enabled=”true” defaultProvider=”DemoRoleProvider”>


</roleManager>

</system.web>

</configuration>

Once you’ve entered the configuration settings, SharePoint Central Administration and your SharePoint site have the settings required to enable Forms authentication. Time to jump back to the SharePoint Central Administration site.

Step 5: Enable Forms Authentication on the SharePoint site

You enable Forms Authentication for SharePoint sites using SharePoint Central Administration. Navigate to the Central Admin site using your browser. You can normally find a shortcut to the site in the Start menu:

Programs > Office Server 2007 > SharePoint 3.0 Central Administration

Once the Central Administration Home page is loaded, click on the Application Management link on the left hand navigation bar. You are taken to the Application Management page, which displays a variety of administration links. Click on the Authentication Providers link under the Application Security section on the right hand column of the page. The Authentication Providers page loads, as shown in Figure 3.

Figure 3 – Authentication Providers screen

When working in SharePoint Central Administration website, make sure the correct Web Application is selected when you are about to change configuration settings; otherwise you’ll be applying changes to the wrong site. There’s a small light-blue bar in the content pane of the page that displays the current Web Application URL. Make sure it’s the web application on which you want to enable Forms authentication. If it’s not, click the little down-arrow next to the URL and choose “Change Web Application” from the drop down list. SharePoint then displays a popup window with a list of web application from which you may choose.

Once you have the right web application selected, the Authentication Providers page displays a list of the zones in that application. Click on the name of the zone in which you want to enable Forms authentication. The Edit Authentication page displays (Figure 4).

Figure 4 – Edit Authentication Page

In the Edit Authentication page, choose the “Forms” option for Authentication Type. The page refreshes and displays the Membership provider and Role manager sections. Enter DemoMembershipProvider in the Membership provider name textbox, and DemoRoleProvider in the Role manager name textbox, then click the Save button. You are taken back to the Authentication Providers screen, but your zone should now say DemoMembershipProvider under the Membership Provider Name column. Forms authentication is now enabled on the site.

Step 6: Authorize the Forms-based user to access the site

Now that Forms authentication is enabled on the site, you can hit the site and see the login form (Figure 6). Microsoft spared no expense making this the blandest form you’ll ever see. You will probably want to customize it so it looks a lot nicer. Maybe include some text about how the user should enter their username and password. Nobody will read it, but it definitely makes a login form look like a login form. Anyway, if you enter your username and password, you will be successfully authenticated and then promptly denied access because you have no authorization to be in the site. So, how do you get authorization? You have to use the Site Collection Administrator account.

You may remember setting up a Site Collection Administrator when you first created the site a while back, and it was almost certainly a Windows user account. If you extended the site and have both a Windows zone and a Forms authentication zone, then you can login to the Windows zone and setup the Forms user in Site Settings as you would any other user.

If you have not extended the site, then you’ve only got one zone and its using Forms authentication. As such, the Windows account associated with the site collection administrator is effectively useless and you need to change the site collection administrator over to a Forms based account. To do this, open SharePoint Central Administration and click on the Application Management link in the left navigation menu. When the Application Management page displays, click the Site Collection Administrators link under the SharePoint Site Management section in the left-hand column of the page. The Site Collection Administrators page displays (Figure 5).


Figure 5 – Site Collection Administrators Page

On the Site Collection Administrators page, make sure that correct site collection is selected. Then, enter the username of the user you created back in Step 2 in the Primary Site Collection Administrator textbox. Click on the Check Names icon (the little red guy with a check mark) next to the textbox. It may take a few seconds, but the page should underline the text in the textbox indicating that the username is valid. If the username is not valid, the page puts a red squiggly line under the username and informs you that the user was not found. If the user is not found, make sure you typed the name correctly. If the issue persists, go back and check your configuration settings to ensure the connection string is valid and there are no typos.

Click on the OK button to save the changes. Your Forms authentication account is now a Site Collection Administrator who has authorization to visit the site. You can use that account to get into the site and setup additional Forms authentication users in Site Settings.

Step 7: Login

When you access the site, you are presented with the previously-mentioned default SharePoint login page (Figure 6). Enter your username and password, and then click the Sign In button. You should be authenticated and authorized, and the site should display as you would expect.


Figure 6 – SharePoint Forms Authentication Login Page

Forms Authentication and the search crawler

If you are planning on using the searching capabilities of SharePoint, then you need to know one major obstacle with Forms authentication. The search crawler can only access zones configured for Windows authentication. If your crawler is pointed at the default zone, and then you change the default zone to use Forms authentication, then your search is going to break. To get around this issue, extend your web application and create a zone that uses Windows authentication, then point the crawler at the new zone. Even though the search is hitting a different zone, the search findings will be available in your Forms authentication zone.

Conclusion

Once you know how to do it, getting Forms authentication up and running on a SharePoint site is fairly easy. You still have a bit of work to do getting your security planned out and adding users and roles to the site, but that’s the case with almost any SharePoint project. I would also highly recommend customizing the Forms login page since it’s not much better looking out of the box than the browser based password dialog you’re trying to avoid in the first place

Hi all
today i was trying to deploy my asp.net application on windows 7, 1st step completed successfully but after making some updates in my web.config file i got some deployment errors, after goggling i found there have a lot of modification in new IIS 7+ which a developer must know before deploying the application, i have listed them for your assistance.

Migration errors

These errors occur due to changes in how some ASP.NET configuration is applied in Integrated mode.  IIS will automatically detect this configuration and issue an error asking you to migrate your application, or move it to classic mode if migration is not acceptable (See breaking change #3 below).

 

1) ASP.NET applications require migration when specifying configuration in <httpModules> or <httpHandlers>.

You will receive a 500 – Internal Server Error.  This can include HTTP Error 500.22, and HTTP Error 500.23: An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode.

It occurs because ASP.NET modules and handlers should be specified in the IIS <handlers> and <modules> configuration sections in Integrated mode.

Workaround:

1) You must migrate the application configuration to work properly in Integrated mode.  You can migrate the application configuration with AppCmd:

> %windir%\system32\inetsrv\Appcmd migrate config “<ApplicationPath>”

2) You can migrate manually by moving the custom entries in in the <system.web>/<httpModules> and <system.web>/<httpHandlers> configuration manually to the <system.webServer>/<handlers> and <system.webServer>/<modules> configuration sections, and either removing the <httpHandlers> and <httpModules> configuration OR adding the following to your application’s web.config:

<system.webServer>

<validation validateIntegratedModeConfiguration=”false” />

</system.webServer>

 

2) ASP.NET applications produce a warning when the application enables request impersonation by specifying <identity impersonate=”true”> in configuration

You will receive a 500 – Internal Server Error. This is HTTP Error 500.24: An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode.

It occurs because ASP.NET Integrated mode is unable to impersonate the request identity in the BeginRequest and AuthenticateRequest pipeline stages.


Workaround
:

1) If your application does not rely on impersonating the requesting user in the BeginRequest and AuthenticateRequest stages (the only stages where impersonation is not possible in Integrated mode), ignore this error by adding the following to your application’s web.config:
<system.webServer>

<validation validateIntegratedModeConfiguration=”false” />

</system.webServer>

2) If your application does rely on impersonation in BeginRequest and AuthenticateRequest, or you are not sure, move to classic mode.

 

3) You receive a configuration error when your application configuration includes an encrypted <identity> section.

You will receive a 500 – Internal Server Error.  This is HTTP Error 500.19: The requested page cannot be accessed because the related configuration data for the page is invalid.
The detailed error information indicates that “Configuration section encryption is not supported”.

It occurs because IIS attempts to validate the <identity> section and fails to read section-level encryption.


Workaround:

1) If your application does not have the problem with request impersonation per breaking change #2, migrate your application configuration by using AppCmd as described in breaking change #1:

> %windir%\system32\inetsrv\Appcmd migrate config “<ApplicationPath>”

This will insure that the rest of application configuration is migrated, and automatically add the following to your application’s web.config to ignore the <identity> section:

<system.webServer>

<validation validateIntegratedModeConfiguration=”false” />

</system.webServer>

2) If your application does have the problem with request impersonation, move to classic mode.

 

Authentication, Authorization, and Impersonation

In Integrated mode, both IIS and ASP.NET authentication stages have been unified.  Because of this, the results of IIS authentication are not available until the PostAuthenticateRequest stage, when both ASP.NET and IIS authentication methods have completed.  This causes the following changes:

 

 

4) Applications cannot simultaneously use FormsAuthentication and WindowsAuthentication

Unlike Classic mode, it is not possible to use Forms Authentication in ASP.NET and still require users to authenticate with an IIS authentication method including Windows Authentication, Basic Authentication, etc.  If Forms Authentication is enabled, all other IIS authentication methods except for Anonymous Authentication should be disabled.
In addition, when using Forms Authentication, the following changes are in effect:

–       The LOGON_USER server variable will be set to the name of the Forms Authentication user.

–       It will not be possible to impersonate the authenticated client.  To impersonate the authenticated client, you must use an authentication method that produces a Windows user instead of Forms Authentication.

Workaround:

1) Change your application to use the pattern explained in Implementing a two level authentication scheme using Forms Authentication and another IIS authentication method in IIS 7.0.

 

 

5) Windows Authentication is performed in the kernel by default.  This may cause HTTP clients that send credentials on the initial request to fail.

IIS 7.0 Kernel-mode authentication is enabled by default in IIS 7.0.  This improves the performance of Windows Authentication, and simplifies the deployment of Kerberos authentication protocol.  However, it may cause some clients that send the windows credentials on the initial request to fail due to a design limitation in kernel-mode authentication.  Normal browser clients are not affected because they always send the initial request anonymously.

NOTE: This breaking change applies to both Classic and Integrated modes.


Workaround:

1) Disable kernel-mode authentication by setting the userKernelMode to “false” in the system.webServer/security/authentication/windowsAuthentication section.  You can also do it by AppCmd as follows:

> %windir%\system32\inetsrv\appcmd set config /section:windowsAuthentication /useKernelMode:false

 

6) Passport authentication is not supported.

You will receive an ASP.NET 500 – Server Error: The PassportManager object could not be initialized. Please ensure that Microsoft Passport is correctly installed on the server.

Passport authentication is no longer supported on Windows Vista and Windows Server 2008.  NOTE: This breaking change applies to both Classic and Integrated modes.

 

 

7) HttpRequest.LogonUserIdentity throws an InvalidOperationException when accessed in a module before PostAuthenticateRequest

You will receive an ASP.NET 500 – Server Error: This method can only be called after the authentication event.

HttpRequest.LogonUserIdentity throws an InvalidOperationException when accessed before PostAuthenticateRequest, because the value of this property is unknown until after the client has been authenticated.


Workaround:

1) Change the code to not access HttpRequest.LogonUserIdentity until at least PostAuthenticateRequest

 

 

8) Client impersonation is not applied in a module in the BeginRequest and AuthenticateRequest stages.

The authenticated user is not known until the PostAuthenticateRequest stage.  Therefore, ASP.NET does not impersonate the authenticated user for ASP.NET modules that run in BeginRequest and AuthenticateRequest stages.  This can affect your application if you have custom modules that rely on the impersonating the client for validating access to or accessing resources in these stages.

Workaround:

1) Change your application to not require client impersonation in BeginRequest and AuthenticateRequest stages.

 

9) Defining an DefaultAuthentication_OnAuthenticate method in global.asax throws PlatformNotSupportedException

You will receive an ASP.NET 500 – Server Error: The DefaultAuthentication.Authenticate method is not supported by IIS integrated pipeline mode.

In Integrated mode, the DefaultAuthenticationModule.Authenticate event in not implemented and hence no longer raises. In Classic mode, this event is raised when no authentication has occurred.


Workaround:

1) Change application to not rely on the DefaultAuthentication_OnAuthenticate event.  Instead, write an IHttpModule that inspects whether HttpContext.User is null to determine whether an authenticated user is present.

 

 

10) Applications that implement WindowsAuthentication_OnAuthenticate in global.asax will not be notified when the request is anonymous[M2]

If you define the WindowsAuthentication_OnAuthenticate method in global.asax, it will not be invoked for anonymous requests.  This is because anonymous authentication occurs after the WindowsAuthentication module can raise the OnAuthenticate event.

 

Workaround:

1) Change your application to not use the WindowsAuthentication_OnAuthenticate method.  Instead, implement an IHttpModule that runs in PostAuthenticateRequest, and inspects HttpContext.User.

 

Request limits and URL processing

The following changes result due to additional restrictions on how IIS processes incoming requests and their URLs.

 

11) Request URLs containing unencoded “+” characters in the path (not querystring) is rejected by default

You will receive HTTP Error 404.11 – Not Found: The request filtering module is configured to deny a request that contains a double escape sequence.

This error occurs because IIS is by default configured to reject attempts to doubly-encode a URL, which commonly represent an attempt to execute a canonicalization attack.
Workaround:

1) Applications that require the use of the “+” character in the URL path can disable this validation by setting the allowDoubleEscaping attribute in the system.webServer/security/requestFiltering configuration section in the application’s web.config.  However, this may make your application more vulnerable to malicious URLs:

<system.webServer>

<security>

<requestFiltering allowDoubleEscaping=”true” />

</security>

</system.webServer>

 

12) Requests with querystrings larger then 2048 bytes will be rejected by default

You will receive an HTTP Error 404.15 – Not Found: The request filtering module is configured to deny a request where the query string is too long.

IIS by default is configured to reject querystrings longer than 2048 bytes.  This may affect your application if it uses large querystrings or uses cookieless ASP.NET features like Forms Authentication and others that cumulatively exceed the configured limit on the querystring size.

NOTE: This breaking change applies to both Classic and Integrated modes.


Workaround
:

1) Increase the maximum querystring size by setting the maxQueryString attribute on the requestLimits element in the system.webServer/security/requestFiltering configuration section in your application’s web.config:

<system.webServer>

<security>

<requestFiltering>

<requestLimits maxQueryString=”NEW_VALUE_IN_BYTES” />

</requestFiltering>

</security>

</system.webServer>

Changes in response header processing

These changes affect how response headers are generated by the application.

 

13) IIS always rejects new lines in response headers (even if ASP.NET enableHeaderChecking is set to false)

If your application writes headers with line breaks (any combination of \r, or \n), you will receive an ASP.NET 500 – Server Error: Value does not fall within the expected range.

IIS will always reject any attempt to produce response headers with line breaks, even if ASP.NET’s enableHeaderChecking behavior is disabled.  This is done to prevent header splitting attacks.

NOTE: This breaking change applies to both Classic and Integrated modes.

 

14) When the response is empty, the Content-Type header is not suppressed

If the application sets a Content-Type header, it will remain present even if the response is cleared.  Requests to ASP.NET content types will typically have the “Content-Type: text/html” present on responses unless overridden by the application.
Workaround:
1) While this should not typically have a breaking effect, you can remove the Content-Type header by explicitly setting the HttpResponse.ContentType property to null when clearing the response.

 

15) When the response headers are cleared with HttpResponse.ClearHeaders, default ASP.NET headers are not generated.  This may result in the lack of Cache-Control: private header that prevents the caching of the response on the client

HttpResponse.ClearHeaders does not re-generate default ASP.NET response headers, including “Content-Type: text/html” and “Cache-Control: private”, as it does in Classic mode.  This is because ASP.NET modules may call this API for requests to any resource type, and therefore generating ASP.NET-specific headers is not appropriate.  The lack of the “Cache-Control” header may cause some downstream network devices to cache the response.
Workaround:
1) Change application to manually generate the Cache-Control: private header when clearing the response, if it is desired to prevent caching in downstream network devices.

 

Changes in application and module event processing

These changes affect how the application and module event processing takes place.

 

16) It is not possible to access the request through the HttpContext.Current property in Application_Start in global.asax

If your application accesses the current request context in the Application_Start method in global.asax as part of application initialization, you will receive an ASP.NET 500 – Server Error: Request is not available in this context.

This error occurs because ASP.NET application initialization has been decoupled from the request that triggers it.  In Classic mode, it was possible to indirectly access the request context by accessing the HttpContext.Current property.  In Integrated mode, this context no longer represents the actual request and therefore attempts to access the Request and Response objects will generate an exception.


Workaround:

1) See Request is not available in this context exception in Application_Start for a detailed description of this problem and available workarounds.

 

17) The order in which module event handlers execute may be different then in Classic mode

The following differences exist:

–       For each event, event handlers for each module are executed in the order in which modules are configured in the <modules> configuration section.  Global.asax event handlers are executed last.

–       Modules that register for the PreSendRequestHeaders and PreSendRequestContent events are notified in the reverse of the order in which they appear in the <modules> configuration section

–       For each event, synchronous event handlers for each module are executed before asynchronous handlers.  Otherwise, event handlers are executed in the order in which they are registered.

Applications that have multiple modules configured to run in either of these events may be affected by these change if they share a dependency on event ordering.  This is not likely for most applications.  The order in which modules execute can be obtained from a Failed Request Tracing log.
Workaround:
1) Change the order of the modules experiencing an ordering problem in the system.webServer/modules configuration section.

 

18) ASP.NET modules in early request processing stages will see requests that previously may have been rejected by IIS prior to entering ASP.NET.  This includes modules running in BeginRequest seeing anonymous requests for resources that require authentication.

ASP.NET modules can run in any pipeline stages that are available to native IIS modules.  Because of this, requests that previously may have been rejected in the authentication stage (such as anonymous requests for resources that require authentication) or other stages prior to entering ASP.NET may run ASP.NET modules.

This behavior is by design in order to enable ASP.NET modules to extend IIS in all request processing stages.

 

Workaround:

1) Change application code to avoid any application-specific problems that arise from seeing requests that may be rejected later on during request processing.  This may involve changing modules to subscribe to pipeline events that are raised later during request processing.

 

 

Other application changes

Other changes in the behavior of ASP.NET applications and APIs.

 

 

19) DefaultHttpHandler is not supported.  Applications relying on sub-classes of DefaultHttpHandler will not be able to serve requests.[M3]

If your application uses DefaultHttpHandler or handlers that derive from DefaultHttpHandler, it will not function correctly.  In Integrated mode, handlers derived from DefaultHttpHandler will not be able to pass the request back to IIS for processing, and instead serve the requested resource as a static file.  Integrated mode allows ASP.NET modules to run for all requests without requiring the use of DefaultHttpHandler.

 

Workaround:

1) Change your application to use modules to perform request processing for all requests, instead of using wildcard mapping to map ASP.NET to all requests and then using DefaultHttpHandler derived handlers to pass the request back to IIS.

 

 

20) It is possible to write to the response after an exception has occurred.

In Integrated mode, it is possible to write to and display an additional response written after an exception has occurred, typically in modules that subscribe to the LogRequest and EndRequest events. This does not occur in Classic mode. If an error occurs during the request, and the application writes to the response in EndRequest after the exception has occurred, the response information written in EndRequest will be shown. This only affects requests that include unhandled exceptions. To avoid writing to the response after an exception, an application should check HttpContext.Error or HttpResponse.StatusCode before writing to the response.

 

 

21) It is not possible to use the ClearError API to prevent an exception from being written to the response if the exception has occurred in a prior pipeline stage

Calling Server.ClearError during the EndRequest event does not clear the exception if it occurred during an earlier event within the pipeline.  This is because the exception is formatted to the response at the end of each event that raises an exception.

Workaround:

1) Change your application to call Server.ClearError from the Application_OnError event handler, which is raised whenever an exception is thrown.

 

 

22) HttpResponse.AppendToLog does not automatically prepend the querystring to the URL.[M4]

When using HttpResponse.AppendToLog to append a custom string to the URL logged in the request log file, you will manually need to prepend the querystring to the string you pass to this API.  This may result in existing code losing the querystring from the logged URL when this API is used.
Workaround:

1) Change your application to manually prepend HttpResponse.QueryString.ToString() to the string passed to HttpResponse.AppendToLog.

 

Other changes

Other changes.

 

23) ASP.NET threading settings are not used to control the request concurrency in Integrated mode

The minFreeThreads, minLocalRequestFreeThreads settings in the system.web/httpRuntime configuration section and the maxWorkerThreads setting in the processModel configuration section no longer control the threading mechanism used by ASP.NET.  Instead, ASP.NET relies on the IIS thread pool and allows you to control the maximum number of concurrently executing requests by setting the MaxConcurrentRequestsPerCPU DWORD value (default is 12) located in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0 key.  This setting is global and cannot be changed for individual application pools or applications.

 

Workaround:

1) To control the concurrency of your application, set the MaxConcurrentRequestsPerCPU setting.

 

24) ASP.NET application queues are not used in Integrated mode.  Therefore, the “ASP.NET Applications\Requests in Application Queue” performance counter will always have a value of 0

ASP.NET does not use application queues in Integrated mode.

 

25) IIS 7.0 always restarts ASP.NET applications when changes are made to the application’s root web.config file.  Because of this, waitChangeNotification and maxWaitChangeNotification attributes have no effect.

IIS 7.0 monitors changes to the web.config files as well, and cause the ASP.NET application corresponding to this file to be restarted without regard to the ASP.NET change notification settings including the waitChangeNotification and maxWaitChangeNotification attributes in the system.web/httpRuntime configuration sections.

 

 

26) ASP.NET deadlock detection is not supported in Integrated mode.

ASP.NET 2.0 Classic mode supports a deadlock detection mechanism which monitors ASP.NET responses and considers the process deadlocked if no responses have been received in more then the amount of time specified in the <processModel responseDeadlockInterval> setting, and there are more than a certain number of requests outstanding.  In this case, the process is marked unhealthy and a new process is eventually started.  In Integrated mode, this feature is not supported.  If your application is prone to deadlocks, it may lead to deadlock conditions being undetected, however it should have no effect on healthy applications that do not exhibit deadlocks.