Slow active directory authentication across campus backbone

[Raymond Jean]

We have a building network in which users authenticate at login via
Netware Client32 to both Novell's eDirectory and to an Active
Directory domain. In our primary building, this works flawlessly.

We have one department located across our campus which connects to the
servers in our building via a highspeed campus fiber optic backbone.
Using the same client methodology, the users login quickly to the
Netware eDirectory, but there is a 15 minute (!?) delay before the
login to Active Directory is completed.

However, once the user has authenticated to AD, they are able to
browse all computers in the domain with no delay, so the problem
appears limited to the AD authentication process.

On a hunch, I tried removing WINS information from the TCP/IP
configuration (Windows 2000 workstation), and created an LMHOSTS file
which identified by IP address a particular domain controller. No
joy.

Any thoughts on how to solve and/or troubleshoot this problem?

Raymond Jean
Computing Services
Tulane Law School
New Orleans, LA

 

[Chriss3]

Rymond have you verify DNS is configure correct, This means you should be
avaiblel to ping the AD FQDN Domain Name from the clients and get response
from a Domain Controller.

 

[Paul]

It sounds like the dns is not set correctly for the
troubled users. Is dns set the same on machines that have
no trouble as compared to those that do? Also what about
your DC that is authenticating these, if they are going to
a different DC then see if the DC is also a GC.

Paul Bergson MCSE, MCT, CNE, CNA, CCA

 

[Raymond Jean]

Paul,

Yes, DNS is working just fine. We point them to the DNS
service running on our DCs, just as we do on the machines in our
primary building. I can ping the DCs by their AD name or FQDN.

Ray

 

[Paul]

Do they have access to a Global Catalog?

-----Original Message-----
Paul,

Yes, DNS is working just fine. We point them to the DNS
service running on our DCs, just as we do on the machines in our
primary building. I can ping the DCs by their AD name or FQDN.

.

 

[Raymond Jean]

Yes, they do have access to a GC. The image on the computers at the
remote site is identical to those in the primary building where the
delay is not experienced.

 

[Ace Fekay [MVP]]

In

Yes, they do have access to a GC. The image on the computers at the
remote site is identical to those in the primary building where the
delay is not experienced.

I hope you don't mean by "image" that they are Ghosted copies?


--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.
This posting is provided "AS IS" with no warranties.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory

 

[Ace Fekay [MVP]]

In

Paul,

Yes, DNS is working just fine. We point them to the DNS
service running on our DCs, just as we do on the machines in our
primary building. I can ping the DCs by their AD name or FQDN.

Ray

Are they ONLY pointing to the DC's DNS? (no ISP's or any other DNS that does
not have a copy of the AD zone). That can cause issues if you're mixing them
up.

Assuming that this is all one domain, are the zones on the DC/DNS AD
Integrated or have an exact copy of the zones at the primary
location? Do the SRV records for the domain exist? Are Sites defined? If so,
do the GCs show up in their respective Sites in the SRVs?


--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.
This posting is provided "AS IS" with no warranties.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory

 

[Raymond Jean]

Ace,

1) The primary and secondary DNS listings on the client computers
which are slow to authenticate are running on 2 of our DCs. We have a
3rd University DNS in the TCP/IP configuration which we placed there
in case of failure in our building - we will try removing it and
leaving just the 2 DNS entries poining to the 2 DC/DNS machines.

2) The zones on the DC/DNS are integrated and I can confirm that
the SRV records exist and that GCs appear correctly in DNS.

Ray

 

[Paul]

Any firewalls between the two sites?

Paul

-----Original Message-----
Yes, they do have access to a GC. The image on the computers at the
remote site is identical to those in the primary building where the
delay is not experienced.



.

 

[Raymond Jean]

On Fri, 5 Mar 2004 07:02:21 -0800, "Paul"

Not sure. The University is doing some filtering between the two
locations, so I can't be sure that this might not be part of the
problem.

If I can go to the University network administrator with a list of
ports necessary during the authentication process, I can get some
feedback.

I guess my fallback should it become necessary is to setup a VPN, but
I'd prefer not to add this level of complexity when traffic is fine
for all things Netware and for the Windows networking EXCEPT during
login/authentication.

 

[Paul]

This has got to be your main suspect right now. If they
need to know which specific ports need to be open then go
out to the knowledge base. They have port definitions.

If you can't find them send me an e-mail off line

(e-mail address removed)

Paul Bergson

 

[Raymond Jean]

Paul,

Thanks for taking the time to work with me on this. I've got
an inquiry into our campus network administrator and we'll work the
problem at this point as a firewall issue.

Regards,

Ray

Raymond Jean
Computing Services
Tulane Law School

 

[Raymond Jean]

To all who offered advice on this problem:

Thanks. We've finally solved the problem. Our campus network
administrator was blocking port 135 between the two sites. He
permitted traffic between the segment at the remote site and our 2
domain controllers here in the main building on port 135 and the
problem cleared up.

 

[Ace Fekay [MVP]]

In

To all who offered advice on this problem:

Thanks. We've finally solved the problem. Our campus network
administrator was blocking port 135 between the two sites. He
permitted traffic between the segment at the remote site and our 2
domain controllers here in the main building on port 135 and the
problem cleared up.

There we have it! Firewalls!


For future reference, here are the AD ports:

Q289241 - A List of the Windows 2000 Domain Controller Default Ports:
http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q289241&

Active Directory Replication over Firewalls - Microsoft Service Providers:
http://www.microsoft.com/SERVICEPROVIDERS/columns/config_ipsec_p63623.asp

154596 - HOWTO Configure RPC Dynamic Port Allocation to Work with Firewall:
http://support.microsoft.com/?id=154596

179442 - How to Configure a Firewall for Domains and Trusts:
http://support.microsoft.com/?id=179442

Download details Active Directory in Networks Segmented by Firewalls:
http://www.microsoft.com/downloads/...familyid=c2ef3846-43f0-4caf-9767-a9166368434e



--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.
This posting is provided "AS IS" with no warranties.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory