Home > Blogs > Eric Shupps | The SharePoint Cowboy > Posts > How to Manually Disable Claims Authentication in SharePoint 2010
 
Eric Shupps eshupps The SharePoint Cowboy is the founder and President of BinaryWave, a leading provider of operational intelligence solutions for Microsoft SharePoint. Eric Shupps eshupps The SharePoint Cowboy has worked with SharePoint Products and Technologies since 2001 as a consultant, administrator, architect, developer and trainer. he is an advisory committee member of the Dallas/Ft. Worth SharePoint Community group and participating member of user groups throughout the United Kingdom. Eric Shupps eshupps The SharePoint Cowboy has authored numerous articles on SharePoint, speaks at user group meetings and conferences around the world, and publishes a popular SharePoint blog at http://www.sharepointcowboy.com. Presentations by Eric Shupps eshupps The SharePoint Cowboy Webinar - Migrating Legacy On Premise Solutions to SharePoint Online and Windows Azure featuring Eric Shupps Who are you and what do you want - Working with OAuth in SharePoint 2013 SharePoint is Talking Are You Listening? Eric Shupps SharePoint 2013 Performance Enhancements Taking Advantage of the SharePoint 2013 REST API Eric Shupps on Improving Performance with New Features in SharePoint 2013 SharePoint 2013 New and Improved Migrating Legacy On Premise Solutions to SharePoint Online and Windows Azure Eric Shupps Presents SharePoint 2013 Real World Help Desk App End to End Windows Azure Apps for SharePoint 2013 Eric Shupps Demonstrates Customizing the Visual Studio 2010 SharePoint Deployment Process Introduction to SharePoint Development SharePoint 2010 Unit and Integration Testing with Eric Shupps Building Enterprise Records Management Solutions for SharePoint 2010 Taming Information Chaos in SharePoint 2010 SharePoint 2010 Performance and Capacity Planning Best Practices Building Dynamic Applications with the SharePoint Client Object Model Articles by Eric Shupps eshupps The SharePoint Cowboy Eric Shupps' Ten Steps to Optimize SharePoint Performance Webcasts by Eric Shupps eshupps The SharePoint Cowboy Secrets of SharePoint Part 5: Configuring Microsoft Office SharePoint Server 2007 for Optimal Performance Creating End User SharePoint Solutions for Performance and Scalability SharePoint 2010 Performance Enhancements for Administrators by Eric Shupps Microsoft SharePoint Server 2010 for the ASP.NET Developer Eric Shupps on Following Best Practices and Avoiding Common Errors with Microsoft Office SharePoint Server 2007 Development Eric Shupps - SharePoint Performance and Capacity Planning Essentials Troubleshooting Common Performance Problems in SharePoint 2010 Videos by Eric Shupps eshupps The SharePoint Cowboy Channel 9 Interview with Eric Shupps SharePoint TechTalk with Eric Shupps - Different Views on Social Computing SharePoint Post-Deployment Planning and Management with Eric Shupps SmartTrack for SharePoint Feature Overview SmartTrack for SharePoint Podcasts by Eric Shupps eshupps The SharePoint Cowboy SharePoint Pod Show - Design for Performance (Eric Shupps) SharePoint Pod Show - Test Driven Development with Andrew Woodward and Eric Shupps eshupps The SharePoint Cowboy Run As Radio - Eric Shupps Improves SharePoint Performance
SmartTrack for SharePoint Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave

 
​The SharePoint Cowboy


