Securing IIS Services

Lesson 6
IIS Security
IIS 7 has many security mechanisms you
can use to protect your Web servers
individually or in combinations.
Each of these mechanisms has its own
configuration interface.
IP Address and Domain Restrictions
IIS 7 retains a security feature from earlier
IIS versions enabling you to specify IP
addresses or domain names that the
server should allow or deny access to a
server, Web or FTP7 site, virtual directory,
folder, or file.
Before you can configure IP address and
domain name restrictions, you must install
the IP and Domain Restrictions role
service in the Web Server (IIS) role.
Authentication Methods
Authentication is the process of
confirming a users identity, usually by
requiring the user to supply some sort of
token, such as a password or certificate.
By identifying the user sending a request,
IIS7 can determine the system resources
the user should be permitted to access.
Authentication Methods
Even though it might not seem so in the
case of public Web sites accessible
through the Internet, IIS 7 does
authenticate every incoming request to
determine the sender.
In the case of a public site, the server uses
Anonymous Authentication, which does not
identify users by name, but still completes
the formality of the authentication process.

Authentication Method
Of the methods listed in the table, only
Anonymous Authentication is integrated into an
IIS 7 installation by default.
All of the other authentication methods require
the selection of additional role services during
the installation of the Web Server (IIS) role.
Even when you install the role services required
for additional authentication methods, IIS 7
leaves those methods disabled by default until
you explicitly enable them.
You can enable and disable authentication
methods for any IIS 7 server, application, site,
folder, virtual directory, or individual file.
Anonymous Authentication
Although anonymous users do not have to
supply credentials, enabling Anonymous
Authentication does not leave your Web
server completely unprotected.
By default, IIS 7 authenticates anonymous
users with a specifically created account.
This account has the permissions
necessary to access the Web site files, but
it does not have access to other files or
sensitive areas of the operating system.
Anonymous Authentication
The anonymous user account in IIS 7 is a built-in
account called IUSR, which is a member of a
group called IIS_IUSRS.
When you install the Web Server (IIS) role on a
Windows Server 2008 computer, IIS 7 creates the
user and the group and assigns the group the
NTFS permissions needed to access the
designated root directory of the Default Web Site
(C:\inetpub\wwwroot).
When an anonymous client connects to the Web
site, IIS 7 maps the request to the IUSR account
and uses that to access the necessary files.

