How to Secure a Default IIS Site & Enable Windows Authentication

If you already had Windows Authentication installed for IIS then this is how you should configure your Authentication option for that site.

Step 3: You have to change the permissions of the web site. I would break inheritance first and remove “Users” from having any access. Thus leaving behind any default Admin security principals that have access. For one-off users, you can simply add them back into the permission stack here with basic read-only access. Note – I did this for “Frank” so that he can have read access to my reports. Normally most people would grant a specific Group Read access to the site.

Right-click site select “Edit Permissions.”

Next, click “Advanced.”

Then, select “Change Permissions.”

Now, UNCHECK, “Include inheritable permissions from this objects parent”

When prompted with a WARNING, select ADD. This simply copies the existing permissions back without inheritance, this is very important as to not break the website for yourself and the system at large.

Next, delete the permission for Users. This will disable the ability for any domain users to simply authenticate to your site to view the reports. Also, this default set of permissions will now allow local admins, and members of IIS_IUSRS to log in and view reports. This set of base permissions can vary from OS to OS. At this stage, you should also double check that no other well-known security principals have any access such as “Everyone”, or “Authenticated Users”.

Last, you can now use the basic “Edit” button to add simple Read Only access for select Users and Groups, in my case I gave Frank Read access to my reports. For basic Site usage nothing more then Read access is really needed. Don’t give people modify or full control access unless there is some special need.

Tips & Notes:

This was tested on Windows 2008 and Win 7, I did not need to bounce IIS for any of these changes to start working.

Depending on your environment and domain, your IIS install may leverage either Kerberos or NTLM for Windows Authentication. Forcing the stronger protocol Kerberos is a topic for a separate blog and may not even be possible depending on the configuration of your domain. Hopefully, at a minimum, if both the server and client are part of well-configured domain Kerberos will be negotiated first, but be advised NTLM is still present almost everywhere as a fallback.

Learn about how STEALTHbits addresses Windows security with StealthAUDIT for Windows.

Don’t miss a post! Subscribe to The Insider Threat Security Blog here:

Name

Email*