photo of  Eric Shupps
BinaryWave
611 S. Main St., Suite 400
Grapevine , TX , 76051 USA
Eric Shupps and Eric Alan Shupps with BinaryWave the BinaryWave Inc in BinaryWave Incorporated around SmartTrack beside SharePoint Monitoring through SharePoint alongside SharePoint Monitoring visiting @eshupps via eshupps near SharePoint performance and SharePoint management. The SharePoint cowboy eshupps BinaryWave and more on Operational Intelligence via Eric Alan Shupps SharePoint blog. SharePoint monitoring is a hot topic along with SharePoint Performance Measurement and SharePoint tips and tricks from Eric Shupps for SmartTrack. Another Eric Shupps on Technology and Eric Shupps on SharePoint with a new SharePoint Post from Eric Shupps. New BinaryWave post through BinaryWave Inc. and with another SharePoint blog we get to Eric Alan Shupps Blog about SharePoint development. That's Eric Shupps - BinaryWave or Eric Alan Shupps Fort Worth Grapevine Texas Dallas of BinaryWave talking about BinaryWave Operational Intelligence at the SharePoint Cowboy blog and on twitter as @eshupps. Of course SharePoint Administration is on topic for eshupps and another great post from Eric Shupps regarding BinaryWave SharePoint and SharePoint Maintenance.
March 20
How to Manually Disable Claims Authentication in SharePoint 2010

In a previous post I shared some thoughts regarding changes to authentication providers in SharePoint 2010. As I worked through the issue of removing Claims/FBA and reverting to NTLM I discovered a number of issues that manifested themselves in strange ways. The first problem I encountered was the inability for a Farm account to make changes to the Authentication Providers settings in Central Administration. The System Account couldn't even view the dialog – each attempt resulted in a 403 error. This was bad news as a lot of things happen behind the scenes when changing authentication settings in this dialog – not the least of which is propagation of changes to all the web servers. This meant I would have to undo all of the Claims settings manually and repeat them on each server. Not my idea of a fun afternoon.

 

I began by changing the authentication provider for my content web applications back to Classic mode using Powershell:

 

$webApp = Get-SPWebApplication http://site
$webApp.UseClaimsAuthentication = 0;
$webApp.Update()
$webApp.ProvisionGlobally()

 

Next, I removed the highlighted membership provider from inclusion in the people picker in all web applications, including Central Administration:

 

<PeoplePickerWildcards>

<clear />

<add key="AspNetSqlMembershipProvider" value="%" />

<add key="MyCustomMembershipProvider" value="%" />

</PeoplePickerWildcards>

 

The next part of the process involves the removal of role and membership provider information, along with any supporting connection strings, from the various web.config files. This has to be done for the Central Administration web app, the Security Token Service web app, and all content web apps that use Claims on each web server. The process is a bit different for each type of web application, so it's not just a simple matter of find and delete.


Starting with the Security Token Service, locate the web.config file in the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\WebServices\SecurityToken directory and remove all the entries added to enable Claims in the first place. Typically, these are located after the <system.net> entries in a new <system.web> node:

 

<system.web>

<membership defaultProvider="i">

<providers>

<add name="i" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

<add name="MyCustomMembershipProvider" connectionStringName="MyDBConnection" passwordAttemptWindow="2" maxInvalidPasswordAttempts="100" enablePasswordRetrieval="true" enablePasswordReset="true" requiresQuestionAndAnswer="false" applicationName="/" minRequiredNonalphanumericCharacters="0" minRequiredPasswordLength="8" requiresUniqueEmail="true" passwordFormat="Clear" description="Stores and Retrieves membership data from SQL Server" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

</providers>

</membership>

<roleManager defaultProvider="c" enabled="true" cacheRolesInCookie="false">

<providers>

<add name="c" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthRoleProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

<add name="MyCustomRoleProvider" connectionStringName="MyDBConnection" applicationName="/" description="Stores and retrieves roles from SQL Server" type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

</providers>

</roleManager>

</system.web>

 

Be sure to also remove any connection strings:

 

<connectionStrings>

<add name="MyDBConnection" connectionString="user id=[User/Password];
Persist Security Info=False;Initial Catalog=[Database Name];Data Source=[Server]" providerName="System.Data.SqlClient" />

</connectionStrings>

 

In the Central Administration web application config, the membership and role provider nodes have a slightly different syntax from the Security Token and content web applications but this doesn't have any bearing on the removal of Claims from the environment. Replace them with the out of the box configuration settings (basically an empty set of nodes), so this:

 

<roleManager defaultProvider="AspNetWindowsTokenRoleProvider" enabled="true" cacheRolesInCookie="false">

<providers>

<add name="MyCustomRoleProvider" connectionStringName="MyDBConnection" applicationName="/" description="Stores and retrieves roles from SQL Server" type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

