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