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 = "http://sharepointservices.genericnamespace.com/")]
[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?

  • 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. Commented Mar 17, 2010 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. Commented Mar 17, 2010 at 22:25

2 Answers 2


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.


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

  • Tried that, didn't make any difference. Commented Mar 16, 2010 at 20:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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