Re: XPSP2 domain firewall settings

From: Anthony Yates (anthony.spam_at_spammedout.com)
Date: 10/16/05 

Date: Sun, 16 Oct 2005 18:43:24 +0100

I wonder if there is a ping test involved in the determination. For example,
lets say the suffix is abc.com. If I ping abc.com, I will get the IP address
resolved by the DNS on that network. If I am on the right network, I will
get the same network address as the NetworkName in the Group Policy History
registry. However if I am on a different network the DNS reply will be
different. In this case it does not matter if the connection-specific suffix
is blank. XP will use the primary suffix, but still get the same reply from
the DNS. If this is the case, then the algorithm is really "If I ping the
apparent domain, do I get the same network address as the last Group Policy
network address?

"Darren Mar-Elia" <dmanonymous@discussions.microsoft.com> wrote in message
news:O5o%23viP0FHA.736@tk2msftngp13.phx.gbl...
> Yes, this is a toughie. I tried tracing down the answer through the code
> and, man, it is pretty circuitous. Here is what I see empirically. If I
> take my laptop home with me and VPN into my corporate network, I don't get
> the domain profile, even though I am successfully processing GP in the
> background. That's even if I override the connection suffix with my
> corporate DNS name (otherwise I just get the DNS suffix that my ISP gives
> me on my Cable modem connection). I suspect the reason for this is that
> the NetworkName value in GP History in the registry lists an IP address,
> rather than the domain name. Thus the profile logic would say that my last
> GP processed network name is different than my current connection suffix
> and so, sorry, no domain profile. The question I have is, how is the
> network name determined. If I'm on a corporate network, that name becomes
> my AD domain name. If I'm VPN'ing in, its just an IP address, so there
> must be some logic in there that says, if I'm coming over a VPN, then my
> NetworkName is the IP address of the DC I'm hitting rather than the domain
> name.
>
> Here is an interesting test that I just tried. I went ahead manually
> entered the DNS suffix for my connection as the DNS name of my corporate
> AD domain. Then I went into the registry and manually modified the
> NetworkName value in GP History to that same DNS name. Then I did a
> ipconfig /release /renew and voila! The firewall changed from standard to
> domain profile. So apparently it is that easy to override!
>
> Darren
>
> --
> Darren Mar-Elia
> MS-MVP-Windows Server--Group Policy
> Check out http://www.gpoguy.com -- The Windows Group Policy Information
> Hub:
> FAQs, Whitepapers and Utilities for all things Group Policy-related
> Just Released! The new Windows Group Policy Guide from Microsoft Press!!!
> Check it out at http://www.microsoft.com/mspress/books/8763.asp
>
>
> "Anthony Yates" <anthonyDINGyates@airDONGdesk.com> wrote in message
> news:%23gNtlHP0FHA.2752@TK2MSFTNGP12.phx.gbl...
>> Part of the logic makes sense. If I connect to a domain controller to
>> obtain a policy I am on the home network. It does not have to be at
>> startup. The last policy could be a few minutes ago, depending on the
>> policy refresh interval. The next question is, how do I know I am still
>> on the home network. The Network Location Awareness service is listening
>> for any change of network connection, so if it changes I would look at an
>> attribute of the connection to see if I am still on the same network. The
>> problem is, which attribute? IP address range is a bit crude, as I could
>> easily move from one 192.168 range to another. Connection suffix just
>> depends what the DHCP server hands out, if anything.
>>
>> Anthony
>>
>>
>> "Steven L Umbach" <n9rou@nospam-comcast.net> wrote in message
>> news:%23jJ0aLO0FHA.1192@TK2MSFTNGP10.phx.gbl...
>>>I certainly agree that something does not add up. The article mentions
>>>connection-specific DNS suffixes which simply do not exist on most domain
>>>computers that use DHCP option 15. Instead I see the domain name as
>>>primary dns suffix. The other thing that does not add up is that when I
>>>look at the value for
>>>HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Group
>>>Policy\History\NetworkName registry entry I see the network IP that the
>>>computer is on as in 192.168.1.0 in my case. So does that mean that if
>>>the computer detects it is not on my regular network IP that is a
>>>trigger?? I suppose there could be other triggers such as failure to
>>>locate or contact a domain controller [which is pinged during startup]
>>>or authentication failure. Maybe the network IP is used since that would
>>>be determinable earlier in the startup cycle so that the firewall could
>>>be enabled early in the startup cycle. If it is triggered by network IP
>>>alone however the firewall might not be enabled if the computer is
>>>started on another network with the same network IP which is very
>>>possible within the private network addresses. I would also like more
>>>details on how the firewall profile is triggered but as know that is
>>>about the only information I have seen. --- Steve
>>>
>>>
>>>
>>> "Anthony Yates" <anthonyDINGyates@airDONGdesk.com> wrote in message
>>> news:eYW$OEN0FHA.800@TK2MSFTNGP12.phx.gbl...
>>>>I understand the Cable Guy article and the process described below.
>>>>There must be more to it. As it is described the process does not fully
>>>>make sense. I'd like to understand exactly how it works.
>>>>
>>>> "If the last-received Group Policy update DNS name matches......" My
>>>> understanding of this is the reg key for Group Policy/History, which
>>>> contains the FQDN of the domain controller, so basically this just
>>>> means the DNS domain name that policies were received from. I'm not
>>>> sure if this really means the last-received (e.g a week ago if now off
>>>> the network).
>>>>
>>>> ".....any of the connection-specific DNS suffixes of the currently
>>>> connected connections on the computer". The Primary suffix of a domain
>>>> computer is the domain name, so it can't be that. The
>>>> connection-specific suffix is whatever the DHCP server handed out.
>>>> There are a few problems with this as it is defined:
>>>> - Mine is blank (Windows DHCP) yet the PC firewall knows it is on the
>>>> domain. It has to be using a different algorithm.
>>>> - XP clients don't need a connection-suffix to resolve names, so there
>>>> is no particular need for the DHCP to hand one out to them
>>>> - If I have two domains on the same network, which suffix would DHCP
>>>> hand out and which domain would then think it was or was not on the
>>>> network?
>>>> - It would be easy to fool the firewall with an incorrect DHCP assigned
>>>> suffix.
>>>>
>>>> The way the process is described only really works in one direction. If
>>>> a domain PC connects directly to the Internet, and if the ISP assigns a
>>>> connection suffix, the computer will know that it is not on the domain.
>>>> That seems a rather unreliable way to go about it. If the ISP does not
>>>> assign a connection suffix it would be blank, exactly as it is on my
>>>> network.
>>>>
>>>> Like I say, the process does not seem to make sense and I'd like to
>>>> understand how it really works.
>>>>
>>>> Anthony
>>>>
>>>>
>>>>
>>>>
>>>> "Steven L Umbach" <n9rou@nospam-comcast.net> wrote in message
>>>> news:OnPkfcB0FHA.2960@tk2msftngp13.phx.gbl...
>>>>> It can always be the same but I believe it compares it to the Group
>>>>> Policy update DNS name which would only be available if connected to
>>>>> the domain where a domain controller is available. The link below is
>>>>> from Microsoft documentation and though it specifies
>>>>> connection-specific DNS suffix it refers to DHCP option number 15
>>>>> which is the domain name and what you see in primary dns suffix in an
>>>>> ipconfig /all. Your problem with the particular computer may be due to
>>>>> it not authenticating to the domain at boot up and it used cached
>>>>> credentials instead to allow the user to logon and then as soon as it
>>>>> can contact a domain controller the user is authenticated to the
>>>>> domain. If it can not find a domain controller at startup Group Policy
>>>>> will not be applied and you may find an error reflecting that in the
>>>>> application log or for sure in the userenv.log file. --- Steve
>>>>>
>>>>>
>>>>>
>>>>> ***************************************************
>>>>> The network determination algorithm performs the following analysis:
>>>>>
>>>>> . If the computer is not a member of a domain, it is always
>>>>> attached to another network.
>>>>>
>>>>> . If the last-received Group Policy update DNS name matches any
>>>>> of the connection-specific DNS suffixes of the currently connected
>>>>> connections on the computer that are not PPP or SLIP-based, then the
>>>>> computer is attached to a managed network.
>>>>>
>>>>> . If the last-received Group Policy update DNS name does not
>>>>> match any of the connection-specific DNS suffixes of the currently
>>>>> connected connections on the computer that are not PPP or SLIP-based,
>>>>> then the computer is attached to another network.
>>>>>
>>>>>
>>>>> Windows uses this network determination process during start up and
>>>>> when it is informed by the Network Location Awareness service that
>>>>> network settings on the computer have changed.
>>>>>
>>>>> The connection-specific DNS suffix of the connection over which the
>>>>> last set of Group Policy updates were received is determined from its
>>>>> TCP/IP configuration, which is typically configured using Dynamic Host
>>>>> Configuration Protocol (DHCP) and the DNS Domain Name DHCP option
>>>>> (DHCP option number 15). You can also manually configure
>>>>> connection-specific DNS suffixes from the DNS tab in the advanced
>>>>> properties of the Internet Protocol (TCP/IP) component, available from
>>>>> the properties of the connection in the Network Connections folder.
>>>>>
>>>>>
>>>>>
>>>>> "Anthony Yates" <anthonyDINGyates@airDONGdesk.com> wrote in message
>>>>> news:Onwt0i9zFHA.1264@tk2msftngp13.phx.gbl...
>>>>>> It can't be the primary suffix, as that is always the same. There is
>>>>>> no point comparing that with anything if the computer is a member of
>>>>>> the domain. There must be a process for confirming whether the PC has
>>>>>> logged onto the domain. If the process is as described then it seems
>>>>>> a very unreliable way of knowing when you are off the domain.
>>>>>> We occasionally get a PC where you can't use Remote Assistance or
>>>>>> Remote Desktop until you reboot it. This seems to be caused by a
>>>>>> faulty determination by the firewall of whether the PC is on the
>>>>>> network or not. I don't mind if it only gets it wrong in one
>>>>>> direction - on when it should be off. I am worried if it gets it
>>>>>> wrong in the other direction - off when it should be on.
>>>>>>
>>>>>> Anthony
>>>>>>
>>>>>>
>>>>>>
>>>>>> "Steven L Umbach" <n9rou@nospam-comcast.net> wrote in message
>>>>>> news:OeJIKM2zFHA.2652@TK2MSFTNGP14.phx.gbl...
>>>>>>>I wonder if they really mean connection specific dns as that often if
>>>>>>>is not configured. The domain name is usually configured in the DHCP
>>>>>>>scope option 15 or even if you do not use DHCP when you run ipconfig
>>>>>>>/all on a domain computer you will see primary dns suffix which I
>>>>>>>believe is probably what is used. That is my guess and I can not
>>>>>>>confirm it. Possibly it could also have something to do with whether
>>>>>>>a domain controller can be contacted and used for authentication of
>>>>>>>the computer account or not. --- Steve
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> "Anthony Yates" <anthonyDINGyates@airDONGdesk.com> wrote in message
>>>>>>> news:ulQfTX0zFHA.3124@TK2MSFTNGP12.phx.gbl...
>>>>>>>> The Windows XP SP2 client is supposed to detect whether it is on or
>>>>>>>> off the domain network by comparing the connection-specific DNS
>>>>>>>> suffix to the last Group Policy.
>>>>>>>>
>>>>>>>> We do not assign a connection-specific DNS suffix in our (Windows)
>>>>>>>> DHCP. Yet the PC's recognise they are on the network and activate
>>>>>>>> the domain firewall policy. Can anyone confirm that there is a
>>>>>>>> smarter piece of logic in place, such as whether the PC connected
>>>>>>>> to the DC or not?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Anthony Yates
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

