----- Original Message -----
Sent: Wednesday, June 02, 2004 10:32
PM
Subject: RE: [ActiveDir] Group Policy at
the Site Level With Remote VPN Us ers - Wrong Site Applied
Darren - Thanks very much for your suggestion. It didn't solve the
issue, but it did provide some keywords that helped in further Google
searches.
Part
of the cause ended up being discarding of large ICMP packets by our Cisco VPN
Concentrator. In preparation for processing Group Policy, workstations send a
series of ping packets to a domain controller that have payloads of both
0 and 2048 bytes. The 0 byte packets got through fine, but the 2048 byte
packets got dropped because they are larger than the MTU and are thus
fragmented. These pings are used to determine if you have a slow link or fast
link. Enabling fragmented packets to pass the VPN Concentrator did the trick,
and now Site GPs are being applied along with other GPs.
I
still have no clue why the GP processing ended up pulling the logon script
from a different site. My suspicion is that the slow link processing code
doesn't know how to cleanly deal with failed responses from only some of the
ping packets. Whoever coded this section may have assumed that either all
would succeed and return a response time value or none would succeed. This is
only speculation because the Userenv.log file didn't reflect any
processing of group policy even though it clearly had
occurred.
When
I have a few minutes I plan on submitting a detailed write-up to MyITForum so
that others will hopefully benefit from our research. Even knowing most of the
answers I couldn't find anything covering this situation in the KB articles.
Thanks again!
Jeff
Jeff-
It's hard to say what is going on here. Group Policy uses whatever site
information is cached on the workstation to determine which site-linked GPOs
to process. In other words, the issue is that when this machine connects to
the corp. network, it is not following the normal site affinity process to
locate a DC to authenticate with. Given the random nature of what you're
seeing, I suspect this means that the workstation's subnet is not being
correctly associated with a site, and so its querying any available DC.
I would check the registry under
HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\DynamicSiteName
to see what site is being cached there after you VPN into the network.
This could be a timing issue where the site information is not correctly
populated on the workstation by the time GPO processing cycle kicks off.
-----Original Message-----
From:
[EMAIL PROTECTED] on behalf of Jeff Salisbury
Sent: Fri 5/28/2004 2:51 PM
To:
'[EMAIL PROTECTED]'
Cc:
Subject:
[ActiveDir] Group Policy at the Site Level With Remote VPN Users - Wrong
Site Applied
We have our logon scripts in GPOs tied to AD Sites in our
Win2K domain, with each site having its own GPO that calls a script
tailored to the locally available file shares. This has worked exceedingly
well, until...
Based on some great input from another list reader
we started testing a feature in the Cisco VPN Client that forces a user to
log off his/her system as soon as the VPN is established. When the user
logs back on to the machine then she/he is authenticating with the domain.
We want this functionality so that the cached copy of the user's password
is updated if he/she changed it recently, and so that the user's logon
script runs to map drives, check A-V signatures, etc.
When I tried
this from my home network (192.168.2.0/24) I connected to our corporate
network in L.A. (Compton) and my notebook was assigned an IP address from
the L.A. facility's internal network (172.16.0.0/21), which is the IP
subnet associated with the Compton-Site in AD. After the logoff, I would
have expected the Compton-Site logon script to run and map my drives.
Instead, Group Policy was applied from a domain controller in Shanghai
China (172.16.56.0/22) and my drives were mapped by their logon script to
their servers. My colleague had a similar experience, except that he
received policy from and was mapped to drives in the Singapore AD Site
(172.16.48.0/22).
I ran GPResult to see if I could figure out what
was happening:
RSOP results for BELKIN\<my user name> on
<my machine name> : Logging
Mode
------------------------------------------------------------
OS
Type:
Microsoft Windows XP Professional
OS
Configuration:
Member Workstation
OS
Version:
5.1.2600
Domain
Name:
BELKIN
Domain
Type:
Windows 2000
Site
Name:
compton-site <-- This is what I expected
Roaming
Profile:
Local
Profile:
C:\Documents and Settings\<my user name>
Connected over a slow
link?: No
COMPUTER
SETTINGS
------------------
CN=<my machine
name>,OU=Notebooks,OU=Compton,OU=US,OU=NA,DC=belkin,DC=com
Last time Group Policy was applied: 5/27/2004 at 9:18:37
PM
Group Policy was applied
from: shanghai.belkin.com <-- This
DC is in the Shanghai China Site!
Group Policy slow
link threshold: 500 kbps
Applied
Group Policy Objects
-----------------------------
Default Domain Policy
Local
Group Policy
The following GPOs were not applied
because they were filtered out
-------------------------------------------------------------------
Shanghai Site Logon Scripts <- There are not logon
scripts tied to the
computer
Filtering: Not Applied (Empty)
The
computer is a part of the following security groups:
--------------------------------------------------------
<SNIP>
USER SETTINGS
--------------
CN=<my user name>,OU=Information
Services,OU=Compton,OU=US,OU=NA,DC=belkin,DC=com
Last time Group Policy was applied: 5/27/2004 at 9:20:20
PM
Group Policy was applied
from: shanghai.belkin.com <-- This
DC is in the Shanghai China Site!
Group Policy slow
link threshold: 500 kbps
Applied
Group Policy Objects
-----------------------------
Default Domain Policy
Shanghai Site Logon Scripts <- Here is what mapped the
drives to Shanghai servers
The following GPOs
were not applied because they were filtered out
-------------------------------------------------------------------
Local Group
Policy
Filtering: Not Applied (Empty)
The user is
a part of the following security groups:
----------------------------------------------------
<SNIP>
I looked through Jeremy Moskowitz's great book (Group
Policy, Profiles, and Intellimirror) and on his web site
(www.gpanswers.com), but I can't find any reference to this mystery. My
understanding is that the notebook's IP address would determine what
Site's GP is applied. If the internal address assigned by VPN is used,
then it should apply the Compton-Site policy. It looks like it DID
determine that I was in the Compton site, but went off and pulled/applied
GP from a different site. I have verified that the sites in AD have the
correct subnets assigned to them, with no overlap.
Has anyone else
seen this happen or see what I am missing? Thanks!
Jeff
Salisbury
Network Infrastructure and Security Manager
Belkin
Corporation
Information Services
310 604-2061
310 604-2022
fax
www.belkin.com
Confidential
This e-mail and any files
transmitted with it are the property
of Belkin Corporation and/or its
affiliates, are confidential,
and are intended solely for the use of
the individual or
entity to whom this e-mail is addressed. If you
are not one
of the named recipients or otherwise have reason to
believe
that you have received this e-mail in error, please notify
the
sender and delete this message immediately from your
computer.
Any other use, retention, dissemination, forwarding,
printing
or copying of this e-mail is strictly prohibited.
List
info : http://www.activedir.org/mail_list.htm
List
FAQ : http://www.activedir.org/list_faq.htm
List
archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
Confidential
This e-mail and any files transmitted
with it are the property
of Belkin Corporation and/or its affiliates, are
confidential,
and are intended solely for the use of the individual
or
entity to whom this e-mail is addressed. If you are not one
of
the named recipients or otherwise have reason to believe
that you have
received this e-mail in error, please notify the
sender and delete this
message immediately from your computer.
Any other use, retention,
dissemination, forwarding, printing
or copying of this e-mail is strictly
prohibited.