</providers>

</roleManager>

<membership defaultProvider=" MyCustomMembershipProvider ">

<providers>

<add name="MyCustomMembershipProvider" connectionStringName="MyDBConnection" passwordAttemptWindow="2" maxInvalidPasswordAttempts="100" enablePasswordRetrieval="true" enablePasswordReset="true" requiresQuestionAndAnswer="false" applicationName="/" minRequiredNonalphanumericCharacters="0" minRequiredPasswordLength="8" requiresUniqueEmail="true" passwordFormat="Clear" description="Stores and Retrieves membership data from SQL Server" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

</providers>

</membership>

 

Becomes this:

 

<roleManager>

<providers>

</providers>

</roleManager>

<membership>

<providers>

</providers>

</membership>

 

We can now move on to the content web applications and remove the membership and role information, along with any connection strings, from those web.config files. Remember that this has to be done on every web server in the farm (including any application servers which have the Microsoft SharePoint Foundation Web Application role). Remove the following nodes in their entirety (if you wish, you may replace the <roleManager> and <membership> sections with empty nodes as was done with Central Administration):

 

<membership defaultProvider="i">

<providers>

<add name="i" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

<add name="MyCustomMembershipProvider" connectionStringName="MyDBConnection" passwordAttemptWindow="2" maxInvalidPasswordAttempts="100" enablePasswordRetrieval="true" enablePasswordReset="true" requiresQuestionAndAnswer="false" applicationName="/" minRequiredNonalphanumericCharacters="0" minRequiredPasswordLength="8" requiresUniqueEmail="true" passwordFormat="Clear" description="Stores and Retrieves membership data from SQL Server" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

</providers>

</membership>

<roleManager defaultProvider="c" enabled="true" cacheRolesInCookie="false">

<providers>

<add name="c" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthRoleProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

<add name="MyCustomRoleProvider" connectionStringName="MyDBConnection" applicationName="/" description="Stores and retrieves roles from SQL Server"
type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

</providers>

</roleManager>

 

<connectionStrings>

<add name="MyDBConnection" connectionString="user id=[User/Password];Persist
Security Info=False;Initial Catalog=LearningCounts;Data Source=[Server]" providerName="System.Data.SqlClient" />

</connectionStrings>

 

After the membership and role settings have been removed, the manner in which users are prompted for authentication must be changed. In Claims mode, a login form is presented to the user but in Classic mode we want the NTLM prompt instead. This setting is controlled by the following lines in the content web application web.config files:

 

<authentication mode="Forms">

<forms loginUrl="/_login/default.aspx" />

</authentication>

 

Changing it to the following will re-enable the NTLM prompt:

 

<authentication mode="Windows" />

 

The next step is to remove all Claims accounts from the web application in User Policy settings and replace them with NTLM accounts:

 

User Policy

 

At this point, Classic authentication should be working on all web applications. As mentioned previously, it will be necessary to remove and replace user accounts in SharePoint groups on each site collection and it may also be necessary to change entries in the Site Owners group. After getting this far, it would appear that Claims has been disabled – users should get an NTLM prompt when attempting to navigate to site pages and be able to login successfully. Alas, our work is not yet done. While the Claims authentication settings have been changed, there are a number of artifacts left behind in the web.config files which enable the system to process Claims identities. These artifacts won't prevent users from logging in using NTLM but they will cause various other issues, one of which is the strange behavior that occurs when attempting to login as a different user in the same browser session.

 

SharePoint provides a link in the Personal Actions menu entitled "Sign in as a different user". This link points to "/_layouts/closeconnection.aspx" with a query string argument of "?loginasanotheruser=true" and a second argument which points back to the referring page. If everything is working properly, the current user will be logged out and an NTLM prompt displayed for new user credentials. If things aren't in such good shape, the user will be redirected to the "/_layouts/accessdenied.aspx" page and receive a generic SharePoint error, which is exactly what happened to me. Digging through the ULS log files, I found the matching correlation ID which revealed the underlying error:

 

System.ArgumentException: Exception of type 'System.ArgumentException' was thrown.
Parameter name: identity

