Hot answers tagged

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.


7

The big difference with claims based authentication is that you can easily (well it is still SharePoint) add other providers. For example you can add another provider and being able to sign in with your google account, live-id, linkedin account etc etc. Claims-based identity allows you to factor out the authentication logic from individual applications. ...


6

Try to prefix the username with the membership provider info. It would look something like: web.EnsureUser("i:0#.f|membershiprovidername|username");


4

Answering myself... I changed the script to perform these operations : Create the webapp with only Windows Auth Enable Claims authentication on the web app Add the remaining auth providers Extend the web app (passing all providers is working) Here the updated script : Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction 0 $winAp = ...


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

Whereas not answering your question exactly, it is very easy to get the "real" user object from a claim: SPClaimProviderManager claimManager = SPClaimProviderManager.Local; SPClaim claim = SPClaimProviderManager.Local.DecodeClaim(userLoginName); The important part being the DecodeClaim method. More information: Determining the original ...


3

Members of AD groups cannot be viewed by SharePoint (without code). Therefore, when you check permissions, members of the group will show as having no rights. Here is an article discussing this: https://www.nothingbutsharepoint.com/sites/eusp/pages/active-directory-groups-vs--sharepoint-groups-for-user-management-a-dilemma.aspx


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

There's only one account in AD but they end up being treated like two different user profiles within SharePoint. You're on the right track when you mention the claims prefix. Most likely, this site at one point used Classic authentication and was later changed to Claims authentication (or vice versa but moving a site 'backwards' from Claims to Classic ...


3

Their are 3 differnt way to implement the claims authentication. Windows authentication methods NTLM Kerberos Anonymous Basic Digest Forms-based authentication methods LDAP SQL Server database or other database Custom or third-party membership and role providers SAML token-based authentication methods AD FS 2.0 Third-party identity provider LDAP ...


2

I must say the to my knowledge the migration to Claims should be done PRIOR to moving to SharePoint 2013, therefore in SharePoint 2010. In your case I'm wondering if the creation of the new user in User Information List isn't happening also because SID are not correctly copied. Also to check the differences - could take one "new" user and one "old" user ...


2

You cannot configure the Forms based authentication if your web application is using Classic Mode Authentication


2

The claims included in your token are only used to make authorization decisions inside of SharePoint. The custom claims provider provides claims augmentation (adding claims to your token) and claims lookup (people picker functionality). If you want to have user properties in the user profile service application, you still have to configure an import ...


2

_ Hi Bernd My draft post became over 2 pages, so I decided to cut some details, to get any replies at all. I have tried AllowNtlm = false, but for some reason I get the error message "The remote server did not satisfy the mutual authentication requirement." when I run. In IIS-Manager on the IIS-app I have only "Windows Authentication" and ...


1

Authentication is managed at the web application level only. It is not possible to have sites within the same web application use different authentication providers unless the entire application supports those providers. Maybe this article will help: http://msdn.microsoft.com/en-us/library/hh237665.aspx


1

Finally i got it to work : SPWebApplication app = SPContext.Current.Site.WebApplication; SPAlternateUrl u = app.AlternateUrls[Request.Url]; SPUrlZone zone = u.UrlZone; SPIisSettings settings = app.IisSettings[zone]; string components = Request.Url.GetComponents(UriComponents.Query, UriFormat.SafeUnescaped); string AuthProviderString; if (flag == 1) ...


1

There is no default way to search for users when using SAML authentication like with SiteMinder federation as SharePoint has no way to know what kind of directory you are using let alone performing lookups in it. The solution is to build a custom claims provider that plugs into SharePoint to provide additional services: claims augmentation and claims ...


1

OK, I got this working (yay!), but man, it was tough. Basically, you need to force the token to be re-issued from the STS, which forces the claims augmentation code to run again. In my case, the business requirements were a little more complicated than that, because I needed to actually only have one of the claims possible, but that's outside the immediate ...


1

everything remains as it is, you have a nice token of your claim that you can manage in your webpart, only that you will be forced to implement a custom provider claims to search for users or groups sull'ldap (people picker) and transform the result into a claim. I hope I explained myself visit this link: http://ldapcp.codeplex.com/


1

I covered this at TechEd NA 2010: http://channel9.msdn.com/Events/TechEd/NorthAmerica/2010/OSP306


1

IClaimsIdentity currentIdentity = System.Threading.Thread.CurrentPrincipal.Identity as IClaimsIdentity; //var userName = currentIdentity.Name; foreach (Claim claim in currentIdentity.Claims) { // claim }


1

Someone actually built a web part extracting all claims from authenticated session http://allthingssharepoint.wordpress.com/2011/04/14/sharepoint-claims-web-part/ C:\Marius


1

I'm quiet mystified by how it works with UserY, it should always fail. When running with Claims without NTLM the only way to pass credentials is through a FedAuth cookie with your SharePoint STS SAML token. To get that token you have to call the SharePoint STS with a SAML token from your identityprovider (ADFS?). To get that token you have to call the ...


1

We finally found a solution, that consisted in changing the client library. We especially use the component described here : Support for NTLMv2 with Apache HttpClient using JCIFS. A sample code we used: QueryServiceStub queryServiceStub = new QueryServiceStub("SHARE_POINT_ASMX_URL"); List authPrefs = new ArrayList(1); authPrefs.add(AuthPolicy.NTLM); ...


1

You state in the picture that the site collection at '/' doesn't even exitst. It should otherwise you're running unsupported unless every site collection is a host header site collection in the web application. See SharePoint 2010: Supportability of unprovisioned root site in a SharePoint web application


1

Update User Profiles via a BCS connection to the web service. The built-in timer jobs will then update the user information list.


1

I'm not sure if this will provide the claims you are looking for, but hopefully will get you pointed in the right direction. In the code behind of the InfoPath form you can grab the current user, and from there determine the claims information. Try something like this in the On_load event SPClaimsAuthMembershipProvider claimsProvider = new ...


1

Can I assume when you say claims you actually mean Claims with Active Directory as user data store, where from your problem, right? If NOT, then you should have no issues as it all handled automatically by the claims - meaning that is all in your connection of the provider! If domainOne and domainTWO also are related to 2 AD domains, bi-directional trust ...


1

What I believe is the major difference is that with classic mode, you login directly, and if you need to be authenticated to a second server, it's not possible (you need to be logged in to this second server first -> new login screen). You will find that this is still often done but in that case the second connection is done under a different account (with ...


1

After converting our 2010 farm to use Claims based authentication, out ArcGIS web services stopped working and our custom WCF web services no longer got the user credentials - I believe they function with anonymous access. It turns out that WCF web services need to be Claims Aware, which they are not. WCF Services used by Silverlight inside of SharePoint are ...



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