For the complicated job Microsoft Proxy Server performs, its setup is very easy and straightforward. The complicated part of Microsoft Proxy Server is understanding the principle behind what Microsoft Proxy Server does. The first thing you should have a clear understanding of before you attempt to configure Microsoft Proxy Server is that Microsoft Proxy Server is actually two separate servers working together to perform similar tasks. These servers are separate services under NT, but are both controlled through the IIS Service Manager. The first part of Microsoft Proxy Server is the Web Proxy server. This is a fully CERN-compatible Web Proxy server, meaning that any client that adheres to CERN Web Proxy standards can use the Microsoft Proxy Server Web Proxy to talk to the Internet. Web Proxy clients do not just have to be Windows-based clients. There are no proprietary elements to the Microsoft Proxy Server Web Proxy. In fact, there is no special software that must be installed on client workstations for them to be able to see the Microsoft Proxy Server Web Proxy.
For example, UNIX-based systems connected to an NT server running Microsoft Proxy Server by the TCP/IP protocol can run the UNIX version of Netscape and see the Internet through the Microsoft Proxy Server Web Proxy server. All flavors of Netscape can be internally configured to see any standard CERN Web Proxy via the TCP/IP protocol. Chapter 1, "Proxy Server Overview," covers the principles behind Web Proxy connections.
The second part of Microsoft Proxy Server is known as the WinSock Proxy server. This part of Microsoft Proxy Server is proprietary to the Windows environment since special WinSock Proxy client software must be installed on workstations in order for them to access the WinSock Proxy server. Rumor has it that Microsoft is planning on releasing WinSock Proxy client software for other platforms (UNIX, Apple, OS/2), but I haven't had confirmation on this from any source.
WinSock Proxy works by replacing the local workstation WinSock DLLs with special DLLs that either keep TCP/IP traffic local, or remote it over the WinSock Proxy server for transport to the Internet, depending on where it destined for. Only WinSock communications version 1.1 are support by the WinSock Proxy server. Microsoft will be updating Microsoft Proxy Server to support WinSock 2.0 communications as soon as it can. When support for WinSock 2.0 standards will be incorporated into Microsoft Proxy Server is hard to say because WinSock 2.0 standards have themselves not be set. It may be that Microsoft Proxy Server 2.0 will still only support WinSock 1.1 standards if WinSock 2.0 standards have not yet been agreed upon. By adding a new WinSock layer to a system, the WinSock Proxy client software communicates to the WinSock Proxy server via a special control channel. This avoids TCP/IP port conflicts on the NT server running Microsoft Proxy Server. Any Internet server software can be run on the NT machine running Microsoft Proxy Server because the WinSock Proxy server itself does not perform broadband TCP/IP port listening, as smaller third-party WinSock Proxy software such as WinGate does. With these third-party software packages, the server side runs by listening to all applicable TCP/IP ports for traffic. The Microsoft Proxy Server WinSock Proxy server communicates with clients via a single control channel. The WinSock Proxy client side software is responsible for listening to specific TCP/IP ports.
By using WinSock Proxy on client workstations, nearly any Internet application (such as e-mail, Newsgroup reader, and FTP client) can operate locally, just as if it were directly connected to the Internet. Because the communication control takes place at the WinSock level, client applications using the WinSock Proxy interface normally needs very little if any special configuration to work correctly.
Once you have a grasp on the two faces of Microsoft Proxy Server, you will know how to best make use of each element on your private LAN. Accessing the configuring controls for both elements is as easy as opening the IIS Service Manager.
The only major prerequisite for being able to install Microsoft Proxy Server is to first have the IIS server installed. The Web Proxy part of Microsoft Proxy Server runs as a sub service of the WWW service, and therefore requires it to be functioning. Microsoft Proxy Server also makes use of the IIS Service Manager to provide an interface for controlling both the Microsoft Proxy Server Web Proxy and WinSock Proxy. The IIS Service Manager can be found in both the Microsoft Internet Server and Microsoft Proxy Server folders. Once started, the interface looks like Figure 6.1.
You may have more Internet services running on your system. By default, all three IIS services, WWW, FTP and Gopher, are installed when IIS is installed. Figure 6.1 only shows the WWW server installed. I have no use for the Gopher server, and I think the IIS FTP server stinks. Gopher is an Internet server which is used to search multiple FTP sites for files. Its use (in my opinion) is negligible since you can only search on specific filenames and not on descriptions. The IIS FTP server (again, in my opinion) is substandard in features and flexibility. As you can see in Figure 6.1, the IIS Service Manager has a very simple interface. Nearly every action that might need to be performed on a service can be accomplished through the toolbar buttons.
The middle set of buttons on the toolbar are the controls for starting, stopping, or pausing services (They appear on the bar in that order). Starting and stopping services is simple enough to understand. All you need to do is highlight one of the services listed in the service list, and click the start or stop button.
Pausing a service is different than stopping a service. When a service is paused, current connections to that service will remain active, but new connections will not be accepted. Pausing a service is best used when the service needs to be fully stopped, but can't because of active connections. A service can be paused first and then fully stopped after all active connections end.
If there are many Internet services running on one machine, it may be convenient to filter out unneeded ones, or sort them for easier viewing. The last five buttons on the toolbar control the list filter. Figure 6.1 shows them all depressed, meaning all services are shown. The buttons from right to left are: FTP, Gopher, WWW, Web Proxy and WinSock Proxy. The display area can show services running on other NT servers on the LAN. By default, only local services are shown. To filter out certain services, simply un-depress the desired filter button.
The service list can be sorted by NT Server, Service, Comment, or State. Click the View menu and select the appropriate sort method. The default sort order is by Server. The view mode of the service list area can also be changed to Server-oriented mode, a Service-oriented mode, or a Report-oriented mode. The default is a Report-oriented mode. The view mode can be changed through the View menu.
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 Microsoft 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, which is what is used to control remote NT services. This means that Microsoft 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. Microsoft 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, obviously.
The connect button can be used to connect to other servers, either by machine name or by IP address. Figure 6.2 shows the Connect to Server dialog box.
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.
The third button on the toolbar is used to configure service properties. Highlight the service to configure, and click this button. As with all Windows 95 and Windows NT 4.0 elements, this can also be done by right-clicking on the service and then selecting Properties from the pop up list.
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 Microsoft Proxy Server deals with security. For a full account of Microsoft Proxy Server security, please read chapter eight.
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 Microsoft Proxy Server Web Proxy, don't rely on the internal Windows login security. CERN authentication is built in to the Web Proxy standard. When a client attempts to use the Microsoft 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.0 or higher) should see a login prompt displayed. Some clients may be configurable to send an authentication name and password directly to the Web Proxy without prompting the user. The client must login with an anonymous login (if that is permitted), or provide a login name and password that is present in the NT user database.
If the Web Proxy login is permitted, then the authentication name and password used will be further used by Microsoft 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 since 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 then used to determine protocol-specific access permissions.
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:
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_servername where servername is the name of your NT IIS server. As you can see in Figure 6.3, the username which controls access to anonymous logins for my system is "IUSR_CONTROLLER 4.0". 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. 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 still displays a string of 14 asterisks for enhanced security.
Note the TCP Port field. This is the field for indicating which TCP port the WWW server listens to. This also affects which port Microsoft 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 example, 81) for network traffic. Another WWW server can be installed to listen to the traditional port of 80. Proxy clients on the LAN can configure their software to talk to port 81, leaving the other web server to handle 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.
The WWW service supports three forms of login access. Any single one of these forms can apply, or all three can be used simultaneously.
Obviously the WWW service itself is designed to field access requests from the outside Internet, and Microsoft 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 dialup link just as it can over twisted pair cable.
Microsoft 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, Microsoft 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 form of communication between a newsgroup server and a newsgroup reader. By convention, this communication is carried out over TCP port 119. Microsoft 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. Microsoft 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 Microsoft Proxy Server until the administrator does some reconfiguring. The following configuration information will cover the basic steps needed, but Chapter eight covers the in-depth issues associated with Microsoft Proxy Server security.
The first thing to do is open up the Web Proxy server configuration dialog box. To do this, follow these steps:
Conforming to the new 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 descriptions of the purpose of each tab.
To select a tab just click on it.
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.
At the bottom of this tab is a button for viewing online sessions to the Web Proxy server. Click this button to view current sessions. Figure 6.5 shows the view current sessions dialog box.
This dialog box shows the name of the user connected, the IP address that user comes from, and how long that user has been online. The username will be anonymous if no authentication information has been exchanged between the client and Microsoft 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.
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. Figure 6.6 shows the LAT editor.
You can make changes to the LAT in the same manner as when Microsoft Proxy Server was installed. If you need help with editing the LAT, refer to Chapter five, "Installing Proxy Server."
The Construct Table button in the LAT editor will call up another dialog box shown in Figure 6.7.
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 five covers the details of configuring this dialog box when installing Microsoft Proxy Server.
Note that the dialog box shows the RAS connection of my NT server as a valid network interface (it's greyed out near the bottom of the dialog box). If you have a static IP for your network connection to an ISP, that 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 affect.
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 configuration elements are in the mix. Figure 6.8 shows the Permissions tab.
The Enable Access Control check box turns on and off all forms of access restrictions. When not checked, the Web Proxy will permit any connections, regardless of the credentials of the client needing access. When checked, the permissions settings set will 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. The display area shows which NT users or groups have permission to use the indicated protocol. The display area currently shows Everyone as having access. If you do not have a need for fancy 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 up to unlimited access. Your Administrator group should be assigned to the Unlimited Access protocol. This will ensure that users with administrator privileges will not be hampered in any way.
Clicking the Add button will allow you to select NT users or groups who should have permission to use the protocol. Figure 6.9 shows the Add Users and Groups dialog box.
If the current domain is in a trust relationship with another domain, you will 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 Microsoft Proxy Server.
To add a user or group to the permission list for the protocol, follow these steps:
The Show Members button will allow 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 will allow you to search for a user, or a group within the current domain or selected domains, which is able to be contacted from the current domain. Multiple domains can be searched simultaneously. On large networks, this is a handy feature to have. Domains must be in a trust relationship before groups and users can be shared between them.
Back on the main Permission tab, the Remove button will remove 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 Web Proxy service can cache objects which 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 Microsoft 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 object not expired or object unchanged on serve). This reduces the amount of external traffic Microsoft Proxy Server has to maintain. The Web Proxy cache settings are controlled through this tab shown in Figure 6.10.
Caching can be turned on and off through the Enable Caching check box. Turning the cache off does not mean that Microsoft Proxy Server will not serve out cached objects to clients. It means that it will not actively store any new incoming objects into the cache.
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:
When the slider is to the left, Microsoft Proxy Server almost always retrieves a new copy of an object, whenever it is requested by a client. When the slider is to the right, objects will be considered fresh for longer periods. To reduce the amount of Internet traffic LAN users create, set this slider all the way to the right.
Active caching causes Microsoft Proxy Server to go out to the Internet and retrieve a fresh copy of an object all on its own 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. Microsoft Proxy Server does not need to be restarted for any alteration in the active caching policy to take affect.
When set to the left, the slider caches objects more actively. The active caching implementation is controlled by an advanced algorithm that factors in such elements as object popularity and Microsoft Proxy Server peak access times. When the algorithm determines it to be the correct time to update an object based on the factors, Microsoft Proxy Server will freshen the object from the Internet. When the slider is to the right, active caching occurs less frequently and the Internet connection is not crowded with Microsoft Proxy Server caching activity.
Microsoft Proxy Server cache should be at least 100 megs plus 1/2 meg 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 Change Cache Size to modify where the cache directories are and how large they should be. Figure 6.11 shows this dialog box:
By default, Microsoft Proxy Server sets up five directories to store cache data in. These cache directories are set up under the URLCACHE directory (they are named DIR1, DIR2, DIR3, DIR4 and DIR5). The reason Microsoft Proxy Server uses multiple cache directories is to speed up access of objects. When a single large cache directory is used, searching the directory for the right object 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 sub directories 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 will take affect. Microsoft Proxy Server does not have to be restarted for any cache change to take affect. Chapter 12, "Controlling the Proxy Server Cache," covers the Web Proxy cache in greater detail.
The Advanced button on the Proxy Service Properties dialog box allows you to control elements, such as what protocols are cached, the maximum size of objects that should be cached, and filtering sites so their objects are not cached. In Microsoft Proxy Server's current version, only WWW objects are cached and so the ability to enable caching of FTP and Gopher objects is not available. Figure 6.12 shows the Advanced Cache Settings dialog box.
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 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 Microsoft 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 Microsoft Proxy Server will return objects in the cache if the target site is currently unreachable, but the object's TTL has expired. This allows Microsoft 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 the 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 you might have configured in Microsoft 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.
www.microsoft.com might be set as a never cache site, but the specific path www.microsoft.com/sitebuilders 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 as well. 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. This is shown in Figure 6.13.
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 manner as adding a new site policy.
Microsoft Proxy Server keeps a very good record of who uses the Web Proxy or WinSock Proxy services and just exactly what sites they access. By default, Microsoft Proxy Server logs data in a straight text format. Log files are stored in the \WINNT\SYSTEM32\PROXYLOGS 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 file names are iaYYMMDD.LOG where YY is the year, MM is the month and DD is the day. Figure 6.14 shows the Logging tab.
The following is a description of each element on this tab:
Microsoft Proxy Server can log to a text file or an SQL or ODBC database, provided that such services are present on the network. Checking the Log to File check box tells Microsoft 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 Microsoft Proxy Server how often to begin a new log file. If you have little Microsoft 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 Microsoft Proxy Server, it will generate an error line for each bad attempt the client makes. Some of the log files on my own network have reached 250+ megs in a single night, 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 Microsoft 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 checked, Microsoft 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 Microsoft Proxy Server to use when attempting to save data in a database format. During installation, Microsoft Proxy Server can install several types of current ODBC drivers. These drivers will allow Microsoft Proxy Server to interface with associated database engines for saving log information in the database engine's own format.
A SQL server is an NT databasing service that can provide database functions to client workstations. SQL server is similar to Microsoft Proxy Server in that it is a stand alone engine that provides a service to clients. Clients must have appropriate access to utilize the services the server has to offer. SQL server does not have to be running on the same machine as Microsoft Proxy Server. Microsoft 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:
Once the SQL/ODBC logging fields have been completed, Microsoft Proxy Server will immediately begin logging to the indicated database table. The service does not have to be restarted.
Setting filters for controlling which sites can or cannot be accessed is a straightforward process. By default, Microsoft Proxy Server does not filter which sites users have access to. Figure 6.15 shows the Filters tab.
To begin the filter assignments, you must determine what approach you will need to take. If you only want to allow LAN users to access a handful of sites on the Internet, all access to all sites should be denied. If you want to deny access to certain sites, but leave the rest of the Internet accessible, all sites should be granted access by default. Click the appropriate radio button for the default permission.
Once you have determined the default permission for sites, you can begin to set the exceptions to that rule. In Figure 6.15, the default shown is to permit access to all sites. As you can see, the only exception is the domain netscape.com. Exceptions can be indicated as single computers designated by IP address, groups or computers designated by IP address, or entire domains such as netscape.com. Choose the Add or Edit buttons to add a new exception or edit an existing one. Figure 6.16 shows the Add(Edit) dialog box.
Exceptions can be indicated in the following manners:
Once you have set all necessary options, click OK to return to the Filters tab. The Edit button can be used to change an existing entry, and the Remove button can be used to remove an entry from the filter list.
Filtering can be very useful and is the one of the major advantages using Microsoft Proxy Server has over giving all workstations on a LAN full access to the Internet on their own. Let's face it, there are a lot of distractions on the Internet and LAN users have a tendency to be easily lured away from their jobs.
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 these 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:
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 though, administrators can define support for new protocols which do not come pre-configured in the WinSock Proxy server. Remember that nearly any Internet application can communicate with the WinSock Proxy server. The WinSock Proxy client software is responsible for listening to local port requests, and then 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 were directly connected to the Internet.
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 commonly used client Internet applications running correctly.
To open the WinSock Proxy configuration, do the following:
The WinSock Proxy Permissions tab looks considerably different than the Web Proxy Permissions tab. Figure 6.17 shows the WinSock Proxy 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 then click the Add button. A dialog box will pop up which looks identical to the one shown in Figure 6.9 . 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, say a protocol had 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 could then select a protocol (or group of protocols with the multiple select method again) and then click OK. The selected groups and users would then be 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 allows you to modify existing protocols or create new protocols that the WinSock Proxy server will support. Figure 6.18 shows the Protocols 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.
In the following paragraphs, I give a quick overview of how to install support for an new protocol. The Internet application I use as an example is Kali for Windows 95. For those of you who are not familiar with Kali95, it's an applications which allows IPX network games such as Descent, Command and Conquer, and Mech Warrior II to be played over the Internet as though the remote players were actually on the local LAN. (Yes, I am truly a geek and spend way too much time on the Internet.)
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 will 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 they will instruct the server 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. Kali95 uses UDP packets and initiates communication with Kali servers over port 2213. It expects a return channel from the server over a dynamically established port (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:
The process isn't too difficult to follow. The WinSock Proxy server acts as the middle man. It pretends to be the target server when talking to Kali95, and it pretends to be Kali95 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. Figure 6.19 shows the dialog box that opens.
The following is a definition of each element on the Protocol Definition dialog box.
Once you have the basics configured, next you will need to add information about how subsequent connections from the target server back to the client application will be made. With Kali95, we 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 dialog box shown in Figure 6.20.
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 Kali95 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 will need to know which ports the client application will be 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 will need to set. For most protocols you will configuring, you can set all subsequent connections for any valid port. I have tested Kali95 under Microsoft Proxy Server, and once I got a hold of the release copy (of MPS), Kali95 worked like a charm.
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.
More than one Microsoft Proxy Server gateway can be used on a network. The Web Proxy and WinSock Proxy servers behave differently in a network environment where more than one Microsoft Proxy Server is used.
Clients can access multiple Web Proxy servers in a cascading fashion. Web Proxy servers can be groups 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 hand out name resolution functionality.
All Web Proxy servers can be grouped 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.
Setting up a fully functional DNS server is a pretty hefty task. Entire books have been dedicated to this topic alone. If you feel you need to use DNS over WINS (which you shouldn't need to do on a Microsoft NT-based network since WINS performs all major functions of DNS as well as some other handy functions) I suggest you grab a good UNIX book and be prepared to read it for a month or two. The NT 4.0 DNS server functions in nearly the same way as a UNIX DNS server. Much, if not all, of the information you can get from a UNIX DNS book will be directly applicable to NT DNS configuration.
Under a WINS environment, a multi-homed static database entry is created to list all of the Microsoft Proxy Servers. The WINS server chooses a representative from this list in a fashion which is different than 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 Microsoft Proxy Server from the list that has the same subnet as the client. Failing to do that, the WINS server then attempts to locate a Microsoft 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.
Consult NT's online help system for more information on how to set up a DNS Internet group, or how to set up a multi-homes group under WINS. Chapter nine, "Concepts and Realities of Name Resolution with Proxy Server," also covers issues relating to name resolution in a Microsoft Proxy Server environment.
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 Internet applications running through the same connection by other network users to a stand still. Chapter four, "Planning Your Installation and Configuration," covers details on how to best arrange your network to provide the most performance possible.
Hopefully, this chapter gives you all the configuration help you need to get your Microsoft Proxy Server(s) up and running. This chapter also gives you a clear understanding of the separation between the Web Proxy server and the WinSock Proxy server. Once Microsoft Proxy Server is initially configured, very little if any daily maintenance is needed to keep it running smoothly.