Anonymous Authentication
Different from older versions of IIS, the
anonymous user account name (IUSR) no
longer includes the computer name, so it is now
identical on each IIS 7 computer.
Second, the IUSR account is now a built-in
account, just like the LOCALSERVICE and
NETWORKSERVICE accounts.
This type of account does not need a password,
which eliminates potential password expiration
problems, and is not subject to the SID conflict
problems that affect the IIS 6 accounts.
As a result, administrators can copy IIS 7
configuration and content files to multiple servers
and use them as is.
Active Directory Client Certification Authentication
If you are running an intranet Web server on an
Active Directory network with its own certification
authority, you can configure IIS 7 to
automatically authenticate domain users that
have client certificates.
This eliminates the need for users to supply
account names and passwords, while providing
a high level of security.
Obviously, this form of authentication is not
suitable for Internet Web sites because the
clients are not members of the Active Directory
domain.
Active Directory Client Certification Authentication
To use Active Directory Client Certificate
Authentication, you need to have the following:
Active Directory
Certification Authority
Secure Sockets Layer (SSL)
Domain Server Certificate
Map client certificates
Active Directory Client Certificate Authentication
only appears in the Authentication pane at the
server level.
You cannot configure individual sites or other IIS
7 elements to use this authentication method.
Windows Authentication
Windows Authentication, Digest
Authentication, and Basic Authentication
are all challenge-based authentication
methods.
Of the three traditional,
challenge/response authentication
methods supported by IIS 7, Windows
Authentication is the most secure.
IIS 7s Windows Authentication module
supports:
NTLM version 2
Kerberos
Digest Authentication
Digest Authentication is also designed
for use with intranet Web servers in an
Active Directory environment. Unlike
Windows Authentication, Digest
Authentication works through firewalls and
proxy servers because it actually transmits
passwords over the network.
The protocol protects the passwords using
a strong MD5 encryption scheme.
Basic Authentication
Basic Authentication is the weakest of
the challenge/response authentication
methods supported by IIS 7.
When a client authenticates to an IIS 7
server using Basic Authentication, the
client transmits its credentials
unencrypted.
In addition, the server caches clients user
tokens for 15 minutes, so it is possible to
read the credentials from the server hard
disk during that time.
Basic Authentication
The advantages of Basic Authentication
are that it is defined in the HTTP standard,
so virtually all browsers support it, and that
it works through firewalls and proxy
servers.
If you must use Basic Authentication, you
should use it in conjunction with SSL so
that the authentication traffic is properly
encrypted.
ASP.NET Impersonation
ASP.NET Impersonation is not an
authentication protocol in itself, unlike
most of the other options in the
Authentication pane.
Instead, ASP.NET is a way to configure an
ASP.NET application to run in a security
context different from the applications
default context.
Forms Authentication
Forms Authentication, on the other hand, is a
login/redirection-based method.
Clients attempting to connect to a site using Forms
Authentication are redirected to an alternative Web
page containing a logon interface.
The advantage of this method is that the
authentication process occurs at the application level,
instead of the operating system level like challenge-
based methods.
If you are running a heavily trafficked intranet site or
an Internet site with publicly available applications,
Forms Authentication can significantly reduce the load
on the operating system, diverting it to your application
instead.
URL Authorization
Authentication is the process of identifying
users and confirming that they are who
they claim to be.
After the IIS 7 server has authenticated a
client, the next step is authorization, which
determines what resources the client is
allowed to access.
URL Authorization
IIS7 URL Authorization uses two major
guidelines to evaluate the rules that apply to a
specific element:
Deny rules supersede allow rules If you create
conflicting rules at the same level, one of which
denies access and one of which allows access,
the deny rule will take precedence.
Parent rules supersede child rules If you
create a rule at one level, and a conflicting rule at
a subordinate level, the high-level rule takes
precedence.
Handler Mappings
In previous versions of IIS, when you
specified the home directory that would
form the root of a Web site, you could
grant clients any combination of read,
write, script, and execute permissions for
the site.
In IIS 7, this capability has been moved to
a feature called Handler Mappings, which
provides additional, more granular,
configuration capabilities.
NTFS Permissions
Although URL authorization rules provide
an excellent alternative, NTFS
permissions still factor into the IIS 7
security picture, and they are still a viable
means of regulating access to Web site
contents.
Secure Sockets Layer (SSL)
Secure Sockets Layer (SSL) is a security
protocol that you can use to encrypt the
data exchanged by clients and IIS servers.
When a user typing a URL omits the prefix
by keying just a domain address, such as
www.sitename.com, the browser
automatically uses the http://prefix. To
connect to the server using SSL, the URL
or link must explicitly contain the
https://prefix.
Secure Sockets Layer (SSL)
To use SSL on an IIS 7 server, you must
complete the following tasks:
Obtain and install a server certificate.
Create an SSL binding for your Website(s).
Configure the Web site or FTP7 site to use
SSL.
Digital Certificates and Certification Authority (CA)
A digital certificate is an electronic
credential, issued by a certification
authority (CA), which confirms the identity
of the party to which it is issued.
A certificate issued to a server enables
clients to verify that this really is the server
it claims to be.
Certificate Request File
To obtain a server certificate for your IIS 7
computer, you must either generate a
request file and send it to a commercial
CA or send an online request to your
organizations internal CA.
SSL Binding
For a client to connect to an IIS 7 server
using SSL, the client must use the https://
prefix in its URL.
For an IIS 7 server to accept an SSL
connection from a client, it must be able to
recognize and process a URL containing
the https:// prefix.
To make this possible, you must create a
binding for each Web site that you want to
use SSL.
SSL for FTP7
SSL for FTP7 eliminates one of the major
shortcomings of FTP: the transmission of
passwords in clear text.
To use SSL with FTP, you still need a
certificate, although you can use a self-
signed certificate.
You do not need to create a special
binding, but you do have to enable SSL for
the FTP site.
SSL for FTP7
FTP uses two separate TCP connections
when establishing a client/server
connection.
The control channel, which uses port
number 21 by default, is for commands,
while the data channel, using port 23, is
for the transmission of data files.
Summary
IIS 7 retains a security feature from earlier
IIS versions that enables you to specify IP
addresses or domain names that the
server should allow or deny access to a
server, site, virtual directory, folder, or file.
IIS 7 supports several password-based
authentication methods including
Anonymous, Windows, Digest, and Basic
Authentication.

Summary
In IIS 7, the authentication settings you
configure at a particular level are inherited
by all subordinate levels.
When a client connects to a site
configured to use multiple authentication
methods, it always attempts to establish
an anonymous connection first.

Summary
The anonymous user account in IIS 7 is a
built-in account called IUSR, which is a
member of a group called IIS_IUSRS.
If you are running an intranet Web server
on an Active Directory network with its
own certification authority, you can
configure IIS 7 to automatically
authenticate domain users that have client
certificates.
Summary
Because Active Directory Client Certificate
Authentication requires the use of SSL
with client certificates, it is not compatible
with any of the other authentication
methods IIS 7 supports.
Of the three traditional challenge/response
authentication methods supported by IIS
7, Windows Authentication is the most
secure.

Summary
The Digest Authentication method in IIS 7
is comparable to the Advanced Digest
Authentication method from IIS6.
Windows Authentication, Digest
Authentication, and Basic Authentication
are all challenge-based authentication
methods.
Summary
The NTFS permissions protecting a particular
file system element are not like the keys to a
lock, which provide either full access or no
access at all.
Permissions are designed to be granular,
enabling you to grant specific degrees of access
to security principals.
NTFS permissions are realized as access
control lists (ACLs), which consist of two basic
types of access control entries (ACEs): Allow
and Deny.
Summary
Permissions tend to run down through a
hierarchy, which is called permission
inheritance.
A digital certificate contains identifying
information about the party to which it is
issued, as well as a public key, which
enables the issuee to participate in
encrypted communications and prove its
identity.

Summary
If you want to use SSL on an Internet
Website, you must obtain a certificate for
your Web server from a commercial CA,
such as VeriSign, which is trusted both by
your organization and by your clients. For
intranet Web servers, you can use a
certificate from an internal CA.
To protect a Website using SSL, you must
have a server certificate and an https
binding. Then you must enable SSL for the
site.