I have a web application that runs on SERVER_A. The web application calls a web service which runs on SERVER_B. The web service returns a set of folder names on the file system from SERVER_B. However the web service fails to return any content when I run my application from SERVER_A, but it works OK when I access the web service directly via a browser or my localhost i.e. via Visual Studio. I can get it to work for SERVER_A if I grant the machine name (SERVER_A) access to the file system via Properties > Security. But I don't think this is very secure..?
Ideally I need to grant a service account the correct permissions, but how do I do this? Do I need to run my application on SERVER_A as this service account in order for it pass the identity when it connects to my web service? If so how do I do this?
You can specify the credientials you are using with the webservice. Once you create your service account (if you haven't already) you can specify the credentials when trying to consume the webservice...here is a MS kb article (take a look at the "Second Method").
http://support.microsoft.com/kb/811318
Related
I am getting an "Access is denied" error on a 2012 R2 server when my web app on that server tries to access a self-hosted WCF service on that server using named pipes.
I do not have this issue on my development machine (Win 7). I can access the WCF service via the client test app on both the server and my development machine.
If I enable ASP.NET Impersonation on the web site using a user account that has full control permissions to the install folder for the WCF service, then the error goes away. I do not want to use impersonation since I understand it has significant performance penalties (not to mention security issues) and the WCF service is called for every user input during a session.
The strange thing is... If I set the app pool to run as either the user with rights to the service folder as described above or as a user with admin privileges, then I still get the error if ASP.NET Impersonation is disabled. The error will go away only after I enable ASP.NET Impersonation on the web site.
I do not have access to the source for the WCF service.
In this case, the web app was located on the D:\ drive and the Anonymous Authentication user (IUSR) did not have RX permissions to the web app location.
Note that if you are using Windows Authentication, then the same issue occurs if the Windows Authenticated user does not have RX permissions to the location of the web app.
The problem was resolved once I gave the authenticated user the proper permission.
Sometimes the solution really is just plain simple...
"Ain't got no gas in it" - Slingblade.
I have ASP.NET WebService as a part of ASP.NET application. However, some of its methods are not supposed to be invoked directly from browser, they are just accessed by winservice from within the same local network. Is there any way to protect web service from remote access by means of web.config files or IIS configuration with no firewall configuration involved?
Change ACLs on your "non accessable" resources so that IIS_USER has no rights. Create another website that binds to localhost:80. Create a new user account and set that as the login account for the new website. Grant that user read/execute to the files you're trying to obscure.
I face a situation where my web service needs to access partion D in server hard disk and can send, receive files to/from client.
Is it true that a web service can do that even when there's no permission on the folder?
I know that I can add to the folder of asp.net path using mappath function...
Can any one illustrate to me how this would be done and how can the web service access the server local disk?
In order for the web service to be able to either read or write files to a folder on your server it must have permission to do so.
The first question you need to determine is what user is the web service executing under? Once you know that then you can set the appropriate rights to the folder in question.
"Is it true that a web service can do that even when there's no permission on the folder?"
NO
Best practice says to keep my web app and database on separate machines, but when doing that it seems I can't get a clear explanation on how best to make this connection. Whil windows auth is the recommended authentication, I don't see how to make a trusted connection . Must I use impersonation to have my application connect to a db server?
Are most people simply using SQL authentication in this case?
Both machines are on a virtual cloud network.
If both computers are in the same domain, I'd use Windows Authentication for the SQL connection. To set it up:
Create a domain account to use for the app.
Give the id the absolute minimum priveleges necessary to host the site on the web server. For example, it must have read access to the web site itself, write access only to folders updated by the web site, etc.
Change IIS so that the domain account is used to run the app. In IIS6 & IIS7, you do this through the application pool. In IIS5, you have to change the settings in the machine.config or in the web.config for the ProcessModel.
All calls to the database will be done through this domain account; you won't have to setup impersonation. In fact, if you are using SQL authentication today, the only change you need to make is to the database connection string; no code changes are needed.
I am having a problem with deploying a ASP.NET V2 web application to our deployment environment and am having trouble with the sql server setup .
When I run the website I get a Login failed for user 'MOETP\MOERSVPWLG$'. error when it tries to connect to the database.
This seems to be the network service user which is the behaviour I want from the application but I don't seem to be able to allow the network service user to access the database.
Some details about the setup. IIS 6 and SQL Server 2005 are both setup on the same server in the deployment environment. The only change from the test setup I made is to point the database connection string to the new live database and of course copy everything over.
My assumption at this point is that there is something that needs to be done to the SQL server setup to allow connections from asp.net. But I can't see what it could be.
Any Ideas?
It sounds like you're able to connect to the database alright and you're using integrated windows authentication.
With integrated windows authentication your connection to your database is going to use whatever your application pool user identity is using. You have to make sure that the user identity that asp.net is using is on the database server.
If it is a fresh install not everything may be setup. Check SQL Server Configuration Manager, http://msdn.microsoft.com/en-us/library/ms174212.aspx. Step by step instructions http://download.pro.parallels.com/10.3.1/docs/windows/Guides/pcpw_upgrade_guide/7351.htm.
The user name you've indicated in your post is what the Network Service account on one machine looks like to other machines, ie "DOMAIN\MACHINENAME$".
If you are connecting from IIS6 on one machine to SQL Server on another machine and you are using Network Service for the application pool's process identity then you need to explicitly add 'MOETP\MOERSVPWLG$' as a login to the SQL Server, and map it to an appropriate database user and role. Type that name in exactly as the login name (minus quotes, of course).
Make sure there is a login created for the user you are trying to log in as on the sql server.
There's a few different things it could be.
Are you using integrated windows authentication? If so, you need to make sure the user ASP.net is running as can talk to the database (or impersonate one that can).
Does the web server have permission to talk to the database? Sometimes a web server is deployed in a DMZ.
If you are using a SQL Server login, does that same login exist on the production server with the same permissions?