The methods with which client applications gain access to both sides of Microsoft Proxy Server (the Web Proxy and the WinSock Proxy) can be difficult to understand if you are not familiar with network security models. This chapter details how clients gain authentication when attempting to use Microsoft Proxy Server services. Both the Web Proxy server and the WinSock Proxy server are discussed independently because security is handled differently by each server.
When any entity on a network attempts to access a secured resource, they must present the right credential to the controller of that resource before access will be permitted. This includes access to network printers, shared directories, and server services such as Microsoft Proxy Server. Presentation of credentials can be a very subtle process, completely hidden from the user requiring no user interaction, or it can be a totally interactive process where the network user must indicate a valid username, password, and (in the case of NT based networks) the network domain which to present the credentials to. Netware-based networks with Netware Directory Services are similar in nature to NT-based domains in that there is an overriding authority for servers called the Tree. For security discussion in this chapter, I focus only on NT-based networks.
The two halves of Microsoft Proxy Server can be set to follow security settings, or they can be set to ignore security settings and permit any access from any client regardless of what credentials they might try to present. In fact, when no security is used by Microsoft Proxy Server, no credentials will be demanded from clients.
When a user starts a Windows machine (Windows for Workgroups, Windows 95, or Windows NT), if the system is configured correctly, Windows will prompt the user for logon information. Logon information can be obtained through a standard Windows logon or by a domain logon. Of the two logon methods, a domain logon is by far the most secure and useful in a complete network environment.
Windows 95 workstations can be set to perform a standard Windows Logon through the Network Control Panel. By default, when a network card is present in a Windows 95 computer, all available network clients will be installed. This includes the Microsoft Network client and the default Novell Netware client. For this chapter, the Novell Netware client will be ignored. The Windows 95 operating system requires the installation of special network client software if the workstation will be accessing servers of that network type. A standard Windows Logon will not be sufficient to gain access to secured NT servers. The Microsoft Network client must be installed before Windows 95 will be able to present credentials to an NT server in the correct format.
Setting a Windows 95 computer to perform only a standard Windows Logon without the presence of the Microsoft Network client will only provide local machine security. Access to NT servers that are part of a domain will not be possible. Access to any Windows workgroup server won't be possible either. The Microsoft Network client controls network access to all Microsoft-based servers. Figure 8.1 shows the configuration area for controlling the logon method used by a Windows 95 machine.
However, a Windows workstation can be set to perform a standard Windows Logon and still have access to network resources when the Microsoft Network client is present. When a standard Windows Logon occurs, a network user is presented with a logon dialog box that asks for username and password. Once entered, Windows checks for the presence of a password list of the given name. If found, the password the user has given will be checked against the stored (and encrypted) password in the password list file. If the two match, Windows permits the logon and the user continues into the operating system. If the two passwords do not match, windows will prompt the user again for a new password (or the user can enter a new username and password). If there is no password list for the username given, Windows prompts for confirmation of the given password and a new password list is created.
Note that this logon process does not involve in anyway authentication by a central security agent like an NT domain controller. After a user logs in with a standard Windows logon, the user is still unknown to the network. Only when the user attempts to access a secured network resource will the workstation be forced to present the logon credentials to the security agent requiring them. However, if the Microsoft Network client is configured to perform a domain logon, immediate network authentication will be attempted (to the default domain indicated in Microsoft Network client properties) using the username and password given at the Windows Logon dialog box. If the name and password given at the Windows Logon dialog box are not valid in the default domain, a second domain logon dialog box will be presented requiring a valid domain username and password. This means that to Windows, a user can be known as two (or even more) identities. To Windows itself, the user is known by his or her Windows logon. To NT servers, the user will be known by the network credentials he has presented (or the credentials that were automatically presented). If Novell Netware servers are participating on the network, a user may be known by a third identity, that of his Netware logon.
If a Windows Logon is used as the primary logon, all subsequent client logon credentials can be stored in the password list created by Windows. This means that subsequent logons will proceed without the user needing to enter a username and password for each network client installed in Windows. Changing secondary network client passwords can be done through the Password icon in Control Panel, or the password list can be deleted and the logon process can be redone (this approach is often the easiest way of changing a password for a secondary client).
If a standard Windows Logon is used, but the Microsoft Network client is set not to log on to a domain, no immediate network authentication is performed. Network authentication will be done when a network resource is accessed (for example, attempting to view a resource list of an NT server listed in the Network Neighborhood). When this is the case, the password list will be consulted for domain logon information. If none is found, the current Windows logon name and password will be presented to a domain controller in the domain of the server being accessed. If the Windows logon username and password are not valid in the domain being consulted, permission to access resources in that domain will not be granted and the user will not be prompted to enter new credentials.
A standard Windows Logon is very low in security because the password list files can easily be deleted or modified on the local machine. For a more advanced security model, a domain based logon must be performed.
The second type of Windows logon that can be performed is known as a domain based logon. This type of logon is similar to a standard Windows logon except that the credentials entered by the user will be immediately presented to an NT domain controller for authentication. The logon dialog box is nearly the same except that an additional field for indicating the logon domain is present.
In order for this type of logon to be used, the Microsoft Network client must be selected as the Primary Network Logon. Setting the Microsoft Network client as the primary network logon is not the only configuration that needs to be done. Further network configuration to indicate a domain logon should be performed. Once the primary network logon has been set to Microsoft Network client, the properties for the Microsoft Network client need to be altered. This is done by highlighting the Microsoft Network client entry in the components list and then clicking the properties button. Figure 8.2 shows the Microsoft Network client properties dialog box.
As you can see, the settings for controlling domain logon and the domain to log on to are clear. Once the Log on to Windows NT Domain check box is checked and a domain name is given, all logons from that machine will be authenticated by a controller in the indicated domain. This will provide immediate network authentication. Network authentication is what Microsoft Proxy Server needs (most of the time) for it own validation purposes.
When a domain logon is performed at startup, a password list will be created for the user logging on to the system. This is done in case a domain controller cannot be found in the future. This permits a user to log on to a Windows machine based on the validation data contained in the password list, even when a domain controller cannot be found (for example, when the network is down). In this logon scenario, the Windows logon name and password will match the domain logon name and password. When a standard Windows logon is performed first, the logon information between the Windows logon and the domain logon may be different.
"Enough of your babble," I hear you say. What does it all mean? I agree, trying to keep track of how the logon process works can get very confusing. The easiest way of setting a Windows machine to logon to a network is to set it to perform a domain logon. This will provide the highest security and immediate network authentication. This approach necessitates that a domain controller be present somewhere on the network to field all logon attempts.
If your network does not contain any domain controllers, you will need to set workstations to perform standard Windows logons, but this necessitates the logon information be unverifiably correct. When I say unverifiable, I mean that a user can log on with bogus credentials and will never know it until they attempt to access a network resource and get an access denied error. However, problems other than bad username and password can cause access denied errors, and troubleshooting this error without a central domain authority can be a real hassle.
When there is no central domain authority for a network workgroup, each NT server on the network is an island which follows its own security database. Usernames and passwords configured on NT servers that are set up as workgroup machines are not shared among other NT servers even when those servers are members of the same workgroup. When a user attempts to access an NT workgroup server, the workstations present network credentials directly to that server. That server permits or denies access to the requested resource or service based on its own security database.
As long as the username and password are valid for a domain resource that a network user is attempting to access, permission will be granted. This means that if a user gains validation in one domain, and his credentials are valid in another domain, access to the second domain will be permitted. This process of having parallel accounts in multiple domains is difficult to manage from a network administrator point of view, but it does overcome certain difficulties.
Another arrangement known as a Trust relationship can be established between two or more domains to allow users from one domain to have access to resources in another. If your network is such that it has multiple domains, you should read up on the benefits of creating Trusts between domains for the purpose of allowing users access to both domain resources.
Simply put, when deciding what the best logon method is, use a domain logon when a domain controller is present and use a standard Windows logon when a domain controller is not present. For standard Windows logons, be sure that the logon information used by network users is correct for the servers they will need to access. Multiple simultaneous workgroup logons are not supported under Windows, so parallel accounts must exist on all workgroup servers that network users must access.
Now that you have an understanding of how a network user is known on a network, let's proceed to discussing how the Web Proxy side of Microsoft Proxy Server grants or denies access to its services. The first element of the Web Proxy that needs to be covered is how it accepts authentication requests.
Remember that the Web Proxy is a fully CERN compliant HTTP proxy and as such can be accessed by operating systems other than Windows. Any operating system that supports the TCP/IP protocol can run applications that can talk to the Microsoft Proxy Server Web Proxy. This being the case, the Web Proxy has to have a way of finding out who is attempting to access its services when the standard Windows network security layer is not usable.
The WWW Service is the actual security controlling mechanism used by the Web Proxy. Because the Web Proxy runs as a sub service of the WWW Service, the security mechanisms configured in the WWW Service also apply to the Web Proxy service. The Service tab of the WWW Service properties contains the configuration elements that control which security mechanisms are permitted. This is shown in Figure 8.3.
The Password Authentication portion of this tab contains the configuration for the permitted security mechanisms. There are three forms of security negotiation that the WWW Service (and therefore the WWW Proxy) can perform. These security methods are:
Checking each security method enables it. The following sections discuss each security method in detail.
If the Anonymous security method is enabled, any client can have access to the WWW Proxy service without providing a valid username and password that can be found in the NT security database. Most practiced Internet users know what anonymous access involves. Generally, anonymous access is gained by entering a username of "anonymous" at a username prompt, and then entering an e-mail address as the password. When Anonymous security is enabled, all non-Windows clients will access the WWW Service and the Web Proxy Server as anonymous clients. This will override Basic security.
When Anonymous security is enabled, clients will never see an authentication dialog box pop up in their browser or FTP client when attempting to access the Web Proxy. For Web Proxy anonymous access, no username or password will be required. This is unlike standard anonymous FTP access when a user is prompted to enter a name of "Anonymous" and an e-mail address as a password.
If your goal is to allow all of your network users unlimited access to the Web Proxy, allowing only Anonymous security is not the best approach. The Anonymous security mechanism is mainly to be used with the actual WWW Service itself and not with the Web Proxy server. This is a double-edged sword that Microsoft has created. On the one hand, if your NT server runs the WWW service along side of the Web Proxy for external Internet users, you will want to enable Anonymous security so that external Internet users are not required to enter a name and password to access your Internet site. However, enabling Anonymous security opens up the Web Proxy to any non-Windows network client wanting external Internet access. It's a very bad paradox that I hope Microsoft will fix in the near future.
There are other ways of permitting any valid network user access to any protocol supported by the Web Proxy without enabling Anonymous security. These security issues will be discussed later in this chapter. It's a tough decision to make. Enable Anonymous security if you have no need to control internal access to the Web Proxy and want external Internet users to freely access your web site. Disable Anonymous access if you want to control internal access to the Web Proxy, but require external Internet users to provide a valid username and password. For Web Proxy control, I suggest you disable Anonymous access.
When this form of security is enabled, clients can pass their credentials to the Web Proxy via a low-level encryption method. This is done in a very simplistic encoding format that can be easily intercepted and decoded by devoted hackers. However, it is the only form of authentication available to non-Windows clients.
When Windows clients access the Web Proxy server with a browser such as Netscape or Internet Explorer, and Basic security is the only security enabled, an authentication dialog box will pop up and allow you to enter a username and password. Figure 8.4 shows the proxy authentication dialog box that Internet Explorer presents.
This name and password combination will be checked against the NT user security database for authentication. Microsoft Proxy Server is the service which initiates the authentication request to the system. Once the user has been validated, the Web Proxy will consult its own security configuration to find out what protocols the user has access to. Remember that once a user has been authenticated, Microsoft Proxy Server will know what NT security groups the user has access to. This means that clients under other operating systems, such as Macintosh, will also be able to use Basic security to gain access to the Web Proxy even though they might not have a full Microsoft Network client connection to the NT server running Microsoft Proxy Server. Figure 8.5 shows the proxy authentication dialog box presented by Netscape on the Mac.
The current versions of Netscape are only capable of performing Basic proxy authentication. Credentials submitted through a Basic security connection will be checked against either the current NT user database, in the case of a stand alone NT server, or the domain security database, in the case of a NT server participating in a domain. Users can submit credentials from another domain on the username line by entering the username as something like:
wolfe\"david wolfe"
The first part of the name is the reference to the domain to check, and the portion after the \ refers to the account name. Double quotes are needed when the account name contains a space. Referencing an account in an external domain requires a trust between the current domain and external domain. Microsoft Proxy Server does not have the ability to pass authentication requests to another domain, unless the authentication name contains a reference to where the credentials should be presented. A trust relationship must exist between the two domains in order for the client to be granted access.
This is the highest form of authentication that The Web Proxy can perform. It is only available between clients that support NT Challenge/Response and the Web Proxy. This is a proprietary Microsoft form of authentication and is used by standard Windows workstations and NT servers. The only current client that supports NT Challenge/Response is Internet Explorer. Understand that all authentication discussed in this chapter is negotiated between Internet client and Microsoft Proxy Server. At no time is the operating system itself performing any negotiation with Microsoft Proxy Server. An Internet client may be able to draw on existing logon information, but the client itself is passing the information to Microsoft Proxy Server and receiving its responses. It is for this reason that the client application must support NT Challenge/Response in order to utilize its advanced security. The current versions of Netscape (as of the writing of this book) do not support NT Challenge/Response in any way.
This form of authentication utilizes the existing user logon information for validation to the Web Proxy. When a client attempts to access the Web Proxy, it sends a authentication demand back. If NT Challenge/Response is enabled, this is the first authentication form that is demanded. If the client supports NT Challenge/Response it will automatically respond with the current domain logon information that the user present when he first logged in to the Windows operating system. The username and password given during a standard Windows logon will be used if there has not yet been a domain logon.
Clients running on other operating systems can use NT Challenge/Response. It is not a feature that is necessarily embedded in the operating system itself. Obviously, clients running on other operating systems may not yet have any default user information they can automatically send to the Web Proxy. In these cases, the user will be presented with a dialog box for entering username, password, and logon domain. For example, Internet Explorer 2.1 for the Mac attempts to respond with an NT-formatted response when it attempts to access the Web Proxy and NT Challenge/Response is enabled. This is shown in Figure 8.6.
The dialog box is fairly clear. The user is prompted to give a username and password as well as indicate which domain to present the credentials. If the domain is a domain other than the one the Web Proxy is running on, a trust must exist between the other domain and the Web Proxy domain or access will be denied even if the credentials are valid on the other domain. Unfortunately, Internet Explorer 2.1 for the Mac does not fully support NT Challenge/Response. Attempting to access the Web Proxy with Internet Explorer 2.1 through NT Challenge/Response will produce the dialog box shown in Figure 8.7.
At present, Internet Explorer 3.0 for the Mac is available in beta form, but would not run on the test Mac I had available. Internet Explorer 3.0 for the Mac is supposed to fully support NT Challenge/Response authentication just as the Windows version of IE does. I assume the dialog box demanding credentials is nearly identical to the one shown in Figure 8.6 but I can't be certain of that.
When a network client authenticates to the Web Proxy with NT Challenge/Response, a much higher level of username and password encryption is used. This greatly decreases the chance that an intermediate hacker might steal vital information. Another aspect of NT Challenge/Response is party verification. When the negotiating process is begun during NT Challenge/Response, each side will attempt to prove to the other they are who they say they are. A client that supports NT Challenge/Response will attempt to ensure that the target party requesting logon credentials is a valid server.
If Anonymous and Basic security are enabled, but NT Challenge/Response is disabled, some clients will be permitted anonymous access while others will be required to perform Basic logon to the Web Proxy. Some clients support password-less proxy access. This means that they can talk to a CERN-compliant proxy, but do not recognize the authentication demand the proxy may respond with. In these cases where the client does not initially respond with an acknowledgment of an authentication demand, the Web Proxy will permit the client to continue as an anonymous access. If, however, the client acknowledges the demand response, the client will be required to provide valid logon credentials.
When Anonymous and NT Challenge/Response security are enabled but Basic security is disabled, any client that is not capable of performing NT Challenge/Response authentication will be granted anonymous access to the Web Proxy. Those clients that do support NT Challenge/Response will be required to provide valid logon credentials through NT Challenge/Response.
If you establish an Internet Explorer 3.0 only policy in your company, you can force network users to adhere to the security configuration you create under the Web Proxy. Simply because you enable anonymous logon does not mean that anonymous logons have any rights in the Web Proxy. In order to fully utilize anonymous logons, the permissions for the Web Proxy protocols must be set for anonymous access. This will be covered shortly.
By severely limiting anonymous access to the Web Proxy, you can steer network users to Internet Explorer 3.0 because this browser will be the only one that can give them full proxy access. It will make Netscape useless to network users if Basic security is disabled and anonymous access is severely limited.
When Anonymous security is disabled, but Basic and NT Challenge/Response security are enabled, no anonymous access will be permitted to either the WWW service or the Web Proxy. Clients will have to provide some form of authentication before they will be granted access to the Web Proxy. Obviously, this also passes through to the WWW service, which in most cases is bad. Most network administrators want their web site to be accessible to everyone on the Internet. If you have the luxury of running your Web server from a different machine than the one running Microsoft Proxy Server, this problem is not a factor.
When Internet Information Server (IIS) is first installed, a user account called IUSR_servername is created on the domain or in the local NT user database, if the NT server is a stand alone server. Servername refers to the name of the NT server itself. For example, the account created on my network's primary domain controller was "IUSR_controller 4.0". This user account is the account that controls the level of access given to anonymous logons for all Microsoft Internet server applications.
You'll note that in Figure 8.3, there is a field for entering the password for the anonymous account. Remember that the WWW server and the Web Proxy server actually present authentication requests to the NT security layer as they would any normal user logon. If you have a password assigned to the anonymous account, be sure to indicate that password in this field, or the WWW server and the Web Proxy server will be unable to gain anonymous authentication when necessary. Normally, the anonymous account can have no password assigned to it because it doesn't have rights to normal network resources.
By default, the presence of this account will grant anonymous users access to the WWW service without any further configuration needed. However, this is not true with the Web Proxy and WinSock Proxy services. In order to grant anonymous access to the protocols supported by the Web Proxy or the WinSock Proxy, protocol permissions must be granted to the IUSR_servername account just as permissions for any other network users is granted. This will be covered later in this chapter.
In the current version of Microsoft Proxy Server, only NT Challenge/Response is used between the WinSock Client software and the WinSock Proxy Server. Because the WinSock Client software runs under a Windows based system, the underlying architecture is present for only NT Challenge/Response security negotiation.
In order for WinSock clients to access the WinSock Proxy, special client software must be installed. Client software is available for all flavors of Windows, but no other operating systems are yet supported. NT Challenge/Response authentication is built in to the WinSock client software. The WinSock client software will automatically grab the current username and password from the system logon information and pass it correctly through to the WinSock Proxy when a WinSock client attempts to make external Internet contact.
Two new security DLL files are added to the \WINDOWS and \WINDOWS\SYSTEM directories when the WinSock client software is installed. These files are SECURITY.DLL (\WINDOWS) and SECUR32.DLL (\WINDOWS\SYSTEM). These libraries control WinSock client authentication to the WinSock Proxy server. Without these files, WinSock clients will be unable to access the WinSock Proxy.
One of the best security features of WinSock Proxy is its ability to utilize IPX as the transport protocol from WinSock Proxy to network client. Only the NT server running the WinSock Proxy needs to have the TCP/IP protocol installed (for communicating with the actual Internet). The WinSock Proxy can use the IPX protocol for communicating with actual network clients. This will make absolutely certain that any intrusion attempts into your network stop at the NT server running the WinSock Proxy because the TCP/IP protocol does not extend beyond the server itself.
All of this discussion about how security is handled goes out the window unless Access Control is enabled. On the Permissions tab for both the Web proxy and the WinSock Proxy, you'll note a check box entitled Enable Access Control. When this check box is checked, the permission structure you set for either of the servers will be followed. If this check box is cleared, any user will be granted access to any protocol supported by the respective server.
This does not mean that anyone can log in to the services. The logon security methods defined for the Web Proxy must still be met before access to the actual service itself will be permitted. However, once a successful logon has been performed, no further access restrictions will be applied to the user accessing the service. Obviously, for WinSock Proxy accesses, clients must still meet the NT Challenge/Response logon requirements before being allowed to proceed.
The following sections will give you a step by step definition of how a logon to the Web Proxy server proceeds. This will hopefully give you a better idea of how all of these pieces fit together.
This example of an anonymous logon assumes Netscape Navigator 3.0 will be used to access the outside Internet through the Web Proxy and that anonymous security is the only security method that can be used.
The following example assumes that Netscape Navigator is used and that Basic security is enabled. In this example, all three forms of security can be enabled and since Netscape supports Basic security, it will respond to any Basic authentication demand. The operating system for this example does not matter.
As you can see there are many services involved with a Basic authentication. The NT user database is referenced and then the internal permissions settings of the Web Proxy are applied.
If a client supports NT Challenge/Response authentication, this form of authentication will be used above all others because it is attempted first. In this example, it is assumed that the browser is the Windows 95 version of Internet Explorer 3.0.
If the authentication attempt is originating from a non-Windows operating system, the user will need to provide on-the-fly logon information (username, password and logon domain) when the browser demands credentials.
This process also applies to WinSock clients accessing the Internet through the WinSock Proxy, because the WinSock client software supports NT Challenge/Response authentication.
You can actually see the difference between a Basic logon and an NT Challenge/Response logon by viewing the current sessions through the General tab of the Web Proxy configuration. Figure 8.8 shows the Current Sessions dialog box through the Web Proxy configuration.
The first session listed is a session between a Mac and the Web Proxy server. The client being used is Netscape 3.0 for the Mac. As you can see, the client passed along the logon credentials to the Web Proxy as "david wolfe". Because this name does appear in the NT domain user database, access was granted.
The second session listed is a session that started using Internet Explorer 3.0 from a Windows 95 workstation. The workstation was set to perform a domain logon to the WOLFE domain, and as such the user logged onto that workstation is known to the network as WOLFE\DAVID WOLFE. When Internet Explorer 3.0 was started on this machine, no authentication information was requested because IE was able to draw it from the operating system itself. The information was then passed along to the Web Proxy in the form you see listed in Figure 8.8, and validation was provided by the WOLFE domain controller.
Viewing current sessions doesn't give you a whole lot of detail about what's going on with the Web Proxy, but it is nice to see who is actually using the service. It would be much nicer if the session viewer showed exactly what Internet sites were being accessed and what data was being transferred. This would increase the network administrator's ability to police the Web Proxy and control access to the Internet. Perhaps this will be an added feature to later releases of Microsoft Proxy Server. Currently the network administrator has to go to the log files created by the Web Proxy to find out this type of data.
Once primary authentication has been gained, the user accessing either the Web Proxy or the WinSock Proxy must still have permission to use the requested protocol. The Permissions tabs of both the Web Proxy and the WinSock Proxy are utilized in the exact same manner. Each proxy controls a certain set of protocols. Users and/or groups of users will be granted permission to use these protocols. Unless permissions are configured for the necessary protocols, access will still be denied even if the user trying to gain access presents valid network credentials. Figure 8.9 shows the Permissions tab of the WinSock Proxy.
The supported protocols are listed in the Protocol drop down list. The Figure shows that the NNTP (Network Newsgroup Transport Protocol) is selected. The Add button will allow you to select a user or group of users to grant permission to access this protocol to. Chapter 6, "Configuring Proxy Server," covers the actual process of adding users and groups to the protocol permission list.
There is a special "Protocol" setting you can configure in the WinSock Proxy Permissions that is not present in the Web Proxy. This protocol is the Unlimited Access protocol. Any group assigned to this protocol will be granted access to use all other protocols under the WinSock Proxy. If you do not want to worry about which network users are accessing which protocols, you can add the Everyone group to the Unlimited Access option. This can be dangerous, however, because it opens the WinSock Proxy to nearly any request generated by an external Internet client. It might be a good idea to follow the instructions given in Chapter 7, "Configuring NT Security for an Open Environment," for setting up an NT security group for users who need some form of proxy access. That group can then be added to the Unlimited Access option.
Once you have set the necessary protocol permissions, network users will have the ability to use the two proxy servers to access the outside Internet from their desktops. The last configuration element that needs to be addressed is site filtering.
Site filtering is a process where the Web and WinSock Proxy servers permit or prohibit access to the Internet based on a list of permissible sites. By default, neither the Web Proxy nor the WinSock Proxy will prohibit access to any site on the Internet. This means network users will have free reign to browse where they want. To some companies with small Internet connections, this can pose a substantial problem. The Filters tab on both the Web Proxy and the WinSock Proxy configuration interfaces allows the network administrator to indicate which sites are permitted or denied access.
A general permit or deny filter policy must first be established. If you only want to allow access to a handful of sites on the Internet, it will be easiest to set a general deny filter and then list exceptions to this rule. However, if your users need access to most of the Internet, but you want to make sure they stay off a certain site, you can set a general permit policy and then list exceptions to that rule. Figure 8.10 shows the Filters tab of the WinSock Proxy.
The figure shows that a general deny policy has been set and that users will only be granted access to sites within the netscape.com and microsoft.com domains. Chapter 6 covers the details of how to establish the actual filter settings.
Unfortunately, the current version of Microsoft Proxy Server does not have the ability to perform site filtering for individual users. If you have only a few problem users, you cannot as of yet filter their access. The filter settings made on the Filters tab in the Web Proxy and the WinSock Proxy apply to all proxy users.
To most medium or large companies using Microsoft Proxy Server, the most important feature of the service will be the security and control element. Understanding how this service deals with user authentication and access is essential to maintaining a well-run proxy server. Hopefully, this chapter gives you the information you need to correctly manage all security elements of Microsoft Proxy Server.