I have created a custom claims provider to allow users to sign into SharePoint from an existing website. This issues claims including a claim of UPN in the format username#domain. The user can log in fine until I enable mapToWindows and useWindowsTokenService under samlSecurityTokenRequirement in the SharePoint web application web.config. At this point I get a standard SharePoint error message, and the following exception is visible in the trace.
Exception fetching current thread user in SPUtility.CacheClaimsIdentity: Exception of type 'System.ArgumentException' was thrown.
Parameter name: identity 0.00143314303912927 0.001357
Runtime Tag(tkau) System.ArgumentException: Exception of type 'System.ArgumentException' was thrown.
Parameter name: encodedValue
at Microsoft.SharePoint.Administration.Claims.SPClaimEncodingManager.DecodeClaimFromFormsSuffix(String encodedValue)
at Microsoft.SharePoint.Administration.Claims.SPClaimProviderManager.GetProviderUserKey(String encodedSuffix)
at Microsoft.SharePoint.ApplicationRuntime.SPHeaderManager.AddIsapiHeaders(HttpContext context, String encodedUrl, NameValueCollection headers)
at Microsoft.SharePoint.ApplicationRuntime.SPRequestModule.PreRequestExecuteAppHandler(Object oSender, EventArgs ea)
at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
I think that the c2wts impersonation part is working correctly because if I disable the AD account represented by the passed UPN claim then I get a different "access is denied" error shown in SharePoint when trying to log in as that user.
Also in the SharePoint log it does appear that the UPN has been converted to a Windows AD account because I get the following in the log:
Verbose ____Current User=i:DOMAINNAME\SSO_administrator 7b4eac31-d017-429c-87f2-a3100ece6797
Update
It looks like maybe this isn't a supported setting to use within SharePoint. However if I leave the setting off, it seems that Performance Point and Excel Services reports embedded in the SharePoint site do not work properly. I get errors like:
The data connection uses Windows Authentication and user credentials could not be delegated. (Excel)
$Resources:ppsma.ServerCommon, ErrorCode_DataSourceCannotGetWindowsIdentityForNonWindowsClaim; (Performance Point SSRS report)
Is there a way around this? I need the user's UPN to be the account used to query the SSAS data behind these, so it is not feasible to use fixed connection strings.
I think there are a lot of information on a SharePoint forum about Claims-based access platform (Geneva) forums
This is some of the searches which hopefully will helps you to manage the issue:
Claims Login Web Part for SharePoint Server 2010
SP2010 Custom Role Provider - Roles.GetRolesForUser(userName) raises exception
How do i redirect the user from Active Directory or Sqlmembership provider to sharepoint default.aspx page or home page after logged in using custom log in page.
Vittorio Bertocci's Blog
SAML 2.0 Protocol Blog
SAML 2.0 Windows Identity Foundation Extension
It turns out that the mapToWindows config value is not supported within SharePoint. You have to rely on each part of SharePoint being claims aware and converting the token themselves. This is a bit of pain because PerformancePoint and Excel Services are not claims aware, so you end up being stuck using Windows auth if your SSAS cube requires AD security.
Related
We are trying to connect an internal application to Sharepoint 365. The goal is to read data from Sharepoint 365 lists and Excel documents. We want to take advantage of the fact we already use OAuthentication and basically our users login with their own Windows credentials. Now, to accomplish that we first need to register an application with Sharepoint which we did using this link:
https://mycompany.sharepoint.com/sites/MySite/_layouts/15/appregnew.aspx
After that we also need to get an authorization code for clients to login with their Windows account. We do that with this URL:
https://mycompany.sharepoint.com/sites/MySite/_layouts/15/OAuthAuthorize.aspx?client_id=14f0e39c-1234-42ea-bed5-ee5c7c834655&scope=List.Read&response_type=code&redirect_uri=https%3A%2F%2Fmysite.mycompany.com%3A9090%2Foauth%2F2.0%2FredirectURL.jsp
When we run that last link we get the error below:
Sorry, something went wrong
There is no claims identity. Please make sure the web application is configured to use Claims Authentication.
TECHNICAL DETAILS
Troubleshoot issues with Microsoft SharePoint Foundation.
Correlation ID: 367ee69f-5066-0000-e1ef-cee55f7b7000
As you can see, the error is not very helpful. I have done already lots of research and answers vary from lack of higher level of access, to invalid URL request. I have elevated access and the URL is well constructed. Yet the error persist.
So, my question, what is the meaning of the error? Why is not executing?
We logged a Microsoft Premier Support ticket and behold! the problem has been fixed.
I have a web app in Azure. The access to that web app is controlled by Azure Active Directory. The app is up and running since September of last year. I didn't make any changes to the app for a while and have 33 users in that app.
So, a week ago I tried to add a user, using the same methods and paths I used before.
The new user can log in to microsoft (portal.office.com). After the initial log in and changing of the password the user goes to the web app in Azure and get the following error: You do not have permission to view this directory or page.
Error tracing gives me this:
HTTP Error 401.73 - Unauthorized You do not have permission to view
this directory or page.
Most likely causes: The authenticated user does not have access to a
resource needed to process the request.
Things you can try: Create a tracing rule to track failed requests for
this HTTP status code. For more information about creating a tracing
rule for failed requests, click here.
Detailed Error Information: Module EasyAuthModule_32bit
Notification BeginRequest Handler
ExtensionlessUrlHandler-Integrated-4.0 Error Code 0x80004005
Requested URL https://*******:80/.auth/login/aad/callback Physical
Path D:\home\site\wwwroot.auth\login\aad\callback Logon Method
Not yet determined Logon User Not yet determined
More Information: This is the generic Access Denied error returned by
IIS. Typically, there is a substatus code associated with this error
that describes why the server denied the request. Check the IIS Log
file to determine whether a substatus code is associated with this
failure. View more information »
Microsoft Knowledge Base Articles:
Another observed behavior: usually when new users are logging in the web app asks for permissions for the AD to access their account information. Ever since this problem came up this is not the case any more.
Other users do not have any problems logging in. This problem only happens with new users who never logged in before.
EDIT: When I go to Active Directory and look at sign ins, I see failures to log into the web app with sign-in error code 90092. Failure Reason: Other.
Microsoft help desk could not give me details on that error code.
Checkout the related question and answer here. All new users have to first consent the application (agree and give your application permissions to access their profile / or you indicated as required permissions).
In short, you have to design "sign-up" button for your application, which uses the "login_url" and appends "&prompt=consent" to the query string.
Read all related resources here to better understand the consent framework.
And please read the documentation about Azure App Service Authentication/Authorization here, as well as the Azure AD specific documentation here.
OMG, I just found an answer. I created a test app and set it up to mirror the settings of my live app.
In Required Permissions the new app had nothing for Microsoft Graph, the live app had 5 permissions. I deleted Microsoft Graph and it works now!
I wish Microsoft communicated better about discontinued API's. I did get an alert, but it was mostly talking about MS Office 365.
I am facing issue in implementing Federated Search between SharePoint 2013 Azure and SharePoint online.
SharePoint 2013 Azure uses ADFS for authentication. Azure active directory and on-premise active directories are not in sync though.
I have followed all the steps that have been mentioned in following two links –
https://technet.microsoft.com/EN-US/library/dn607307.aspx
https://technet.microsoft.com/en-us/library/dn197169.aspx
However when I am trying to test the Federated result source, I are getting following error –
Web error: System.Net.WebException: The remote server returned an error: (401) Unauthorized.
at System.Net.HttpWebRequest.GetResponse()
at Microsoft.SharePoint.Client.SPWebRequestExecutor.Execute()
at Microsoft.SharePoint.Client.ClientContext
I am not sure if we are missing something which is implied or not mentioned in the technet links.
Grateful if someone can help in resolving this issue.
Finally after a month of effort and taking help of Microsoft support, we have resolved the issue. The problem was the value of variable $spcn.
In the article, it was not very clear to which domain it has to be set.
$spcn - The root domain name of your public domain. This value should not be in the form of a URL; it should be the domain name only, with no protocol.
An example is adventureworks.com.
We were initially setting it to domain of SharePoint Online. Finally after lot of hit and trial, we found that we have to add domain of both SharePoint Online and SharePoint 2013. It worked after that.
I have a Sharepoint 2013 on premise environment for which I am developing an provider hosted app using Visual Studio.
The Visual Studio project has an app project which contains a custom ribbon button that goes to the web project. The web project is hosted on Windows Azure and here I get the error that the context token is null or an empty string.
Getting the token is done using the following code:
var contextTokenString = TokenHelper.GetContextTokenFromRequest(Request);
SharePointContextToken contextToken =
TokenHelper.ReadAndValidateContextToken
(contextTokenString, Request.Url.Authority);
When I see what is passed to the site hosted on Azure I notice that the SPAppToken is null. When using ULS viewer I get the error "The Azure Access Control service is unavailable"
I have already checked if the app is registered (using appregnew.aspx) and that the id is the same for this and in the appManifest.xml and web.config files.
How do I get the context token? Do I need to do something else in Azure in order to make it work?
The link from the comments helped me. I'm posting the answer here so we don't need to rely on a url sticking around.
You get the "EndpointAuthorityDoesNotMatch" message when your app's launch url doesn't match the "app domain" registered for your app's client_id.
For mine this meant that I needed to re-register the app for our test server separately from our develoment server via the _layouts/15/appregnew.aspx page on the O365 site. Here's a link with more info on registering client ids: http://msdn.microsoft.com/en-us/library/jj687469.aspx
Message 'The Azure Access Control service is unavailable' says that SharePoint can’t construct the SPAppToken because it can’t talk to ACS (Azure Access Control) in order to do that. This could be for a variety of reasons (e.g. network connectivity problems).
You can also check this blog: CJG: The Azure Access Control service is unavailable.
UPDATE
I can now perform succesful UI impersonation. This was an issue with the code I was using and after viewing Jay Nathan's article I have reverted to his code and all is working great.
In response to a comment this is the code I am using to create a new site collection:
Dim newSite As SPSite = webApp.Sites.Add( _
txtWebApp.Text & "/cg/" & strURL, txtName.Text, txtDesc.Text, 1033, "SITEDEF#0", _
"DOMAIN\ACCOUNT", "NAME", "EMAIL", _
"DOMAIN\ACCOUNT", "NAME", "EMAIL")
and yes "SITEDEF#0" is a perfectly valid site defintion.
Hopefully I have overcome this issue by using an Application Page which is available as an element on the Site Actions menu (to site admins only). Using impersonation I can succesfully instigate this process. There are some additional issues which I have highlighted in another question.
ORIGINAL QUESTION
I have a need to allow non farm administrators to be able to create site collections using a very specific site definition. These people will not have access to central admin and so require a custom solution to allow the creation of these. I have tried several solutions, but want some consensus on a recommended approach.
Custom Web Service - I have written a custom web service to perform this task however this caused major headaches and even though the web service was running in an app pool using the same identity as the sharepoint app pool I could not get this to work. Also had form digest issues in trying to perform this v ia a web service.
Web Part/Application Page - No form digest issues here as we are in the SharePoint context, however I have tried using RunWithElevatedPrivileges but I still get an access denied when calling SPWebbApplication.Sites.Add(), even though all SPSite and SPWeb pbjects are being instantiated inside the elevated code block. I have tried direct impersonation at the UI level and I get an UnhandledException saying that impersonation has failed.
Application Wrapper Around stsadm - I have not attempted this yet as I am concerned about the viability of this approach, surely there is a cleaner way than this?
Some guidance on this would be useful as I cannot find much out there on this.
Thanks
I'd go with option number 1. It's probably an authorization issue. How are you accessing SharePoint? with the SDK or trough its web services?
I'd go for number 2. That code should work, maybe the impersonation code is not correct? You can't use SPContext like you normally would for instance.
Also, you are elevating to the identity of the application pool of your SharePoint site. Does this account have sufficient rights to create Site Collections?
You can check in Central Administration > Application Management > Policy for Web Application.