14

To get claim for All Authenticated Users in PS you need to use: $claim = New-SPClaimsPrincipal -EncodedClaim "c:0(.s|true" for windows users (NT AUTHORITY\authenticated users): $claim = New-SPClaimsPrincipal -EncodedClaim "c:0!.s|windows" and for all forms authenticated users (basic asp.net membership provider) $claim = New-SPClaimsPrincipal -...


9

"Keyset does not exist" means you need to give your web application pool identity account access to your certificate. Do this in the Certificates Snap In.


8

AFAIK, there is no automatic mapping between claims and the My Settings page. For instance, providing an "email" claim does not populate the "email" field. Update: actually, it seems that IF your identity claim is of type http://schema.microsoft.com/.../emailaddress AND your identity claim value looks like an email, then your email gets populated (I found ...


7

You need to configure the farm to trust LiveID. Technet has documentation on configuring claims for LiveID http://technet.microsoft.com/en-us/library/ff973117.aspx Edit I have not implemented this myself, so I'm speaking just from knowledge of how I perceive it to work. I don't think you need to edit the _trust/default.aspx page, but implement a custom ...


7

We all know the first time that you navigate to a Microsoft SharePoint 2010 site that is secured with SAML claims, it redirects you to get authenticated to ADFS , get your claims. Your SAML identity provider, also known as identity provider security token service (IP-STS), does all that and then redirects you to SharePoint. The terms you are talking about ...


6

I havent tried this for claims in SP2010, but in SP2007 this was done for FBA by adding PeoplePickerWildCard element to membership provider in web.config <PeoplePickerWildcards> <clear /> <add key="AspNetSqlMembershipProvider" value="%" /> <add key="fbaMembers" value="%" /> </PeoplePickerWildcards> http://msdn.microsoft....


5

If you already created a webapplication with claim based authentication. Open Central Administration Go to the webapplication list en select your webapplication In the ribbon - click Authentication providers


5

I had the same problem when creating my custom login page, and the answer was to add the "/_layouts" to the front of the path I was linking to. Creating a Simple Shared Login Screen If you want some form of shared login screen, without needing the IP address or a feature or anything else, here's what I did to get that: For each site involved, created a ...


5

Instead of a network credential, you will need a SharePoint Online Credential: http://msdn.microsoft.com/en-us/library/office/microsoft.sharepoint.client.sharepointonlinecredentials_members(v=office.15).aspx


5

WindowsTokenLifetime: lifetime of tokens issued to logins that use Windows-based login LogonTokenCacheExpirationWindow: minimum lifetime of a token returned from the logon token cache. As title of both property is telling the story, one is actual setting and 2nd is cache of actual.Tokens which are currently valid, but will be expired after the time ...


4

I think that the 3 web config will need to be configured differently eg This for your FBA Site <membership defaultProvider="i"> <providers> <add name="i" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> &...


4

Usernames display as "domain\username" when User Profile Synchronziation has not yet been configured or there is issues with the service application / synchronization once it has been setup. Here is the MS TechNet information on how to configure User Profile Sync - http://technet.microsoft.com/en-us/library/ee721049.aspx.


4

IMHO - I reproduced the issue you are having on one of our systems except for the use of Claims authentication. My search account does have 'Read' access for the web application. A list was created and anonymous access was initially enabled from inheritance. The search index was already built (it is scheduled to run often) and could query the list as ...


4

Actually a hotfix did help. http://support.microsoft.com/kb/2536591/en-us. This is a sharepoint bug and the hotfix does fix it. Search for "people picker" on the kb-page and you will find following text: "After you apply the hotfix package that is described in KB article 2516472, the Trusted Identity claim provider does not appear when you open SharePoint ...


4

Every column in SharePoint has 3 names: InternalName (just called Name in <Field> and <FieldRef> elements) StaticName DisplayName (called Title in SPField) InternalName can't be changed after field has been created StaticName can be changed through code DisplayName can be changed through code/UI When accessing data/fields you should always ...


