In previous topic discussed the issues related to sharing a folder so that users, with the Client For Microsoft Networks, can access resources on a server running the File And Print Sharing For Microsoft Networks service. That is, however, only one means by which users can access the files and folders they require. It is also possible to enable access through Internet technologies such as FTP and Web (HTTP) services.
In this topic, you will learn how to configure and manage IIS. You will discover how to configure Web and FTP sites, virtual directories, and IIS security.
Installing IIS 6.0
To decrease the attack surface of a Windows Server 2003 system, IIS is not installed by default. It must be added using the Add/Remove Windows Components Wizard from Add Or Remove Programs, located in Control Panel. Select Application Server, click Details, and then select Internet Information Services (IIS). You can control the sub-components of IIS that are installed, but unless you are very familiar with the role of subcomponents, do not remove any default components. You may, however, want to add components, such as ASP.NET, FTP or FrontPage Server Extensions.
Administering the Web Environment
When IIS is installed, a default Web site is created, allowing you to implement a Web environment quickly and easily. However, you can modify that Web environment to meet your needs. Windows Server 2003 provides the tools necessary to administer IIS and its sites.
After installation has completed, you may open the Internet Information Services (IIS) Manager console from the Administrative Tools group. By default, IIS is configured to serve only static content. To enable dynamic content, select the Web Service Extensions node. As shown in Below Figure, all the extensions are prohibited. Select the appropriate extension and click Allow.
The fundamental processes that take place as a client accesses a resource from IIS are
The client enters a URL (Universal Resource Locator) in either of the following forms:
http://dns.domain.name/virtualdirectory/page.htm or ftp://dns.domain.name/virtualdirectory
Domain Name Service (DNS) resolves the name to an IP address and returns the address to the client
The client connects to the server’s IP address, using a port that is specific to the service (typically, port 80 for HTTP and port 21 for FTP)
The URL does not represent the physical path to the resource on the server, but a virtualization of the path. The server translates the incoming request into the physical path and produces appropriate resources to the client. For example, the server might list files in the folder to an FTP client, or might deliver the home page to an HTTP client.
The process can be secured with authentication (credentials, including a user name and password) and authorization (access control through permissions).
You can see this process in action by opening a browser and typing http://Syscare (server name). The server produces the Under Construction page to the client browser.
Configuring and Managing Web and FTP Sites
IIS installation configures a single Web site, the Default Web Site. Although IIS, depending on your server’s hardware configuration, can host thousands, or tens of thousands of sites, the Default Web Site is a fine place to explore the functionality and administration of Web sites on IIS. This Web site is accessible if you open a browser and type the URL: http://syscare.mcseweb.in. The page that is fetched is the Under Construction page.
Remember that a browser’s request to a Web server is directed at the server’s IP address, which was resolved from the URL by DNS. The request includes the URL, and the URL often includes only the site name (www.microsoft.com, for example). How does the server produce the home page? If you examine the Web Site tab of the Default Web Site Properties, as shown in below Figure, you see that the site is assigned to All Unassigned IP addresses on port 80. So the request from the browser hits port 80 on the server, which then identifies that it is the Default Web Site that should be served.
The next question, then, is what information should be served. If the URL includes only the site name (for example, www.microsoft.com or syscare.mcseweb.in), then the page that will be returned is fetched from the home directory. The Home Directory tab, as shown in Below Figure, displays the physical path to the home directory, typically c:\inetpub\wwwroot.
Which file, exactly, should be returned to the client? That is defined on the Documents tab, as shown in Below Figure. IIS searches for files in the order listed. As soon as it finds a file of that name in the local path of the home directory, that page is returned to the client and the server stops looking for other matches. If no match is found, the IIS returns an error (404–File Not Found) to the client indicating that the page could not be found.
A browser could, of course, refer to a specific page in the URL, for example http:// syscare.mcseweb.in/contactinfo.htm. In that event, the specific page is fetched from the home directory. If it is not found, a File Not Found error (404) is returned.
To create a Web site, right-click the Web Sites node or an existing Web site in IIS Manager and choose New Web Site. To configure a Web site, open its Properties. You can configure the IP address of the site. If a server has multiple IP addresses, each IP address can represent a separate Web site. Multiple sites can also be hosted using different ports for each site, or using host headers. The specifics of these options are beyond the scope of this book. You can also configure the path to the directory that is used as the home directory. And you can modify the list or order of documents that can be fetched as the default content page.
A URL can also include more complex path information, such as http:// www.microsoft.com/windowsserver2003. This URL is not requesting a specific page; there is no extension such as .htm or .asp on the end of the URL. Instead, it is requesting information from the windowsserver2003 directory. The server evaluates this additional component of the URL as a virtual directory. The folder that contains the files referred to as windowsserver2003 can reside anywhere; they do not have to be located on the IIS server.
To create a virtual directory, right-click a Web site and choose New Virtual Directory. The wizard will prompt you for the alias, which becomes the folder name used in the URL, and the physical path to the resource, which can be on a local volume or remote server.
FTP sites work, and are administered, similarly to Web sites. IIS installs one FTP site, the Default FTP Site, and configures it to respond to all incoming FTP requests (all unassigned addresses, port 21). The FTP site returns to the client a list of files from the folder specified in the Home Directory tab. FTP sites may also include virtual directories so that, for example, ftp:// syscare.mcseweb.in/pub may return resources from a different server than ftp:// syscare.mcseweb.in/vendor-uploads. FTP URLs and sites do not use default documents.
Complex IIS servers may host tens of thousands of sites, each with customized settings to make them tick. Losing all that configuration information could be painful, so although a normal file system backup might allow you to restore the data files after a failure, the configuration would be lost. To back up or restore IIS configuration, you must back up or restore the metabase, an Extensible Markup Language (XML) document that is used to store settings. Right-click the server node in IIS Manager and, from the All Tasks menu, choose Backup/Restore Configuration.
Securing Files on IIS
Security for files accessed by way of IIS falls into several categories: authentication, authorization through NTFS permissions, and IIS permissions. Authentication is, of course, the process of evaluating credentials in the form of a user name and password. By default, all requests to IIS are serviced by impersonating the user with the IUSR_computername account. Before you begin restricting access of resources to specific users, you must create domain or local user accounts and require something more than this default, Anonymous authentication.
Configuring Authentication Methods
You may configure the following authentication methods on the Directory Security tab of the server, a Web (or FTP) site, a virtual directory, or a file:
Web Authentication Options
Anonymous authentication Users may access the public areas of your Web site without a user name or password.
Basic authentication Requires that a user have a local or domain user account. Credentials are transmitted in clear text.
Digest authentication Offers the same functionality as Basic authentication, while providing enhanced security in the way that a user’s credentials are sent across the network. Digest authentication relies on the HTTP 1.1 protocol.
Advanced Digest authentication Works only when the user account is part of an Active Directory. Collects user credentials and stores them on the domain controller. Advanced Digest authentication requires the user to be using Internet Explorer 5 or above and the HTTP 1.1 protocol.
Integrated Windows authentication Collects information through a secure form of authentication (sometimes referred to as Windows NT Challenge/ Response authentication) where the user name and password are hashed before being sent across the network.
Certificate authentication Adds Secure Sockets Layer (SSL) security through client or server certificates, or both. This option is available only if you have Certificate Services installed and configured.
.NET Passport authentication Provides a single sign-in service through SSL, HTTP redirects, cookies, Microsoft JScript, and strong symmetric key encryption.
FTP Authentication Options
Anonymous FTP authentication Gives users access to the public areas of your FTP site without prompting them for a user name or password.
Basic FTP authentication Requires users to log on with a user name and pass-word corresponding to a valid Windows user account.
Defining Resource Access with Permissions
Once authentication has been configured, permissions are assigned to files and folders. A common way to define resource access with IIS is through NTFS permissions. NTFS permissions, because they are attached to a file or folder, act to define access to that resource regardless of how the resource is accessed.
IIS also defines permissions on sites and virtual directories. Although NTFS permissions define a specific level of access to existing Windows user and group accounts, the directory security permissions configured for a site or virtual directory apply to all users and groups.
Below Table details Web permission levels:
Read (default): Users can view file content and properties.
Write: Users can change file content and properties.
Script Source Access: Users can access the source code for files, such as the scripts in an Active Server Pages (ASP) application. This option is available only if either Read or Write permissions are assigned. Users can access source files. If Read permission is assigned, source code can be read. If Write permission is assigned, source code can be written to as well. Be aware that allowing users to have read and write access to source code can compromise the security of you server.
Directory browsing: Users can view file lists and collections.
The Execute permissions control the security level of script execution and are as described in Below Table .
None: Set permissions for an application to None to prevent any programs or scripts from running.
Scripts only: Set permissions for an application to Scripts only to enable applications mapped to a script engine to run in this directory without having permissions set for executables. Setting permissions to Scripts only is more secure than setting them to Scripts and Executables because you can limit the applications that can be run in the directory.
Scripts and Executables: Set permissions for an application to Scripts and Executables to allow any application to run in this directory, including applications mapped to script engines and Windows binaries (.dll and .exe files).
Friday, February 19, 2010
Administering Internet Information Services
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment