Default Web Site

Configuring Web Application Services

Tony Piltzecker , Brien Posey , in The Best Damn Windows Server 2008 Book Period (Second Edition), 2008

<configuration>

…

<system.applicationHost>

…

<sites>

…

<site name="Default Web Site" id="1">

<application path="/">

<virtualDirectory path="/" physicalPath="%SystemDrive%\inetpub\wwwroot" />

</application>

<bindings>

<binding protocol=" http " bindingInformation="*:80:" />

</bindings>

</site>

…

</sites>

…

</system.applicationHost>

…

</configuration>

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597492737000112

Clients

Tony Redmond , in Microsoft Exchange Server 2007 with SP1, 2008

7.7.7 Authentication

By default, Outlook Web Access uses forms-based authentication to present users with the ability to provide credentials necessary to log on and connect to a mailbox (Figure 7-46). The logon screen allows users to select whether the computer they are using is a public or shared computer (such as one in an Internet café) or a private computer (like the one you use at work). They can also select whether they wish to use the light version of Outlook Web Access. These options are stored in a hidden item in the root of the user's mailbox. As we will see later on, the choice of private or public computer also influences some of the options to control a user's environment, such as their ability to download attachments. It also affects the time-out for the client, which kicks in between 15 and 23 minutes for public computers (to ensure that even if a user leaves the PC without logging off, there is a manageable risk that someone might compromise the data). By comparison, private computers have a time-out period of over eight hours.

Figure 7-46. Outlook Web Access logon screen

Time-outs work through session cookies. The Client Access server sends an encrypted cookie together with the username and password back to the client. The server continues to generate encryption keys and keeps the last three in memory. Clients send the encryption key along with their requests to the server. If the encryption key is still in memory, the server responds by sending a new encryption key back to the client. However, if the encryption key has expired and the server has discarded it, the server times the session out and the client must reauthenticate. The time-out value for a cookie is specific to a Client Access server. See http://technet.microsoft.com/en-us/library/bb124787.aspx for information about how to set the time-out value (ranging from 1 minute to 30 days) for the cookie used by forms-based authentication.

You can control how Outlook Web Access handles client authentication by amending the properties of the "owa (Default Web Site)" object. Go to the Client Access node of Server Configuration, click on the Client Access server that you want to work with, and then select the web site and click on "Properties." This reveals a set of property pages that allow you to change the way that Outlook Web Access deals with clients. We will begin by changing the way that users authenticate themselves when they log on to Outlook Web Access. The options available are shown in Figure 7-47. You can select from three different logon formats for forms-based authentication:

Figure 7-47. OWA Authentication Options
▪

Standard Windows Domain and username: For example, XYZ\Redmond

▪

User Principal Name: For example: [email protected]

▪

User Name only: For example: Redmond

If you do not want users to see the standard Outlook Web Access logon screen, you can opt to use one, two, or three other standard authentication methods.

▪

Basic authentication uses a HTTP mechanism to encode the user name and password before Outlook Web Access sends the credentials to the Client Access server to be validated. This mechanism supports the widest range of connections to Exchange via Outlook Web Access, including browsers that run on non-Windows platform. Ideally, you should use the basic authentication mechanism with SSL so that the communications between the browser and the Client Access server is protected.

▪

Integrated Windows authentication, which means that the browser can use any cached credentials that exist on the client PC. This mechanism works very smoothly to achieve a fast logon if the client PC is part of the same domain as Exchange or is in a trusted domain.

▪

Digest authentication provides an extra level of protection by transmitting passwords over the network as hashed values.

Exchange holds all of these settings in properties that you can manipulate with the shell. To see their values, use the Get-OwaVirtualDirectory command. For example, the values shown in Figure 7-47 as viewed through the shell are:

You can see that forms-based authentication (fba) is in use for both internal and external authentication and that the logon format is user principal name.

If multiple mechanisms are available, the client PC selects the most appropriate to use and will present the user with a standard credentials gathering dialog if it cannot find suitable credentials to use. You have to restart the IIS service to make the change effective if you enable or disable forms-based authentication. You can do this with the following shell command:

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781555583552500106

