Re: ICMP Ping and Group Policy Update

• Previous message: Heavner, Charlie: "MS03-040 - potential bug issue"
• Maybe in reply to: Information Security: "ICMP Ping and Group Policy Update"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date:         Tue, 7 Oct 2003 15:53:03 -0700
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

>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.

This may be too late but I encountered and solved the large ping problem
a few months ago. Here is the document I wrote detailing the fix.
-----------------

When running a M$ based network with a central location and numerous
satellite locations, you may encounter a rather nasty problem. Windows
2000's method for locating a domain controller is not exactly flawless.
When a workstation checks connectivity with the DC it first uses a
normal icmp ping. If the normal ping succeeds it then tests the
connection speed with an oversized ping. Specifically the size is
2048k* which puts the total packet size over 2k due to headers. This
isn't a problem when you are on a local network with nothing between you
and the DC but a switch. However, if you are at a satellite location
and you must traverse a VPN to speak to the DC there may be trouble.
Our VPN is operated by Cisco Pix series firewalls. The Pix denies
oversized icmp traffic by default. This functionality is designed to
prevent ye-old ping flood among other things. Because of this behavior
workstations at satellite sites succeed with the first normal ping but
fail on the oversized one. That causes the following error to show up
in the workstation's event log.

Windows cannot obtain the domain controller name for your computer
network. Return value (59).

The userenv.log, which can be found in /winnt/debug/usermode/, will show
you more useful information if you have environment debugging turned on.
To do this add the following key to the workstation's registry.
Key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
NT\CurrentVersion\Winlogon
Value: UserEnvDebugLevel
Value Type: REG_DWORD
Value Data: 10002 (Hex)
The information provided in the userenv.log will show you that the DC is
found and "lost" as described above.

USERENV(b8.27c) 11:51:30:760 ProcessGPOs: Starting computer Group
Policy processing...
USERENV(b8.27c) 11:51:30:760 ProcessGPOs:
USERENV(b8.27c) 11:51:30:760 ProcessGPOs:
USERENV(b8.27c) 11:51:30:760 EnterCriticalPolicySection: Machine
critical
section has been claimed. Handle = 0x288
USERENV(b8.27c) 11:51:30:760 ProcessGPOs: Machine role is 2.
USERENV(b8.27c) 11:51:30:800 PingComputer: First time: 30
USERENV(298.294) 11:51:31:211 LibMain: Process Name:
C:\WINNT\system32\MSTask.exe
USERENV(1f4.2a0) 11:51:31:982 LibMain: Process Name:
C:\WINNT\System32\svchost.exe
USERENV(b8.27c) 11:51:33:629 PingComputer: Second send failed with
11010
USERENV(b8.27c) 11:51:33:652 PingComputer: First time: 60

As you can see, the "second send failed," but the first succeeded.
I discovered two solutions to this problem. The most obvious and best
for my particular situation was to increase the ping size limitation to
3k on the PIX firewalls. A more secure but harder to implement solution
is to add the following two keys to every computer affected by this
problem:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System]
"GroupPolicyMinTransferRate"=dword:00000000

Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System]
"GroupPolicyMinTransferRate"=dword:00000000

These keys tell the workstation to not test the speed of the connection
with the DC. This setting is also available in group-policy; however,
the computers must first have the setting to download the group-policy.
That is commonly known as the chicken and the egg problem. The
complicated part of this problem is that every user on every workstation
must have the user key added. Adding the key to the default user
registry space was not effective. I never put much work into a fully
automated method of distributing these keys. There is a shareware
program called "Multi Remote Registry Change"
(http://www.eytcheson.com/mrrc.htm) that was useful on the short term.
        

-Alex N. Speaks
M$ Network Administrator

As usual, everything in this document is for informational purposes
only, use at your own risk. Any damage you do to your system using my
advice is your own fault. Why can't Americans take responsibility for
their own stupid mistakes? Alex Speaks's views are definitely not the
views of his employer.

-----
Want to reply to the person who sent this message?

This list is configured such that just hitting reply is going to result in
the message coming to the list, not to the individual who sent the message.
This was done to help reduce the number of Out of Office messages posters
received. So if you want to send a reply just to the poster, you''ll have to
copy their email address out of the message and place it in your TO: field.
-----

• Previous message: Heavner, Charlie: "MS03-040 - potential bug issue"
• Maybe in reply to: Information Security: "ICMP Ping and Group Policy Update"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]