Hot answers tagged

12

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.


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> ...


6

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 ...


6

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 ...


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

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


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

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

you can only use BCS to embelish existing windows account based profiles with additional properties (regardless of how they authenticate, which has nothing to do with UPS) the primary source of the account must be windows principals. that is why for example we can't directly sync with AD LDS


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

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 ...


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: ...


4

I can't comment on user1272352's answer (rep too low), but that is correct. 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. 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: ...


3

You can define custom signout URL with PowerShell. Set-SPCustomLayoutsPage -identity "Signout" -RelativePath "/_layouts/customsignout.aspx" -WebApplication "http://server_name/mywebapp" You can view the current signout page with Get-SPCustomLayoutsPage -Identity "Signout" -WebApplication "http://server_name/mywebapp"


3

I called Microsoft on this (case 11303‚Äč0110256288) and it's a product bug in 2013 - apparently a regression from 2010. Another customer had reported the same issue. It's an acknowledged bug with no KB yet. They hope to pick it up in an upcoming cumulative update but it wasn't know when to expect it yet.


3

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 ...


3

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 ...


3

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 unfortunatelly it seems that doesn't work so far, like sharepoint engine can't do that ;/


3

MSDN: Why Use Claims-Based Identity


3

you should be understanding the concept of Authentication Providers in Sharepoint which makes use of claims based authentication. For your requirement you need to implement SSO for your application which would be done by STS in Sharepoint 2010.You need to implement and get the SAML2.0 token from Identity provider(that is the 3rd party network) and convert to ...


3

Yes you can! You can switch your Authentication Provider between either Claims Based Authentication(CBA) or Classic Authentication, before embarking on changing the authentication provider I would first recommend reading the following technical articles: Migrate from classic-mode to claims-based authentication Plan Authentication Method More information ...


3

Switching from claims to classic is possible (as @saumilm describes), but it's not supported and you have to recreate all permissions. In your comment to @saumilm you mention that you haven't created your webapp yet, wants to start with windows, but have to option to add forms later. In that case you're free to choose, forms is claims, so you can start with ...


3

You can get claims through below code: var claimsPrincipal = Page.User as IClaimsPrincipal; if (claimsPrincipal != null) { IClaimsIdentity claimsIdentity = (IClaimsIdentity)claimsPrincipal.Identity; var userClaims = claimsIdentity.Claims; } But if you want to add the claim at the time of ...


3

I'm not entirely certain this will work, but you could try inspecting HttpContext.User.Identity within the RunWithElevatedPrivileges delegate, and see if it returns the application pool identity. If so, you could provide some way of retrieving the application pool identity for a given SPWebApplication (possibly via SPWebApplication.ApplicationPool?), and ...


3

I ended up writing my own custom membership and roles provider. This allowed me to not have to use the default FBA configuration in SharePoint 2010 that now uses Claims. This article got me started. I then customized to meet my requirements. ...


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();


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

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 | ? ...



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