Managing the Client Access Server

Henrik Walther , in How to Cheat at Configuring Exchange Server 2007, 2007

Client Access Servers and the SSL Certificate Dilemma

In previous versions of Exchange, you simply issued a request for an SSL certificate, and when received, assigned this certificate to the Default Web Site in the IIS Manager. But in Exchange 2007, it is a different beast when it comes to securing client connectivity to the CAS using SSL certificates.

A default self-signed SSL certificate is assigned to the Default Web Site during the installation of the Exchange 2007 CAS role. If you take a closer look at this certificate, you'll notice that it contains multiple subject alternative names.

An SSL certificate that supports additional subject alternative names typically costs in the range of $600 per year.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597491372500083

Get Started with IIS 7.0's Configuration

Chris Adams , ... Gene Whitley , in How to Cheat at IIS 7 Server Administration, 2007

Unlocking Configuration Sections

As the system administrator you can unlock configuration sections for numerous situations. Here we will go through step by step where we need to add an application to our existing Default Web Site in IIS 7.0, and by unlocking configuration sections for delegation, we will be able to control certain settings via a web.config file. Before you start, do the following:

1.

Back up the ApplicationHost.config file sitting in the %windir%\system32\inetsrv\config directory.

2.

Create a directory to hold our web.config file that we will create later. In this example we are storing it in the C:\Test directory.

NOTE

For the purposes of this exercise we disabled directoryBrowse in our ApplicationHost.config file.

Now we will demonstrate how to unlock configuration sections in IIS 7.0.

1.

First, you will add an application called app to your Default Web Site. To do this pull up IIS Manager; do not use the IIS 6.0 Manager. Open the site and highlight Default Web Site, as shown in Figure 4.12.

Figure 4.12. Default Web Site in IIS Manager
2.

Right click Default Web Site and choose Add Application.

3.

In the Add Application dialog box, enter the information as shown in Figure 4.13, then click OK.

Figure 4.13. Add Application Information
4.

You should now see your application listed below Default Web Site in IIS Manager (see Figure 4.14).

Figure 4.14. Application app in IIS Manager
5.

Now click on the server's name in the far left pane. In our example the server's name is ALDERON.

6.

In the middle pane of IIS Manager, scroll down to the IIS Group and double-click Directory Browsing. After doing so you should see a screen similar to the one shown in Figure 4.15.

Figure 4.15. Authentication Section Group
7.

On the right side under Actions, select Enable. This will now allow directory browsing to be available to site administrators and application developers.

8.

Open a text editor or Visual Studio and create a web.config file similar to the one in Figure 4.16. Save it in the C:\Test directory. Notice that in the web.config file has directoryBrowse enabled.

Figure 4.16. New Location Tag in ApplicationHost.config
9.

Now open Internet Explorer to the following URL: http://localhost/app.

10.

You should now see the C:\Test directory with your web.config file in it (see Figure 4.17).

Figure 4.17. Results of Unlocking Configuration Sections
11.

To disable it in your web.config change <directoryBrowse enabled="false"/>, as you did in Figure 4.18.

Figure 4.18. Disabling Directory Browsing in Web.config
12.

After disabling <directoryBrowse> refresh Internet Explorer, and you should see a screen similar to the one shown in Figure 4.19.

Figure 4.19. Testing Directory Browsing Disabled

So why is delegation so important in IIS 7.0? First, IIS 7.0 configurations may now exist side by side with ASP.NET configurations. This means that Web server and application configurations can be deployed along with content. Another reason that del egation is so important is that security is not compromised. Administrators can pick and choose the features they make available for modification without having to provide system administrator rights to developers or lower level administrators; thus, everyone is more productive and efficient.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597491556500082

Troubleshooting 101: Diagnostics in IIS 7.0

Chris Adams , ... Gene Whitley , in How to Cheat at IIS 7 Server Administration, 2007

Add Managed Module to IIS 7.0

With our new module compiled, we'll now add it to IIS 7.0. Before we can add our new module into IIS, we'll need to copy our compiled components to the /bin directory of our Web application.

