5. Determining Which IPsec Policy Is Active
It's possible that IPsec isn't working because incompatible policies have been
assigned to computers on the network. For example, one policy might be trying
to use certificates to authenticate whereas others will accept only shared-key
authentication. There are two ways to determine which IPsec policy currently
holds sway. The first is the IP Security Monitor. The Microsoft Management Console
(MMC) IP Security Monitor snap-in, which Figure
3 shows, replaces the Windows 2000 Ipsecmon.exe utility and can determine
which IPsec policy is active on the current computer.
You can get the same information from the command line by issuing the Netsh command
netsh ipsec dynamic show all | more
which places all the IPsec information on the clipboard. You can then paste
this information into Notepad, as you see in Figure
4. In the text output, you can see that a policy is applied at the local
level (i.e., Client: Respond Only) and through AD (i.e., Server: Request Security).
Once you have this information, you might quickly discover that the reason IPsec
isn't working is that the computer either doesn't have a policy assigned or
has an incompatible policy assigned. After you resolve the policy incompatibilities,
IPsec will probably function correctly.
6. Investigating Kerberos Authentication Problems
Kerberos authentication relies on AD. If a Kerberos problem arises, there's
likely a problem with the computer accounts involved. You might need to reset
the computer account password or re-enable the computer account. If problems
persist, you might need to exempt Kerberos traffic from IPsec on the domain
controller (DC). To do so, issue the command
netsh ipsec dynamic set config ipsecexempt value=0
Win2K permits Kerberos authentication traffic, but Windows 2003 doesn't. This Netsh command forces Windows 2003 to behave like Win2K.
7. Investigating Certificate Authentication Problems
If you're having trouble with certificate-based authentication, you can probably
trace the problem to one of three causes: The certificate isn't installed, the
certificate is expired, or the Certificate Revocation List (CRL) check isn't
completing. The default certificate period for an IPsec certificate is two years,
which is long enough for most organizations to have forgotten about it. Unlike
some other certificate templates, the default IPsec certificate template isn't
configured for auto-enrollment.
The easiest way to determine whether certificates are installed, corrupted,
or expired is to open the local computer's certificate store. The MMC Certificates
snap-in is also the tool that you would use to request a new IPsec certificate.
When you create an MMC Certificates snap-in to examine the expiration date of
the installed IPsec certificate, you need to ensure that you select the Computer
account option, as Figure 5 shows. If
you select the My user account or Service account option, you
won't be able to locate the issued IPsec certificate.
In the long run, the best course of action is to create a new IPsec certificate
template that supports auto-enrollment (a feature that's limited to Windows
2003 Enterprise Edition). IPsec certificates will then be updated automatically,
and no one will have to remember that IPsec certificates expire every two years,
as long as you select the autorenewal option.
When certificates are in use, IPsec checks the CRL to check whether a certificate has been revoked. IPsec allocates a certain amount of time for this check, and it's possible that this window might close before IPsec obtains a result. To disable the CRL check, issue the command
netsh ipsec dynamic set config strongcrlcheck 0
8. Checking Whether Everyone Is Using the Client Policy
Administrators new to IPsec sometimes apply the default Client (Respond Only)
policy to all the computers on the network, then wonder why nothing is being
encrypted. For IPsec policies to come into force, one of the partners needs
a policy that either requests or requires the use of IPsec. If all hosts have
the Client (Respond Only) policy assigned, none of them will request the use
of IPsec. To resolve the problem, try activating one of the server policies
on your computer and running GPU Update.
9. Checking the IKE Log
If all the aforementioned strategies don't help you with your IKE problem, you
might have to take a more detailed route to resolution. At this point, you'll
need advanced knowledge of Internet Security Association and Key Management
Protocol (ISAKMP) RFC 2408 and IKE RFC 2409. You can enable tracing for IKE
negotiations by issuing the command
netsh ipsec dynamic set config ikelogging 1
You can increase the amount of logged information by increasing the ikelogging value to as much as 7 (which logs all possible data). The IKE trace log is located at \%systemroot%\Debug\Oakley.log, and you can use a text editor to view it. Note that the log-file content is dense, and people new to IPsec will probably be quickly out of their depth when trying to read its contents.
Beware Customization
The IPsec policies that ship with Windows 2003 typically work straight out of
the box. Only when you start customizing them to use certificate-based or shared-key
authentication do problems begin to arise. If you do want to modify the way
that IPsec authenticates, you should create a new policy rather than edit an
existing one. As long as you follow that advice, you'll be able to quickly switch
to a working configuration while you investigate any problems that crop up.
End of Article
Prev. page
1
[2]
next page -->
