Friday, October 30, 2015

IIS ApplicationPoolIdentity - Credit -

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 SysInternalsProcess 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.

Repost - 

Wednesday, October 07, 2015

FTP Certificate TLS Encryption fix

  • Windows 2008 R2 - IIS 7.5 using FTP
  • FileZilla (Protocol=FTP; Encryption=Require explicit FTP over TLS; Logon Type:=Normal; UserName=****; Passwword=****** Currently there are 3 virtual drives and when I connect via FileZilla they all display fine, however when I try to configure a 4th virtual directory it will not display in FileZilla.
I am actually getting a sporadic failure all together after the directory is created:
Command: LIST Error: GnuTLS error -110: The TLS connection was non-properly terminated. Status: Server did not properly shut down TLS connection Error: Transfer connection interrupted: ECONNABORTED - Connection aborted Response: 550 Keyset does not exist Error: Failed to retrieve directory listing
If I delete the Virtual Directory the directories will display again. What is wrong, all the permissions are identical. Is there something with the SSL that has to be configured on the directory? Any assistance would be great.
ANSWER - The "550 Keyset does not exist" error message may be caused by the pass-through authentication settings for the virtual directory. If pass-trough authentication is configured to use a 'specific user' rather than the default setting of 'application user' then the 550 error will be returned unless(probably) the 'specific user' is granted permission to access the Machine Keys for certificates.
Granted READ ONLY Access to the C:\ProgramData\Microsoft\Crypto\RSA directory for the particular FTP User Account