Tested with 3.6 and works as expected. You are doing the right thing (impersonate) as we can't trust the username sent via the service manager for authentication.
Please make sure that in IIS you don't have anomnymous access enabled for the Gemini site.

Thanks for the quick reply.  I have verified that Anonymous access IS NOT enabled, but I'm still receiving the error.  How did you test that it worked on your side?  Can you send me your test harness or code snippet of the successful test, so that, I can try it on my side?

I ran the same code as you, created a service manager and called WhoAmI()....

Try and call the service directly without the service manager to see what is that you are getting back. It seems like you are being sent back a page and not XML.

How did you configure the application pool?  Are you using the Network Service account?  I am new to using REST.... do you have a sample piece of code to "call the service directly"?  Any help is appreciated.

Here is a sample code:

HttpWebRequest req = (HttpWebRequest)HttpWebRequest.Create("http://localhost/gemini/api/users.ashx/users/username/" + HttpUtility.UrlEncode("manager"));
            req.Method = "GET";
            req.Accept = "text/xml";
            req.ContentType = "text/xml";
            HttpWebResponse res = req.GetResponse() as HttpWebResponse;
            string responseString;
            using (StreamReader sr = new StreamReader(res.GetResponseStream()))
            {
                responseString = sr.ReadToEnd();
            }

Thanks for the sample.  When I execute the code, on the req.GetResponse call, a "The remote server returned an error: (401) Unauthorized." System.Net.WebException is being returned.

1.  Gemini is configured to use Windows authenication.  Is there any special permission that need to be set on the api directory?

2.  The .NET 2.0 web app that I used to call the sample code also used Windows authentication and <identity impersonate="true" /> is set in the web.config file.

3.  The URL I'm referencing in the HttpWebRequest.Create is:

http://<<url to gemini>>/api/users.ashx/users/username/<<DOMAIN NAME>>/<<DOMAIN Username>>

4.  I'm using my credentials to access the .NET 2.0 web app and I am a Domain Admin and a Gemini Administrator.

Also, in the Gemini SystemLog, the following Error is being recorded:

The file '/rss/Issues.ashx' does not exist. at System.Web.UI.Util.CheckVirtualFileExists(VirtualPath virtualPath) at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile) at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile) at System.Web.Compilation.BuildManager.GetVPathBuildResult(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile) at System.Web.UI.SimpleHandlerFactory.System.Web.IHttpHandlerFactory2.GetHandler(HttpContext context, String requestType, VirtualPath virtualPath, String physicalPath) at System.Web.HttpApplication.MapHttpHandler(HttpContext context, String requestType, VirtualPath path, String pathTranslated, Boolean useAppConfig) at System.Web.HttpApplication.MapHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Sorry that something so simple is taking so long to resolve and I appreciate your time to help me resolve this.

Cheers.

You need to encode the username:

HttpUtility.UrlEncode("DOMAIN\USER"));

Also, set the credentials on the request.

For your tests, are the Gemini ASHX files and your test application being run on the same machine or is the web app on one server and Gemini installed on another?

If the web app and Gemini are installed on the same machine, can you install your web app on another machine and re-run your test?  I've be doing some research and I think the problem is being caused by the dreaded "double-hop" authenication issue when using Windows authenication.

The test was run between a client and a server (2 machines).
What is the page you are getting back?

The page being returned is a 401 - Unauthorized error.  It appears that eventhough I have setup IIS to use Integrated Windows Authenciation, set the web.config's authenication mode to Windows and identity impersonate to true, the logged in users credentials were not being passed.  It appears to be a "double-hop" authenication issue and that the user is being authenticated using NTLM instead of Kerberos.

I have "fixed" the problem with the following steps:

1. Created a domain user account to run the application pool as.
2. Ensured the Active Directory domain's functional level was set to Windows Server 2003.  This is for kerberos delegation.
3. Set the web site for the .Net application in IIS to use Integrated Windows Authenication.
4. Configure the App Pool for the .Net application to use the domain user and associate App Pool with IIS web site.
5. Set the .Net application's web.config file's authenication mode to Windows and identity impersonate to true.
6. Used adsutil.vbs to check to make sure the .Net application's web site NTAuthenicationProviders were configured to use both Negotiate and NTLM.  Note: If Negotiate is not set, Kerberos will not work.
7. Used setspn.exe to configured the Service Prinicpal Name (SPN) for the .Net application web site and bound it to the user account of the App Pool.  See http://technet.microsoft.com/en-us/library/cc773257(WS.10).aspx
8. Within Active Directory, permitted the domain user Delegation Trust.
9. Configure the App Pool for Gemini to use the domain user and associate App Pool with the Gemini IIS web site.
10. Used adsutil.vbs to check to make sure the Gemini web site NTAuthenicationProviders were configured to use both Negotiate and NTLM.  Note: If Negotiate is not set, Kerberos will not work.
11. Used setspn.exe to configured the Service Prinicpal Name (SPN) for the Gemini web site and bound it to the user account of the App Pool

In my case, the above 11 steps were needs to ensure Kerberos authenication from the .Net web application through to the Gemini API REST services.  Now, when the user accesses the .Net web application, the user's credentials are being passed to the Gemini API REST service and the "double-hop" authenication problem has gone away.

One big note !!!  Both the .Net web application and Gemini web site are being used and accessed from our corporate Intranet.  The above 11 steps work for us (ie: my company) and are not any recommendation of best practices and we take no responsibility and assume no liability.

   

Many thanks for the update. Glad you managed to get it workling.

I am using Windows 2003 IIS 6.0 x86, Forms Authentication. This article fixed this issue for me: link text