If your company is like most, you probably have a group of employees who access their e-mail from outside the office using either Outlook Web Access (OWA) or a Virtual Private Network (VPN) connection.
Therein lies a potential problem: If the machine that a remote user is connecting through were infected with a virus or other type of Trojan, your network could potentially become infected when your employee is connecting. At first this might not seem like a likely situation, but think about it for a second. You have absolutely no control over what your users have on their home machines. It is not uncommon for users to have home machines with old operating systems with no service packs or hot fixes, and no virus protection.
Your network's security should be good enough that if someone were to attach to it through a machine that was outdated and had no virus protection, it wouldn't cause any problems. But do you really want to take that chance?
OWA out-muscles VPN connection
You can consider several steps to protect your Exchange organization against connections from external clients with questionable security. For starters, if you have a choice between using a VPN connection or OWA, I recommend OWA. The reason is because once a VPN connection is established, a user can do anything just as though he was physically connected to the network. There are no port or protocol restrictions in place to protect your network against viruses or Trojans that might exist on the user's machine.
With OWA, on the other hand, the user is connecting to a Web site through HTTP port 80. Other TCP ports might be used for the initial authentication process, but keep in mind that the OWA server has been hardened to protect your network against malicious activity, especially if it is running a front end / back end configuration. A VPN server is also hardened against attacks from the Web, but once a user authenticates into it, your network is no more protected than it would be if the user plugged his PC directly into your network.
New version of quarantine mode coming
I realize that VPNs have their place. Sometimes users need to access more than just Exchange resources, and in such cases a VPN server is the way to go. Fortunately, there is a way to protect your network against VPN connections by machines with questionable configurations.
In Windows Server 2003, Microsoft introduced a new feature called "quarantine mode." Quarantine mode was designed to compare any machine that connected to the network against a predefined security template. If the machine's configuration was secure and up to date, the machine was given access to the network. Otherwise, the machine was quarantined until it could be updated.
If you are wondering why you have never heard about quarantine mode or why you aren't using it, it's probably because quarantine mode is difficult to configure. The good news is that when Microsoft releases its new version of Windows Server 2003, code named R2, quarantine mode will be redesigned to make it easier to implement. The new name for quarantine mode will be Network Access Protection (NAP).
Two variations of NAP will be available: one will work at the VPN level, scanning machines as they attempt to make VPN connections, and the other will operate at the Dynamic Host Configuration Protocol (DHCP) level, and scan machines as they attempt to lease or renew IP addresses.
The basic idea behind how either flavor of NAP works is that each client runs an agent that's specifically designed to communicate with NAP. When the client connects to the network, the agent passes a statement of health to the quarantine server. The server then uses a validator component to see if the statement of health is up to par. If it is, then the machine is given access to the network.
If the statement of health is not up to date, then the machine is placed into quarantine mode. This basically means that the machine is placed into a special subnet where it can only access the quarantine server, a DHCP Server, a Domain Name System Server and a Systems Management Server (SMS).
Once the machine is quarantined, it sends a notification to the SMS Server. The SMS Server then pushes the missing items to the client and updates the client's statement of health. The client then once again requests access to the network, and this time receives access since the statement of health is up to date.
This example is actually a little bit over simplified. In the real world, you would probably check the clients based on a number of different criteria such as operating system and service pack level. There is a separate statement of health and a separate validator component for each criterion. The quarantine server must look at the reports from each validator prior to making a decision as to whether or not to allow the machine to be on the network.
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as the CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer he has written for Microsoft, CNET, ZDNet, TechTarget, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at http://www.brienposey.com.
Do you have a useful Exchange tip to share? Submit it to our monthly tip contest and you could win a prize and a spot in our Hall of Fame.
