In this Chapter
Microsoft has increasingly and quite seamlessly integrated the Internet, such as Web-based accessibility, into the core of Windows. Windows Server 2003 epitomizes this integration and offers a broad spectrum of features aimed at simplifying the way users access and publish information via a Web-like interface. Resources that were once inaccessible while either on the road or otherwise away from the office can now be accessed securely and reliably.
The wide adoption of Web-based functionality and accessibility to access file and print resources from anywhere, anytime has created some security challenges in the past for the Windows administrator. Ensuring that the underlying files and print resources aren’t compromised has been quite a daunting challenge. This was, in part, due to many features being installed with the Everyone group enabled and Anonymous access by default. However, Windows Server 2003 is now more secure by default than its predecessors. As a result, you can focus on providing valuable services for your users rather than worrying about locking everything down.
Web shares, or virtual directories, can be very useful in publishing corporate information to users both inside and outside the company’s network. By using the existing server or DFS (distributed file system) shares within the company, administrators and end users can publish content without the use of specialized Web editing tools.
Securing such shares requires you to pay special attention to both the underlying operating system and the method by which the end user is accessing the resources. Using both NTFS permissions and Web-based permissions to ensure the security of the Web shares is the best possible method because it provides a layered approach to securing the Web shares.
You should pay special attention to the root folder of each disk volume. By default Windows Server 2003 installs the Everyone group on the system volume. This is the volume where Windows Server 2003 is installed. By default this group has Read and Execute permissions on any new folders that are created on this volume. It’s a best practice to remove this group to avoid leaving the entire directory structure vulnerable to attack.
Companies should always use a firewall plan and an intrusion detection system (IDS) to create a way to monitor traffic to and from their Web servers. It is called a firewall plan because it’s not just a hardware or software product. A firewall plan involves multiple products and security planning, including what to do when there is a compromise in the company’s security. Compromises will happen; what you do to reduce exposure is an essential part of the plan.
Part of the firewall plan can be virtual private network (VPN) access and some form of Internet authentication services such as the one provided by RADIUS. Both of these services are available on the Windows Server 2003 platform. The VPN approach should be used when accessing any enterprise resources from outside the firewall perimeter. As is discussed later in this chapter, in “Establishing Virtual Directory Permissions,” authentication and document access can be provided by front-end Web servers that are placed between two firewalls in what is known as a demilitarized zone (DMZ).
There are numerous best practices for protecting Web servers facing the Internet. Here are just a few ways to reduce the impact of a security breach:
If you have the server resources, do not host the Internet Information Services (IIS) server on a domain controller or even a domain member if possible. The less participation the IIS server has with the domain the better (from a security standpoint).
Enable only the services that the server will be hosting. Inadvertently forgetting that a service is on or not yet configured is probably the biggest security risk on an IIS server.
Secure the NTFS permissions on the partition where the operating system is loaded. Remove nonessential groups and allow only administrators and designated groups access to the OS partition and its folders.
Move the Web and FTP root directories to a partition other than where the operating system resides. This ensures that if a traversal of directories takes place the attackers do not have access to operating system or IIS functions.
IIS authentication is the front line of defense in the access authorization process. When a user makes an HTTP request for a Web page several security-related steps take place. The sequence of events is as follows:
Is the request coming from an IP address, subnet, or domain name that has authorized access?
Is the user required to authenticate with a username and password or .NET Passport?
Do the IIS permissions allow the specific HTTP action the client is requesting?
If the virtual directory is located on another host, do the UNC share permissions allow access?
Finally, do the NTFS permissions allow the authenticated user or anonymous account access to the OS resource?
Following the order in which IIS allows access makes your troubleshooting efforts easier. By turning off or lessening levels of authentication you can determine which authentication method might be disallowing the delivery of the Web content to the end-user.
Narrowing the field of possible vulnerabilities is one of your best tools in protecting Web-based content. By allowing only trusted IP addresses or disallowing known abusers to access the Web content you can keep your eyes on efficiency. To enable or disable IP addresses, IP ranges, or domains perform the following steps:
Open IIS Manager, and click on the desired server.
Right-click on the Web site you want to protect, and choose Properties.
Click on the Directory Security tab, and select Edit in the IP Address and Domain Name Restrictions section.
Initially the By Default, All Computers Will Be Granted Access radio button is selected. You now have two possible options:
Choose the Granted Access radio button and then choose Add. This option enables you to Deny Access to individual IP addresses, Groups of computers (by subnet), or by Domain names.
Choose the Denied Access radio button and then choose Add. This option gives you the ability to Allow Access to known trusted IP addresses, Groups of computers (by subnet), or trusted Domains.
The method by which you choose to limit access will most likely depend on whether the Web site will be used solely on an intranet, in which you should allow access by domain name. If the Web site is going to be accessed via the Internet as well, you might have to grant access to domains as well as front-end Web servers and known IP addresses or subnets of users.
To publish content to the company’s intranet or to an SSL-secured Internet site, you need to create a Web site in IIS and then Virtual Directories under that Web root. These Virtual Directories can exist in the directory structure of the server that IIS is running on, or a UNC (Universal Naming Convention) path. These Virtual Directories can be created either from the IIS Management console or in the file system using Explorer.
IIS Administrator Needs to Allow Either Browse or Directory Browsing
To allow content to be viewed that doesn’t have an HTML formatted home page, the IIS administrator needs to allow either Browse or Directory Browsing. Otherwise an error page will appear instead of the desired folder contents.
To create a Virtual Directory in the Internet Information Services (IIS) Manager, perform the following steps:
Right-click on the Web site to which you want to publish.
Select New, Virtual Directory.
Fill in the Virtual Directory Alias box. (This should be an abbreviated version of the directory or UNC that will be published.) Click Next.
Fill in the Path box (this can either be a folder located on the IIS server or a UNC path to a share). Click Next.
If the Path box was filled in with a locally hosted folder the Virtual Directory Access Permissions page will be displayed. Choose the appropriate permissions and click Next.
If the Path box was filled in with a UNC path, the Security Credentials page will be displayed. Either fill in the desired username and password of an individual user or select the check box stating Always Use the Authenticated User’s Credentials When Validating Access to the Network Resource and click Next.
You have the option of creating a Web site Virtual Directory through the Windows Explorer. This is an easy way to publish content quickly that resides on the IIS server without opening up the IIS Manager tool. To create a Web share, perform the following steps:
On the IIS server navigate to the desired drive and right-click on a folder to share, and then select Properties.
Click on the Web Sharing tab and select the desired Web site from the pull-down menu.
Select the Share This Folder radio button shown in Figure 19.1. The Edit Alias dialog box appears.
Enter an abbreviated Alias for the Virtual Directory. Also select the appropriate Access Permissions and Application Permissions for this folder. Click OK twice.
When creating either a new Web site or a virtual directory under that site, you must decide who will have access, and of which type to the published content. A preferred method of protecting the content is by first choosing the access rights to the content.
IIS Virtual Directories that reside on the local server are secured by both the underlying NTFS permissions and the permissions granted through IIS. To set the permissions on a locally hosted Virtual Directory perform the following steps in IIS Manager:
Right-click on the virtual directory to secure, and then select Properties.
On the Virtual Directory tab find the section called Local Path.
In the Local Path section, select the desired boxes that are associated with access permissions:
Script Source Success. Used with IIS features such as FrontPage and WebDAV to allow access to executable content as long as Read or Write, or both are enabled.
Read. Allows the browser to read content published within the virtual directory folders. If this box is checked without any others being checked it creates a read-only scenario.
Write. This option is desirable when publishing folders where contributors might post content such as a document repository or through IIS tools programs like FrontPage and WebDAV.
Directory Browsing. You should enable this feature when no home page document is present in the root folder of the virtual directory. This feature is useful when publishing a set of folders and documents that might normally reside on a file server in a legacy Windows environment.
As described previously, virtual directories can point to UNC paths containing content hosted on other servers or workstations on the local area network. Shares can have their own permissions as well. It’s a best practice to leave the share permission to Everyone Full Access. This method makes it much easier to track the applied permissions on folders and files within the enterprise.
Placing permissions on the folders and down to the files, if desired, allows for more granular management and auditing of file access. NTFS permissions enable you to discretely allow or deny any group or user permissions down to the file level. Authentication either directly from the Web site or passed through to the host of the UNC share will determine the permissions allowed to that user.
IIS 6.0 now allows you to use pass-through Web authentication to UNC share and NTFS permissions. Simply put, the Web server sends the authentication request on to the server or workstation that is hosting the virtual directory UNC resource and asks permission for access. The steps to allow this process to take place are as follows:
Open IIS Manager, select the server and click on Web Sites, and then the Web site that is hosting the virtual directory.
Right-click on the virtual directory to secure and click Properties.
Click on the Connect As button located next to the Network Directory box containing the UNC path.
In the Network Directory Security Credentials dialog box you can choose either of the following:
Choose a static User Name and Password to authenticate against the remote UNC share and NTFS permissions.
Use delegation to pass the Web user’s username and password to the computer hosting the UNC share. To do this select the Always Use the Authenticated User’s Credentials When Validating Access to the Network Resource check box. When this box is checked the User Name and Password boxes become grayed-out.
Just as you set permissions on traditional file shares, you must also take this approach on directories and files exposed via IIS virtual directories. There are also several options related to Web content access as mentioned in the “Securing Virtual Directories Mapped to Local Directories” section earlier in this chapter.
As stated previously, there are several lines of defense—at the IIS level, at the share level, and at the file level. How you choose to secure their shared data depends quite a bit on their installed environment. Creating the IIS 6.0 virtual directories will definitely give you more tools and levels of authentication than ever before. To choose the proper authentication method you need to take the following steps:
Open IIS Manager, select the server, and double-click on Web Sites.
Right-click on the Web site that is hosting the virtual directory, and then choose Properties.
In the Web Site Properties dialog box, choose the Directory Security tab, and then choose Edit in the Authentication and Access Control section.
In the Authentication Methods dialog box you are presented with several choices, as shown in Figure 19.2. The options and their function are as follows:
Enable Anonymous Access, in which a default “IUSR_MachineName” User Name and Password are prefilled in. This option should only be used for nonsecure publishing of content, in which the user’s identity is less important for tracking access.
In the Authenticated Access section you have the following choices:
Integrated Windows Authentication—. This option is checked by default and is the easiest to use in a Windows domain environment. Internet Explorer works well with this authentication method.
Digest Authentication for Windows Domain Servers—. This method is best used to selectively grant access to users in select realms. This is much easier to do within strictly a Windows Server 2003 environment. In a mixed environment with both Windows 2000 and 2003 IIS sub-authentication must be installed and configured.
Basic Authentication (Password Is Sent in Clear Text)—. This method should only be used when the client’s credentials are being sent through SSL, VPN, or on an intranet that is secured. If you need to support browsers other than Internet Explorer they must use this method.
.NET Passport Authentication—. If you choose this method, all other authentication methods are unavailable. This method should only be chosen if your Web sites are enabled to work with .NET Passport authentication from the Microsoft servers.
You need to be constantly aware of risks associated with giving access to users outside the company. This is especially true with Web traffic that is traversing numerous unknown and possibly unsecure networks. Network packet analyzers are constantly looking for key words and phrases such as “username” or “password”. Using Secure Sockets Layer (SSL) encryption you can make sure that authentication of the Web folders on their IIS servers is not being passed in the clear.
SSL can be applied to an entire Web site, directories (including virtual directories), or just certain files within the site. You can specify which sections of the Web site are secured using SSL through the Internet Information Services (IIS) Manager. This Microsoft Management Console (MMC) snapin should also be used in conjunction with authentication methods and access control lists (ACLs) to ensure that access to those resources is as secure as possible.
SSL Requires an X.509 Digital Certificate
SSL requires an X.509 digital certificate that can be obtained either from a trusted certificate authority such as Verisign or from the company’s public key infrastructure (PKI).
To assign a certificate to a Web site it must first be requested and then installed. The request can either be created to obtain a certificate from an external Trusted Certificate Authority (CA), or when used internally from a standalone root CA or Enterprise CA within the organization’s PKI infrastructure. For example, to request and install a certificate from an internal Enterprise CA the following steps should be performed:
Open IIS Manager; expand the desired computer, Web sites, and the desired Web site to assign the certificate.
Right-click on the Web site and select Properties.
On the Directory Security tab, select Server Certificate located in the secure communications section.
The Web Server Certificate Wizard will open; click Next.
Choose the Create a New Certificate button and click Next.
Select the Prepare Request Now, But Send It Later button and click Next.
Type a “friendly” name in the dialog box and choose the desired Bit Length for the encryption key then click Next.
Type the company’s legal name in the Organization box and the responsible department for either this site or the company’s security department in the Organization Unit box, and then click Next.
Type the name of the computer hosting the Web site in the Common Name box. If the site will be accessed from the Internet be sure to fill in the fully qualified domain name, such as server.domain.com. Click Next.
Select a Country or Region from the first pull-down menu and type in the State/ Province and City/Locality that will be embedded in the certificate; click Next.
Enter an easily remembered filename, including path, or browse for a desired location and enter the filename in that path. (This file is important and will be used in subsequent steps. Note its name and location.) Click Next.
The next screen is called the Request File Summary. If there are any errors, select the Back button and navigate to the page where the data was entered and correct it now. If everything looks correct click Next and then Finish.
The name on the security certificate is invalid or does not match the name of the site
The Common Name in step 9 is the name that the certificate is published with and is checked against for validity. If this name does not match the URL exactly the user will receive an error stating The name on the security certificate is invalid or does not match the name of the site.
After the certificate is requested it can be sent to an external trusted certificate authority. This is usually the case when the SSL secured content is going to be viewed by customers. If the SSL secured pages are going to be viewed internally or by users who can be instructed on how to install an internally generated certificate, the less costly option is to generate the certificate with the internal PKI services. To process the certificate request internally follow these steps:
Enter the URL of the company’s IIS server that is hosting Certificate Services (for example,
http://servername/certsrv).If a sign-in dialog box appears, enter a username and password with sufficient privileges to generate the certificate and click OK.
On the initial Welcome page select Request a Certificate.
On the Request a Certificate page select Submit an Advanced Certificate Request.
On the Advanced Certificate Request page select Submit a Certificate Request By Using a Base 64-encoded CMC or PKCS #10 File, or Submit a Renewal Request By Using a Base-64-encoded PKCS #7 File.
On the Submit a Certificate Request or Renewal Request page, click on Browse for a File to Insert link, click on the Browse button and find the certificate request text file created in the previous section.
When the filename appears in the Full Path Name box click on the Read button. The Saved Request box will now be populated with the text that was contained in the certificate request.
Under the Certificate Template section use the pull down to select the Web Server selection and then click the Submit button.
On the Certificate Issued page, select the Download Certificate link. When prompted select Save and Select a Folder and Desired Filename to save the certificate. When the download is complete click Close and then close the browser window.
Open IIS Manager and navigate to the Web site for which the certificate was created.
Right-click on the Web site and select Properties.
Click on the Directory Security tab and select the Server Certificate button.
Click Next on the initial Server Certificate Wizard page.
Select Process the Pending Request and Install the Certificate, and then click Next.
Browse for the certificate file that was created in the previous steps and select it (this will be a filename ending in .cer). Click Next.
On the SSL Port page enter the desired SSL listening port for this Web site (443 is default). Click Next.
On the Certificate Summary page the information from the certificate response file is displayed. Ensure that the correct filename and corresponding information is displayed. If it’s not, click on the Back button and choose the correct file. If the information is correct click Next, and then Finish.
After the certificate is installed on the site all three buttons under the Secure Communications section of the Directory Security tab become available for selection.
Internet Printing Protocol (IPP) is defined in the Internet engineering task force (IETF) request for comment (RFC) 2910. IPP is a useful tool that can simplify the publishing and management of printers within an enterprise. You can use this tool to expose printer shares to both their intranet Remote Procedure Call (RPC) and Internet (HTTP) users.
RPC offers more features and is the preferred method of connecting to printers in an intranet environment. If the user’s Internet Explorer security is set Medium to High he will connect via HTTP. For the user to acquire a True-connect like a UNC share over RPC, his Internet Explorer security settings must be set to medium-low. Microsoft is focusing on more features on the RPC capabilities over the HTTP IPP feature set.
Standard Windows Server 2003 print server shares can be exposed via IPP through the use of a simple URL such as http://<servername>/printers. This enables users to connect and automatically configure printers and administrators to view and manage print queues from a single Web page per IPP-enabled print server.
On a Windows Server 2003 with IIS 6.0, Internet Printing and Active Server Pages (required for Web-based printer management) are not installed by default. To install these required services you must perform the following steps:
Go to Control Panel, choose Add/Remove Programs, and then Add Remove Windows Components.
Open Application Server, Internet Information Services (IIS) and then select Internet Printing, as shown in Figure 19.3.
Finally, go to World Wide Web Service, select Active Server Pages, and then select OK.
With HTTP, the print server generates a .cab file that contains the required .inf and installation files and sends the .cab file to the client. On the client computer, the .cab file starts the Add Printer Wizard to complete the installation. A progress bar is displayed in the browser while the printer drivers are being installed.
You must pay special attention to printers that you’ve shared to intranet and Internet users. Removing the Everyone group and allowing only authenticated domain users or defined security groups print access is a best practice. The security on the printer is set at the share level as follows:
Click on Start and then click Printers and Faxes.
Right-click on the desired printer and select Sharing.
On the Security tab, select the Everyone group and click the Remove button.
To select groups with Print, Manage Printers, Manage Documents, or Special Permissions access, click on the Add button and choose the appropriate Active Directory security groups. Then select the Desired Level of Access check box under the Allow column.
File Transfer Protocol (FTP) has been used effectively for many years on the Internet. This protocol is very efficient at serving up static documents for download or for anonymously posting material to a folder. With the ease of use comes widespread abuse. Many FTP sites are set up carelessly and left wide open for illegal trading of copyrighted files and hijacked storage space for hackers.
You should know what your FTP sites are going to used for in advance of implementation. Simple downloads can be accomplished safely by imposing a few basic rules. Creating a useful posting space for company employees, clients, or partners can be done quite easily, with some planning and the appropriate settings.
On Windows Server 2003 and IIS 6.0 the FTP server service is not installed by default. This is due to IIS being locked down by default. Too many IIS servers were installed with FTP services left with the default TO allow Anonymous users read and write access. This is part of the overall plan of leave the service off unless it’s going to be used.
To install FTP services you must perform the following steps:
Go to the Control Panel and choose Add/Remove Programs. Then choose Add/Remove Windows Components.
Next open the Application Server and then Internet Information Services (IIS).
Finally, choose File Transfer Protocol (FTP) Service, as shown in Figure 19.4, and then select OK.
In many scenarios documents and drivers are shared with the public from files stored on an FTP server. This can be done safely by locking down the folders with NTFS permissions on the published folder. In the case of public access like this, there should be a minimal number of entries in the permissions on those folders. The Anonymous alias should have read-only access and the group responsible for posting content should have read/write access.
FTP logging can be used to track access of the FTP site and for troubleshooting logon issues as well as other valuable statistics.
Choose W3C Extended Log File Format. This format has the most comprehensive list of available logging options.
Move the log file directory to the root of your IIS FTP server folder as a best practice. This will make it easier to find that log file if multiple sites are configured.
When Anonymous is disabled, the permissions on the root folder that the FTP user is accessing grants or denies what that user can do. You should take special care in removing unnecessary users from that folder and propagating permissions to the subfolders.
Blind-put access describes a method of hosting an FTP site where the user has only write access. Read access is left off at both the Home Directory and the folder being accessed.
Administrators of IIS FTP servers should take advantage of the operating system storage features. Disk quotas have been available for some time now. One of the best applications of this functionality is to prevent users from filling up hard disk space. In the case of FTP, creating quotas on users of this service minimizes the danger of someone hijacking an account and using the FTP server as a storage point for illegally copied movies, MP3 files, and so on.
When used in conjunction with FTP services logon time restrictions can help reduce the exposure of the server during nonworking hours when no one is around to monitor the server.
One of the first items IIS checks is the permitted or excluded IP address range of the client requesting data. Protecting FTP from unwanted attack can be narrowed down that much more by limiting the range of allowed IP addresses.
By monitoring the FTP logging constantly, you can see problems with failed logon attempts and other malicious behavior. By using tools such as Web Trends to analyze user traffic and folder usage, you can block IP addresses or domains that are constantly attempting to logon. You can also use the logging to see when valid users are having trouble opening their home directories or being locked out due to authentication problems.
Enforcing the use of strong passwords is one of the keys to securing FTP services. Windows Server 2003 allows you to enforce user’s compliance with strong password requirements by enabling the Passwords Must Meet Complexity Requirements Policy. This option is located in the Local Security Policy (standalone server), or Group Policy (Domain member).
FTP server accounts are very popular targets for password cracking programs that often use an exhaustive list of passwords in an attempt to guess the correct password. You can greatly reduce the success of such an attack by enabling the Password Policy settings in either the Local Security Policy or Group Policy. When an attacker tries repeatedly to log in with a valid username and bad password the account should be set to lock.
With local drive mapping now available Windows Server 2003 Terminal Services is a great way to work with computers remotely. Remote Desktop allows access to documents and corporate applications that might not be available on the local machine.
By default Remote Desktop is disabled on Windows XP and Windows Server 2003. You need to perform the following to enable Remote Desktop control:
Terminal Services is one of the more popular remote control programs for Windows. It also has a pretty well-known port (3389) and therefore is well port scanned. It is a good practice to change this port to avoid unwanted Remote Desktop connections.
To change the port number that Terminal Services listens on, perform the following:
Run Regedt32.exe and navigate to the following key:
LOCAL_MACHINESystemCurrentControlSetControlTerminal ServerWinStations RDP-Tcp
In the Details pane find the PortNumber subkey and double-click on it.
In the Base section of the window choose the Decimal radio button. The number now in the Value Data box, by default, will be 3389. Change this to any high port number that is not being used in the company for another service. Before closing the window change the Base value back to Hexadecimal, and then click OK.
For the listening port number to take effect, Terminal Services must be restarted. At the command prompt type net stop termservice and then net start termservice.
One of the most important factors in server security is awareness. Logging and auditing allow you to monitor suspicious activity as well as establish a normal baseline of user interaction with server resources.
The standard Windows Server 2003 installation doesn’t have auditing turned on by default. One reason for this is that on a busy server over-auditing can fill up event logs and drag down system resources. You need to be selective in what you choose to audit.
IIS 6.0 does have logging turned on, but it might not be a suitable configuration for all cases. The default directory for log files is %winddowsroot%system32LogFiles. You might want to place your log files under a directory that better identifies the logs. Also, as mentioned earlier in this chapter, it’s better to create the IIS data folders on a partition other than where the operating system resides.
You should enable both successful and failed login attempts to the IIS server that is hosting the Web sites and FTP services. This can be both a good troubleshooting tool, when the sites are first established, and a security measure over time. You should watch your Security event logs for repeated failed logon attempts. This could point out an attack or simply a user who forgot his password and needs it to be reset.
On the Web server security auditing needs to be enabled and configured. There are two possible scenarios for enabling auditing. The first is on a standalone server that is not a member of the domain. The second is a member-server.
To enable or modify auditing policy settings on a standalone Web server follow these steps:
Click on Start, Administrative Tools and then choose Local Security Policy.
In the console tree, click Local Policies and then click Audit Policy.
In the Details pane, double-click on the desired event category.
On the Properties page for that event category select both Success and Failure and then click OK.
To enable or modify the auditing policy settings for an event category on a server that is a domain member perform the following steps:
Click on Start, Administrative Tools and then Active Directory Users and Computers.
Right-click on the desired domain, site, or organizational unit (OU) and click Properties.
On the Group Policy tab, select or create a Group Policy object to edit.
In the Group Policy Object Editor console tree expand Computer Configuration, Windows Settings, Security Settings, Local Policy, and then click Audit.
In the Details pane, double-click on the desired event category.
If the auditing policy has not been set for this event select Define These Policy Settings check box.,
Enable auditing by clicking either Success or Failure or both and then click OK.
Web server administrators need to be especially aware of content changes on their Web sites. Due to the fact that most Web sites, either intranet or Internet facing, contain mostly static pages or templates, content changes are usually planned events by specific users. Tracking any change attempts by un-authorized users is a good way to reduce attacks such as de-facing of the site where content is replaced by a hacker’s slogan or undesired content.
Auditing of file or folder objects is defined on their perspective Property pages. Before auditing becomes active it must be enabled by the administrator or a designee that has Manage auditing and security log rights.
To enable object access auditing on a standalone server follow these steps:
Click on Start, Administrative Tools, and then click Local Security Policy.
Expand Local Policies and then click Audit Policy.
Right-click on Audit Object Access and select Properties.
Enable auditing by clicking either Success or Failure or both and then click OK.
To enable object access auditing on a domain member server perform the following steps:
Click on Start, Administrative Tools, and then Active Directory Users and Computers.
Right-click on the desired domain, site, or organizational unit (OU) and click Properties.
On the Group Policy tab, select or create a Group Policy object to edit.
In the Group Policy Object Editor console tree expand Windows Settings, Security Settings, Local Policy, and then Audit Policy.
Double-click on Audit Object Access.
Ensure that the Define These Policy Settings check box has been selected.
Enable auditing by clicking either Success or Failure or both, and then click OK.
Now that the object access policy has been enabled you can define the auditing policy settings for folders or files contained in the Web site. To apply or modify auditing policy settings perform the following steps:
Navigate in Windows Explorer to the desired folder within the Web site.
Right-click on the folder or file that you want to audit and then select Properties.
Select the Security tab.
Click on the Advanced button and then select the Auditing tab.
At this point you can either Add, Remove, or Edit Users or Groups that are being audited.
In the Apply Onto box, indicate what actions are to be audited.
In the Access box, indicate which actions are to be audited.
To stop auditing on this container, click Clear All.
If you want to audit subfolders as well as the current folder, ensure that the Apply These Auditing Entries to Objects and/or Containers Within This Container Only check box is cleared.
Administrators who have to maintain numerous Web and FTP sites will find that writing the log files of each site to a central location becomes more convenient. One way to accomplish this is by enabling centralized binary logging. The steps to accomplish this are as follows:
At a command window, change to the following directory: c:inetpubAdminScripts.
Type cscript.exe adsutil.vbs SET W3SVC/CentralBinaryLoggingEnabled true.
Press Enter. You will see the Windows Script Host version number and Microsoft copyright information followed by CentralBinaryLoggingEnabled: <BOOLEAN> True.
Stop the Web services by typing net stop W3SVC and then press Enter.
Start the Web services by typing net start W3SVC and then press Enter.
For detailed output of this procedure see Figure 19.5.
This procedure will create a new file in the C:windowssystem32logfilesw3svc directory with the name format of rawyymmddhh.ibl. The .ibl extension stands for Internet binary log. This extension change ensures that text editors, by default, do not attempt to open these files.
You can use the Log Parsing Tool 2.1 that ships with the IIS 6.0 Resource Kit, or downloadable from Microsoft’s Web site, to run queries against the .ibl files. The Microsoft script center Web site at http://www.microsoft.com/technet/scriptcenter/ has examples of how to use the Logfile Parsing Tool.
As mentioned previously the W3C Extended Logging offers the most comprehensive list of events occurring on the IIS 6.0 Web and FTP servers. Tables 19.1 and 19.2 contain the field name definitions and descriptions of the log file content.
Table 19.2. W3C Extended Logging Field Definitions
You can use a variety of tools to manage your IIS 6.0 Web sites and permissions. Microsoft has provided many new tools for use at the command line and through scripting.
You can use IIS Manager to create, edit, or delete sites and properties. You can also use VBScript to perform those same tasks. If the task needs to be repeated several times, scripts are usually more efficient tools. If you want to see the status of the network or items such as disk space, the command line instruction might be faster.
For simple one-time management requirements the IIS Manager MMC console works fine. If you need to set up a new FTP site quickly, creating or editing a script might take too long. A simple rule to follow is: if you have to do it more than twice automate it.
You often use the Windows command console to quickly find out status of a machine or the network. Examples of this are using ping to check the status of a network resource or running ipconfig to see what the IP addresses are associated with the network interfaces on the local machine.
Taking this logical approach one step further is the Windows Management Command Line (WMIC). This tool makes it easier for you to access WMI for quick tasks.
To see items such as which servers are bound to which TCP port number on the current server, they might run a command line request such as the adsutil.vbs example shown in Figure 19.6.
In the past you could use WMI to passively monitor your network and servers. In the latest version of WMI you can also make changes to parameters of those networks and servers. There are two ways to use WMI to manage IIS. The first is via the Windows Scripting Host (WScript.exe) and the second with through the console, or command line with CScript.exe.
Windows Server 2003 has more than 6,000 managed resource properties that can monitored by WMI. Of these resources, more than 140 can be configured by WMI.
IIS 6.0 places some sample scripts in the WindowsSystem32 directory. These scripts are written in the Microsoft Visual Basic scripting language and use the IIS 6.0 WMI provider to access configuration information within the IIS metabase. The included scripts are as follows:
IISapp.vbs—. List process IDs and application pool IDs for currently running worker processes.
IISftp.vbs—. Create, delete, start, stop, and list FTP sites.
IISftpdr.vbs—. Create, delete, or display virtual directories under a given root.
IISconfg.vbs—. Export and import IIS 6.0 configuration to an XML file.
IISweb.vbs—. Create, delete, start, stop, and list Web sites.
IISvdir.vbs—. Create and delete virtual directories, or display the virtual directories of a given root.
Console-based Scripts Run with the CScript Engine
Console-based scripts run with the CScript engine. To force the WScript.Echo lines to display in the Command Prompt window call your script preceding it with CScript //nologo.
One of the important duties of an IIS administrator is making sure that the drives don’t fill up and crash the server. The following is a sample script to monitor hard disk utilization:
Const LOCAL_HARD_DISK = 3
strComputer = "servername"
Set objWMIService = GetObject("winmgmts:"_
& "{impersonationLevel=impersonate}!\" & strComputer & "
ootcimv2")
Set colMonitoredDisks = objWMIService.ExecNotificationQuery _
("Select * from __instancemodificationevent within 30 where " _
& "TargetInstance isa 'Win32_LogicalDisk'")
i = 0
Do While i = 0
Set objDiskChange = colMonitoredDisks.NextEvent
If objDiskChange.TargetInstance.DriveType = LOCAL_HARD_DISK Then
If objDiskChange.TargetInstance.Size < 10000000000 Then
Wscript.Echo "Hard disk space is below 10000000000 bytes."
End If
End If
Loop
If the hard disk on the local machine drops below 10GB free then a dialog box pops up on the screen and says Hard disk space is below 10000000000 bytes. This is just a simple example using Windows Scripting and WMI to monitor computers on the network.
Obviously an IIS administrator wouldn’t be standing at the console of the IIS server waiting to see if the hard disk space is running out. A more realistic scenario would be to have the preceding script monitoring the group of computers running IIS and FTP send an e-mail if the drive space dropped below a certain number of bytes free.
You need to know pertinent information when monitoring the health of your servers. Poring over hundreds or thousands of entries to find meaningful errors can be tedious. The following is a sample script to query the System event log on the local machine for stop errors that have the string SaveDump in them:
strComputer = "servername"
Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\" & strComputer & "
ootcimv2")
Set colLoggedEvents = objWMIService.ExecQuery _
("Select * from Win32_NTLogEvent Where Logfile = 'System'" _
& " and SourceName = 'SaveDump'")
For Each objEvent in colLoggedEvents
Wscript.Echo "Event date: " & objEvent.TimeGenerated
Wscript.Echo "Description: " & objEvent.Message
Next
This script is an example of how you might parse through very large log files and only extract the data that helps them troubleshoot hard errors on their servers.
Creating alternative ways to access data stored in a Windows environment with tools such as Web folders, Internet Printing Protocol, and FTP services allows you great flexibility over where the data is stored and how it is accessed. By using some of the examples outlined in this chapter you will be able to give easier visibility and possibly more secure access to your company’s data.