Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I have this Cloudshare environment consisting on 3 machines:

  • One for Sharepoint 2013 (this is where I develop with VS2012 installed)
  • Another for SQL Server 2012
  • And another for Active Directory

I'm trying to create a basic high trust app for Sharepoint 2013 using server-to-server protocol.

I've followed several guides:

When I run the project (default template code) from VS and trust the app I get an exception in the following line:

Uri hostWeb = new Uri(Request.QueryString["SPHostUrl"]);

using (var clientContext = TokenHelper.GetS2SClientContextWithWindowsIdentity(hostWeb, Request.LogonUserIdentity))
{
    clientContext.Load(clientContext.Web, web => web.Title);
    clientContext.ExecuteQuery(); // throws exception
    Response.Write(clientContext.Web.Title);
}

in Default.aspx.cs

The exception could be any of the following:

The remote server returned an error: (403) Forbidden.

The remote server returned an error: (401) Unauthorized.

I have tried several troubleshooting tips with no luck. I'm not a SP2013 expert so any help will be appreciated.

Thanks

UPDATE

Here are the ULS log entries related to the request: http://pastie.org/pastes/8395956/text

share|improve this question
    
Has security for the site been set to 'local intranet' in IE > internet options > security? –  billfredtom Oct 15 '13 at 3:04
    
@billfredtom It was set to "Trusted sites". I move it to "Local intranet", nothing happened. Same error. –  emzero Oct 15 '13 at 18:46
add comment

2 Answers 2

up vote 6 down vote accepted
+50

for simplicity I will state the obvious!

user is not authenticated and resource requires authentication

this tells me there is somthing wrong going on with the hand shaking (your certificate is not sent or is wrong), as its a microsoft product the best place is to look at msdn.

to make it clear please read this:

The following step is optional. However, we recommend that you develop and test with HTTPS turned on. Turning off HTTPS might cause you as a developer to miss certain issues when building an app that would occur during a production deployment where HTTPS is required.

now you read the note, read the issue that your having!

OAuth now requires SharePoint to run HTTPS, not only for your service but also for SharePoint 2013. You’ll get a 403 (forbidden) message when attempting to make a call to SharePoint by using a test certificate.

On the computer where you have SharePoint 2013 installed, you can turn off the HTTPS requirement during development by using the following Windows PowerShell cmdlets.

so that is your problem right there! to get around it whilst developing do:

this in powershell for testing/development:

$serviceConfig = Get-SPSecurityTokenServiceConfig
$serviceConfig.AllowOAuthOverHttp = $true
$serviceConfig.Update()

once finished return it back to how it was!

$serviceConfig = Get-SPSecurityTokenServiceConfig
$serviceConfig.AllowOAuthOverHttp = $false
$serviceConfig.Update()

now i would also like to note:

In a high-trust app, there is no context token, even if you use the appredirect.aspx file. The context token is specific to configurations that use Windows Azure Access Control Service (ACS). However, an access token is still required. If you’re using a high-trust configuration, your web application has to authenticate the user in the same way that SharePoint 2013 does (that is, the app is responsible for creating the user portion of the access token).

are you using the tokenhelper class to get the clientcontext?

        using (var clientContext = TokenHelper.GetS2SClientContextWithWindowsIdentity(hostWeb, Request.LogonUserIdentity))
        {
            clientContext.Load(clientContext.Web, web => web.Title);
            clientContext.ExecuteQuery();
            Response.Write(clientContext.Web.Title);
        }

also what exactly are you trying to do as you might need more permissions depending on what your doing!

To access other properties, you may need to request permissions on the host web.

http://msdn.microsoft.com/en-us/library/fp179901.aspx

hope the above answers your question! you need to make sure that the above is correctly done for it to work!


if that is still an issue than its somthing wrong with the guid that is issued by vs2012, that is auto sent when you press F5, this is set in web.config at this line:

<add key="IssuerId" 

change the guid from upper case to lower case:

from:

<add key="IssuerId" value="F2AE6B96-1FC0-43C6-B5D0-900117C491A4"/>

to

<add key="IssuerId" value="f2ae6b96-1fc0-43c6-b5d0-900117c491a4"/>

obviously your guid is going to be different from above ;)

also like to note you need a unique certificate for each individual app! also make sure the guid is the same as the powershell guid using Get-SPTrustedSecurityTokenIssuer should be the same as the web.config!

http://www.jamestsai.net/Blog/post/SharePoint-Provider-Hosted-App-401-Unauthorized-error-on-clientContextExecuteQuery().aspx

UPDATE

Just looked at your log file!

to break it down its failing straight away with the authentication! what method are you using? ntlm? kerbos? ect...

This is fundamental to know how you have setup your farm and authentication!

