Windows Service DefaultCredentials are empty?

[The Man From SQL]

Hello,

I have a v1.1 Windows Service that calls a v1.1 web service asynchronously.
Both the windows service and web service are on the same Server 2003 machine.
The Web Service is wrapped in Oracle CoreID for security and uses Integrated
Windows Authentication with Basic as the authentication level. The Windows
Service runs under a Windows Account (let's call it TMP\bob). The CoreID
consumer instructions are that I only need to explicitly set the web client
proxy's credentials to DefaultCredentials, like so:

ws.Credentials = System.Net.CredentialCache.DefaultCredentials;

When I try to access the web service front page from a browser and enter the
bob's credentials at the login prompt, I am able to access the site.

When I call the web service from a console app specifying DefaultCredentials
(my own windows account also has permissions to access this web service), I
am able to access the site.

When I call the web service from a console app and create a new
NetworkCredential for TMP\bob, I am able to access the site.

When I create a Windows Service and run it under either my login or bob's
login and try to call the web service, I get an HTTP 401 Unauthorized error.

I've read online about the double hop problem, but mostly in relation to
ASP.NET clients, not Windows Service clients. Plus, it works from a console
app.

I'm at a loss as to what to do and I don't want to have to store and encrypt
the user name and password somewhere. Can someone explain why the Windows
Service call doesn't work and some possible workarounds?

Thanks very much,

TheManFromSQL

 

[The Man From SQL]

Hi Steven,

Thanks very much for your reply. I think I was able to get to the bottom of
this issue yesterday by doing some digging online. How I was able to get it
to work is by setting the web proxy's PreAuthenticate property to true before
I set the credentials.

MyWebService ws = new MyWebService();
ws.PreAuthenticate = true;
ws.Credentials = System.Net.CredentialCache.DefaultCredentials;

For some reason, this worked doing the asynchronous call. The documentation
page on the PreAuthenticate property leads me to believe that an asynchronous
call, for some reason, doesn't resubmit when it gets a 401 error.

From the MSDN documentation:

"When PreAuthenticate is true, the WWW-authenticate header is sent with the
first request if the authentication mechanism supports doing so. When
PreAuthenticate is false, a request is made to the XML Web service method
without initially attempting to authenticate the user. If the XML Web service
allows anonymous access, then the XML Web service method is executed. If
anonymous access is disallowed, a 401 HTTP return code is sent back to the
client. In response, the WebClientProtocol class returns authentication
credentials to the Web server. If the client is authenticated and
subsequently authorized to access the XML Web service, the XML Web service
method is executed; otherwise the client is denied access."

The security tool our server team is using (CoreID), is an ISAPI filter so
it may have been killing the request when it saw that it was anonymous and
not allowing a retry.

But that still doesn't explain why I was able to hit the web service
asynchronously from a console app using the same credentials.

This morning we install the new Windows Service to QA (I was trying to hit
the QA web service from my machine) and see if the changes take.

 

[Steven Cheng[MSFT]]

Thanks for your reply,

As for the "PreAuthenticate" property you mentioned, it is abit unexpected
because in my local test environment, I never explicitly assign this
property(no matter in sync or async mode when calling the webservice).

BTW, as for the CoreID security tool, have you tried on a webservice (same
authentication setting in IIS) which is not secured by this tool? If such
as service can be called successfully without explicitly setting the
PreAuthenticate property, the problem is likely specific to the security
tool's internal authentication implementation.

Please feel free to let me know if there is any new finding or any other
question you wonder.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



This posting is provided "AS IS" with no warranties, and confers no rights.

 

[The Man From SQL]

Steven,

Thanks for your post. It turned out that after we applied the fix and
redeployed to the Server 2003 environment we continued to get the error. So
it's back to the drawing board.

Question about your web service/windows service model. Is the windows
service calling an asynchronous web service and specifying a callback and an
Asyncstate parameter? If not, are you able to test this scenario?

Thanks very much,

TheManFromSql