Creating Claims-Based Web Applications in SharePoint 2013
This post is going to talk about how to create claims-based web applications in SharePoint 2013. This is actually something else that I ran into when I was configuring my own lab environment, and everybody will run into this at one point or another in the lifecycle of their SharePoint 2013 environment. The reason for that is that Windows classic mode authentication is deprecated in SharePoint 2013. And this is well documented in this article:
What's new in authentication for SharePoint 2013
Background
As I said, I ran into this issue when I was configuring my own lab environment. I was using some existing scripts I had for SharePoint 2010, since most of them work, in order to create several web applications. If you haven't seen the documentation on TechNet, don't worry. SharePoint is pretty good about telling you that classic mode authentication has been deprecated in SharePoint 2013. This is a screenshot of what you will see if you configure a Windows classic mode authentication web application:
This is the text contained in the informational message, in case you're encounter the issue:
WARNING: The Windows Classic authentication method is deprecated in this release and the default behavior of this cmdlet, which creates Windows Classic based web application, is obsolete. It is recommended to use Claims authentication methods. You can create a web application that uses Claims authentication method by specifying the AuthenticationProvider parameter set in this cmdlet. Refer to the https://go.microsoft.com/fwlink/?LinkId=234549 site for more information. Please note that the default behavior of this cmdlet is expected to change in the future release to create a Claims authentication based web application instead of a Windows Classic based web application.
The good news is, we won't have to think about this forever – and it will end up being automatic eventually.
Issue
I ran into a few issues with this. The first issue I ran into with this was that using my SharePoint 2010 scripts and simply passing the AuthenticationProvider parameter my web applications were not consistently being deployed using windows claims authentication. The first web application would get created with windows claims authentication, every subsequent web application would ignore the AuthenticationProvider parameter and the web application would be created using windows classic authentication.
When this occurred, this would set off a chain of failures in my scripts, particularly when creating web application policies and assigning object cache accounts. The error message that you when this happens is also pretty helpful, and shouldn't set you back too far. Here's a screenshot:
This is the text contained in the error message, in case you encounter the issue:
The specified principal does not correspond to the authentication mode of this collection
Resolution
I never did find out why I was having inconsistent AuthenticationProvider behavior. It was however resolved by rewriting my PowerShell script, and breaking everything out into functions created using claims authentication. I've made the script that I'm using available in the TechNet Gallery. The script itself does have a significant amount of conflict and error detection, and should make deploying claims authentication web applications in SharePoint Server 2013 pretty simple.
Download
The script can be downloaded from the following location:
Download CreateSP2013ClaimsWebApplication.ps1 (zipped)
Feedback
As always, if you have any questions or feedback, let me know. If you have any ideas to optimize the script, I'd like to hear that too. Thanks for reading!
You can also follow me on Twitter:
Comments
Anonymous
September 24, 2014
I'm confused on one aspect of the process. Based on what I have read, i.e. www.sharepoint2013.me/.../object-cache-user-accounts-in-SharePoint, the super reader and super user accounts have to be added with the appropriate permissions to the web application (which first needs to be created). So in your script how do the lines: $WebApp.Properties["portalsuperuseraccount"] = $PortalSuperUser $WebApp.Properties["portalsuperreaderaccount"] = $PortalSuperReader where (similar to) $PortalSuperReader = "i:0#.w|domainsp_superreader" $PortalSuperUser = "i:0#.w|domainsp_superuser" do not exist yet (they do in AD but can't possibly be added to the User Policy of the web application yet, since it hasn't been created). Am I missing something here? Do they just, first, need to be added as a managed account under .../_admin/ManagedAccounts.aspx and that is enough? Thanks.Anonymous
September 24, 2014
Oh wait, it's been a long day... you update the web app in the SetObjectCache, since it is created earlier in the script. Sorry about that, its been a long day :P