IIS Requests Login Credentials on Windows Authentication - asp.net

I have decided to transfer several of my web applications from one virtual server ot another. The way everything works on my current server is pretty bad - everyone has rights for reading and accessing the content of my "applications" folder on the machine, and so does the IIS. I want to organize stuff on the new server, so only IIS can access this folder.
I have installed IIS and the ASP.NET addons on the new server, and forced my test website to Windows Authentication, as all of my websites are configured on the current server. Then, after doing some reading regarding the permissions, I have given full control to the folder that contains my website to the next users: IIS_IUSRS & TestAppPool (which is the Application Pool I have created for my 'Test' application).
For some reason when I try to access the website from another user within the domain, through the browser, it promts for Login Credentials. I would like to understand why my application wont retrieve the permissions I have granted the IIS users upon accessing the website.

not sure if this would help, but can you try changing the app pool's identity to Network Service?

Related

Missing site assets when no local\Users permission on the folder

I'm working on the Umbraco site (asp.net MVC) hosted on local Windows Server 2016+IIS10.
During regular template modification, I have experienced strange behavior - the site lost all of the assets hosted from local files. All the requests to cases or images were redirected to the login page. A few people reported similar behavior, commonly resolving it by permission checking. So did I - ensured that my pool user has granted full access to the folder and all its descendants. It was, so I removed it and applied it once again. Still no luck. I have copied the website files and created another web app in IIS - this one worked without any glitch.
Later, my co-worker found that the application folder is missing access permission for the local machine "Users" group. When we added it - the site is served without any issues.
The webserver is part of the corporate domain (AD) and the app pool user is a "service user".
Is it normal that it needs both - pool user and local "Users" permission?
Why is so?
It is normal. When the static file and the application are in same machine, the application needs higher permissions to read the static file.
When the application runs in IIS, it will use the identity of the application pool to read static files, and the default identity of the application pool is ApplicationPoolIdentity, with the lowest permissions.
The test in visual studio does not have this problem because IIS express runs the application with the same permissions as the administrator.

IIS and ASP.NET impersonation

What risk is a user exposed to if he accesses a .net web application with impersonation enabled?
What impersonation level is ASP.NET impersonation?
This is the documentation of impersonation-levels.
Can I create a website, then lure a sysadmin to open it and do some bad stuff in his name (like adding me to the local sysadmins. I can deploy web applications but I am not an admin)? What are the boundaries of this impersonation? Did not find any precise description in the docs.
First of all you need to understand what is ASP.NET Impersonation. Apart from msdn given definition, in layman language, ASP.Net impersonation is ability to get user information of Active Directory Logged-in user on machine using client side asp.net application.
As you mentioned, there are different impersonation-levels.But before going to that you need to understand that ASP.Net is managed environment. It exist under the scope of IIS application pool. So any application is ability is limited to what an web application in managed environment can do on server.
To directly answer your concerns, these are few considerations:
If you can host an application is IIS having ASP.impersonation, you should be admin of that machine(non-admin users can't even open IIS)
Any IIS application can't do Administrative tasks like Creating, deleting users, changing user permissions without calling any native application for manipulation active directory(need to configured & much work needs to be done, non admin can't think of that). That is almost impossible even somehow possible with some 3rd party unmanaged code then also non-admin user can not install those tool/sdk on server without having direct access to servers.
ASP.Net impersonation is mainly for active directory users and Active Directory exists in securely managed environments in VPN or Office Premises. You need to be active directory user to access impersonation. Even somehow you did that(not possible without admin server access) then also audit/system logs/network logs will find who is insider culprit to did something like that so what that means inside an organisation(apart from getting fired) I leave upto you.
Still you think asp.net impersonation is unsafe, you can ask questions. :)
UPDATE for comments
Impersonation Level link you got above is for desktop/windows application which runs in full trust. ASP.net application impersonation is just a way to get identity of Active Directory User with some defined attributes and it is mainly used for authentication & authorization. I again reiterate, ASP.net is managed application inside App pool which only can perform action which is authorized to Account from which you have hosted application and with that too native/administrative actions like creating or modifying Active Directory User access is not possible without calling some another SDK which is already trusted & installed on that machine.
So summarize, operations like creating files or deleting file on the place where you have given Directory access to Web App is possible(Also on network if permission exists while deploying for User used for hosting not logging in) but deleting everything on server or performing Administrative tasks like AD User creation/modification is not possible via login of Admin impersonation of ASP.net webapp without assist of already installed trusted unmanaged software that can do this.
I had a palaver with my sysadmin yesterday. If the user is authenticated by kerberos, it is possible that the webapplication accesses resources on other servers in behalf of the user (delegation). Kerberos constrained delegation works with a white-list.
If my application needs to read files on a file share with credentials of the logged in user, the security admin has to add an entry that my application (identity of app-pool) accesses this file server in the name of the logged in user. I can not create a malware application that reads all the emails of my boss just because he is visiting my webapp.
See https://blogs.technet.microsoft.com/pie/2017/06/30/credential-theft-made-easy-with-kerberos-delegation/

Using ASP.Net Impersonation w/ Windows Authentication

