The major prerequisite for installing Proxy Server is to have the IIS server installed first. The Web Proxy part of Proxy Server runs as a sub-service of the WWW service and therefore requires it in order to function. Proxy Server also makes use of the IIS Service Manager to provide an interface for controlling both the Web Proxy and the WinSock Proxy. If you are running IIS 4, as we have suggested, then the IIS Service Manager can be found in the NT Option Pack Microsoft Internet Information Server folder. If you are running IIS 3, the Internet Service Manager can be located in the Administrative Tools (common) folder. You may have more Internet services running on your system. For example, our server includes the NNTP, SMTP, MTS, MSMQ, WWW, and FTP services, as well as the three proxy services.

Note Whichever IIS version you are running, note that Proxy Server installs into its own folder and has its own service manager—in the case of IIS 4, another plug-in to the MMC.

Connecting to Other Servers

NT is a fantastic environment for being able to fully control services running on other NT machines. The IIS Service Manager can be used to control any valid Microsoft Internet service running on another NT machine on the local LAN or even over the Internet. In fact, the Proxy Server installation routine can be used on NT Workstations for just installing the Administration tool, which is just another name for the IIS Service Manager. By installing the Administration tool on an NT Workstation, that workstation can be used to control the Internet services running on NT Servers anywhere on the network. However, the WinSock Proxy cannot be used to remote NetBios traffic, although it is used to control remote NT services. This means that Proxy Server cannot be used to allow LAN workstations to perform network type activities, such as mapping drives or printing to systems on the Internet. Proxy Server does not currently remote NetBios traffic.

The first two buttons on the toolbar are Connect to Server and Search Servers. The Search button will only locate IIS servers running on other NT machines on the private LAN. It won't search the Internet.

The Connect button can be used to connect to other servers, either by machine name or by IP address. A NetBios machine name or the actual IP address to connect to can be entered here. Once connected, the service display area will list all services running on the other machine, as well as services running on the local machine. From that point, all services can be controlled in any way.

Configuring Service Properties

To configure service properties, highlight the service to configure, right-click, and choose Properties from the resulting pop-up menu. You can also choose Properties from the Action menu.

Authentication Principles

A large part of configuring both the Web Proxy and WinSock Proxy Servers deals with setting up security. This section will give a brief overview of how Proxy Server deals with security. For a full account of Proxy Server security, please see Chapter 17.

The Web Proxy service uses two levels of security, whereas the WinSock Proxy service uses only one.

The first level of authentication used by the Web Proxy service is login authentication. Since other operating systems can access a Proxy Server Web Proxy, don't rely on the internal Windows login security. CERN authentication is built into the Web Proxy standard. When a client attempts to use the Proxy Server Web Proxy service, it must send a standard HTTP request for access over port 80. Upon receiving this, the Web Proxy Server returns an authentication challenge to the client. Clients that adhere to CERN authentication (such as Netscape and IE 3 or higher) should see a login prompt displayed. Some clients may be configured to send an authentication name and password directly to the Web Proxy without prompting the user. The client must log in with an anonymous login (if that is permitted) or must provide a log in name and password that is present in the NT user database.

If the Web Proxy login is permitted, the authentication name and password used will also be further used by Proxy Server to determine which specific Web Proxy services the user can access (WWW, FTP, and/or Gopher). This is the second level of authentication: protocol-specific access.

The WinSock Proxy service, on the other hand, uses only protocol-specific authentication because the WinSock Proxy client can only run on a Windows platform. It's assumed that the network itself has already taken care of login authentication. Therefore, the WinSock Proxy service can use the internal NT security layer to demand network identification from clients to find out exactly who they are. That information is used to determine protocol-specific access permissions.

Using the WWW Service to Provide Login Access

Because the Web Proxy service runs as a sub-service of the WWW service, the login configuration of the WWW server applies to the Web Proxy service. To examine the login setup of the WWW service, follow these steps:

1. Highlight the WWW service in the service list of the IIS Service Manager.
2. Click the Properties button. The WWW Properties dialog box is displayed.
3. If you want to alter which account controls anonymous login permissions, enter a new user account name in the Username field of the Anonymous login section. Even if a password is blank, NT displays a string of 14 asterisks for enhanced security. As you have learned in earlier chapters, when the IIS server is installed, an NT user account is created to handle the rights given to anonymous logins. The name of this account is usually IUSR_computername where computername is the name of your NT IIS server. This account should not be assigned a password. If this account is given a password, anonymous logins must provide this password for access. The nature of the anonymous login is to use the e-mail address of the requesting user for a password.
4. Note the TCP Port field of the WWW Properties dialog box. This is the field for indicating which TCP port the WWW server listens to. This also affects which port Proxy Server listens to and can be used to great effect when necessary. For example, if you want to run a completely separate WWW server, you can set the IIS Web server to listen to a port other than 80 for network traffic (for example, port 81). Another WWW server can be installed to listen to the traditional port 80. Proxy clients on the LAN can configure their software to talk to port 81, leaving the other Web server to handle available external connections on port 80. There is an option in the Web Proxy configuration for disabling external Web connections to the IIS server, though. When LAN workstations install the WinSock Proxy client software, they will automatically import the correct settings for whatever port you have set the IIS Web server to listen to.

Forms of Access The WWW service supports three forms of login access, all of which you learned about in earlier chapters. Any single one of these forms can apply, or all three can be used simultaneously.

Anonymous When anonymous logins to the WWW service are permitted, anyone can log in without providing any form of authentication. Unlike FTP anonymous access, which requires a login name of anonymous and a valid e-mail address given as a password, WWW anonymous access requires no credentials. If the WWW service does not receive any user information upon client connection, it is assumed that the connection should be extended anonymous login access permissions.

Basic (Clear Text) When clear text logins are permitted, WWW clients can present their username and password in a standard, low-level encryption format. This form of authentication is fairly simple to break and should be avoided if possible.

Windows NT Challenge/Response This option is the highest form of security that the WWW service supports. When a client attempts to access the WWW service, the WWW service demands the presentation of login credentials in NT security encryption and format (NTLM C-R). In order for this form of login authentication to be available, the WinSock Proxy service must be present, and the client must have the WinSock Proxy client software loaded. Windows 9X and NT support this form of authentication, but Windows 3.1 and Windows for Workgroups 3.11 do not. However, they can be upgraded to do so if you can still find the software.

The WWW service is designed to field access requests from the outside Internet, and Proxy Server is designed to field access requests from the inside. Keep in mind that a TCP/IP connection to the Internet is just another network connection. Login authentication can take place over a dial-up link just as it can over twisted pair cable.

Proxy Server and NT Security

Proxy Server runs as a standard NT service. As such, access by clients is controlled on a user-by-user basis. When a user attempts to connect, Proxy Server consults the internal NT user database. Both the Web Proxy and the WinSock Proxy Server grant access to Internet protocols. A protocol is a TCP/IP virtual port and a standard form of communication between two applications: client and server side. For example, the NNTP protocol is a form of communication between a newsgroup server and a newsgroup reader. By convention, this communication is carried out over TCP port 119. Proxy Server grants outside access on a protocol-by-protocol basis. All communication with the Web Proxy Server happens over port 80, no matter if the client is a WWW client, an FTP client, or a Gopher client. The Web Proxy Server determines the protocol request by the format of the data. The WinSock Proxy Server determines the protocol by the port the client attempted to connect to.

Each protocol handled by the Web Proxy and WinSock Proxy Servers has independent access permissions assigned to them. These permissions can be in the form of permission for specific users or permission for a group of LAN users. Proxy Server can take full advantage of local NT security groups for assigning access to protocols. Out of the box, neither the Web Proxy nor the WinSock Proxy Servers have permissions assigned to any of the protocols they support. Therefore, no one can use Proxy Server until the administrator does some reconfiguring. The following configuration information will cover the basic steps needed. Chapter 17 covers the in-depth issues associated with Proxy Server security.

Configuring the Web Proxy Server

The first thing to do is open up the Web Proxy Server configuration dialog box. To configure the Web Proxy Server, follow these steps:

1. Open the IIS Service Manager.
2. Highlight the Web Proxy Server in the service list.
3. Click the properties button on the toolbar or choose the Properties option from one of the available dialog boxes. Figure 16.1 shows the Web Proxy Server configuration dialog box.

If your browser does not support inline frames, click here to view on a separate page.

Figure 16.1 The Web Proxy Server configuration dialog box

Conforming to the Microsoft configuration interface format, elements of the Web Proxy configuration are accessed via tabs at the top of the dialog box. The following is a basic description of the purpose of each tab.

Service A basic description of the Web Proxy service can be added on this tab. If only a specific group of users is permitted to access the server, some comment to that effect would be a good idea. A large environment of Internet servers is easier to manage if you know what each server does. This tab also allows you to access the LAT (Local Address Table) and edit it as needed.

Permissions Access permissions for each protocol handled by the Web Proxy Server are configured on this tab.

Caching This tab has settings that control the Proxy Server Web Proxy cache.

Routing This tab has settings that control how the proxy is routed outside the local network, including the aliasing that the proxy performs.

Publishing Computers downstream from the Proxy Server can use it to publish to the Internet. Enabling Web publishing allows you to control how such publishing works.

Logging This tab has settings that control how the Proxy Server Web Proxy logs activity information. Tracking access information is second in importance only to security.

To select a tab, click it. The following sections will consider each of the tabs.

The Service Tab

The Web Proxy Server comment will be displayed in the IIS Service Manager service display area. If there are many Internet services running on a network, using comments is important to keep things straight. This tab also allows you to view current connections and edit the LAT.

Viewing Current Sessions At the top, right-hand side of this tab, there is a button for viewing online sessions to the Web Proxy Server. Click this button to view current sessions. Figure 16.2 shows this dialog box.

If your browser does not support inline frames, click here to view on a separate page.

Figure 16.2 The Microsoft Proxy Server User Sessions dialog box

This dialog box shows the name of the connected user, the IP address that user comes from, and how long that user has been online. The username is anonymous if no authentication information has been exchanged between the client and Proxy Server. If anonymous access is not permitted, the username will be displayed. This dialog box does not dynamically refresh itself. To update the list, click the Refresh button. Click the close button to return to the Web Proxy configuration dialog box.

Editing the LAT The LAT is the table that indicates which addresses are local to the network. This is a text file stored in the MSPCLNT share and is transferred to WinSock Proxy clients when the WinSock Proxy client software is installed. This file is named msplat.txt. The Edit Local Address Table button calls up an editor that will allow you to make changes to the LAT should your network arrangement change. The LAT is also dynamically sent to clients via the WinSock Proxy control channel.

You can make changes to the LAT in the same manner that you did when Proxy Server was installed. The Construct Table button in the LAT editor will call up another dialog box.

This dialog box allows you to import the values found in the NT routing table to create the LAT. The NT routing table contains all IP information about how to route TCP/IP packets between all network interfaces on the NT Server. There are also options on this dialog box for creating entries in the LAT for the reserved local IP subnets. Chapter 15 covers the details of configuring this dialog box when installing Proxy Server.

Note that the dialog box shows any existing RAS connection of your NT Server as a valid network interface, even though it will be grayed out near the bottom of the dialog box. If you have a static IP for your network connection to an ISP, that static IP address should be part of the LAT.

Once the LAT has been edited correctly, the NT Server should be rebooted in order for the changes to take effect.

The Permissions Tab

Configuring the permissions for the Web Proxy Server protocols is simple compared to configuring permissions for the WinSock Proxy Server. With the Web Proxy Server, only three protocols have to be dealt with. These three protocols also have nothing special to configure. With protocols handled by the WinSock Proxy Server, many more configuration elements are involved, so you have to be a bit more careful in making configuration decisions.

The Enable Access Control check box turns on and off all forms of access restrictions. When not checked, the Web Proxy permits any connections, regardless of the credentials of the client needing access. When checked, the permissions settings restrict client access accordingly.

The drop-down box allows you to select the protocol to configure permissions for. Three Web Proxy protocols can be configured: HTTP, FTP, and Gopher (even though Gopher support is deprecated in IIS 4). The display area shows which NT users or groups have permission to use the indicated protocol. By default, the display area shows no access. If you do not have a need for manual security associated with each protocol, assigning Everyone as a permission to a protocol opens the protocol up for LAN-wide use.

You can also assign the Everyone group to the Unlimited Access protocol to open the Web Proxy to unlimited access. Your Administrator group should be assigned to the Unlimited Access protocol. This ensures that users with administrator privileges will not be hampered in any way.

Clicking the Add button allows you to select NT users or groups who should have permission to use the protocol.

If the current domain is in a trust relationship with another domain, you have access to add users and groups from the other domain into the permission list for the protocol being configured. The List Names From drop-down list allows you to select the domain from which to draw users and groups. The default is the home domain of the Proxy Server.

To add a user or group to the permission list for the protocol, follow these steps:

1. Highlight the group to add to the permission list. If you want to add a specific user, click the Show Users button. Proxy Server pulls in a list of all users of the selected domain.
2. Click the Add button. The user or group selected shows up in the Add Names display area.
3. Repeat the process and select all users and groups to give permission to for this protocol.
4. Click OK. Those users and groups will now have permission to use this Web Proxy protocol.

The Show Members button allows you to display exactly which NT users are members of a highlighted group. This is very handy to view just who you are granting Web Proxy permission to when you are granting permission to a group.

The Search button allows you to search for a user or a group within the selected domains that can be contacted from the current domain. Multiple domains can be searched simultaneously. On large networks, this is a handy feature. Domains must be in a trust relationship before groups and users can be shared between them.

Back on the Permission tab, the Remove button removes a highlighted user or group from the permission list of a protocol.

You may consider creating an Internet group rather than relying on one of the existing NT groups for handling Internet access.

The Caching Tab

The Web Proxy service can cache objects that pass through it on their way to clients. These objects can be graphics, sound files, icons, anything that would normally be part of a Web page. Currently, only WWW objects are cached. Files transferred by the FTP protocol through Proxy Server are not cached, just as Gopher data is not cached. These stored objects can later be issued out to requesting clients on the private LAN if the right conditions are met (such as if the object has not expired or if the object is unchanged on the server). This reduces the amount of external traffic Proxy Server has to maintain. The Web Proxy cache settings are controlled through this tab, shown in Figure 16.3.

If your browser does not support inline frames, click here to view on a separate page.

Figure 16.3 The Caching tab of the Web Proxy

Caching can be turned on and off through the Enable Caching check box. Turning the cache off does not mean that Proxy Server will not serve out cached objects to clients. It means that it does not actively store any new incoming objects into the cache.

Modifying the Cache Expiration Policy Objects held within the cache are set to expire after a certain time period. This is called an object's time to live or TTL. It is a value measured in seconds. Two things can happen to an object when it has expired:

• The object will no longer be issued out by Proxy Server from the cache to clients, and a new version of the object will be kept when a client requests the object from the Internet.
• Proxy Server will actively update the objects on its own if active caching is configured properly.

To access and control TTL information directly, you must click the Advanced button on the Caching tab. Otherwise, the input you provide to Proxy Server from the radio buttons on the tab only gives it direction in how to make decisions about the appropriate TTL for a given page or site.

Modifying the Active Caching Policy Active caching causes Proxy Server to go out to the Internet and retrieve a fresh copy of an object without needing a client to prompt it to do so. This ensures that popular objects in the cache are always under their TTL and are synched with the originals of the objects on the Internet. This means that clients get HTTP objects locally and do not clutter up the Internet connection.

The Enable active caching check box turns active caching on and off. Proxy Server does not need to be restarted for any alteration in the active caching policy to take effect.

When you choose the first radio button, Proxy Server caches objects more actively. The active caching implementation is controlled by an advanced algorithm that factors in elements such as object popularity and Proxy Server peak access times. When the algorithm determines it to be the correct time to update an object based on these factors, Proxy Server refreshes the object from the Internet. When you choose the last radio button, the algorithm is adjusted so that active caching occurs less frequently, and the Internet connection is not crowded with Proxy Server caching activity.

Modifying Cache Size and Directories As discussed in previous chapters, Proxy Server's available cache space should be at least 100megs plus 1/2meg for every proxy client that will be supported. If there are many users on a LAN accessing many different sites on the Internet, the suggested size may not be enough to provide adequate caching services. Click the Cache Size button to modify where the cache directories are and how large they should be.

By default, Proxy Server sets up five directories to store cache data. These cache directories are set up under the URLCACHE directory. They are named DIR1, DIR2, DIR3, DIR4, and DIR5. The reason Proxy Server uses multiple cache directories is to speed up access to objects. When a single large cache directory is used, searching the directory for the right object (in the Proxy Server) can be time-consuming. Cache directories should always be placed on a local hard drive, not on a network drive.

Setting the cache is as easy as indicating the drive for a piece, or all, of the cache. The URLCACHE directory will be created automatically on all selected drives. Each of the subdirectories within the main URLCACHE directory will be used equally by the Web Proxy. The Set button must be clicked to set any size alterations or additions before the changes take effect. Proxy Server does not have to be restarted for any cache change to take effect.

Advanced Cache Settings The Advanced button on the Proxy Service Properties dialog box allows you to control elements, such as what protocols are cached and the maximum size of objects that should be cached, and to filter sites so that their objects are not cached. In Proxy Server's current version, only WWW objects are cached. The ability to enable caching of FTP and Gopher objects is not available.

The settings available on this dialog box limit the size of cached objects, return cache objects when the target site is unreachable, and set filters so that specific sites are not cached. The "Limit the size of cache objects" check box allows you to indicate a maximum size for cache objects. Objects above the size indicated in kilobytes will not be cached by Proxy Server and will always be retrieved from target Web sites. The default is to have all objects cached no matter what their size.

The Return Expired Objects When Site Is Unavailable check box controls whether or not Proxy Server will return objects in the cache if the target site is currently unreachable, but the object's TTL has expired. This allows Proxy Server to simulate a successful connection to a target site even when the objects returned are expired. This can be bad and good for obvious reasons. It's up to you how you want to handle this setting.

The lower portion of this dialog box displays any special filter considerations that you might have configured in Proxy Server. Filters can specifically include or exclude certain sites for or from caching. Sites can be set to Always cached or Never cached. It is possible to set a general never cache policy for a root domain but create a special always cache policy to cache certain sites within that domain. For example, you could set a never cache policy for *.microsoft.com, but create an always cache policy for www.microsoft.com. That way, only objects from www.microsoft.com will ever be cached from the microsoft .com root domain. Cache policies can be set for specific paths on a domain, as well.

You might set www.microsoft.com as a never cache site, but the specific path www.microsoft.com/proxy might be set as an always cache site. Append a site with an asterisk if you want all sub-paths from the parent path to be cached. Without the asterisk, only the specific path will be cached.

The Add button will present a dialog box for adding a site filter to the cache configuration. Simply enter a site name in the appropriate format, as indicated in the URL field, and indicate whether the site is to be Always or Never cached. Click OK after configuring a site's caching policy.

The Edit button allows you to edit existing cache policies in the same way that you add a new site policy.

The Routing Tab

You will use the Routing tab with arrays to direct client requests for Internet objects. Requests can be routed through an array to upstream Proxy Server computers or directly to the Internet. You use the Routing dialog box to configure routing for Web Proxy clients.

The Use HTTP Via header appends the name in the text box to the HTTP Via header for proxied requests. Typically, this entry should be the name of the computer on which Proxy Server is installed.

The Upstream Routing options determine whether a client request is sent directly to the Internet or to another Web Proxy Server or array. The default is to use a direct connection to the Internet; however, if you use a Web Proxy, you can also set a backup route. In the event that the primary upstream Proxy Server or array is inaccessible, you can specify a backup sequence that the Proxy should use to access the Internet.

The Publishing Tab

Computers downstream from the Proxy Server computer can use Proxy Server to publish to the Internet. Proxy Server supports reverse proxying and reverse hosting. These two features enhance security by allowing any computer on your internal network to publish to the Internet. All incoming and outgoing requests are filtered through the Proxy Server computer. In addition, Proxy Server can also cache incoming requests from the Internet, which provides safe, easy access.

To take advantage of these settings, you must enable Web publishing. Then, you can decide whether incoming Web server requests should be discarded, sent to the local Web server, or transferred to another Web server. If transferred to another Web server, you can specify the request path and the mapping it should use within the spaces at the bottom of the dialog box.

The Logging Tab

Proxy Server keeps a very good record of who uses the Web Proxy or WinSock Proxy services and exactly what sites they access. By default, Proxy Server logs data in a straight text format. Log files are stored in the \WINNT\SYSTEM32\MSPLOGS directory for Web Proxy accesses and in the \WINNT\SYSTEM32\RWSLOGS directory for WinSock Proxy accesses. By default, both services start a new log file daily. The filenames are YYMMDD .LOG where YY is the year, MM is the month, and DD is the day. These log files are prefixed with WS for Winsock and W3 for the Web Proxy.

The following list is a description of each check box on the Logging tab:

Enable Logging Controls whether the Web Proxy service logs information. Unchecked, the Web Proxy service will not keep track of accesses.

Regular Logging Controls whether a full range of information is stored in each log file. If unchecked, only minimal information is stored in the logs. This cuts down on the size of log files.

Verbose Logging Controls whether or not each Internet access is recorded. By default, Proxy Server Web Proxy will only keep information concerning who on the local LAN accesses the Web Proxy Server. Verbose logging will force Proxy Server to record what Internet sites were visited by each user.

Proxy Server can log to a text file or a SQL or ODBC database, provided that these services are present on the network. Checking the Log to File check box tells Proxy Server to log to a standard text file in the appropriate directory. The Daily, Weekly, Monthly, and When File Size Reaches check boxes tell Proxy Server how often to begin a new log file. If you have little Proxy Server activity, a longer logging period is best. The higher the activity, the shorter the turn-around time should be for opening new log files. Be very watchful of your log files. If a client has a great deal of trouble accessing Proxy Server, it will generate an error line for each bad attempt the client makes. Some of the log files on networks we have seen have easily reached and exceeded 250Mb in a single day due to continuous automatic client reconnection attempts. It's a good idea to archive your log files or delete them on a regular basis to conserve disk space.

If you have a need to change the location where Proxy Server stores Web Proxy logs, you can change the contents of the Log file Directory field.

If the Log to SQL/ODBC Database check box is marked, Proxy Server will attempt to connect to a database server to store its log information. This form of logging is slightly slower than writing to a straight text file, but data manipulation for reports and so on is much more powerful. Any installed ODBC (Open Database Connectivity) drivers can be used. Microsoft Access is a common application that installs a full set of ODBC drivers for external applications, such as Proxy Server, to use when attempting to save data in a database format. During installation, Proxy Server can install several types of current ODBC drivers. These drivers will allow Proxy Server to interface with associated database engines for saving log information in the database engine's own format. Proxy Server can log database information to any machine on the network.

The configuration information in this area of the Logging tab is defined as follows:

ODBC Data Source Name (DSN) This field contains the name of the DSN of the database engine to connect to.

Table This is the name of the table within the database that Proxy Server opens to store its log information.

Username This is the username associated with the database table.

Password If the table is password protected, this field contains the correct password to allow Proxy Server to have access to the table.

Once the SQL/ODBC logging fields have been completed, Proxy Server immediately begins logging to the indicated database table. The service does not have to be restarted.

Configuring the WinSock Proxy Server

Configuration of the WinSock Proxy Server is almost an identical process to configuring the Web Proxy Server. The Service, Logging, and Filters tabs are identical in purpose and configuration elements. Refer back to the tab definitions in the Web Proxy Server configuration section earlier in this chapter for details on the settings involved. The following differences in the three tabs apply:

• The Service tab of the WinSock Proxy configuration does not have a View Sessions button. The WinSock Proxy Server cannot view a list of sessions it is currently supporting; instead, you can view the sessions for the WinSock Proxy from the View Sessions dialog box that you saw figure 16.2.
• The Caching tab is not present in the WinSock Proxy configuration. No caching occurs with WinSock Proxy, so this tab does not apply.
• An extra tab is present. This is the Protocols tab and is used to add support for new protocols or edit settings for support on existing protocols.

A major difference in configuration between the WinSock Proxy Server and the Web Proxy Server is in the Permissions tab. Like the Web Proxy Server, each protocol support by the WinSock Proxy Server is assigned a different set of access permissions. Unlike the Web Proxy Server, administrators can define support for new protocols that do not come pre-configured in the WinSock Proxy Server. Remember that nearly any Internet application can communicate with the WinSock Proxy Server. The client software is responsible for listening to local port requests and establishing a link between the client and the WinSock Proxy Server. As long as a port is correctly configured in the WinSock Proxy setup, almost any Internet application can use the WinSock Proxy Server as though it was directly connected to the Internet.

Protocols the WinSock Proxy Server Supports by Default

By default, the WinSock Proxy Server comes pre-configured to handle all major TCP and UDP port communications. Support for TELNET, FTP (non-proxied), NNTP (Network News Transfer Protocol), SMTP (Simple Mail Transfer Protocol), POP3 (Post Office Protocol 3), Finger, RealAudio, VDO Live, and several other common Internet sockets is configured into the WinSock Proxy Server. This means that unless you have special Internet applications that communicate over an uncommon port, you will probably not have to do any special configuration on the WinSock Proxy Server to get all the commonly used client Internet applications running correctly.

The WinSock Proxy Permissions Tab

To open the WinSock Proxy configuration, do the following:

1. Highlight the WinSock Proxy service in the service list of the IIS Service Manager.
2. Click the Properties button on the toolbar.

The WinSock Proxy Permissions tab looks substantially similar to the Web Proxy Permissions tab but provides a greater amount of configurable options than the Web Proxy does. Figure 16.4 shows the WinSock Proxy Permissions tab.

If your browser does not support inline frames, click here to view on a separate page.

Figure 16.4 The WinSock Proxy Server Permissions tab

Assigning permissions to WinSock Proxy supported protocols is the same process as assigning permissions to Web Proxy protocols. Select the protocol to assign permissions to in the right drop-down list and click the Add button. For more information concerning granting users and network groups rights to use a protocol, refer to the Web Proxy Permission tab discussion earlier in this chapter.

The Copy To and Remove From buttons can be used to copy sets of groups and users from the currently selected protocol to groups of other protocols. For example, if a protocol has seven permission definitions in it, you could display this protocol, select five of these definitions in the traditional Windows select method (holding down CTRL and clicking the desired elements), and then click Copy To. A list of all available protocols would be displayed. You can then select a protocol (or group of protocols with the multiple select method again) and click OK. The selected groups and users are copied into the permission sets of the target protocols. Remove From works in the same way but in reverse. Selected groups and users will be removed from the selected protocols rather than added to them.

The Protocols Tab

The Protocols tab allows you to modify existing protocols or create new protocols that the WinSock Proxy Server will support. When you view this tab, you see the protocols that the WinSock Proxy Server supports listed in the Protocol Definitions area. From this dialog box, existing protocols can be edited or removed, and new ones can be added. The dialog boxes produced by the Add and Edit buttons are identical.

When adding support for a new protocol, the first thing you have to know in advance is what port the client application talks to its server on and what type of data packets (TCP or UDP) the application uses. Most clients initiate communication with a server over one port, but expect a response over another port. Some clients expect the server to set the return port number, while others expect a return over a consistent port. For example, under normal circumstances, FTP clients initiate communication with an FTP server over port 21 but expect a response over port 23. However, most good FTP clients can be set for something called Passive transfer (PASV Mode), which means that they instruct the server to set up a non-standard return port.

