Re: XPSP2 domain firewall settings

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\C urrentVersion\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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

Well, it looks as though no one knows for sure how the network determination
is done!



"Anthony Yates" <anthony.spam@spammedout.com> wrote in message
news:%230WCekn0FHA.3756@tk2msftngp13.phx.gbl...
>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
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>