How to set explicit NetworkCredential for authenticating to a workgroup computer instead of domain

Question

I am using the following form of the NetworkCredential constructor to set explicit credentials before invoking a webservice that requires a specific identity:

myWebService.Credentials = new System.Net.NetworkCredential(userName, password, domain);

This has been working fine in our IIS 6.0 development and IIS 7.5 staging environments where the various servers are part of our domain.

Now this code has been deployed to a production environment where the servers are NOT part of a domain but just members of a WORKGROUP and the proper authentication is not working. At runtime, this effective substitution is failing:

myWebService.Credentials = new System.Net.NetworkCredential("localuserName", "XyZ!XyZ", "myServerName");

I don't have complete access to these various workgroup machines and the sysadmin who configured things there appears to have set up the local accounts and application pools correctly.

So, in summary, can use of the above technique continue to work in a WORKGROUP by simply using the name of the server instead of the domain name? If the code should work in either case, then there must be some other configuration problem where I will have to chase down more information on the problem.

Answer 1

i'm using iis 7 and there is no problem with following:


1. find the ip address of machine which is running IIS and
find webservice bindings the bindings in IIS is like the following   http://192.368.228.1:8051/

2. set domain like this : http://servername:port/ or http://machine-ip:port/
also you can set webservice url like the following

        myWebService.Url ="http://192.368.228.1:8051/service1.asmx";
        myWebService.Credentials = new System.Net.NetworkCredential("user", "pass");

no domain is used in this way.

for more information about this subjects have look on following link this section: Passing Credentials for Authentication to Web Services

http://msdn.microsoft.com/en-us/library/ff649362.aspx#secnetch10_usingclientcertificates

hope this could be helpful.