Using IIS Manager, we'll now add our new module into the IIS 7 pipeline. In this example, we're going to add our module to a specific application within the Default Web Site:

1.

Click Modules and then click the Open Feature from within the Actions pane. Or you can simply double-click the Modules icon (see Figure 6.16).

Figure 6.16. Adding a New Module to IIS 7
2.

From the Actions pane, click Add Managed Module … (see Figure 6.17).

Figure 6.17. The Add Managed Module
3.

In the Add Managed Module window, provide the following information and then click the OK button:

▪

Name: HowToCheatIIS7

▪

Type: HowToCheatIIS7.TraceModule

This also could be done by directly updating the web.config file for the application. The following would be added within the<modules> XML node.

You'll now see HowToCheatIIS7 added to the list of modules. Clicking the View Ordered List … link in the Actions pane, you'll see the actual order in which IIS7 will process each module as a request is submitted to this application. Our new module will be at the bottom of this list. By moving it up in the list, you'll be able to capture and potentially modify data and actions before later modules. This is extremely useful when you want to trace certain types of information before another module handles the request.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597491556500100

Troubleshooting 101: Diagnostics in IIS 7.0

In The Best Damn Exchange, SQL and IIS Book Period, 2007

Add Managed Module to IIS 7.0

With our new module compiled, we'll now add it to IIS 7.0. Before we can add our new module into IIS, we'll need to copy our compiled components to the /bin directory of our Web application.

Using IIS Manager, we'll now add our new module into the IIS 7 pipeline. In this example, we're going to add our module to a specific application within the Default Web Site:

1.

Click Modules and then click the Open Feature from within the Actions pane. Or you can simply double-click the Modules icon (see Figure 17.16).

Figure 17.16. Adding a New Module to IIS 7
2.

From the Actions pane, click Add Managed Module…(see Figure 17.17).

Figure 17.17. The Add Managed Module
3.

In the Add Managed Module window, provide the following information and then click the OK button:

■ Name: HowToCheatIIS7

■ Type: HowToCheatIIS7.TraceModule

This also could be done by directly updating the web.config file for the application. The following would be added within the <modules> XML node.

<add name="HowToCheatIIS7" type="HowToCheatIIS7.TraceModule" preCondition="" />

You'll now see HowToCheatIIS7 added to the list of modules. Clicking the View Ordered List…link in the Actions pane, you'll see the actual order in which IIS7 will process each module as a request is submitted to this application. Our new module will be at the bottom of this list. By moving it up in the list, you'll be able to capture and potentially modify data and actions before later modules. This is extremely useful when you want to trace certain types of information before another module handles the request.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597492195000170

Putting It All Together

In The Best Damn Exchange, SQL and IIS Book Period, 2007

Centralizing Your Log File to Reduce Clutter

Centralizing your log file isn't required, nor is it always the recommended approach for all environments. However, centralized logging (better known as server-wide logging) reduces disk clutter and simplifies access to log data. It also enhances performance by reducing the number of log file handles open on large servers. Obviously, on servers that host only one or two Web sites, centralized logging is potential overkill.

Centralized logging comes in two flavors—Centralized binary logging and Centralized W3C logging—and each has their upside. For 95 percent of the cases, Centralized W3C logging is the most effective and simplest approach.

Start off by ensuring you enable some extended properties so you can locate data for each individual site. This property, s-sitename, will log the site name the request is associated with, such as Default Web Site. For example, Default Web Site is logged as W3SVC1, indicating this request belongs to this site. It makes it easy to then extract it from the log files requests for the individual site.

Best Practices According to Microsoft

For more information on Centralized logging, Microsoft has a Webcast aimed at understanding each type, as well as discussions about how each works, their advantages and disadvantages, and lastly how to set them up on IIS 6.0. This Webcast will apply to IIS 7.0 for the most part, minus how to enable it. These log types were only enabled in the metabase in IIS 6.0 and had no IIS Manager–supported method. In IIS 7.0 on Windows Server 2008, logging changes are made in the IIS Manager, as well as directly in the configuration.

Some Independent Advice

