Sign in with
Sign up | Sign in
Your question

XPsp2 Firewall wrongly detecting domain/standard - DNS Suf..

Last response: in Windows XP
Share
January 12, 2005 4:47:17 AM

Archived from groups: microsoft.public.windowsxp.general,microsoft.public.windowsxp.security_admin (More info?)

Hi - Posted late yesterday same issue, but thinking it was Windows
Update hotfix related. It isn't. I can't post an update to the
thread as Google is erroring...! ;) 

But - now been able to perform more tests.

Basically, XPsp2 firewall settings set via GPO. On Domain, (DOMAIN
settings) firewall is off. Away from Domain (STANDARD settings)
firewall is on.

IPAutoConfiguration is DISABLED via GPO (e.g. laptops retain DHCP
address unless another DHCP server gives it new details. However, in
testing this we have tried with this both enabled and disabled, and to
be honest, doesn't make any differnce.

We thought XPsp2 detected whether to run in DOMAIN/STANDARD profile by
talking to a DC - but it just seems to check if the suffix domain name
is correct. We can prove this by setting IP manually, and then
setting connection specific suffix to "anyoldname.com" (STANDARD
Profile - firewall on) - and then to "mycompany.com" (DOMAIN Profile -
firewall off)

So as you can see, our thoughts of XPsp2 being clever to
enable/disable the firewall by itself isn't accurate enough to trust
(unless we are doing something wrong).

Machine "Primary DNS Suffix" is set via GPO to "mycompany.com"

The firewall is INCORRECTLY DISABLED under the following conditions
(proved by checking state and seeing it is running in DOMAIN mode)

* Plugged onto "private LAN" without DHCP server away from network.
IPAutoConfiguration being disabled means old DHCP settings are
retained, including DNS suffix - so firewall turns off. (okay - admit
this should not cause too many issues!)
* Plugged onto "private LAN" with DHCP server configured - but
publishing IP/SNM/GW only - not DNS suffix. With a blank DNS suffix
the client "defaults" to the "mycompany.com" suffix and hence disables
the firewall. (how? Does it default to Primary DNS Suffix?)

Any suggestions on how to sort this out? Clearly there may be (are!)
networks out there which do not publish a DNS suffix via DHCP (default
on some home use hardware firewalls)

PS - Having firewall enabled whilst on corporate LAN is not an option

THANKS!
Anonymous
January 12, 2005 7:06:22 PM

Archived from groups: microsoft.public.windowsxp.general,microsoft.public.windowsxp.security_admin (More info?)

RJ wrote:

> Hi - Posted late yesterday same issue, but thinking it was Windows
> Update hotfix related. It isn't. I can't post an update to the
> thread as Google is erroring...! ;) 
>
> But - now been able to perform more tests.
>
> Basically, XPsp2 firewall settings set via GPO. On Domain, (DOMAIN
> settings) firewall is off. Away from Domain (STANDARD settings)
> firewall is on.
>
> IPAutoConfiguration is DISABLED via GPO (e.g. laptops retain DHCP
> address unless another DHCP server gives it new details. However, in
> testing this we have tried with this both enabled and disabled, and to
> be honest, doesn't make any differnce.
>
> We thought XPsp2 detected whether to run in DOMAIN/STANDARD profile by
> talking to a DC - but it just seems to check if the suffix domain name
> is correct. We can prove this by setting IP manually, and then
> setting connection specific suffix to "anyoldname.com" (STANDARD
> Profile - firewall on) - and then to "mycompany.com" (DOMAIN Profile -
> firewall off)
>
> So as you can see, our thoughts of XPsp2 being clever to
> enable/disable the firewall by itself isn't accurate enough to trust
> (unless we are doing something wrong).
>
> Machine "Primary DNS Suffix" is set via GPO to "mycompany.com"
>
> The firewall is INCORRECTLY DISABLED under the following conditions
> (proved by checking state and seeing it is running in DOMAIN mode)
>
> * Plugged onto "private LAN" without DHCP server away from network.
> IPAutoConfiguration being disabled means old DHCP settings are
> retained, including DNS suffix - so firewall turns off. (okay - admit
> this should not cause too many issues!)
> * Plugged onto "private LAN" with DHCP server configured - but
> publishing IP/SNM/GW only - not DNS suffix. With a blank DNS suffix
> the client "defaults" to the "mycompany.com" suffix and hence disables
> the firewall. (how? Does it default to Primary DNS Suffix?)
>
> Any suggestions on how to sort this out? Clearly there may be (are!)
> networks out there which do not publish a DNS suffix via DHCP (default
> on some home use hardware firewalls)
Hi

If last-received Group Policy update DNS name match any of the
connection-specific DNS suffixes of the currently connected
connections (not PPP or SLIP-based) on the computer the FW's
domain settings will be used. There is no way to change this
behavior.

From
The Cable Guy - May 2004
Network Determination Behavior for Network-Related Group Policy Settings
http://www.microsoft.com/technet/community/columns/cabl...

<quote>
To apply this behavior to Windows Firewall settings:

() If the connection-specific DNS suffix of a currently connected
connection on the computer that is not PPP or SLIP-based (such as
an Ethernet or 802.11 wireless network adapter) matches the value
of the
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Group
Policy\History\NetworkName registry entry, Windows Firewall uses
the domain profile.

() If the connection-specific DNS suffix of a currently connected
connection on the computer that is not PPP or SLIP-based does not
match the value of the
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Group
Policy\History\NetworkName registry entry, Windows Firewall uses
the standard profile.

You can determine the connection-specific DNS suffixes of the
currently connected connections on the computer from the display
of the ipconfig command issued from a command prompt.

</quote>

Read the Cable Guy article for more about this.



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