4

There is no way to change the claimprovider back to the original one. You'll have to remove the SPTrustedIdentityTokenIssuer and create it again with the right settings. Be sure to use the same name if you want your existing users to be able to login again. Remove your SPTrustedIdentityTokenIssuer from all web applications Delete your ...


4

I believe that SP2010 and SP2013 both support/utilize WIF (Windows Identity Foundation) for claims-based authentication. (semi) Recently, there was a WIF extension released to support the SAML 2.0 protocol. http://blogs.msdn.com/b/card/archive/2011/05/16/announcing-the-wif-extension-for-saml-2-0-protocol-community-technology-preview.aspx With some ...


4

I think SharePoint doesn't support SAML v2.0 even we are talking about WIF. I tried to handle SAML 2.0 token in SharePoint but unfortunately it seems that doesn't work so far, like SharePoint engine can't do that ;/


4

SharePoint 2013 only supports SAML 1.1. source


4

I've come across this error before, it was because the ADFS server was not configured correctly. When configuring the relying party in ADFS - for SharePoint - you have to add "/_trust" to the "WS-Federation Passive protocol URL" field. See step 11 in this guide. Steve Peschka also mentions it on his blog: http://blogs.technet.com/b/speschka/archive/2012/05/...


4

It might be worth a shot to try adding ACS as an App in Azure AD, configure it for Single Sign-On and then using the WS-Federation end point for the app to add the Identity Provider. The first part of this post has a more detailed walkthrough: http://blog.helloitsliam.com/Lists/Posts/Post.aspx?List=e10cb685-6b5c-4b6c-aaf4-e1d122d57174&ID=120


4

With PowerShell: $sts = Get-SPSecurityTokenServiceConfig $sts.UseSessionCookies = $true $sts.Update() iisreset http://msdn.microsoft.com/en-us/library/office/hh147183(v=office.14).aspx


4

SharePoint also tries to convert accounts, which are disabled or deleted from ActiveDirectory. Those accounts cannot be converted and produce this error message in ULS-Log. This is normal and cannot be avoided or solved.


3

My own answer to my question: I gave Full Read to All Authenticated Users on the web application level then added All Authenticated Users to Site Members.


3

Take a look at Using SAML Claims, SharePoint, WCF, Claims to Windows Token Service and Constrained Delegation to Access SQL Server or look through articles in the blog. They might give you a clue


3

InfoPath Form Services does not support claims based authentication (that's what MS Support told us, when we faced a similar issue with Nintex Workflow.asmx about a month back). If you look in the IIS logs you will see that the calls to the UserProfileService.asmx are getting made as nt authority\anonymous user instead of the currently logged in user. This ...


3

You will find entries similar to the following in the section of the web.config for your web application or in the root web.config if you configured FBA at the IIS root. You can change the name(s) directly in the web.config file. <roleManager> <providers> <add name="FBARoleProvider" type="System.Web.Security....


3

I ended up removing all the non-claims users in the new site, and replaced references to the old user with the new user where applicable. I created this PS-function to remove all non claims users from the rootweb (since webs inherit users by default) function RemoveOldUsers([Microsoft.SharePoint.SPWeb]$web) { $oldUsers = @() $web.AllUsers | ? {!$...


3

My guess is that you didn't set claims provider to be default membership and role provider. This is common mistake and I reproduced exactly the same error on my machine. After setting up FBA providers in web.config (most likely with IIS manager) in most explanations next step is to set FBA provider as default membership and role provider. This is 'required' ...


3

You should just be able to use SPWeb.EnsureUser. It understands claims. For example (from Tyler Holmes): SPUser spUser = web.EnsureUser(string.Format("i:0#.f|providerName|{0}", fbaUser.UserName)); spUser.Name = "FriendlyName"; spUser.Update();


Only top voted, non community-wiki answers of a minimum length are eligible