Home > Uncategorized > SharePoint 2010: Getting SharePoint Claims Web Applications to Work With None-Claims Aware Applications / Services

SharePoint 2010: Getting SharePoint Claims Web Applications to Work With None-Claims Aware Applications / Services

I recently ran into an issue with an in house solution that was developed in Visual Studio leveraging .NET and C# which made SOAP Web Service calls to SharePoint to populate form data from SharePoint lists.  This solution worked fine in my SharePoint 2007 environment that utilized Classic Authentication.  However after upgrading to SharePoint 2010 and switching the authentication type to Claims broke the ability for the solution to make successful SOAP Web Service calls to SharePoint.

So instead of me having to completely reengineer the in-house solution to be claims aware I took a different approach.

For me to successfully get this to work I had to do a few things.

ONE
1.  Extend the Claims Web Application to a new zone (intranet) that used Integrated  Windows Authentication (NTLM).  Give the Web Application a new name.  I used (SharePoint – Portal_NTLM)

Since extending the Web Application will keep the same Authentication mode of Claims as of the default primary Web Application I still had a little bit of work left to do.  I had to essentially “trick” the extended Web Application to think it was using Classic Authentication instead of Claims.

Since extending the Web Application creates a new web.config file I had to modify this file on each WFE Server for the new extended web app.  This is usually found in c:\inetpub\wwwroot\wss\VirtualDirectories\Extended Web Application

Open up the Web.Config File and search for the following lines
<add key=”aspnet:AllowAnonymousImpersonation” value=”true” />
Change to
<add key=”aspent:AllowAnonymousImpersonation” value=”false” />

Search for the following lines:
<authentication mode=”Forms”>
Change to
<authentication mode=”Windows”>

Make the changes to all web.config files and save.

TWO
Since the Default Web Application leveraged CLAIMS with Kerberos Authentication, and the Extended Web Application leveraged CLAIMS (hacked “Windows” in web.config) and NTLM Authentication the service account that ran the Application Pool for the Default Web Application did not have the necessary rights to call SOAP Web Services from within the in-house solution.  If I were to change the  Pass-Through Authentication in IIS for the Extended Site to use the “Connect As” and manually enter in the Farm Account and Password the in-house solution executed successfully, but I ran into another issue with NINTEX Workflows.  Since changing the Pass-Through Authentication to use “Connect As” it was using the Farm Account which when authenticating to SharePoint was signing in as the “System Account”  which broke the NINTEX Workflows from automatically kicking off because it was expecting a dedicated service account.

Since the Extended Web Application leveraged the same Application Pool as the Default (Main) Web Application I had to create a new Application Pool which used the Farm Account as the Identity.

For me to create a new Application Pool I had to do a few things.

I leveraged PowerShell to create a new Application Pool and associated that new Application Pool with the new extended web application:

Below is the PowerShell to create a new Application Pool and associate it with the extended Web Application.

Before you execute this PowerShell script make sure you write down the name of the original Web Application Pool name for the Default (Main) Web Application. *This will be important later*

————————————————————–

$WebAppURL = http://portal/extendedwebapp
$NewAppPoolName = “SharePoint – Portal_NTLM”
$NewAppPoolUserName = “DOMAIN\FarmAccount”

$Farm = Get-SPFarm
$Service = $Farm.Services | where {$_.TypeName -eq “Microsoft SharePoint Foundation Web Application”}
$Password = Read-Host -Prompt “Please enter your password” -AsSecureString
$NewAppPool = New-Object Microsoft.SharePoint.Administration.SPApplicationPool($NewAppPoolName,$Service)
$NewAppPool.CurrentIdentityType = “SpecificUser”
$NewAppPool.Username = $NewAppPoolUserName
$NewAppPool.SetPassword($Password)
$NewAppPool.Provision()
$NewAppPool.Update($true)

$NewAppPool = $Service.ApplicationPools[$NewAppPoolName]
$WebApp = Get-SPWebApplication $WebAppURL
$WebApp.ApplicationPool = $NewAppPool
$WebApp.ProvisionGlobally()
$WebApp.Update()

————————————————————–

After associating the new Extended Web Application to the new Application Pool I ran into one other problem.  Since the Extended Web Application shares the same Application Pool with the default (Main) Web Application, when doing this  it also re-associate the default (Main) Web Application with the new Application Pool.  Remember the note I mentioned up above “Before you execute this PowerShell script make sure you write down the name of the original Web Application Pool name for the Default (Main) Web Application. *This will be important later*”.   There is where this will now come into handy.  If your default (Main) Web Application utilizes Kerberos Authentication and the App Pool User Identity is different then that of the new Application Pool Identity you will run into problems.

To fix this problem you have to re-associate the default (Main) Web Application with its original App Pool.   To do this you basically run the same PowerShell script above minus the creation of the new Application Pool as follows:

————————————————————–
$Farm = Get-SPFarm
$Service = $Farm.Services | where {$_.TypeName -eq “Microsoft SharePoint Foundation Web Application”}
$NewAppPool = $Service.ApplicationPools[NAME OF DEFAULT APPLICATION POOL]
$WebApp = Get-SPWebApplication “URL OF THE DEFAULT WEB APPLICATON”
$WebApp.ApplicationPool = $NewAppPool
$WebApp.ProvisionGlobally()
$WebApp.Update()

————————————————————–

Now after running this script you will run into one last problem.  As mentioned above since the Extended Web Application shares the same Web Application Pool as the Default (Main) Web Application the Application Pool will again change for the Extended Web Application to use the Web Application Pool of the Default (Main) Web Application.  This is because the schema for the Web Application’s Application Pool lives within the ConfigDB.

If you execute the following two PowerShell lines below you will see which Web Applications are associated with which Web Application Pools:

$Farm = Get-SPFarm
$Service = $Farm.Services | where {$_.TypeName -eq “Microsoft SharePoint Foundation Web Application”}
$Service

You will notice that both the Default (Main) and the Extended Web Application are associated with the same Application Pool in the Config Database.  There is no way around associating the Extended Web Application to a new Application Pool and keeping the Default (Main) Web Application the same in the ConfigDB.  So you have to basically tell IIS to use a different Web Application Pool which basically bypasses what is associated in the ConfigDB.

Since now that there is a new Application Pool in IIS, you can now then manually re-associate the Extended Web Application Site to that new Web Application Pool.  This can only be done in IIS.  If you were to run the same two PowerShell scripts above you will still see the Extended Web Application is associated with the Default (Main) Web Application Pool, but will be assigned the new one in IIS.

Now the only problem with this is if you ever have to do any configuration of the Extended Web Application that might cause the reset of the Application Pool in IIS you have to again manually go back into IIS and re-associate the right Application pool to the Extended Web Application.

This was the way I was able to get an Extended Web Application to use Classic Authentication with NTLM from a Claims Authentication with Kerberos Web Application.

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: