1. Claims Based Authentication in SharePoint 2013
Microsoft SharePoint
9/20/2018
Claims Based Authentication in SharePoint 2013
Steve Peschka
Sr. Principal Architect
Microsoft Corporation
© 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

2. Authentication Modes
SharePoint 2013 continues to offer support for both claims and classic authentication modes
However claims authentication is THE default authentication option now
Classic authentication mode is still there, but can only be managed in PowerShell – it’s gone from the UI
Support for classic mode is deprecated and will go away in a future release, so we recommend moving to Claims
There also a new process to migrate accounts from Windows classic to Windows claims
In SharePoint 2013 we still support both claims and classic authentication, however claims authentication is now the default authentication option. That means Windows claims, forms based authentication claims, or SAML claims. You can no longer create a web application in central admin that uses classic authentication, but it can be done with PowerShell. At this point we are deprecating support for classic authentication and it will go away in a future release, so we strongly recommend that you move to claims authentication. This is a new process also in SharePoint 2013 to do the migration of accounts from Windows classic to Windows claims.
*************************************
Pg. 41
Reviewer Notes:
<Sesha>
Bullet point#3: When you say ‘new process’ do you intend to say ‘new cmdlet’? The overall process i.e. run a cmdlet against a windows classic web app in order to convert it to windows claims hasn’t changed.
STEVE: The process itself is different if you compare it to what was documented from o14 (i.e. in my blog, which was the defacto statement on this)
Bullet point#2: We should also call out that Classic is going away so that the customers can start preparing to move to Claims now itself.
STEVE: Added content to bullet 2a to address this
STEVE: Removed this bullet since subsequent slide has now been reviewed: Details to be released post Beta 1

3. Authentication Migration
The MigrateUsers method in SharePoint 2010 is no longer the correct way to migrate accounts – it is now deprecated
A new cmdlet has been created called Convert-SPWebApplication
A simple example – you have a Windows classic web application
Run Convert-SPWebApplication -Identity " -To Claims –RetainPermissions [-Force]
Your FIRST option for migrating from classic to claims is to do so in SharePoint 2010 before you migrate your content to SharePoint 2013
In SharePoint 2010 we used the MigrateUsers method of the web application to migrate users from classic to claims; in SharePoint 2013 that has been changed. There is a new PowerShell cmdlet called Convert- SPWebApplication that is used instead. Here’s a simple example to convert an existing Windows classic web application – just run the cmdlet and pass to it the web application to convert, set the TO parameter to claims, and use the RetainPermissions flag. When you’re planning your move from SharePoint 2010 to SharePoint we encourage you to do the claims migration first while you’re still in SharePoint 2010, and then upgrade your farm afterwards. That way if there are issues migrating the accounts it can be determined ahead of time so you don’t need to try and figure out if an issue is being caused by an authentication migration or a content migration.
****************************
Pg. 41
Reviewer Notes:
<Sesha>
The cmdlet is Convert-SPWebApplication and the syntax is as below:
Convert-SPWebApplication -Identity "web app, example: -To Claims – RetainPermissions [-Force]
Other comment from Sesha:
Bullet 1:
We should call out that MigrateUsers is deprecated in O2013.

4. Other Claims Migration Scenarios
If you don’t migrate from classic to claims in SharePoint 2010, you have these options to migrate a SharePoint 2010 content DB:
Option 1:
Create a web application in SharePoint 2013 that uses Windows classic authentication
Attach the SharePoint 2010 content database to this SharePoint 2013 web app
Attaching it will upgrade it to the SharePoint 2013 database format, so verify that it is working correctly after attach
Run the Convert-SPWebApplication cmdlet on the SharePoint 2013 web app to convert the users from Windows classic to Windows claims
Detach the content database from the SharePoint 2013 Windows classic web app
Attach the content database to its final SharePoint 2013 Windows claims web app
Option 2:
Attach the content DB to an existing Windows claims web application
Run the MigrateUsersToClaims method on the content database only (explained next)
If you are migrating a content database from SharePoint 2010 to SharePoint 2013 you have a couple of choices. You can create a web application that uses Windows classic authentication. Attached the SharePoint content database to it, which will upgrade the content. Test all the content afterwards to make sure that it is working. Then run the Convert-SPWebApplication cmdlet on the web app to convert the users from classic to claim. Try it out again to make sure all is working, then if you are in a test environment you can detach the content database from the test web application and attach it to the final production web app where it will live. You would probably only go through all of these steps when you are first bringing your content over. After you have migrated one or two content databases you will probably just want to go the more direct route outlined in option 2. Attach the content database to an existing SharePoint 2013 Windows claims web application, then run the MigrateUsersToClaims method on the database.
************************************
From OneNote notes of call with Sesha
Reviewer Notes:
<Sesha>
Steve, I’ve sent a mail on the steps and once we close on that, then this slide can accordingly be updated.

