IIS Insider - August 2006
By Ken Schaefer, Systems Engineer Consultant, Avanade
IIS Insider is a monthly column designed to answer your questions on how to troubleshoot and make the most of Microsoft Internet Information Services (IIS).
.gif)
The example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious. No association with any real companies, organizations, products, domain names, e-mail addresses, logos, persons, places, or events are intended or should be inferred.
Authentication and Authorization in IIS
Fac1
Q. I have installed Windows Server 2003 with IIS 6 in an intranet environment and I want to configure authentication, using basic authentication, so that only a particular Windows user is able to access the pages and other users cannot access the pages. How do I do that?
A. Before answering your question, it is important to understand a security-related concept, namely the division between authentication and authorization (frequently abbreviated to AuthN and AuthZ).
Authentication is the process of proving you are who you say you are. You might connect to a remote service and say �I�m John Doe� and the remote service replies, �Prove it.� At this stage, there are various technologies that allow you to send credentials to the service to satisfy the service that you are who you claim to be. IIS provides support for a number of technologies, including Basic Authentication, Digest Authentication (for Active Directory accounts), NTLM (various versions), Kerberos and client-certificates. The strengths and weaknesses of these various authentication mechanisms were discussed in an earlier IIS Insider column.
Authorization is a separate concept. Authorization is a process by which the system determines what actions you as a user can perform. Typically this involves comparing your user identity (after you have authenticated), and the action you want to take (for example, read a file) against an Access Control List (ACL) that lists the actions authorized to be taken by various users.
Returning to your original question, Basic Authentication cannot be used to limit which Windows users can access the Web site. Basic Authentication is a method by which a user authenticates to the server. To restrict access to a single user, we need to configure appropriate Access Control.
We can control access via NTFS (NT File System) permissions. To do this, please do the following:
Locate the files or folders you wish to secure in Windows Explorer.
Right-click and choose Security.
Remove those users and groups that should not have access, and add those users and groups that should have access.
Typically, most Web pages (both static HTML pages, and dynamic pages such as ASP/ASP.NET) need Read access only.
Note: There are two types of read permissions: NTFS file system permissions and metabase permissions. Although IIS also has a read right stored as a metabase property, this attribute is not required in this case. IIS does not require dynamic or scripted content to have the metabase read permission set. It is important to not confuse these concepts.
In the screenshot below, we have removed the Users group, and permitted only the IISInsider Test User access to this folder.
.jpg)
Kerberos Authentication in a Load-Balanced Web Farm
Fac2
Q. I have a two Web servers in an NLB cluster. How can I configure Kerberos authentication to work in this scenario?
A. As part of the authentication process when using Kerberos Authentication to a domain, the Key Distribution Center (KDC) gives the client machine an encrypted service ticket. When using Microsoft Active Directory, the KDC is hosted on an Active Directory Domain Controller. The client machine then sends this service ticket to the server, which decrypts the ticket, and uses it as part of the process of verifying the user�s identity.
The service ticket needs to be encrypted using a shared secret that only the KDC and the server (IIS, in this case) have knowledge of When running Web application pools using LocalSystem, Network Service or Local Service, the web server�s Active Directory computer account password is used as the shared secret since this is known only to the server and to Domain Controllers.
However, when in a Web farm scenario, the KDC doesn�t know which individual Web server will be receiving the client�s request. So there is now way that it can know which machine account password should be used to encrypt the service ticket.
To resolve this problem, we need to configure our Kerberos infrastructure in a way that resolves this ambiguity. To do this, follow the following steps:
Run the Web application pools on both servers using the same custom Domain user account.
Register a Service Principal Name (SPN) for your Web application�s fully qualified domain name (FQDN) under this domain account (and only under this domain account) in Active Directory.
Once this is done, the KDC knows to use the password of this custom account to encrypt the service ticket when accessing the Web application using this FQDN, and it will be able to be decrypted on either Web server, because the application pools on both Web servers are running under that same account.
SPNs can be registered using the SetSPN.exe resource kit tool, or by using a graphical tool such as ADSIEdit.msc. To use SetSPN to set the necessary SPN, run the following command:
setSPN HTTP/host.domain.com Domain\User
In this example, the FQDN equals host.domain.com used to access the site by your clients, and Domain\User is the user account that is set as the identity of the IIS Application Pool. To successfully add, edit, or modify SPNs in Active Directory, you must have Domain Administrator privileges.
For more learning and tools for Kerberos, please use the following resources:
� Registering SPNs
� Download SetSPN Resource Kit
� Install ADSIEdit
� Kerberos in Load-balanced environments Whitepaper
IP Addresses Automatically Added to IP Address Restrictions?
Fac3
Q. I've had some issues with IP addresses appearing to be automatically added to IP address restrictions (at the �Web sites� level) and being denied access on an Exchange front-end server. This is affecting OWA users as it prevents access to their e-mail. Do you have any suggestions as to what could be causing this?
A. IIS has no built-in feature to do this. You will need to look at other products you have installed on the server (most likely, security software of some sort) that might have some functionality that analyzes incoming requests and alters the IP address restrictions settings.
If you have the original Microsoft Operations Manager (MOM) 2005 IIS Management Pack (MP) installed"the one that comes with MOM 2005'"there is a set of rules in that MP that causes this behavior. The current IIS Management Pack (available here) no longer has this functionality.
If you are running Windows Server 2003 SP1, one way to track down what process is making these changes is to enable IIS metabase auditing, which provides alerting on changes made to the IIS metabase. See https://www.adopenstatic.com/faq/IISMetabaseAuditing.aspx for instructions on enabling this, or view the Microsoft webcast, Important Updates to IIS 6.0 in Windows Server 2003 Service Pack 1.
For More Information
Submit your questions to IIS Insider. A response is not guaranteed; however, selected questions along with the answers will be posted in a future IIS Insider column.
Visit IIS Insider column archives for a list of previous months' questions and answers.
We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as is," without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported, or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental, or consequential, even if it has been advised of the possibility of such damages.