In Windows Vista, there are no logging capabilities in the IIS Manager. The only way to change the logging type was directly through configuration or via one of the other administration tools discussed in Chapter 16. This was supplemented with community support on Microsoft's IIS.NET DownloadCENTER located at www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1328 with a logging module.

Windows Server 2008 has full user interface support for logging.

To enable centralized W3C logging, do the following:

1.

Open an elevated command-prompt.

2.

Change to the %windir%\system32\inetsrv directory.

3.

Using Appcmd.exe, issue the following command:

C:\Windows\System32\inetsrv>appcmd set config -section:log /CentralLogFileMode:CentralW3C

After setting this value, you will must restart HTTP to have it change the logging type since HTTP.sys does all of the IIS logging. To do this, issue the following command:

Net stop http /y & net start w3svc

To view your consolidated log file, navigate to the %systemdrive%\inetpub\logs\w3svc directory.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597492195000182

Using XML with SQL Server

In Designing SQL Server 2000 Databases, 2001

Configuring IIS to Allow URL Queries

1.

From the Start menu, click Programs | Microsoft SQL Server | Configure SQL XML Support in IIS.

2.

Now we will create a new virtual directory called XMLDemo on IIS. Right-click Default Web Site. From the Context menu, select New | Virtual Directory. This action will bring up the New Virtual Directory Properties dialog.

3.

In the Virtual Directory Name frame, enter XMLDemo.

4.

In the Local Path field, enter C:\INETPUB\XMLDemo. You can use the Browse button to bring up the Browse dialog box or Windows Explorer to create this folder. Your settings should look like those in Figure 11.3.

Figure 11.3. Virtual directory name and path settings.
5.

On the Security tab, enter the username and password for your SQL Server (for example, username: sa with a blank password).

6.

On the Data Source tab, select the SQL Server you will be using (for example, local) and select the Northwind database.

7.

On the Settings tab, check all the settings.

8.

On the Virtual Names tab, click the new button to bring up the Virtual Names Configuration dialog box.

9.

For the Virtual Name, enter Queries, and select Template for the type. For the path, enter C:\INETPUB\XMLDEMO.

10.

Click the Save button to save the new virtual name. The Virtual Names tab should now look like Figure 11.4.

Figure 11.4. Adding a virtual name.
11.

For the virtual name for schemas, on the Virtual Names tab, click the New button to bring up the Virtual Names Configuration dialog box.

12.

Enter Schemas, and select Schema for the type. For the path, enter C:\INETPUB\XMLDEMO.

13.

Click the Save button to save the new virtual name.

14.

Click OK to create the new virtual directory. You will now have the XMLDemo virtual directory under the default Web site.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781928994190500142

Platform level defenses

Justin Clarke , in SQL Injection Attacks and Defense (Second Edition), 2012

Use an Empty Default Web Site

The HTTP/1.1 protocol requires HTTP clients to send the Host header in the request to the Web server. To access a specific Web site, the header value must match the host name in the Web server's virtual host configuration. If a match is not found, the default Web site content will be returned. For example, attempting to connect to a Web site by Internet Protocol (IP) address will result in the content of the default Web site being returned. Consider the following example:

GET / HTTP/1.1

Host: 209.85.229.104

...

<html><head><meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"><title>Google</title>

Here a request has been made to 209.85.229.104, which is actually an IP address of a Google Web server. What is returned by default is the familiar Google search page. This configuration makes sense for Google because Google likely doesn't care whether it is being accessed by IP address or host name; Google wants everyone on the Internet to use its service. As the owner of an enterprise Web application, you may prefer a little more anonymity and would like to avoid discovery by attackers scanning your IP address range for ports 80 and 443. To ensure that users are connecting to your Web application by host name only, which usually takes the attacker more time and effort to dig up (but is known to your users), configure the Web server's default Web site to return a blank default Web page. Given that legitimate users usually prefer easy-to-remember host names, access attempts via IP address could be a good way to detect potential intrusion attempts. Lastly, it's worth pointing out that this is a defense-in-depth mechanism and is not sufficient to prevent unwanted discovery, but it can be especially effective against automated scanning programs (such as vulnerability scanners or even SQL injection worms) looking to identify vulnerable Web sites by IP address.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597499637000098