5. Claims Migration for Content Databases
Microsoft SharePoint Server 2013
Claims Migration for Content Databases
The Convert-SPWebApplication cmdlet does migration at the web application level
SharePoint 2013 also allows you to migrate only a single content database
Very useful during upgrade, since most content will be moved with DB attach
A new method has been added to the SPWebApplication class for this purpose - MigrateUsersToClaims
The Convert-SPWebApplication cmdlet is really designed to migrate an entire web application, but we provide a different method to just migrate an individual content database. There is a new method that’s been added to the SPWebApplication class called MigrateUsersToClaims. As the PowerShell snippet here demonstrates, you just get a reference to your web application, create a new argument object for the database or databases you want to migrate, and then call the MigrateUsersToClaims method. The domain\user argument should be the domain and username of the person that is running the PowerShell cmdlet. They are temporarily granted elevated rights in the web application while the migration is being performed, and then those elevated rights are removed again. It does not refer to the account that is being migrated though – all classic groups and accounts are migrated to claims.
***********************************************
$wa = Get-SPWebApplication
$arguments = New-Object Microsoft.SharePoint.Administration.SPWebApplication+SPMigrateUserParameters
$arguments.AddDatabaseToMigrate($wa.ContentDatabases[contentDbNumberYouWantToMigrate])
$wa.MigrateUsersToClaims("domain\user", $true, $arguments)
© 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

6. Authentication Infrastructure
One of the big improvements is that SharePoint tracks FedAuth cookies in the new Distributed Cache Service
In SharePoint 2010 each WFE had its own copy
That meant that if you got redirected to a different WFE, you would need to re-authenticate
Having the Distributed Cache service means that sticky sessions are no longer required when using SAML or FBA claims!
One of the big changes for the authentication infrastructure is being able to use the new Distributed Cache Service. SharePoint uses that caching service to keep track of FedAuth cookies for users that authenticate using FBA or SAML authentication. In SharePoint 2010 each web front end kept their own local cache of fed auth cookies, and as a result we required you to use sticky sessions with your load balancers to ensure that once a user got authenticated, he or she was always redirected back to the same server so the authentication cookie could be found. By using the new Distributed Cache to keep track of these authentication cookies, we no longer require sticky sessions when you use FBA or SAML claims in SharePoint 2013.
***************************************************
Not sure where I saw this, but may have been in the Velocity spec

7. New Claims Features
You can choose the characters for the claim type and there is no enforcement on the ordering of claim providers
Pre-populate the custom claim types and characters across all farms
Install the claim providers that use those custom claim types in any order
You can add multiple token signing certificates to the SharePoint STS
Useful in S2S scenarios
Use the Set-SPSecurityTokenServiceConfig cmdlet
Some of the new claims features in SharePoint 2013 include having the ability to choose the characters for the claim type. This could be an issue in SharePoint 2010 where you were connecting multiple farms together, like a services farm and one or more content farms. Part of the value for a claim is based on the order in which the claim provider is installed in the farm, so in order to get claim values to be the same for users across different farms you had to make sure that you installed all your claims providers in the same order on all of them. Now though you can control that part of the claim value that was previously based on the order in which the provider was installed, so it gives you more flexibility when deploying large installations.
In addition, you can now also have multiple token signing certificates for the SharePoint STS. This can be useful in cases where you are replacing the default STS token signing certificate because you want to expire the certificate on a regular basis. Having multiple certificates allows you keep supporting existing trusts, such as you would have in a Server to Server, or S2S, trust when you expire one token signing certificate out and bring a new one in.
The exact cmdlet to use to add multiple token signing certificates to SharePoint is:
Set-SPSecurityTokenServiceConfig and –queueSigningCertificate or –revokeSigningCertificate
Pg. 42 and OneNote notes of call with Sesha
Reviewer Notes:
<Sesha>
First bullet said “…ordering of claim types” but should say “…claim providers”
<Bullet point #1>We had this in the spec but the full feature didn't make it in, I will need to double-check.
Sesha’s comment next to bullet point #1: We had this in the spec but the full feature didn't make in. Claim mappings are immutable, however, the customer can choose specific characters for the claim type and no enforcement on the ordering of claim types.
Per Sesha’s , support for an updateable claim collection has been dropped, so it is considered to be immutable again. So that bullet was deleted.

8. Authentication Logging
There is significantly more logging provided to help troubleshoot authentication issues. You can see things like:
Adding / removing FedAuth cookies from the cache
Where authentication requests get redirected
Which claims providers were used and which were not
Reason why a FedAuth cookie failed to be used (i.e. expiration, failure to decrypt, etc.)
Finally, we also improved our logging support for authentication issues in SharePoint Now you can see things like when fedauth cookies are added or removed from cache, where authentication requests get redirected, what claims providers were used and reasons why a particular fed auth cookie may NOT have been used.
That concludes this look at what’s new in claims authentication in SharePoint 2013.
**********************
Pg. 41

9. 9/20/2018 8:02 AM
© 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.
© 2010 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.