SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have developed a custom SharePoint web service, and deployed it to /_vti_bin/myservice.asmx. As a "regular" user, browsing to that ASMX URL works fine. When I try to browse to "/_vti_bin/myservice.asmx/js" as required to call this service from ASP.Net AJAX, I get a 403. If I browse to it as no less than a farm admin (site collection admin doesn't work), I get a 403. It is entirely possible that the farm admin's role as a local server admin is also allowing it to work.

This is my web service class:

[WebService(Namespace = "")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class ApprovalSvc : System.Web.Services.WebService
    [ScriptMethod(ResponseFormat = ResponseFormat.Xml)]
    public XmlDocument GetInboxItems(string inboxName, string s_Id)
      // code removed

This is the art of my web part code where I am hooking up the ASP.Net AJAX stuff:

ScriptManager scriptMgr = new ScriptManager();
string webUrl = SPContext.Current.Web.Url;
ServiceReference srvRef = new ServiceReference(webUrl + "/_vti_bin/ApprovalSvc.asmx");

If I'm logged in as a farm/server admin, it works. Otherwise, no. The web service assembly is listed in SafeControls. Any ideas?

share|improve this question
Don't know if it's just me or not, but am having trouble fully understanding what you have tried with the various users and the results of each test. – Jaap Vossers Mar 17 '10 at 14:56
Problem was that when a non-admin user logged into the site, the ASP.Net ScriptManager control failed to register the service reference on the client, and did not render the JavaScript proxy class. Didn't matter if the user was a Farm Admin, only worked for people in the server Administrators group. – Greg Hurlman Mar 17 '10 at 22:25
up vote 1 down vote accepted

Good old Process Monitor to the rescue.

The facts:

  • The service code DLL is in the web application's bin directory, as it cannot be signed b/c it references unsigned DLLs.
  • The request for the service DLL is coming from ASP.Net & not SharePoint, specifically an HttpModule in the System.Web.Extensions assembly.

The solution:

Because the request didn't come through SharePoint, and identity impersonation is also turned on by default, the default NTLM permissions on the web app's BIN directory were not good enough - the user's account had no access to the BIN directory or the DLLs within it.

We gave the NT AUTHORITY\Authenticated Users Read access (not Read & Execute, not List Folder Contents, just Read) to the folder, and all is well.

share|improve this answer

Try <trust level="Full" originUrl="" /> in your web.config

share|improve this answer
Tried that, didn't make any difference. – Greg Hurlman Mar 16 '10 at 20:36

Your Answer


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.