This blog post was written about the Preview of SharePoint 2013. This behavior may be different in the RTM version of the product.
It’s been a tough pill to swallow, but like my friend Wictor Wilen put it, Claims is the new black. Keeping that in mind, I’ve decided to embrace Claims and pretend like I’ve liked it all along. I put my newfound love of Claims to the test this week when I was building out a shiny new SharePoint 2013 farm. Since I’ll be doing this a lot I decided that I should use my BFF PowerShell to script as much as I could. This included creating my Web Applications.
Wictor’s blog post covers it, but let me recap. In SharePoint 2013 the default authentication provider is Claims. If you create a Web Application in Central Administration you don’t get the option for Claims or Classic like you did in SharePoint 2010. It’s just Claims. If for some reason you do need a Classic Web Application, you can create it in PowerShell with the New-SPWebApplication cmdlet. However, since Claims and I go way back, I wanted to create a Claims web application. Turns out that’s harder to do than I thought it would be. In my head one of the switches of New-SPWebApplication would let me specify that I wanted the fancy new Claims, but alas that was not the case. I also thought that since Claims was the default if I just didn’t specify anything that I’d get a Claims Web Application. I was wrong. That’s twice in one day! I did however get something that I thought would help:
This gives me a stern talking to and tells me that Classic is deprecated and that I should use Claims. Buddy, I’m already on board! It does give me hope though, it points me to a URL. Of course, quick like a bunny, I pasted that URL into the nearest web browser I could find. Unfortunately that page is just the MSDN documentation for New-SPWebApplication. Like the message above says, it mentions you have to specify an AuthenticationProvider parameter, but it doesn’t tell you which parameter. Curses, foiled again! Back to the drawing board.
I did some furious Binging and found out the part I needed. Before I call New-SPWebApplication I need to create a SPAuthenticationProvider object to pass it. If I play my cards right, that object will tell SharePoint to hook me up with that gooey Claimsy goodness. The PowerShell looks like this:
Here it is in text for your copying and pasting pleasure.
$ap = New-SPAuthenticationProvider -UseWindowsIntegratedAuthentication -DisableKerberos
New-SPWebApplication -Name "Shane Stinks" -ApplicationPool "Default SharePoint Web Apps" -HostHeader shanestinks.contoso.com -Port 80 -Url http://shanestinks.contoso.com -AuthenticationMethod NTLM -AuthenticationProvider $ap -DatabaseName "WSS_Content_ShaneStinks"
Notice a few things about this. First, creating a new Web Application is now more steps. We have to create the SPAuthenticationProvider object, then we pass that to New-SPWebApplication. New-SPAuthenticationProvider has a few switches, so be sure to do a help New-SPAuthenticationProvider before you use it, so you use the right switches. Second, you’ll notice that even though I’m creating a Claims aware Web Application I still get yelled at about it. Is it never enough for you New-SPWebApplication?? If you doubt yourself you can use this PowerShell to verify your new Web Application is really down with Claims:
Get-SPWebApplication | select displayname, url, UseClaimsAuthentication
You can also verify this in Central Admin. Since we didn’t specify any Claims Providers this will give us the plain Jane Windows Authentication. If you want to create a Web Application that uses a different Claims Provider the steps are different. Fortunately there are a lot of blog posts that cover that, so you’re in good shape.