Re: ICMP Ping and Group Policy Update

• Previous message: Paul Robichaux: "Re: ICMP Ping and Group Policy Update"
• In reply to: Information Security: "ICMP Ping and Group Policy Update"
• Next in thread: Information Security: "Re: ICMP Ping and Group Policy Update"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date:         Wed, 1 Oct 2003 12:27:17 -0400
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

Information Security wrote:
> In response to Nachi, we blocked ICMP Pings to & from our VPN. However,
> it appears that this also has disabled group policy updates for remote
> VPN users. We ran network traces and saw the ICMP packets, I think
> they're part of the negotiation phase where the server tries to
> determine if the client is on a slow link.
>
> I suspect a lot of networks cranked down on ICMP after Nachi. Can
> anyone else confirm this behavior? Does anyone have a workaround or
> configuration setting to override/bypass this feature?

   This is a known issue that we nailed down a few weeks ago, after we
blocked ICMP in some places internally for the same reasons.

   Here's what's going on and a workaround that allows you to leave a
full ICMP block in place.

   By default, when a client machine (XP or W2K) attempts to connect to
a DC to retrieve group policy information, it first sends a series of
ICMP pings to the DC in order to test connectivity and link speed. If
the ping response takes longer than a certain amount of time then the
client goes into a "slow link" mode.

   If the ping *fails* then the client aborts processing and records
error 1054 in the system log. The text of this message is "Windows
cannot obtain the domain controller name for your computer network. (An
unexpected network error occurred.). Group Policy processing aborted."

   This means that, in environments where ICMP is being blocked, the
client's attempts to ping the DC will not get a response and therefore
it will not update its policies even though the DC is reachable by other
means.

   This "slow link detection" can be disabled via group policy, but how
do we push an updated policy to clients that can't update their group
policy information?? (!)

   The solution to this, other than re-enabling ICMP in some way, is to
set the registry key manually on the clients - which can be done
remotely even if the block is in place. The value you need is named
"GroupPolicyMinTransferRate" and it needs to be set in two separate
places, which are listed below. This value needs to be set to (DWORD)
ZERO to disable slow link detection.

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

   You need to create this value in both locations in order to get
things fully working again. Note the HKEY_CURRENT_USER value - this
can't be set remotely so it's best to modify the HKEY_USERS\.DEFAULT
version and then find some way to make sure that users pick this up.
(perhaps by deleting locally cached profiles?

   Hope this helps.

                                                - Ken Hoover

--
Kenneth J. Hoover <ken.hoover@yale.edu>
Systems Programmer
Yale University ITS AM&T
-----
Wondering as to whether the list is running? The NTBugtraq archives are
updated first before messages are emailed to subscribers. Check the
archives first to see if you have missed any messages;
http://www.ntbugtraq.com/archives
-----

• Previous message: Paul Robichaux: "Re: ICMP Ping and Group Policy Update"
• In reply to: Information Security: "ICMP Ping and Group Policy Update"
• Next in thread: Information Security: "Re: ICMP Ping and Group Policy Update"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]