PASV mode is a security form. It is mostly needed to pass over routers and firewalls. The purpose of a firewall is to prevent access to a network over known ports, such as the return FTP port 23. When the server sets up a non-standard return port, the communication can pass over a firewall.

You must be familiar with how a client/server pair communicates before you can correctly set up the WinSock Proxy Server to connect the two. For example, an application might use UDP packets and initiate communication with conforming servers over port 2417. The application might expect a return channel from the server over a dynamically established port—that is, the return port will vary. The return port is not as important as knowing the initiating port. Most of the time, the WinSock Proxy client software will be able to tell the WinSock Proxy Server what port to expect a return response on from the way the actual client secures the return port on the workstation. The process happens like this:

1. The application initiates communication with a server over port 2417.
2. The WinSock Proxy client software intercepts this call and informs the WinSock Proxy Server about it over its control port—1745.
3. The WinSock Proxy Server begins to communicate with the application as though it was the actual site that the application is trying to talk to. Understand that the WinSock Proxy Server is not responding for the actual target server. It can't. It doesn't know what the application wants. The WinSock Proxy Server only receives the network connection as though it were the target site.
4. The application initiates a listen on a dynamic UDP port for return data from the server it is trying to contact.
5. The WinSock Proxy Server intercepts the listen and tells the WinSock Proxy Server what port the application is listening to.
6. The WinSock Proxy Server initiates a connection between itself and the target site over port 2417. At the same time, the WinSock Proxy Server begins to listen for a response over the UDP port that the application is listening to.
7. When the target site responds on the dynamic return port, the WinSock Proxy Server forwards the response to the application, as if it were the actual site.

In this process, the WinSock Proxy Server acts as the middleman. It pretends to be the target server when talking to the application, and it pretends to be the application when talking to the target server. As long as it knows what port to expect an initial connection on and what type of data packets to toss around, it should be able to handle any Internet client/server combo.

To add support for a new protocol, click the Add button in the Services (protocols) dialog box. The following list defines each element on the Protocol Definition dialog box.

Protocol Name This is any name you want to assign to the protocol.

Initial Connection Port This is the port the client will use when first attempting to contact a server.

Initial Connect Type This can be either TCP or UDP. You must know what type of packets a client uses to initiate communications with a server. If you are not sure, try TCP. TCP packets are more commonly used than UDP.

Initial Connection Direction This setting tells the WinSock Proxy Server which direction to expect the packets on this port. Since the application begins the communication in the model we have sketched, the direction is outbound. Outbound will be the direction for 95% of all protocols you set up.

Once you have the basics configured, you need to add information about how subsequent connections from the target server back to the client application will be made. With our sample application, we will need to indicate that any UDP port can be used for a return connection. Clicking the Add button (or the Edit button to edit an existing return port) will produce the Return Connection dialog box.

The return port number (or range) should be indicated in the Port or Range fields. A value of 0 indicates that any port may be used as a return port for this protocol.

The Type will set the packet type that is normally the same as the outbound packet type, in this case, UDP. The Direction will be inbound. The application will not send further outbound packets to the target server over a different port. Some protocols may need to send out packets over multiple ports once an initial connection to a server is made. If this is the case, you need to know which ports the client application is utilizing and create multiple subsequent connection entries, or create a range for ports.

Once you have indicated these elements, you can click OK to return to the primary protocol definition dialog box. Those should be the only configuration elements you need to set. For most protocols you will configure, you can set all subsequent connections for any valid port. Once the protocol has been completely defined, click OK to return to the Protocols tab. Don't forget to add permissions to new protocols you configure.

Multiple Proxy Server Gateways

More than one Proxy Server gateway can be used on a network. The Web Proxy and WinSock Proxy Servers behave slightly differently in a network environment where more than one Proxy Server is used.

Multiple Web Proxy Servers

Clients can access multiple Web Proxy Servers in a cascading fashion. Web Proxy Servers can be grouped and accessed in a chain to provide the best possible performance for clients. In order for this to be possible, some form of internal name resolution ability must be present on the network. Either a DNS or WINS server must be available to perform name resolution on behalf of the clients and then provide resolved name information to the clients.

All Web Proxy Servers can be put into an Internet group. This group is defined as an entity by a DNS server or a WINS server. When the group is accessed, either the DNS server or the WINS server serving out the name resolution functionality for the network will sequentially choose a member from the group and resolve the group name requested as the IP of one of the members of the group. The name server is responsible for tracking which member of the group is up for the next resolution request.

Under a WINS environment, a multi-homed, static database entry is created to list all of the Proxy Servers. The WINS server chooses a representative from this list differently from how the DNS server chooses its representative. The WINS server first matches a client's request with the client's IP. The WINS server then tries to find a Proxy Server from the list that has the same subnet as the client. Failing to do that, the WINS server attempts to locate a Proxy Server on the same net as the client. If none of these searches finds a proper candidate, the WINS server picks a member of the group at random and resolves the request to that member's IP address.

Multiple WinSock Proxy Servers

WinSock Proxy Servers cannot be cascaded like Web Proxy Servers can. In order to make best use of multiple WinSock Proxy Servers, network clients should be evenly distributed among all WinSock Proxy Servers to make sure that no one WinSock Proxy Server becomes overloaded. You need to have a good understanding of which Internet protocols demand the most out of a connection. Knowing that will allow you to separate client access correctly. Internet applications, such as RealAudio and VDO Live, consume huge amounts of connection bandwidth and can bring the Internet applications of other network users that are running through the same connection to a stand still.

