The ApplicationPoolIdentity
is assigned membership of the Users
group as well as the IIS_IUSRS
group. On first glance this may look somewhat worrying, however the Users
group has somewhat limited NTFS rights.
For example, if you try and create a folder in the C:\Windows
folder then you'll find that you can't. The ApplicationPoolIdentity
still needs to be able to read files from the windows system folders (otherwise how else would the worker process be able to dynamically load essential DLL's).
With regard to your observations about being able to write to your c:\dump
folder. If you take a look at the permissions in the Advanced Security Settings, you'll see the following:
See that Special permission being inherited from c:\
:
That's the reason your site's ApplicationPoolIdentity
can read and write to that folder. That right is being inherited from the c:\
drive.
In a shared environment where you possibly have several hundred sites, each with their own application pool and Application Pool Identity, you would store the site folders in a folder or volume that has had the Users
group removed and the permissions set such that only Administrators and the SYSTEM account have access (with inheritance).
You would then individually assign the requisite permissions each IIS AppPool\[name]
requires on it's site root folder.
You should also ensure that any folders you create where you store potentially sensitive files or data have the Users
group removed. You should also make sure that any applications that you install don't store sensitive data in their c:\program files\[app name]
folders and that they use the user profile folders instead.
So yes, on first glance it looks like the ApplicationPoolIdentity
has more rights than it should, but it actually has no more rights than it's group membership dictates.
An ApplicationPoolIdentity
's group membership can be examined using the SysInternals Process Explorer tool. Find the worker process that is running with the Application Pool Identity you're interested in (you will have to add the User Name
column to the list of columns to display:
For example, I have a pool here named 900300
which has an Application Pool Identity of IIS APPPOOL\900300
. Right clicking on properties for the process and selecting the Security tab we see:
As we can see IIS APPPOOL\900300
is a member of the Users
group.
Your problem is spaces around =
.
This will work (attention to space before closing quote):
Console.WriteLine(Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT"));
Or remove spaces (better, see comment of @Isantipov below):
set ASPNETCORE_ENVIRONMENT=Production
P.S. Stop trying to "fix error with space" in this answer! It's not a typo! The real problem in question was with extra space (in SET...), so answer is either use same space in GetEnvironmentVariable() or remove it from SET... command!
Best Answer
The environment variables you set in VSTS are just used for the deployment itself (ie anything that VSTS is doing such as building your application or running unit tests), but the runtime application will use whichever ones are on the server hosting it.
You will need to set the environment variables on the IIS server that VSTS is deploying to if you want your deployed application to use them as well. Microsoft docs show how to set this depending on your server: Setting the environment
Update in response to comments:
The reccommended way to set environment variables is on the machine itself - ie. log in to the IIS server you are deploying to and add the
ASPNETCORE_ENVIRONMENT
environment variable there insystem properties -> advanced settings -> environment variables
If for some reason you aren't able to do this, you can set them in the
Web.config
file (according to that documentation). If you are always setting the same value you should be able to just put what you need in theWeb.config
like soIf you really need the XML transforms (which, honestly, I'm not sure you do in this situation - this is for altering the
Web.config
file at deployment time based on the build configuration. As somebody else mentioned, with asp.net core the reccommended config setup isappsettings[.environment].json
files which are automagically loaded based on the matching machine levelASPNETCORE_ENVIRONMENT
env variable), you need to actually define the transformations in a transform file using the correct syntax and have it replace the parts you want to change. This is obviously the more difficult option.See: How to: Transform Web.config When Deploying a Web Application Project for creating the transformation files and Web.config Transformation Syntax for Web Project Deployment Using Visual Studio for the configuration syntax if you choose to go down that path
Something like this (unable to currently test but this should give you an idea - note the transform namespace on the transform file and the
xdt:
attributes). I believe the transform file that gets loaded matches the build configuration which you may need to configure as part of the VSTS task:Web.config
Web.Release.config (transform file for build configuration "Release")