Calling a custom SharePoint web service from ASP.Net AJAX gives a 403 error?

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 = WsiProfi开发者_运维百科les.BasicProfile1_1)]
[System.ComponentModel.ToolboxItem(false)]
[System.Web.Script.Services.ScriptService]
public class ApprovalSvc : System.Web.Services.WebService
{
    [WebMethod]
    [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");
scriptMgr.Services.Add(srvRef);
this.Controls.Add(scriptMgr);

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

---

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.