Securing IIS. Thwarting the Hacker-Week 23

This week's video covers the users used by IIS and how to lock down your web server. 

Securing IIS is a necessary step that every web administrator needs to perform to properly prepare their web server with the best configuration. This week’s video covers the users used by IIS and how to lock down your web server. We cover the application pool identity, the anonymous user, the new IIS 7.0/7.5 setting for the anonymous user, and more.

This is week 23 of a 52 week series for the Web Pro. This week’s topic is foundational in properly understanding the security sandbox boundaries in IIS.  Past and future videos can be found here:

You can find this week’s video here.


  • Hi Rovastar,

    Great feedback, thanks! You're right, I probably over-simplified it by just covering the IIS lockdown. I did briefly mention that this doesn't cover the application lockdown, but you are right that there is a lot more to consider to keep up on a well tuned and secure web server. Your interview sounds like a fun one. :)

  • No reason to leave System and Administrator's group at the same time in Permissions tab.
    BUILTIN\System account is already part of local Administrator's group on machine.

  • Gregory, you're right that it's technically correct to just leave the Administrators group assigned. I still set both specifically for consistently throughout the OS. The Microsoft default is to grant both users. Then if the Administrators user is ever adjusted, at least the operating system isn't denied access.

    So I always consider these as two separate accounts/roles just to keep to keep to clean and consistent (in my perspective anyway).

  • Hi Scott,

    if I use ApplicationPoolIdentity under "Application tools" for my website, is it really necessary to create a local user under Windows and then give it permissions for the website?
    Besides it, on the permissions of website should I also delete the user IIS_IUSRS?

    Thank you!

  • Hi German,

    That's the nice thing about the ApplicationPoolIdentity. You don't need to manage local users anymore.

    Just make sure to confirm that at the website level you set the authentication / anonymous user to use the app pool identity, and at the application pool level you select ApplicationPoolIdentity.

    Then the IIS_IUSRS will never be used. I wouldn't delete it since it's a group created by IIS and who knows what other dependencies it has or if you would need to use it for something in the future (it's a special group with a set SID).

  • Well, the website level for anonymous user is apppoolidentity.
    But after delete these 3 users from the website permissions the webpage doesn't load: CreatorOwner, TrustedInstallers, Server\Users.

    In order to load the webpage again I have to give permissions to "Server\Users" again.
    I don't know what is wrong here, but this is not the behavior I see on this video.

  • Hi German,

    Are you logging in as an anonymous user, or are you authenticating as your own user? If you don't have anonymous turned on then you will need to grant your user access on disk too.

    Just to be sure, there are 3 things to check (assuming anonymous).
    - Go to your website, authentication, click on Anonymous and click edit. Then make sure that the "Use Application Pool Identity" is selected.
    - Confirm which app pool your site is in. Go to the application pools, select the app pool that you're in, click advanced settings, select the identity and in the dropdown select "ApplicationPoolIdentity".
    - Go to the path on disk for your site (right-click on your site in IIS Manager and click 'Permissions') and add IIS Apppool\apppoolname (where apppoolname is the name of your app pool). It should add a user with a group icon with the name of your app pool. Make sure that if all sub-folders which aren't inheriting from parent are updated too.

    Once all three of those steps have been completed then all interaction on disk should use the app pool identity and it should work without using the Users account. If it still doesn't work then double check everything, for example which app pool the site is in, if the IIS bindings are bound to the correct site, etc.

  • Thank you Scott for your help.
    The problem was caused for the item 1 of your detailed list. Now it is fixed.
    What I don't understand is the item 3 of that list. ¿What should be "Apppool": is that "Application Pools"? Anyway, even without this configuration the site is running fine.
    BTW: I'm using anonymous authentication.

  • Hi again,

    I delete the users we talked. But when I check permissions of the website's folders on the hard disk, the dir "aspnet_client" is not inheriting permissions (and it seems I can't change it) and this has two users else: "everyone" and "server\users". Is that right?

  • Hi German,

    Great! Glad that you got that working.

    The aspnet_client folder hasn't been needed since .NET 1.1 so you can delete it and it shouldn't hurt your site. But to fix permissions you would need to edit the folder settings, go to advanced and turn off 'inherit from parent folder' (or a similar name). Then you will be able to remove unneeded users.

    Here's a video that explains the iis apppool users: It's from the previous week.

Comments have been disabled for this content.