Tag Info

Hot answers tagged

7

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


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


5

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


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

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


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


3

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.


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


3

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


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


3

customer.Collaboration.Provisioning.SPI.EventReceivers.ProjectProvisioningEventReceiver.ProjectProvisioningEventReceiver.ItemAdded(SPItemEventProperties properties) This means that your ItemAdded Receiver for ProjectProvisioning feature fails. It will report site creation as failed because it rolls back and throws an exception. Take out all custom ...


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

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

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


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

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

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


3

I had faced the similar issue when i was working with STS. The reason you get the error is because there is no trust being established between the Sharepoint and STS . If i am not wrong you might be getting the error at the below lines of code :) This is definitely a certificate issue. SecurityTokenService sts = new ...


3

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


2

Have you verified that the portalsuperuseraccount and portalsuperreaderaccount properties of the web application are set to Claims-based account names? If they were set before the migration, they may still exist in a non-Claims encoded format. You can update these values through PowerShell: $wa.Properties["portalsuperuseraccount"] = "i:0#.w|domain\apppool" ...


2

As I noted in my comment above, I think navigating to "_windows/default.aspx" will redirect you to the custom login page. I think the best approach would be to add an option to your custom login page to login using Windows Authentication. You can present the user with the username/password as being the default method for login, but have a link or button ...


2

These settings are stored in Web.Config file. Use following techniques to work with web.config files in SharePoint world. Working with Web.config Files How to: Add and Remove Web.config Settings Programmatically It is important to update the config files the "sharepoint way" so that the changes can be applied to all Web Servers in the farm.


2

To simply change application to Claims authentication from code you can use: SPWebApplication webApp = SPWebApplication.Lookup(new Uri("http://testwebapp/")); webApp.UseClaimsAuthentication = true; webApp.Update(); But my suggestion is that you use PowerShell or Central Administration to setup Claims.


2

Maybe you can try different approach. You can secure application in page code rather to alter/add web.config file(s). This link is bit old but for general info will be ok: http://msdn.microsoft.com/en-us/library/dd878359(v=office.12).aspx#SecuringAppPages_ValidatingUserPermissions I still have few scars left from my last fight with Sharepoint web.config.



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