Relevant Pages

  • Re: DNS Disappears- Intermittently
    ... > not resolve some DNS names on the network. ... The default search suffix is the Primary DNS Suffix. ...
    (microsoft.public.windows.server.dns)
  • Re: XPSP2 domain firewall settings
    ... computer detects it is not on my regular network IP that is a trigger?? ... The Primary suffix of a domain ... > suffix is whatever the DHCP server handed out. ... > connection suffix, the computer will know that it is not on the domain. ...
    (microsoft.public.windowsxp.security_admin)
  • Re: DNS Disappears- Intermittently
    ... However for some reason they could not ... manually entered in the network settings, ... >> Yes that is what I was referring to (DNS Suffix). ...
    (microsoft.public.windows.server.dns)
  • How to lose "domain"/"primary DNS suffix"
    ... laptop so that my laptop was a member of ... I could access email & network drives. ... Nslookup showed that Computer2 was ... insists that some suffix be appended, ...
    (microsoft.public.windowsxp.network_web)
  • Re: Cant join domain: Network path was not found
    ... Your domain name now is hq.infotouchs.sys but your workstation ipconfig points to hq.infotouchsys.com as connection specific suffix. ... So i think you have to change the suffix in your DHCP server options settings to match. ... trying to join the domain 'hq.infotouchsys.com': Network path not ... I have a single server running as the primary domain controller (PDC) ...
    (microsoft.public.win2000.active_directory)