Can a sysadmin add a user as a local administrator remotely by using ADFS?
I would like to avoid to do it from every machine.
/Marco
No - ADFS is used for authentication, not for provisioning.
There is no ADUC-like functionality.
You could probably customize it (depending on the version you are using) but (security wise) that's probably not a good idea.
Related
I'm working on on-premise web application (front end hosted on IIS) that currently uses traditional form-based authentication. Our client wants the application to support "single sign on", which basically means he wants the users to automatically log in to the application. AFAIK there are two ways I can take to achieve the desired effect:
Most articles that I found suggest using some kind of Identity Provider system (like Active Directory Federated Services), which my application can communicate with over SAML/OIDC in order to obtain user's claims.
On the other hand, I could set up IIS to use Integrated Windows Authentication and get user claims directly from Active Directory through Kerberos/NTLM. This approach seems easier.
Given that my application will not be used outside of intranet, it is hosted in environments using Microsoft products (Active Directory, Windows Server, users using Windows machines), is there any reason I should consider the first approach?
I had some malicious javascript appended to my .js files on a website and tracked the hack in my logs to an old FCKEditor exploit.
As a relative novice, I've been reading up a bit on how this was done and how I can protect against it, but I have a few specific questions, listed below.
If it's helpful, this was Windows Server 2012, IIS 8 and SQL Server, and, I'm embarrassed to say it, but this was an old site still running Classic ASP. Here are my questions:
I had IUSR as my Anonymous User in IIS. When the hacker uploaded the .asp file to get shell access, I assumed they only had the privileges conferred to them via IUSR, correct? If the server is properly hardened, they can't escalate privileges to get more access than what IUSR has, right?
I've changed my Anonymous User to be the application pool identity. Since a hacker's grab-shell-access ASP program now won't have IUSR's privileges and will only have the application pool identity, is it safe to assume that they can't get the ability to run commands like WHOAMI or any other such commands? What rights would application pool identity (and thus any of my .asp programs that serve up web pages) have?
Last question. OK, so I clearly was giving IUSR too much power on this box, given that an anonymous user for IIS could run a .asp program and get shell access. So how do I query what privileges IUSR has across the entire computer? I know I can, for example, right click on my inetpub folder and look a security to see what IUSR can do, but is there a way to get a report across the entire server to understand the full rights and privileges for that particular user.
My focus with these questions is more about general learning than about protecting this box. I'm sure some might be inclined to say your box is probably toast and backdoored, so dump it and start with a new server, but I know that. I also know that I should have done some hardening that I didn't. Thanks for your answers to questions above, which will help me learn and improve. Much appreciated.
1.IUSR will determine what identity you are using to view your web page and also application pool identity will decide whether the application or shell can be executeed. So you need to minimize permission for both app pool identity and iusr.
2.By default application pool identity don't have permission to access something like powershell or cmd. So you don't have to afraid command like whoami will be executed.
3.I'm afraid there is no simple way to do permission traversal. But you just need to make sure you have already minizized your application pool identity permission.
I have a new Win7 workstation and I am trying to get ScrewTurn Wiki to run on the machine. My STW installation is using the file system option to store its data, and as such I need to give write permissions to the ASP.NET worker process in the folder the website is installed in.
HOWEVER, I cannot seem to be able to come up with name of the worker process in Win7 in order to add it to the permissions for the folder. In XP it was ASPNET_WP, if I remember correctly, but that is not its name in Win7.
Can someone please tell me?
Edited to add:
In response to #Dragan_Radivojevic, here's what the application pool in question looks like (named ScrewTurnWiki):
The Identity is "ApplicationPoolIdentity"
Giving write permissions to all IIS_USRS group is a bad idea from the security point of view. You dont need to do that and you can go with giving permissions only to system user running the application pool.
If you are using II7 (and I guess you do) do the following.
Open IIS7
Select Website for which you need to modify permissions
Go to Basic Settings and see which application pool you're using.
Go to Application pools and find application pool from #3
Find system account used for running this application pool (Identity column)
Navigate to your storage folder in IIS, select it and click on Edit Permissions (under Actions sub menu on the right)
Open security tab and add needed permissions only for user you identified in #3
Note #1: if you see ApplicationPoolIdentity in #3 you need to reference this system user like this IIS AppPool{application_pool_name} . For example IIS AppPool\DefaultAppPool
Note #2: when adding this user make sure to set correct locations in the Select Users or Groups dialog. This needs to be set to local machine because this is local account.
I know this is an old thread but to further expand the answer here, by default IIS 7.5 creates application pool identity accounts to run the worker process under. You can't search for these accounts like normal user accounts when adding file permissions. To add them into NTFS permission ACL you can type the entire name of the application pool identity and it will work.
It is just a slight difference in the way the application pool identity accounts are handle as they are seen to be virtual accounts.
Also the username of the application pool identity is "IIS AppPool\application pool name" so if it was the application pool DefaultAppPool the user account would be "IIS AppPool\DefaultAppPool".
These can be seen if you open computer management and look at the members of the local group IIS_IUSRS. The SID appended to the end of them is not need when adding the account into an NTFS permission ACL.
Hope that helps
My immediate solution (since I couldn't find the ASP.NET worker process) was to give write (that is, Modify) permission to IIS_IUSRS. This worked. I seem to recall that in WinXP I had to specifically given the ASP.NET worker process write permission to accomplish this. Maybe my memory is faulty, but anyway...
#DraganRadivojevic wrote that he thought this was dangerous from a security viewpoint. I do not disagree, but since this was my workstation and not a network server, it seemed relatively safe. In any case, his answer is better and is what I finally settled on after chasing down a fail-path due to not specifying the correct domain for the AppPool user.
The full command would be something like below, notice the quotes
icacls "c:\inetpub\wwwroot\tmp" /grant "IIS AppPool\DefaultAppPool:F"
I always thought the user running the app pool was used to, for instance, access the file system when an application is trying to write a file.
I have an application in IIS, setup with Windows Integrated Authentication, that tries to write a file to the file system. I always get an error unless I give permissions on the file system to the specific domain user that logged in through Windows Integrated Authentication.
Any reason why I´m observing this behaviour?
Thx in advance
Are you using Impersonation? This would use the User's identity to do stuff, rather than the one of the AppPool. If you're using a third party ASP.net Application, check if they use Impersonation (for example, SharePoint does).
There is a way to revert the identity of the AppPool. Check this question which includes the RevertToSelf and HostingEnvironment.Impersonate methods. The Question is about SharePoint, but these two answers are the non-SharePoint way of reverting to the apppool, so they apply.
I've recently had my PC upgraded to Vista, which means it includes IIS7. The problem is that the ASP.NET website we're working on doesn't work anymore. I get an error because the application is trying to connect to the SQL Server with NT AUTHORITY/ANONYMOUS LOGON instead of my domain user, and anonymous isn't authorized. I've tried several things, but no solution yet:
- install and enable the 'IIS Metabase and IIS 6 configuration compatibility'
- enable Windows Authentication for this website
- created a different Application Pool with managed pipeline mode set to Classic
- enabled IIS6 WMI compatibility and IIS6 management console (getting desperate here)
In our web.config there's and in our machine.config there's . I've tried putting impersonate to false and entering my domain user and password in the machine.config (it used to be like this) but that didn't help either.
Are there things I'm missing? Has anyone else had a similar problem?
How does your application authenticate with SQL Server? Does it use SQL or Windows Auth? I hope you are trying to use Windows Auth. In that case, your IIS worker process should be running under that Windows user account. If not, it should at the least impersonate a Windows user account that has necessary access rights to SQL Server. If you have impersonation enabled and if you are using the right Windows user account and if SQL Server authenticates using Windows auth and if you are still unable to access SQL Server, you may be running into the classic double hop issue. In other words, you are trying to authenticate to IIS once and you are using the same crdentials to authenticate to the SQL Server over a network next(which is your second hop) and Windows does not allow that for security reasons.
I believe I have found a/the solution. At least it's working now. This is what I did:
The website is now running in a seperate application pool with Managed Pipeline mode set to classic, Load userprofile set to False and Identity set to custom and using a domain user (and password) that has access to the database.
Under 'authorization' of the website itself, I have Anonymous set to enabled and ASP.NET impersonate set to disabled.
in the web.config of the site is also set.
Credit where it's due, this site helped me.
I'm sorry to say I can't look into the issue any further. Indeed, it probably is something with the way we connected to SQL Server (Win Auth) because we've changed it now. Now we connect with username and password in the connection string and it's solved.
So I can't really say if you provided the answer, msvcyc, but I did vote on your solution. Thanks for the time and trouble.
Well, I recommend you migrate to Integrated mode if there is not too many troubles to enjoy the innovation it brings. :)
http://mvolo.com/blogs/serverside/archive/2007/12/08/IIS-7.0-Breaking-Changes-ASP.NET-2.0-applications-Integrated-mode.aspx