Recommended
Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
Sharepoint 2013 Feature
- 1. ©2012 Microsoft Corporation. All rights reserved.
- 2. ©2012 Microsoft Corporation. All rights reserved.
- 3. ©2012 Microsoft Corporation. All rights reserved.
- 4. ©2012 Microsoft Corporation. All rights reserved.
- 5. ©2012 Microsoft Corporation. All rights reserved.
- 6. If you want to do this to an endpoint ©2012 Microsoft Corporation. All rights reserved. Use this HTTP request Keep in mind Read a resource GET Create or update a resource POST Use POST to create entities such as lists and sites. The SharePoint 2013 REST service supports sending POSTcommands that include object definitions to endpoints that represent collections. Update or insert a resource PUT Use PUT and MERGE operations to update existing SharePoint objects. Delete a resource DELETE Use the HTTP DELETE command against the specific endpoint URL to delete the SharePoint object represented by that endpoint.
- 7. http://server/site/_api/site http://server/site/_api/web ©2012 Microsoft Corporation. All rights reserved.
- 8. ©2012 Microsoft Corporation. All rights reserved.
Editor's Notes
- 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
- 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 2013 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: http://webapp:80" -To Claims –RetainPermissions [-Force] Other comment from Sesha: Bullet 1: We should call out that MigrateUsers is deprecated in O2013.
- 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 2010 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.
- 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. ***********************************************
- 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
- 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 email, support for an updateable claim collection has been dropped, so it is considered to be immutable again. So that bullet was deleted.
- Finally, we also improved our logging support for authentication issues in SharePoint 2013. 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