Go to KBArticle
And the solution is to temporarily disable the local security authority credential cache on your ADFS servers. Jump to the KB article and follow the instructions.
Considerations When Using Claims with SharePoint
Users who
access a SharePoint 2010 application that is configured to use
claims-based authentication and has multiple authentication methods set
up will have the same access to resources and services
when using
any of the authentication methods. However, if the user has two
different accounts configured (in other words, has accounts in two
different repositories, such as a social identity provider and
ASP.NET), and
the authentication method used validates the user against one
of these accounts, the user will have access to only resources and services
configured for the account that was validated.
When upgrading existing applications to SharePoint 2010, be aware of the following factors that may affect your choice of authentication type:
- Claims-based authentication requires communication over HTTPS with a token issuer and identity provider. It typically also requires multiple redirects for clients that are using a web browser. These are likely to be slower than Windows Authentication or ASP.NET forms-based authentication lookup. Even after initial authentication, as users move between applications taking advantage of single sign-on, the applications and services must make calls over HTTPS to validate the authentication tokens.
- Web Parts or custom code that relies on or uses Windows identities must be modified if you choose claims-based authentication. Consider choosing classic mode authentication until all custom code is updated.
- When you upgrade a web application from classic mode to claims-based authentication, you must use Windows PowerShell®command-line interface to convert Windows identities to claims identities. This can take time, and you must factor in time for this operation as part of the upgrade process.
- Search alerts are currently not supported with claims-based authentication.
- You cannot use custom ISAPI extensions or HTTP modules with the forms-based authentication method because the SharePoint STS communicates directly with the forms authentication provider by calling its ValidateUsermethod.
- Some client-hosted applications may attempt to authenticate with the server when displaying content linked from SharePoint application web pages. If you are using claims-based authentication and the client-hosted application is not claims-aware (as in the case of Windows Media Player), this content might not be displayed.
- Managing the session lifetime is not a trivial exercise when using claims-based authentication. For details of how you can manage session lifetime, see Chapter 11, “Claims-Based Single Sign-On for Microsoft SharePoint 2010.”
- The External Content Type Designer in SharePoint Designer 2010 cannot discover claims aware WSDL endpoints. For more information, see MSDN®Knowledge Base article 982268 at Link
SharePoint 2013 & SkyDrive(Pro)
SkyDive Pro in SharePoint 2013 has nothing to do with SkyDrive.com. Do not worry, nothing will go to Microsoft's server or users personal SkyDrive accounts.
SkyDrive Pro, while being your MySite Documents library, is also the name of the technology that syncs SharePoint 2013 to your desktop.
The desktop sync works like original SkyDrive with an entry in favorites of windows explorer. You can have multiple libraries synced to your desktop (now drag and drop documents).
References
SkyDrive Pro, while being your MySite Documents library, is also the name of the technology that syncs SharePoint 2013 to your desktop.
The desktop sync works like original SkyDrive with an entry in favorites of windows explorer. You can have multiple libraries synced to your desktop (now drag and drop documents).
References
Cross-site publishing in SharePoint 2013
The great site barrier for content in SharePoint has been
the pivot for development projects for long. Ranging from custom event
handlers, custom timer jobs, even custom windows services etc. to harvest data
from cross sites have been common talk.
And then SharePoint 2013 walks in like a boss and turns off
the switch on all of above. The question is how this fits with your needs and
where/how can you avoid custom code?
A simple example can be when you want to publish the content
secured behind your intranet to extranet or to the internet site. With this
feature you can pull news/blog entries from the company’s intranet and publish
them on your public website. This will act like a passive hot link to the item
on your secured site with the refresh rate dependent on the search crawl.
Basics
There are a few logical components to consider
- An authoring site is where content is created and hosted
- A catalog is an attribute that you can add to a list or a library in the authoring site. Marking a list or a library as a catalog makes the content easily accessible to other site collections.
- Search is the engine/glue that connects your catalog to a publishing site.
- The term store holds metadata terms that are used to organize content for publishing on target sites.
- A publishing site is where visitors go to see and read content.
Limitation
The content which can be indexed is the requirement for
cross site publishing. The files (images, documents) still need to be handled traditionally.
Benefits of Using Cross Site Publishing
- Site architectures will have a broader canvas (Do remember to plan the assets).
- Allows content to be shared anonymously from intranets/extranets
- Can be used across site collections and even across farms.
- Separates content authoring from branding and rendering , avoids content duplication.
Subscribe to:
Posts (Atom)
