I read Paula Sharick's "Use IPSec to Protect Your LAN Resources" (October 2000), and I found the article informative. However, I have a couple of comments about points the article made that might give someone who's unfamiliar with IP Security (IPSec) the wrong idea.

First, in the section that talks about using Require Security, the author says, "However, if you activate the Client policy on your Win2K workstations, the workstations will never be able to access the legal server because the Secure Server policy accepts only secure connections, and the Client policy never initiates secure connections." This statement isn't correct. If you activate the Client (Respond Only) policy, the workstation will be able to communicate just fine with a server that has the Secure Server (Require Security) policy.

Second, the recommendation to move Triple Data Encryption Standard (3DES) down the list of security methods that are available when the IPSec policy agent negotiates a security association (SA) might result in the use of a weak encryption method when the policy agent completes an SA connection. I don't think that point is clear in the article.

Bjorn Larsson 2/16/2001 12:28:12 PM

A Respond Only client can communicate with a server running Require Security only if the server initiates the connection. When the client initiates a nonsecure connection attempt, the Require Security server will refuse.


As to your second point, I mention in the article that the policy agent offers the algorithms in the order in which they appear in the security methods' preference list. I don't directly state that moving 3DES down the list will make it less likely to be negotiated, but I was trying to make the point that you can eliminate annoying warning messages if you don't need 3DES in the first place.
--Paula Sharick

Paula Sharick 2/16/2001 12:25:39 PM

I don't understand how having client on the WS and SErver on the SErver is a problem. Supposedly since Client won't initiate a secure connection it won't work but yet it will work for NT 4.0 clients that don't initiate a secure connection. I haven't actually tested this but this seems to contradict what I read. I figured that client won't initiated but if asked will connect securely.

So how can you effectively use these built-in policies? Suppose you have a server that publishes active-lawsuit information, and you want to ensure that only known users and computers can access the data. To ensure that other users on the network can't read the data in transit, you need to encrypt all packets that flow to and from the legal server. To secure the server, you can activate the Secure Server policy. However, if you activate the Client policy on your Win2K workstations, the workstations will never be able to access the legal server because the Secure Server policy accepts only secure connections, and the Client policy never initiates secure connections. If you instead activate the Server policy on the workstations, they will request security from the legal server and the server will respond in kind. The Server fallback option also permits workstations to communicate with systems that aren't IPSec-enabled.

Mike Cropsey 1/19/2001 9:14:21 AM

"Use IPSec to Protect Your LAN Resources" (October 2000) includes an error in the byline. Paula Sharick is the author of the article.


In Tricks & Traps: "Daily Answers" (October 2000), the answer to the question about ERD and System State backups contains an error. In the sentence "For all Win2K systems, a System State backup contains a copy of the system Registry hive files (as the ERD does), ...", the parenthetical phrase should be omitted; the Windows 2000 Emergency Repair Disk (ERD) doesn't contain the Registry.


Reader to Reader: "Win95 Systems Logging On to an NT Domain" (October 2000) incorrectly identifies TCP/IP as an example of a NetBEUI protocol. We apologize for any inconvenience these errors might have caused.



OOPS 10/19/2000 3:57:18 PM