Explorer unresponsive when port 445 is blocked from client

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I originally posted this in Winodws Vista administration; I'm posting here
to encourage a response.

I experience unresponsiveness (also could be seen as slowdown) after joining
my Vista machines to the active directory. I experience it particularly when
I take an
AD-joined laptop and carry it to another location, such as a friend's house
or coffee shop. When I do this, and the provider (e.g. Comcast or T-Mobile,
because I know the problems occur there) blocks port 445 outgoing, the
symptoms will arise. In particular, any function that requires interaction
with Explorer (.exe) will take 30-90 seconds to complete. This includes, for
example, saving a downloaded file using Firefox. Because Firefox integrates
with Explorer to save files (I think to render the icons), when I try to save
a file using firefox in this environment, the download will block for 30-90
seconds before proceeding.

It seems to be that Explorer is blocking to perform some sort of Active
Directory action which requires port 445 (microsoft-ds) on which to
communicate. Explorer resolves a name for the AD action but must wait for
the TCP timeout to occur before returning control to the calling application.

I don't use isolated DNS, so my Active Directory DNS is visible from any
host on the Internet. I can see in other deployments why this symptom would
not arise -- because if the DNS were isolated, the host would not have an AD
server to attempt a connection, and thus would not have to wait for the TCP
timeout.

I would not be feasible for me to put an AD server at every location,
because I have about 2 PCs per location, so it's also difficult for me to
isolate the DNS.

This problem occurs with or without roaming profiles. It occurs on brand
new Vista machines recently joined to the domain. This problem also
exhibited itself to a lesser degree in Windows XP.

One work-around that often works is to establish a VPN connection to one of
the domain controllers. In this way, microsoft-ds traffic can pass
unobstructed, and the problem goes away immediately. Unfortunately, it's
cumbersome to instruct other users to establish a VPN connection to keep
their machine from becoming non-responsive.

This to me is clearly a design flaw or design oversight, or possibly just an
unsupported configuration.

I've applied all Windows Updates as well as kb941649, but the behavior
remains the same.

I would very much appreciate any suggestions for alleviating this problem.
I'm also happy to provide additional details if a Microsoft rep takes
interest in reproducing the problem.

Sincerely,
Jason R. Coombs
 
Are you saying that your AD dns server is visible to the world? If so that
is a bad idea and I'm guessing your workstation is attempting to talk to
services inside the firewall which your client can't reach (At least I hope
you have that all firewalled off). I would try to get a dns server address
from whatever dhcp service provides your client with an ip address. I could
be wrong but that sounds like where your problem is stemming from.

--
Paul Bergson
MVP - Directory Services
MCT, MCSE, MCSA, Security+, BS CSci
2003, 2000 (Early Achiever), NT

http://www.pbbergs.com

Please no e-mails, any questions should be posted in the NewsGroup
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Thanks Paul for the comments.

To clarify, yes, the AD dns server is visible to the world. I don't see
this as being a particularly bad idea. I don't have AD traffic firewalled
off, because I want to have Directory Services (single sign-on, etc)
available to the client machines regardless of where they're located. In
other words, the Internet is my intranet.

I'm using ISP-assigned DNS servers; my AD domain is also my Internet domain,
so when my machines want to authenticate to the domain, they query the
Internet domain servers, which forward the requests to the domain controllers.

This is the most straightforward and direct implementation of an AD domain
over a WAN. Again, I don't see a way to have an AD domain with unified
authentication and single-sign-on without
(a) having one domain controller that's globally accessible,
(b) having domain controllers at every site, or
(c) using VPN connections to tunnel.

(b) is impractical due to licensing costs of Windows Server and the fact
that I have 1-2 PCs per site. One laptop is primarily on the Internet
through Verizon wireless broadband (i.e. it's never on a private network).
(c) doesn't work in all cases, particularly if VPN traffic is blocked. I
believe I understand the security implications of choosing (a), but please
let me know if there's something inherently insecure about having domain
services exposed to untrusted hosts.

The problem is that my domain spans infrastructure over which I don't have
control, and in particular, Windows clients and Explorer don't degrade
gracefully when the AD DNS is available but port 445 traffic is disallowed.
Because port 445 is blocked arbitrarily, I don't have a good way to block AD
DNS requests from those networks.

I believe this is a limitation of Windows/Explorer and probably something
that could be addressed.

Nevertheless, I'm still open to suggestions that don't involve buying more
equipment.
 
Once I have better understood what you are attempting to do, I don't know a
way around other than vpn and I haven't worked with a system like what you
have setup. 2008 will provide rodc's which is being presented (From what I
understand) to be more of what you are attempting to accomplish.

--
Paul Bergson
MVP - Directory Services
MCT, MCSE, MCSA, Security+, BS CSci
2003, 2000 (Early Achiever), NT

http://www.pbbergs.com

Please no e-mails, any questions should be posted in the NewsGroup
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Back
Top