I just read something that said it's much better to use integrated security here on SO, so I've switched all my connection strings over.
The error I get is "Login failed for user 'IIS APPPOOL\DefaultAppPool'."
Before I go ahead and grant this user permission, I wanted to ensure that it was the correct thing to do and I wasn't inadvertently opening the floodgates of hacker hell.
Should I grant this app pool permission to access my SQL or should I create a new app pool?
I'm writing WCF services in .NET 4.5
Do you have other sites or services on the server that use this app pool and could potentially provide a security risk for database access? If yes, create a new app pool. Do you have another site that might cause the app pool process to crash, or might have a memory leak (thus affecting other sites in the same app pool)? If yes, create a new app pool.
Other than slightly more memory usage, app pool isolation really doesn't have any serious downsides. Microsoft "generally" recommends it (although this article is about SharePoint setup, the app pool / database access concept is the same):
You need to establish which Application Pool in IIS is going to be used by the IIS Web Site. Application Pools in IIS access resources on behalf of the Web Site using an account identity that you specify. This Application Pool will be used by the web application to access its content database. Generally, you’ll want to create a new one to keep it separate from the existing Application Pools.
See this thread for some additional discussion of the pros and cons of separate app pools per site.
Related
I've got a rather unwieldy legacy intranet app that does a lot of file manipulations across multiple network shares (file reads, moves, deletes, creates directories, etc) and I want to set up a preproduction instance. Currently the app pool is running under a domain account that has been granted access to all these scattered directories. I'm wondering if running a second instance of the site (different server) using the same domain account would be an issue.
This doesn't seem to be an easy question to formulate in a way to get a useful answer out of google. Anyone have any experience doing this? I would rather not have to create more accounts and track down all the locations that would require added permissions if I don't have to.
The aim to set different application pool identity for different application pools is to restrict the limit for application pool. Independent application pool will isolation NTFS permission from accessing the files that the web app shouldn't reach. Just in case the server are under vulnerability attack.
Of course, if you are hosting your web apps in a isolated network environment, you could share your domain account for multiple application pools.
As Lex said, consult your network administrator would get more practical answer.
We have a multi-tenant web app running in Azure App Services. Occasionally, we need to bind a new custom domain. Unfortunately, this causes the app to recycle - as I'm guessing the web.config is altered.
Is there any way to do this without a recycle?
I'm not 100% sure if this will avoid recycle but might be worth giving it a try.
You could associate a traffic manager with your app and then do the domain assignment on the traffic manager.
Traffic manager will work even if you have a single endpoint and might give you the indirection you need.
To who it may concern,
I am looking to move more of our applications that the company uses to azure. I have found that Remote App will allow people to us the apps I have allowed via the Remote App. The application which will be used is linked to a database which is on site, I am just worried about people being able to access this database as it will contain important data which cant be leaked. I am trying to work out what are some security precautions which could be taken to prevent the data from being viewed by the wrong people. I have seen app locker to stop applications on the virtual machine from being accessed. Any other security suggestions would be greatly appreciated.
You should be fine. Remote app is running remotely - meaning that theres no way of getting to the connection string (reverse engineering). Access to the app is also ensured by AAD login. The database should be protected as well with AD credentials. Also, adding a service tier that fronts the database would provide a facade.
just starting to explore Azure and I am still a bit confused regarding the purposes of web roles vs worker roles. In the solution I'm working on mobile apps (iPhone, Android, Windows etc) will be accessing our server product via a REST api. So there is really no public facing web site for our service (as in web pages).
This made me think that I don't need a web role but instead have one or worker roles listening on our http endpoints. I have created a prototype along these lines. When from a mobile device I do I an http post to the endpoint, I get no response back. And I see nothing in the Azure logs that indicate that indeed my worker role was started or is running and responding to it.
Is this an appropriate approach? Is there something I need to do in setup code because I don't have a web role? I read in another thread that web roles run in IIS but worker roles don't.
Thanks for bearing with me. I am still getting to grips with Azure and so have a little difficulty formulating the right question.
You don't need to have a web role in your azure deployment. As you read, a web role has IIS, and your web site is hosted in it. A worker role is basically a plain old W2K8 server without IIS. Honestly, I haven't RDP'd to a worker role instance, so I'm not 100% sure that you don't have IIS or not.
But you don't need a web role in order to expose a WCF service. Here's a nice example (although the background color needs some work) that shows you how to do this.
Good luck! I hope this helps.
Adding to what David Hoerster said: You can host up to 25 externally-facing endpoints (each with its own port number) on any role type, with each endpoint being http, https, or tcp. With a Web Role and IIS, a web application typically grabs an endpoint mapped to port 80. In your case, you'll be creating your own endpoints on your specific ports. You're responsible for creating your ServiceHost (or whatever you're using to host your service) and binding it to one of your endpoints. To do this, you'll need to either map each endpoint explicitly to a specific internally-facing port, or inspect the endpoint's properties to discover which port has been dynamically assigned to it, for you to bind to (might this be the issue you're running into with your prototype code?).
If you're looking for the benefits IIS offers when hosting your endpoint, you're better off with a Web Role, as it's going to be much easier for you to do this since a Web Role enables IIS by default (and it's easy to add WCF services to a Web Role from Visual Studio).
Even if you were to self-host your endpoints, you could still use a Web Role, but now you'd be carrying the extra memory baggage of a running, yet unused, IIS service.
My web-app runs in IIS 6.0 under windows server 2003, and we all know that in this situation, user account "Network Service" is used by IIS.
I happen to have to allow certain user to perform some action on my web page, and that action requires administrator privilege.
The laziest solution to me seems to add "Network Service" to Administrators Group, and it actually works.
MY QUESTION is, how DANGEROUS this solution is, and in what way can it compromise the security of my web server?
This is generally "a bad idea". If this is a public facing server then this is a really bad idea.
What you should do, and this is how we approach problems such as this, is sandbox the specific admin tasks you need to carry out in another process such as a Windows service which has elevated rights.
We then host a Remoting Server in the Windows Service and communicate with the service either over a named pipe or TCP/IP (if machine to machine and this is over a back end private network).
For more information, please see this answer which I left for another user regarding a similar problem:
Windows User Account that executes only IIS7 Provisions
An even better approach would be to never have direct communication between the web application and the windows service, but go through an intermediary such as a job or message queue. Your low privileged application places request for the admin task to be carried out, your elevated privileged service reads these tasks from the queue and carries them out.
In both cases you should ensure that you don't overscope the responsibility of each task. i.e. ensure that if the task is to create a new Windows account on the server then don't allow that new account to gain more rights than it needs.
If I were to write some web function that required box-level admin, I would make that it's own application in its own app pool, lock down that application as tightly as I could, give that app pool a named account (a domain resource, if on an Active Directory), and then give that account admin privileges on the box. Keeping it in its own app pool effectively locks it down from your regular application.
NT Authority/Network Service interacts with a ton of stuff on your machine. I cannot come up with any good reason to get Network Service admin privileges.
Under no circumstances do this.
If you add Network Service to admin group, then all anonymous users accessing your Web app will be admins by default and the damage potential is massive.
Per your question
I happen to have to allow certain user to perform some action on my web page, and that action requires administrator privilege.
that's fine - use Windows authentication on that web page and make the user a normal Windows admin. Now they, and all other admins, can perform the tasks you have set up.