now there could be several issues going on here by the looks of the errors! I recommend that you read through the links below! I would highly recommend once you have read the links that if all is correct in your setup to run New-SPTrustedSecurityTokenIssuer this example can be found in my last link at the bottom of the page! this might solve you issue with the token part and the correct handshaking between two servers(validating each other).

1) the token is not being sent due to the security settings that are not compatible!

If you are using Windows claims mode for user authentication and the web application is configured to use only Kerberos authentication without falling back to NTLM as the authentication protocol, then app authentication does not work.

http://technet.microsoft.com/en-us/library/ee806870.aspx

or/and

2) your using server to server auth, this is where it could be going wrong! have your profile been synchronized??

for 2013 server to server make sure that group memberships are synchronized with the User Profile service application.

If a user profile exists for a user and the relevant group memberships are not synchronized, access may be denied when the user is supposed to be granted access for a given resource. Therefore, make sure that group memberships are synchronized with the User Profile service application.

http://technet.microsoft.com/en-us/library/jj219806.aspx

now this is needed for server to server setup to work!

Server-to-server authentication allows for servers that are capable of server-to-server authentication to access and request resources from one another on behalf of users. Therefore, the server that runs SharePoint Server 2013 and that services the incoming resource request must be able to complete two tasks:

To rehydrate a user’s identity, a server that can perform server-to-server authentication requests access to SharePoint resources. SharePoint Server 2013 takes the claims from the incoming security token and resolves it to a specific SharePoint user. By default, SharePoint Server 2013 uses the built-in User Profile service application to resolve the identity.

and the result of the above is:

If a user profile and the relevant group memberships for the user are not synchronized, SharePoint Server 2013 may incorrectly deny access to a given resource. Therefore, make sure that group memberships are synchronized with the User Profile service application. For Windows claims, the User Profile service application imports the four key user attributes previously described and group memberships.

http://technet.microsoft.com/en-us/library/jj729797.aspx

point being is the token and authentication is not working correctly because either your setup is wrong with security type or configuration! knowing what you have done will determin where its going wrong! clearly it looks like server to server auth is getting rejected as the token is not sent properly.

If you belive that the authentication protocol is correct than, you can follow this guide once you have read the above links:

http://technet.microsoft.com/en-us/library/jj655400.aspx

link above explains and demonstrates server to server steps for specific senarios

to create a trust between two servers (Creates a trust between a server to server principal.)

follow this guide! using New-SPTrustedSecurityTokenIssuer

http://technet.microsoft.com/en-us/library/jj219695.aspx

sorry for the long text and many links! as its server to server and the log is generic/setup I can give you a definitive answer! but what i do know is the handshaking between two servers is going wrong meaning you have missed somthing out with the initial setup! the links above should hopefully solve your issue between handshaking to pass the correct credentials to work properly!

share|improve this answer
    
Thanks for the long reply. Unfortunately, I've already tried all of that. Tried disabling HTTPS, didn't work. Yes, I'm using the default code that comes with the provider-hosted app for Sharepoint 2013 which indeed uses the TokenHelper class. Regarding permissions, I'm not trying to do anything but the default code which I think only authenticates the user and nothing more. And regarding the ID, VS2012 doesn't update the IssuerId, just the ClientId. The IssuerId corresponds with the one get from Get-SPTrustedSecurityTokenIssuer, and yes, both are lowercase. This is driving me crazy. –  emzero Oct 16 '13 at 15:22
    
just updated my answer! sorry for the long read! youll be an expert after this ;) , iv noted that you might just need New-SPTrustedSecurityTokenIssuer as explained in the link and text iv written! –  ali Sharepoint Oct 17 '13 at 9:37
    
Thanks again for the answer. I'll check everything you pointed out but want to make clear that there are no 2 servers. The same place where the app resides is where Sharepoint is and where I develop using VS2012. It's a Cloudshare environment. –  emzero Oct 17 '13 at 15:11
    
That is excactly the problem for windows auth and non netbios names. The issue could be related to an issue called loopback authentication. If you access the server on an url other that the servername your authentication will fail if you are on the same server. On the server configure loopback auth. check out this KB: support.microsoft.com/kb/896861 –  Marco Scheel Oct 18 '13 at 13:51
    
one way to test your theory is access the site from a client machine to see if its working, if it is than your right if not than your not! but i dont belive that is the issue here! –  ali Sharepoint Oct 18 '13 at 15:24
show 8 more comments

I had similar problems. Instead of using ClientContext or TokenHelper, I switched to the new SharePointContext which you can read about here: http://blogs.msdn.com/b/kaevans/archive/2013/09/24/introducing-sharepointcontext-for-provider-hosted-sharepoint-apps.aspx

Once I made this switch, my 401 and 403 problems disappeared. The new SharePointContext uses the underlying TokenHelper, so make sure you have the latest version of the TokenHelper file also.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.