at Microsoft.SharePoint.Administration.Claims.SPClaimProviderManager.
GetUserIdentifierEncodedClaim(IIdentity identity)

at Microsoft.SharePoint.Administration.Claims.SPClaimExtensionMethods.
GetDisplayName(IClaimsIdentity claimsIdentity)

at Microsoft.SharePoint.ApplicationPages.AccessDeniedPage.OnLoad(EventArgs e)

at System.Web.UI.Control.LoadRecursive()

at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)    26b85aba-6b2a-4b96-93de-91aa18db98d3

 

The error indicates that the system is still trying to process user identities in Claims mode instead of Classic mode. To rectify this situation, it is necessary to remove all the Claims-related entries in the content web application web.config files. Your mileage may vary, but a compare on a clean non-Claims config file and the ones I had been working with revealed the following entries which needed to be cleaned up:

 

<httpModules>

<add name="FederatedAuthentication" type="Microsoft.SharePoint.IdentityModel.SPFederationAuthenticationModule, Microsoft.SharePoint.IdentityModel, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

<add name="SessionAuthentication" type="Microsoft.SharePoint.IdentityModel.SPSessionAuthenticationModule, Microsoft.SharePoint.IdentityModel, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

<add name="SPWindowsClaimsAuthentication" type="Microsoft.SharePoint.IdentityModel.SPWindowsClaimsAuthenticationHttpModule, Microsoft.SharePoint.IdentityModel, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

</httpModules>

 

<assemblies>

<add assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

<add assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

<add assembly="Microsoft.Web.CommandUI, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

<add assembly="Microsoft.SharePoint.Search, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

<add assembly="Microsoft.Office.Access.Server.UI, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

<add assembly="Microsoft.SharePoint.Publishing, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

<add assembly="Microsoft.Office.Server.Search, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

<add assembly="Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

<add assembly="Microsoft.SharePoint.IdentityModel, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

</assemblies>

 

<modules runAllManagedModulesForAllRequests="true">

<remove name="AnonymousIdentification" />

<remove name="FileAuthorization" />

<remove name="Profile" />

<remove name="WebDAVModule" />

<remove name="Session" />

<add name="SPRequestModule" preCondition="integratedMode" type="Microsoft.SharePoint.ApplicationRuntime.SPRequestModule, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

<add name="ScriptModule" preCondition="integratedMode" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

<add name="SharePoint14Module" preCondition="integratedMode" />

<add name="StateServiceModule" type="Microsoft.Office.Server.Administration.StateModule, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

<add name="RSRedirectModule" type="Microsoft.ReportingServices.SharePoint.Soap.RSRedirectModule, RSSharePointSoapProxy, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91" />

<add name="PublishingHttpModule" type="Microsoft.SharePoint.Publishing.PublishingHttpModule, Microsoft.SharePoint.Publishing, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

<add name="FederatedAuthentication" type="Microsoft.SharePoint.IdentityModel.SPFederationAuthenticationModule, Microsoft.SharePoint.IdentityModel, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

<add name="SessionAuthentication" type="Microsoft.SharePoint.IdentityModel.SPSessionAuthenticationModule, Microsoft.SharePoint.IdentityModel, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

<add name="SPWindowsClaimsAuthentication" type="Microsoft.SharePoint.IdentityModel.SPWindowsClaimsAuthenticationHttpModule, Microsoft.SharePoint.IdentityModel, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

</modules>

 

<microsoft.identityModel>

<service saveBootstrapTokens="true">

<audienceUris />

<issuerNameRegistry type="Microsoft.SharePoint.IdentityModel.SPPassiveIssuerNameRegistry, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral,
PublicKeyToken=71e9bce111e9429c" />

<securityTokenHandlers>

<clear />

<add type="Microsoft.IdentityModel.Tokens.X509SecurityTokenHandler,
Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35" />

<add type="Microsoft.SharePoint.IdentityModel.SPSaml11SecurityTokenHandler, Microsoft.SharePoint.IdentityModel, Version=14.0.0.0, Culture=neutral,
PublicKeyToken=71e9bce111e9429c">

<samlSecurityTokenRequirement>

