XPSP2 domain firewall settings

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

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" wrote in message
...
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

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" wrote in message
...
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" wrote in message
...
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

Anthony Yates wrote:

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.

Hi,

The determination process is described in this article:

The Cable Guy - May 2004
Network Determination Behavior for Network-Related Group Policy Settings
http://www.microsoft.com/technet/com...uy/cg0504.mspx


--
torgeir, Microsoft MVP Scripting, Porsgrunn Norway
Administration scripting examples and an ONLINE version of
the 1328 page Scripting Guide:
http://www.microsoft.com/technet/scr...r/default.mspx

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" wrote in message
...
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" wrote in message
...
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" wrote in message
...
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

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" wrote in message
...
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" wrote in message
...
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" wrote in message
...
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" wrote in message
...
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

Torgeir,
I have read this but it does not add up. My DHCP assigned DNS domain name is
blank and the clients know they are on the domain.
Regards,
Anthony

"Torgeir Bakken (MVP)" wrote in message
...
Anthony Yates wrote:

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.

Hi,

The determination process is described in this article:

The Cable Guy - May 2004
Network Determination Behavior for Network-Related Group Policy Settings
http://www.microsoft.com/technet/com...uy/cg0504.mspx


--
torgeir, Microsoft MVP Scripting, Porsgrunn Norway
Administration scripting examples and an ONLINE version of
the 1328 page Scripting Guide:
http://www.microsoft.com/technet/scr...r/default.mspx

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\Curr entVersion\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" wrote in message
...
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" wrote in message
...
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" wrote in message
...
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" wrote in message
...
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" wrote in message
...
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

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" wrote in message
...
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\Cur rentVersion\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" wrote in message
...
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" wrote in message
...
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" wrote in message
...
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" wrote in message
...
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" wrote in message
...
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

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" wrote in message
...
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" wrote in message
...
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\Cu rrentVersion\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" wrote in message
...
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" wrote in message
...
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" wrote in message
...
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" wrote in message
...
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" wrote in message
...
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

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" wrote in message
...
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" wrote in message
...
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" wrote in message
...
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" wrote in message
...
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" wrote in message
...
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" wrote in message
...
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" wrote in message
...
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" wrote in message
...
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" wrote in message
...
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" wrote in message
...
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" wrote in message
...
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" wrote in message
...
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" wrote in message
...
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" wrote in message
...
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" wrote in message
...
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" wrote in message
...
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" wrote in message
...
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