to controll a windows service (and some other stuff) we use a WebAPI. For the communication between the API and the windows service I used NampedPipe. When I run the code in visual studio, everything works fine. After deploying the api to the IIS it get an IO exception access denied. Is this an configuration issue or is it impossible to access NamedPipes from the IIS API?
What could by a differnt approach? Ip connection?
Thanks for your help!
EDIT:
After some research and try and error I came to the conclusion: for NamedPipes to work both processes have to run under the same user.
So I assigned to both service and iis website the same user an gave it a try and it worked.
Is it safe to run a website on iis on a differnt user?
Application get activated in IIS express When you debug application in development environment. In IIS express, your current login user are used to execute the application.
However, when you deploy the application in IIS, everything get executed by application pool identity and isolated in session 0.
So most of time, you can try to set app pool identity to local system.
Since Local system grant too much permission for an application, use a dedicated account to host your IIS application would be a good idea.
As long as you follow the least permission principle, use a different user for your website can be safe.
Related
I have a Windows Service AND a Website which perform the same action. To copy a file to a network share on a server on another continent.
The Windows Service does an automated action but when there is an error the user can manually initiate the same action from the website.
Both the windows service and website intermittantly return false on a directory.exist using a unc path.
If I recycle the app pool it works.
If I restart the web service it works.
I have a domain user account as identity for both the windows service and app pool.
Maybe this is a network permission issue or server timeout?
For now we added some retry logic but I would really like to understand what is happening.
Any ideas?
You have here an answer.
They propose to use new DirectoryInfo(path).Exists instead of
directory.exist for UNC folders.
I am trying to set up a Test server to try out asp.net (3.5) web applications before they're moved to Production. I want to mirror the settings in IIS from Production server. On my web app, application pool is set as Classic .NET AppPool with identity NetworkService and Windows Authentication is enabled. When I attempt to access app on Test server I get error "The EXECUTE permission was denied on the object 'GetTable', database 'DatabaseName', schema 'xxx'. I realize I can add the network account to that stored procedures security but I shouldn't have to - it works in production without it.
I am using a restored copy of the production database thus the permissions are identical between the two. I did have to add the querying Test server name (i.e. xxx\Test$) to the database security in SQL server to gain access to the database, but I shouldn't have to add other local network permissions as they are included in the Security Logins of SQL (public).
In Windows Event Log* on Test server this piece of the error detail bothers me because the "Thread account name is NT AUTHORITY\NETWORK SERVICE compared to when a permission error is thrown on production server the Thread account name is the name of the user.
I think I need to get the Test server to recognize the real user. I (obviously) do not understand security to the fullest for web apps yet. Can someone suggest other areas for me to investigate? I did research this but I'm only finding things like how to change the apppool account, or identity, not the piece that troubleshoots permissions between client to web server to database server. BTW the production and test databases are on the same server. The product and test applications are on different servers (both Server 2008/IIS 7).
There is one difference: ASP.NET 1.1 application pool is not installed on IIS on Test server. Could that be the issue?
*Windows Event Log snippet:
Request information:
Request URL: http://server/appname/default.aspx
Request path: /appname/default.aspx
User host address: xx.xxx.xx.xx
User: xxx\username
Is authenticated: True
Authentication Type: Negotiate
**Thread account name: NT AUTHORITY\NETWORK SERVICE**
BTW if I move my test app to production server in a new folder, it works fine. Problem is with the test server configuration.
ANSWER: Set Active Directory for IIS server to say "trust this computer for delegation". I found my answer from a 2007 entry posted by plq in this: Microsoft ASP.NET forum
ANSWER: Set Active Directory for IIS server to say "trust this computer for delegation". I found my answer from a 2007 entry posted by 'plq' in this forum: Microsoft ASP.NET forum
I have created a sample ASP.NET website and hosted it in IIS 6.0 . It is working fine , if the identity of the defalut app pool is "local system". But when i changed the identity with some other configurable user id then it is showing as "Service Unavailable".
The following message is found in the event viewver.
"The identity of application pool 'DefaultAppPool' is invalid, so the World Wide Web Publishing Service can not create a worker process to serve the application pool. Therefore, the application pool has been disabled."
Either the credentials provided for the user is not valid, or the user does not have the needed permissions.
I believe there is a security group on the machine called IIS_WPG that is created when Asp.net is installed, add the user to this group, it should give them the needed permissions.
Message is self-explanatory. The selected user id isn't valid - probably due to insufficient privaledges to run the service.
The user identity you use needs to have fairly significant rights to operate. At a minimum the user needs to have read/execute permission on the root directory of the folder. This user should also have read/write/execute permission on the Temporary Asp.Net Files folder located within the %SystemRoot%/Microsoft.Net/Framework/ folder.
FYI,
In a development environment you can use the default app pool to create your web applications.
In production environment you want to use lusrmgr.msc (Server 2008/R2/7 Ultimate and Pro) to create new users (and their credentials) on the machine and assign the users to the right group (IIS_IUSRS).
Also once you have created the user, you will want to give it access to your data source back-end (if sql is running on the same machine and using windows authentication to access SQL).
Check Application Pools which assign Site on IIS, probably it is stopped.
I'm facing a weird problem :
I have a simple WCF service that retrieves some data from the DB. When I host the service on local serviceHost everything works fine, but when I host the same service on local IIS (7.5 - windows 7) I get this exception: The Undelying provider failed on open.
I have some logging services inside the service and I found out that this exception occures
only when the service calls some DB service (not one particular, any DB service). The strange thing is that when the service is not hosted on IIS this same DB call works fine.
Things I've done: enabled ASP.NET impersonation on the IIS server -> didn't help.
Another thing : I'm using sql server 2008 express.
Other ideas ???
What security mechanism are you using? It's likely that you are using some sort of Kerberos/Windows Authentication and IIS is unable to pass those credentials to SQL server. This issue is sometimes referred to as the double hop issue and is typically solved by delegation (not ASP.NET delegation).
Link: Delegation and Impersonation
Assuming you are running the service in .NET 4.0 have a look in IIS and the Application Pool serving the application in question.
If the account running the application pool is ApplicationPoolIdentity look in your database that login "IIS AppPool\DefaultAppPool" has rights to access ayour database.
One of the simplest things to get pointed in the right direction is to check your windows event logs, particularly the security log. It may be telling you what's going on.
Check these on both the IIS machine and the DB machine.
Sounds to me like the most likely cause would be security.
In IIS 7.5 you have various security layers. Each AppPool has it's own security credentials which you might want to check.
Also the IIS Windows Service it self has security credentials. You might want to try setting this to Network Account if it's set to local account.
But the error message you posted is the generic WCF error. I would agree with Jim about looking in the event log for more detail. If you find it post it here.
I have a web application set up on our intranet that uses windows authentication (successfully) that I am trying to link to a database running on a separate server.
The problem that I am having however, is that when I try to use a trusted connection to log in to the sql server, instead of passing the domain/username of the person using the website the application is passing NT AUTHORITY\ANONYMOUS LOGON.
I checked that the authentication was working by having the website display a greeting that does identify my username correctly when I log on to the site, so it isn't an anonymous access issue. I think it is an impersonation issue somehow despite the fact that set in the web.config file for the application.
Curiously, the web application works fine when I run it on either my dev machine or even locally through remote desktop on the production server. I'm not sure what's going on here.
Finally, I'm running iis 7.5, windows server 2008 r2 and sql server 2008
This is called Constrained Delegation. Basically what that means is that an impersonated context by default cannot be delegated to authenticate with a resource on the network. If constrained delegation would not be in place anyone could create a web site in the enterprise and expose some benign application. But underneath, once the user authenticated with the site, it could impersonate that user to do anything, like read his mail, sale stock on his behalf, give raises to site developer, *anything. This is why impersonated contexts are not trusted outside the machine that impersonated the user.
To allow an impersonated context to connect to a remote resource (like a file share, or a database server) the domain administrator has to explicitly set up Constrained Delegation, which allows the impersonated context to authenticate with one specific resource.
There are numerous articles describing the problem and the solution:
How To: Use Protocol Transition and Constrained Delegation in ASP.NET 2.0
Protocol Transition with Constrained Delegation Technical Supplement
How To: Connect to SQL Server Using Windows Authentication in ASP.NET 2.0
Configuring Servers for Delegation (IIS 6.0)
How to: Use Protocol Transition for Impersonating and Delegating the Original Caller in WCF
it is a known behavior called double-hop issue. See http://weblogs.asp.net/owscott/archive/2008/08/22/iis-windows-authentication-and-the-double-hop-issue.aspx
If your web application tries to access your database it does it with the account under which the IIS w3wp.exe process is running (networkservice by default).
If you want to change this, you will need to use impersonation.
This document explains it pretty good.
As the document also explains depending on your application, you might want to use trusted subsystem instead of impersonation.