<nameClaimType value="http://schemas.microsoft.com/sharepoint/2009/08/claims/userid" />

</samlSecurityTokenRequirement>

</add>

<add type="Microsoft.SharePoint.IdentityModel.SPTokenCache,
Microsoft.SharePoint.IdentityModel, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

</securityTokenHandlers>

<federatedAuthentication>

<wsFederation passiveRedirectEnabled="false" issuer=https://none
realm="https://none" />

<cookieHandler mode="Custom" path="/">

<customCookieHandler type="Microsoft.SharePoint.IdentityModel.SPChunkedCookieHandler, Microsoft.SharePoint.IdentityModel, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

</cookieHandler>

</federatedAuthentication>

</service>

</microsoft.identityModel>

 

Once these are removed, all Claims settings should be gone and Classic mode fully restored. Note that the above samples are all based on the AspNetMembershipProvider using SQL as the data source. Use of LDAP or other identity providers may result in a different set of configuration entries. Alter the procedure as necessary for your environment, remembering to compare a pre-Claims config file (if you have one) with a post-Claims file to identify all of the changes. Don't forget to check the Authorization settings in the IIS manager as well just to be sure everything is working properly.

 

 

 

 

 

 

 

Comments

There are no comments for this post.

Add Comment

Items on this list require content approval. Your submission will not appear in public views until approved by someone with proper rights. More information on content approval.

Title


Body *


Comment Date *

Select a date from the calendar.
Enter the current date to prevent automated spambot comments.

Spam Prevention *


How many letters, not including spaces, does it take to spell "SharePoint Cowboy"?

Attachments

 
photo of Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave Eric Shupps
BinaryWave
611 S. Main St., Suite 400
Grapevine , TX , 76051 USA

 
 
 
Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave 

Eric Shupps LinkedIn Eric Shupps Twitter Eric Shupps Facebook Eric Shupps Google+
 
 

 


 


BinaryWave Eric Shupps eshupps The SharePoint Cowboy SharePoint monitoring SharePoint monitoring tool SharePoint metrics SharePoint administratrion SharePoint monitoring best practices SharePoint management SharePoint management tool SharePoint operations SharePoint operationsmanagement SharePoint administration SharePoint administration tool SharePoint SLA SharePoint service level agreement SharePoint operational intelligence SharePoint performance SharePoint performance monitoring SharePoint analytics SharePoint real-time SharePoint intelligence SharePoint ITIL SharePoint service operations SharePoint uptime SharePoint alerts SharePoint health SharePoint tools SharePoint metrics SharePoint diagnostics SharePoint SmartTrack SmartTrack Operational Intelligence


Copyright © 2013 BinaryWave, Inc. All rights reserved.
This site is brought to you by BinaryWave in cooperation with Eric Shupps Eric Alan Shupps eshupps @eshupps The SharePoint Cowboy. We hope you enjoy the SharePoint-related content on topics such as performance, monitoring, administration, operations, support, business intelligence and more for SharePoint 2010, SharePoint 2013 and Office 365 created by Eric Shupps The SharePoint Cowboy. We also hope you will visit our product pages to learn more about SmartTrack, Operational Analytics for SharePoint, SharePoint monitoring, and SharePoint administration, while also discovering great offers from our partners. Please visit the blog of Eric Alan Shupps, Twitter handle @eshupps, for more information on application development, the SharePoint community, SharePoint performance, and general technology topics. Eric Shupps Eric Alan Shupps eshupps @eshupps The SharePoint Cowboy is the founder and President of BinaryWave, a leading provider of operational support solutions for SharePoint. Eric Shupps Eric Alan Shupps eshupps @eshupps The SharePoint Cowboy has worked with SharePoint Products and Technologies since 2001 as a consultant, administrator, architect, developer and trainer. He is an advisory committee member of the Dallas/Ft. Worth SharePoint Community group and participating member of user groups throughout the United Kingdom. Eric Shupps Eric Alan Shupps eshupps @eshupps The SharePoint Cowboy has authored numerous articles on SharePoint, speaks at user group meetings and conferences around the world, and publishes a popular SharePoint blog at http://www.binarywave.com/blogs/eshupps.