We have a web application that copies files to a remote server within our domain (OurDomain). The following issue occurs with users that log on to their laptop with another domain, and then log on to the web application with OurDomain. Users that log on to both the laptop and web application with OurDomain\User don't have this problem.
We have two webforms:
The 1st webform retrieves the user's ID using System.Security.Principal.WindowsIdentity.GetCurrent() and then sends an email with this userid. This code retrieves the user's ID only if we have Windows Authentication set to Enabled and ASP.Net Impersonation also set to Enabled. If ASP.Net Impersonation is set to Disabled, the user will be Network Service. So I set both to Enabled and everything here works great.
The 2nd webform copies some files to the remote server, also under the domain OurDomain. With Windows Authentication set to Enabled and ASP.Net Impersonation set to Disabled, then Network Service is used to copy the files to the remote server and are copied correctly. On the other hand, If ASP.Net Impersonation is set to Enabled, it seems to bypass Network Service and even OurDomain\User and tries to copy with, apparently, the credentials used to log on to the laptop (Another domain). The files don't copy and I get error Access to the path is denied
The only fix I've found is to add OurDomain\User to the folder, and it's really not a big deal, but I wanted to see why this was happening.
Thanks.
I believe OurDomain\User is the user who is logged into the system from web browser. It is not a good security practice to give server folder access to that group of users. If you give access to those users they can even browse the remote folder without your web application.
NetworkService is a user who has role on in the system where it is created.
Better create a user as asp.net appPool user in OruDomain\webappuser ie the user who runs the w3wp worker process. Let the password with be the admin.Give OurDomain\webappuser the permission on the remote folder. Run the web form without impersonation.
Now the files which are received via file upload dialog in webform2 can be copied to the folder safely as the asp.net application run in the context of OurDomain\webappuser

IIS7 Accessing Network Share

I am running IIS 7 on Windows Server 2008 R2 with PHP 5.4. One of my PHP scripts is trying to access a file on a protected network share using a UNC path. How can I change the IIS service account to an account that has permission to access the share? This is really easy to do on Apache HTTP server (you just change it), but it's not clear how to do with IIS. What can I do?
Update:
I was able to get things working using the "Connect As" option in the "Basic Settings" of my website and then specifying an account that has access to the network share. It appears that my problem is related to this question:
https://serverfault.com/questions/366234/iis-identities-application-pool-vs-connect-as-in-basic-settings
For IIS 7 running on Windows Server 2008 R2 ... In the IIS Manager, select the Application Pool under which your Web Site is running.
Click "Advanced Settings". There will be an entry for Identity (it is under the Process Model section). Click it, provide credentials for your account that has permission to access the share.
UPDATE
You should make sure that if you are using an Active Directory Domain Account, you provided that correctly under Identity for the running App Pool. For example, MYDOMAIN\myAccount.
After making this change, you will need to do the following:
Stop the Web Site.
Recycle your Application Pool.
Start the Web Site.
UPDATE II
From the comment discussion on this answer, #HydroPowerDeveloper was able to get the PHP script to be able to access the network share via UNC path using WebSite -> Basic Settings -> "Connect As" and setting the credentials there.
In the past, I have always used the approach of setting Identity via Application Pool and that has allowed my code to access Network shares via UNC path.
However, all of the sites/applications I have deployed on IIS are .NET based WCF or ASPX sites.
I would speculate (but am not 100% certain on this, would need research/testing to confirm) that the Identity specified in the Application Pool is used by executing .NET code, whereas the "Connect As" is used by the PHP script.
Generally the Application Pool is set using the least amount of privileges as possible.
http://msdn.microsoft.com/en-us/library/ff647402.aspx
The easiest route is to allow access to the current IIS account.
In Explorer, navigate to the shared directory.
Right Click -> Properties -> Security
If you don't see the expected IIS user in the list (Group or user names), edit and add the user as required.
I used "NETWORK SERVICE" -> Check names.
The detailed instructions are on that site.
In this way, the system is still restricted, we're ONLY allowing access to specific directories, we don't need to create any new users, we don't need to recycle the application pool and we don't need to perform any nifty impersonation code.
To resurrect an old question...
I've just been setting up a Win 2016 server that uses some Perl to access a UNC share. I set the Application Pool to an account that I verified had the correct permissions on that share. I then set up my site to 'Connect as...' (under 'Basic Settings') the same user. I still couldn't get access working.
Much head scratching later, I realised that my 'Virtual Directory', cgi-bin, was running under the original 'pass through' account. I then set up the virtual directory to 'Connect as...' the same account as the site and the application pool and, bingo, it all works fine.
So, remember to update any Virtual Directories as well as the site and App Pool...

Configure IIS 6 web application on a personal server

A group of us wrote a .NET web application for our University class and in order to let our prof test with it I am setting it up on my webserver at home. Here is what I have done so far:
I created a new account on my domain, I then granted that account Read, write access to the folder where the app is stored. I have setup an application pool that uses this new account as its identity and created a new site that uses the new application pool.
I initially was receiving the Service unavailable error message, so I realized I had to add my account to the IIS_WPG account. So now I am stuck at the "page cannot be found". The website is pointing to the correct folder (I can see the aspx page list from within the IIS browser) but when browsing the site either in IIS, on a browser on the server or on a browser within my network I keep getting Page cannot be found. The home directory is pointing to default.aspx which is what our app uses.
The app of course works just fine when running from within the IDE, but now that I am trying to get it to work it doesn't want to.
Any thoughts?
Thanks.
you should give error details first.
for now, I suggest you check the 'network service' account's permission.this is the ASP.NET's account.
then publish your site to *.aspx file and *.dll file. to see if there is any errors.
So I found the issue. What I didn't know is that by default, IIS 6 does not turn on support of active server pages and .NET pages in Web Service Extensions. Once I had turned this on the site began to work just fine.

Resources