If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Hello Guest,Our records indicate that you have never posted to our site before! Why not make your first post today by saying hello to our community in our Introductions forum.

Please review the forums rules, start with your first post today and become an active part of petri.co.il forums now!

30 sec authentication delay to external trusted domain

19th November 2008, 03:16

Hi There

Domain A has a one way trusting external trust Domain B. These domains are in separate forests.
These domains are separated by firewalls etc, only the domain controllers have firewall rights to talk to each other.

If we jump on a member server in domain A and try to authenticate using domainB credentials, we get a 30 sec delay before authorisation finishes. (it does work successfully though)
If we try this same step on a DomainA domain controller, the authentication is instaneous.

things I have checked:
-I have confirmed that the member servers are pointing to the domain controller for DNS services. The domain controllers point to themselves for DNS
-DNS contains no incorrect SRV records or anything like that
-dcdiag tests come up fine
-I have run the trust verification option in AD domains and trusts.

questions:
-Is there a way to eliminate this delay?
-Does anyone know of a explanation somewhere of the authentication process at work here? I can find plenty of examples on technet about how a client in domainA would authenticate and get access to a resource in domainB, but nothing on how a domainA computer login using domainB credentials works.

Comment

I've done a packet trace
The server tries kerberos authentication directly to the external domain controller, since this traffic is blocked it gets no replies, so tries the other domain controller etc. this is where the delay is.
When it gives up trying kerberos it sends 4 rpc_netlogon packets to the local domain controller which is where the trace ends after working.
The packets are NetrLogonSamLogonEx request, NetrLogonSamLogonEx response, NetrLogonGetDomaininfo request, NetrLogonGetDomaininfo response,

So i'm guessing there are settings somewhere to force this behaviour and cut out kerberos