We're trying to run a set of administrative tasks on the server via a web administration console. The console runs with impersonation as the currently logged-in user, and only administrators on the local machine are allowed to log in. Right now it works for most cases but we're having trouble when running under UAC.
The first issue is a blocker: it seems like admins do not get the "BUILTIN\Administrators" role even if they are an admin on the local box. This can prevent them from even getting into the admin console, since we're using the web.config <allow roles="BUILTIN\Administrators"> notation to specify security. I suspect that the only solutions here are to either run the ASP.NET app as SYSTEM, or to allow more users and do a more granular permissions check in code. Any other ideas? Is there any way to inject an elevation request into the built-in ASP.NET permissions check?
The other problem is that we want to run some commands that require administrator access. The user visiting the site is an administrator, and is correctly impersonated, but when we spawn a process it fails due to lack of administrator privileges. The clear answer is to elevate for the duration of that command. There are solutions that will let me temporarily elevate by impersonating a specific username and password, but I'd prefer not to have to ask the already-validated user for his password. Are there any tricks for elevating the current user?
(I can understand why the ASP.NET team might try to make this hard, so that web pages can't take invisible advantage of an administrator visiting the web site... but surely there must be some way to pro grammatically declare that your code needs full Administrator rights, appropriately warning the IIS admin of its intentions?)
There are a series of answers for Windows Forms apps, such as:
How to elevate privileges only when required?
and File.Exists returning false from a network share
but I'm hoping to find one that will work with ASP.NET...
Thanks
Steve
We were able to achieve a "higher" impersonation level from the user currently accessing the website by enabling the server for delegation in Active Directory. Per Microsoft, You can think of delegation as a more powerful form of impersonation, as it enables impersonation across a network. You may not need to go across the network, but it may resolve your security issues.
Here are a few resources on setting up delegation, hopefully this will help you.
Impersonation and Delegation
Impersonation and Delegation in ASP.NET
http://support.microsoft.com/kb/810572
http://msdn.microsoft.com/en-us/library/aa291350(v=vs.71).aspx (older article)
http://msdn.microsoft.com/en-us/library/ms998351#paght000023_delegation
Related
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/
I have looked at numerous articles and tried a multitude of settings, but I can't seem to achieve what I'm looking for in my intranet site. Even if I don't get a solution, a definitive "you can't do that" will help me move forward. Here is what I'm trying to do:
Web site recognizes the user's network login credentials - ONLY so I can get their user ID without a login
The website uses some generic account (IUSR or something like that) to access a SQL Server that the same network users can NOT access EXCEPT through the website
Users can upload files to a set of folders created on-the-fly by the website to contain their files for later reference by them
The website can construct web pages on-the-fly with links to the users' files - and ONLY theirs - so they can open / download them through the web pages
Users can NOT access the uploaded files through a network share on the web server
All of the folder creation, file upload, and file serving occur under some generic account like IUSR
I currently have things configured to use Windows Authentication and I could probably live with that except I don't want to require a login to the site. Apparently, in order to make this happen, I need to have the server configured as a trusted delegate and IT is dragging their feet on doing that. Also, this config allows the users to access the SQL Server and folders/files through means other than the web site and I don't really want that. I only need to pick off their user ID so I can use it to get information about them out of Active Directory and keep track of their interactions with the web app.
In reviewing your post I must first say "Yes" it seems like what you want to accomplish can be done. However the enormity of your question precludes simple posting answers. From what I gather there are three security issues you want to navigate 1) Windows Authentication, 2) Admin only SQL access, 3) User only Access to files and directories while authenticated using Active Directory.
I have been building ASP.net intranet web applications using Active Directory (Windows logins) for a few months. I would encourage you to explore this article: http://www.mikesdotnetting.com/article/216/windows-authentication-with-asp-net-web-pages for details on setting up windows authentication in an ASP.net web application. You can add elements to your web pages using a section of Visual Studio [Toolbox] called 'Login', which contains elements such as 'LoginName'.
Next I am pretty sure you can control the SQL server query access using authentication parameters of your choosing. In the portion of the connectionString that is normally 'Integrated Security=True;' you will need to switch that to 'Integrated Security=False;username=sqlAdminUserName;password=sqlAdminPassword'. For more information I suggest reviewing this post: Integrated Security = False.
For the third security issue once you have isolated the user's windows login identity you should be able to dynamically build web pages, files, directories, and whatever other resources you require all customized for that individual user. I believe the generation of all those materials can be done with an IUSR account with the only needed ingredient being the Windows login user identity.
Good Luck and I hope my suggestions help move you ahead.
Actually, the answer is not all that complex and it is a real mystery why it is so difficult to find a single source on the web to spell it out. Here is my IIS authentication for an intranet app that acts exactly how I want:
Enable ASP.NET Impersonation and edit to Authenticated User
Enable Windows Authentication
Advanced Settings->Extended Protection->Off
Advanced Settings->Enable Kernel-mode authentication->unchecked
Providers->Available Providers->Negotiate:Kerberos and move that to the top
Disable all other authentications
Most critical: Make the server a 'trusted delegate' in Active Directory
That should do it.
I am trying to give access to an App Pool to create some files in the website directory (inside inetpub) and I it keeps denying me access because it says the user doesn't have admin rights. I ran the AppPool as LocalSystem and it still failed. Doesn't LocalSystem have full control over folders? I ran it as AppPoolIdentity and gave the proper rights to those folders, and it doesn't work. The only way I can get it to work is by giving it a custom admin account... but that saves the username/pass in the web.config and that password expires every 90 days. We cannot have websites fail every 90 days.
Is there an easy way where I can run the AppPool as built-in admin without giving some custom account?
Only 18 months late. Nevertheless, I think the problem is that your website runs with anonymous connections right? Anonymous users connecting to your website will not run as admin. This is configurable.
The following is applicable to IIS7 (I think it'll also be applicable to IIS6, though I have no access to that version; almost certainly not applicable to IIS5 and earlier).
So anyway, to change this setting in the IIS Manager, go to:
Sites > [Your Website]
In "Features" view under the IIS subsection
Authentication [Open Feature] > Anonymous Authentication [right-mouse "Edit..."] > Select: Application Pool Identity [OK]
This allows anonymous connections to work under an admin privileges on the OS level, giving you access to files and a whole lot more besides.
Either that, or I've not quite understood your problem.
This application is using windows integrated authentication in IIS. No anonymous login.
It's also using an application pool defined to log on with a domain user.
If a try to browse any page, it pops up the username and password dialog box and even though I entered a valid user (including the domain administrator) it doesn't log on into the app. I keep getting the username/password dialog. If I logon locally (in the IIS box), it works OK.
Also, if I change the application pool to use Network Services, it works OK.
The domain user is already a member of the local IIS_WPG group in the IIS box.
Am I missing something here?
If you use a domain account for the Application Pool you have to run a series of scripts on the domain controller. So, apparently it's not recommended to use a domain account, rather a local server account. Microsoft has this issue documented on a case:
http://support.microsoft.com/default.aspx/kb/871179
I suspect the NTFS file persmissions on the .aspx files don't allow the users you are logging in as the needed access to read/execute them. What are the file permissions on the files you are trying to view? What do your authorization and authentication elements in web.config look like?
This sounds like it's related to the privilges assigned to the domain user. i.e. whether they, or indeed the server, are permitted to impersonate the user that is logging in. Or, something regarding "Trusted for delegation" in the server's settings in AD. Either way, you'll probably get a better response on serverfault =)
Try entering the same user of the appPool as the anonymous user (Web Site Security tab)
I had the same user/pwd Popup problem in Svr 2003.
I solved it by CHECKING ANONYMOUS ACCESS in directory security of DEFAULT WEB SITE.
It promps you if you want to also affect your sites you click OK.
That did it.
I've been having trouble getting my ASP.NET application to automatically log users into the Intranet site I'm building. No matter the googling or the experimentation I applied, there is always a login box displayed by IE7.
I've got Windows authentication mode set in the Web.config, disabled anonymous access and configured the correct default domain in IIS, but it's still asking the user to log in and, more annoyingly, the user is required to provide the domain too (DOMAIN\auser), which is causing problems with non-technical visitors. Thank Zeus for password remembering functionality.
I'm not the network administrator so it's possible that something about Active Directory is set up incorrectly, or it could just be me missing something very simple. Please note that I don't want to impersonate the user, I just need to know that the IPrincipal.Name property matches that of a valid record in my user database, hence authenticating the user to my application.
To this end, it would be very useful to have a checklist of all configuration requirements for AD, ASP.NET and IIS to work together in this manner as a reference for debugging and hopefully reducing some user friction.
It sounds like you've covered all the server-side bases--maybe it's a client issue? I assume your users have integrated authentication enabled in IE7? (Tools -> Internet Options -> Advanced -> Security). This is enabled by default.
Also, is your site correctly recognized by IE7 as being in the Local Intranet zone? The IE7 default is to allow automatic logon only in that zone, so users would be prompted if IE thinks your site is on the internet. I believe using a hostname with a dot in it causes IE to place the site into the Internet zone.
Open Active Directory Users and Computers MMC snap in
Expand computers section from TreeView (left side)
Check if the computer is registered in your domain.
Also, you have to login with a domain account on that computer, otherwise that authentication box will be shown.
In IIS, enable annonymous access and allow the web.config to handle user authentication.