Configuring Proxy Server Security and Authentication

Proxy Server security relies directly on the internal security found in NT's architecture. When NT Servers are used in a workgroups-based network, the user information provided on each server is separate and independent. Each server or NT workstation system can maintain a full database of users and groups. These user and group definitions only apply to accessing the particular server on which they are kept.

Arranging a network into a domain takes a little more effort to manage, but the benefits of less confusion and tighter security far outweigh the extra management effort. NT Servers in a workgroup are like islands of independent security. The security credentials needed to access resources or services on one NT Server may not be the same as those needed for a different NT Server.

Login Process

As you should know, several things happen when a workstation logs on to a network. If the workstation is set to logon as a workgroup member, the workstation itself performs user authentication with its own user database of information. If the workstation is set to logon as a domain member, the workstation machine will consult the primary domain controller for user authentication. A login proceeds in the following manner:

1. The domain controller must be found before the logon when the system is started. This process is called discovery and is only done when a workstation is set to log on to a domain. The actual method of discovery depends on the protocol(s) the network uses. To discover a PDC (primary domain controller), a workstation must perform a network broadcast, which triggers the PDC of the network to perform its own broadcast to indicate with a directed datagram where the PDC can be found. Once the workstation receives the broadcast response from the PDC, which lets the workstation know exactly where it can find the PDC so that the workstation can correctly direct its own datagrams, the next step of logging on can proceed.
2. Once the PDC is found, the workstation attempts to establish a secure channel between itself and the PDC, or the BDC (backup domain controller) if it responded in place of the PDC. This secure channel consists of datagrams directed back and forth between the workstation and PDC. Each side must prove to the other that they are who they say they are. This process is called Secure Channel Setup.
3. Once the workstation and the PDC have found each other and set up a secure channel, Pass-Through Authentication can occur. In this process, the workstation sends the login username and password to the PDC (or a BDC) in encrypted format. If the user information is correct, the PDC sends back an OK for the workstation to permit the login.
4. After authentication is complete, the system and user are given a security token by the controller that performed the authentication. This token is the actual network item that is passed around to network servers accessed by the client workstation. Any target server will use this token to consult a controller to find out if it is valid and if the associated user should be granted access to use whatever resource the user is attempting to access.

A Proxy Server is like any other resource on the network. Accessing it takes proper network validation. The Proxy Server service is fully capable of utilizing the internal NT security process.

Domain Controllers and Their Impact on Proxy Server

On an NT-based network, the central authority figures are known as controllers. There is one primary domain controller and any number of backup domain controllers. These systems are responsible for fielding all Microsoft Network Domain logins and granting or denying access to secured network resources. PDCs and BDCs are always NT Servers and, as such, all share information. User data stored on the PDC is replicated to all BDCs across the domain. The network administrator determines which NT systems are to be BDC machines when these systems are installed. The job of the BDCs is to share some of the workload of the PDC. On medium or large networks, a single authority figure might quickly become overloaded with network traffic. BDCs help to ensure that network performance is kept as high as possible.

Administration of user data can be done from any NT machine, Server, or Workstation, as long as the logged-in user has administrator rights. The main application for modifying user data is User Manager for Domains, which is found in the Administrative Tools folder. When systems are not members of a domain, this application only modifies user information stored in the local user database. When an NT system is a member of a domain, this application links to an available controllers and modifies the domain-wide user database.

When talking about user information concerning Proxy Server authentication, note that we are discussing a domain-wide database of user information. While a Proxy Server machine can be a completely isolated server, not part of any domain, the task of managing separate authorization for network users and Proxy Server users in such an environment becomes far more time-consuming and counterproductive.

In general, most NT installations deal exclusively with a domain-based network. To that end, we will focus on implementing Proxy Server within an NT domain model.

Creating a Global Security Group To create a global group, follow these steps:

1. Click the File menu in the User Manager for Domains.
2. Click the New Global Group selection.
3. The Create Global group dialog box will appear.
4. The name of the group should appear in the Group Name field. In this example, you might name it something like Proxy Users.
5. The Description field can be any description you want to give this group.
6. Next, indicate which users should be members of this group. The Not Members list shows all users who are not currently members of this group. Because this is a new group, the Not Members list shows all NT users. Select all users who should be allowed general proxy access and click Add.
7. Click OK. The Proxy Users group is created and a set of users are defined.

Warning Make sure you do not add the IUSR_servername user to the group. If this account is added to the group, anonymous users will be granted access to whatever features you assign to the Proxy Users group. This account should only be dealt with on an individual basis and never assigned to any global group.

Once the group is created, it can be used within Proxy Server to define access to various protocols. If this group needs to have special NT network permissions granted to it, the group can be nested within an existing local group that already has the permissions assigned to it. This approach is a simple way of cutting down some of the management time spent on security. If a group of users needs to have certain access permissions in more than one domain, two groups should be created: one that is local and one that is global. Both can have the same name. Users can be assigned to the global group, and the global group can be nested within the local group. The local group can then be granted whatever permissions are needed, and those permissions will filter down to the global group users.

The next step is to grant this group access to a supported protocol, either in the Web Proxy or the WinSock Proxy.

Granting Proxy Permission to the New Group

Open the IIS Service Manager and open the properties for the Web Proxy. Once you have opened the properties of the Web Proxy, select the Permissions tab. By default, no permissions are configured for any protocol in Proxy Server. Therefore, no users have access to get to the Internet through the Web Proxy or the WinSock Proxy. In order to grant access permission to the new Proxy Users group, do the following:

1. Select the protocol you wish to grant access to in the Protocol drop-down list. For example, you will often use the WWW (HTTP) protocol.
2. Click the Add button. This opens a dialog box for adding groups or users to the access list for this protocol.
3. The List Names From drop-down list allows you to select any domain you currently have access to. Access to foreign domains can be through a trust relationship or from having a parallel account in other domains. By default, you can select users and groups from the local domain.
4. The Default Only drop-down list has both local and global groups. However, you can list users by clicking the Show Users button. This displays the users of the domain, as well as the groups. Configuring individual users is fine for small networks or special cases, but this can be a management nightmare for medium or large networks. You should always work with groups whenever possible.
5. Scroll down the name list until the Proxy Users group is displayed.
6. Highlight the Proxy Users group and click the Add button. This adds the Proxy Users group to the Add Names list.
7. You can select any additional groups or users to grant WWW access permission to if necessary.
8. Click OK to return to the Permissions tab. The group appears in the Grant Access To list area and has access to use the WWW protocol.

The Members button on the Add Users and Groups dialog box displays a list of users for the currently highlighted group. If more than one group is selected, this button is not available. The Add button at the bottom of this dialog box will add the group to the Add Name list on the Add Users and Groups dialog box. It is not for adding additional users to the group. This function allows you to view which users are members of the group.

The Search button on the Add Users and Groups dialog box will let you search for users or groups on the local domain or on domains that you have access to, either through a trust relationship or by having a parallel account on the other domain(s).

In this dialog box, you can indicate which domains to search and the name of the user or group you want to search for. You can search in the local domain or in all available domains. By default, all domains will be searched. Search results will be displayed in the lower area. Elements of the search result can be selected. Click the Add button to add the user or group to the permissions list.

Once you have added the Proxy Users group to the permission list for the WWW protocol, the users of that group will be able to use Web browsers through Proxy Server Web Proxy to access WWW sites on the Internet.

Complete this process for all of the protocols (WWW, FTP, Gopher, or Secure) you need to grant users permissions to. The process for adding permissions to WinSock Protocols is very similar, but the WinSock Proxy has special universal access settings that make it easier to grant global protocol permissions for a group of users.

Controlling Inbound Access from the Internet

When Proxy Server is installed, two elements of NT are altered so that security is enhanced. The first element that is altered is IP Forwarding. IP Forwarding is found within the TCP/IP settings. It is turned off by default. It controls whether or not NT will forward IP packets between network interfaces in managers (such as a network card and a RAS connection to an Internet Provider). Under conditions where a dedicated, full-time Internet connection is available to a network and each workstation on the LAN is configured for its own direct Internet access, IP forwarding must be enabled for workstations to pass their packets to the Internet and vice versa. This in itself will halt all inbound traffic at the NT Server, which is connected to the Internet.

To further restrict access to the NT Server from clients connecting from the Internet, Proxy Server disables listening on all TCP/IP ports which do not have permissions set for them. This means that any Internet server application (such as an FTP server, a telnet server, or a POP3 server) running on the connected NT Server will be unable to hear any external inbound traffic until permissions are set for the associated protocol in the WinSock Proxy. The Web Proxy only listens to port 80 for traffic. If permissions are set for any of the supported protocols in the Web Proxy, port 80 will be listened to for inbound traffic.

Isolating Proxy Server on Its Own Domain

If you want to set your network security at a very high level for proxy access, one approach is to set up the NT Server running Proxy Server as a primary domain controller of its own domain. A one-way trust relationship can be established between the Proxy domain and the network domain. The Proxy domain would be set to trust the network domain, but the network domain would not trust the Proxy domain. This arrangement will further limit the access that can take place between the proxy server and all other systems on the network domain.

This arrangement also works well when the network is not set as a domain but rather as a workgroup. The NT Server running Proxy Server can be set on a primary domain controller of its own domain, which will give greater security control and allow easier expansion for future growth.

Case Study: Using Proxy as Part of a Proxy Array

Often, companies find that they have to divide their network into several local groups, using routers and bridges to divide it up. This reduces the amount of traffic that transits certain parts of the physical network.

In such an environment, building a Proxy Server array can be a useful technique, particularly if the users in the different subnets tend to access substantially different pages. In such a case, building a Proxy Server array can speed user access without substantial impact on the network as a whole.

The Problem

Assume for the moment that a company has five divisions, each of which works closely with extranets of vendors and other related organizations. However, none of the different divisions overlap on access to any of these particular extranets. Instead, these only overlap on generic Web site surfing.

The Solution

By configuring a proxy array and setting individual routing tables, you can set up each individual Proxy Server to cache the information appropriate only to its department, while accessing a central Proxy Server for generalized Internet access. Such a construction will speed departmental access to common sites, reduce network traffic, and still maintain our Proxy Server goals of providing central points of management accessible by the administrative staff.

Summing It Up

While Proxy Server lends itself to simple Internet access distributions, using it in a complex environment with a multiple-server array model can help you effectively manage Internet access, as well as network bandwidth.

About the Authors

M. Shane Stigler, MCSE and MCT, is a senior partner in a consulting firm based in Las Vegas, Nevada and provides technical training to a variety of companies.

Mark A. Linsenbardt, MCSE and MCT, is a seasoned trainer who has taught certification classes and provided consulting services all over the country. Currently, Linsenbardt is the president of a small consulting firm in Las Vegas, Nevada.

Copyright © 1999 Sybex, Inc.

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. All prices for products mentioned in this document are subject to change without notice. International rights = English only.

International rights = English only.